• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 99 subscribers
  • Views 1229 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: TI HS-SE-TIDK sample boot from UART issue

Raymond Zhang2
Intellectual 300 points

Part Number: TDA4VM

Dear TI experts:

We are developing an ECU powered by TI TDA4 / XJ721E SOC. Everything is fine with the General Purpose chip samples.

As our board doesn't have SD slot, we have to boot the SOC through the UART X-Modem at the very beginning. Now we are switching to the High-Secure-SE-TIDK sample, but we cannot bring it up from UART.

We confirm that we have configured the strap pins of boot mode correctly <boot from uart>, because we can boot the board with GP sample successfully through UART.

---------------------------------------See below successful logs, with the GP samples ---
TDA4_EMMC$ stty -F ${MCU_UART} raw 115200 -crtscts cs8 -cstopb
TDA4_EMMC$ sb -vvvvvvvvvvvvvvvvvvvvvvvvvv -k --xmodem tiboot3.bin > ${MCU_UART} < ${MCU_UART}
sb 0.12.21rc
mode:1
Sending tiboot3.bin, 963 blocks: Give your local XMODEM receive command now.
wctx:file length=123339
Xmodem sectors/kbytes sent: 0/ 0kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 8/ 1kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 16/ 2kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 24/ 3kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 32/ 4kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
... ...
Xmodem sectors/kbytes sent: 963/120kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Calling read: alarm=60 Readnum=128 Read returned 32 bytes
06 0d 0d 0a 4d 69 6e 69 42 6f 6f 74 20 52 65 76 69 73 69 6f 6e 3a 20 30
31 2e 30 30 2e 30 39 2e
Bytes Sent: 123392 BPS:5750
mode:0
Transfer complete

However, while we switch to the board with HS-SE-TIDK samples, the uart data link seems broken or halted after only a small part of data transferred.

-------------------------------See below failed logs, with HS-SE-TIDK samples ----
$ sb -vvvvvvvvvvvvvvvvvvvv -k --xmodem tiboot3.bin > ${MCU_UART} < ${MCU_UART}
sb 0.12.21rc
mode:1
Sending tiboot3.bin, 1827 blocks: Give your local XMODEM receive command now.
wctx:file length=233920
Calling read: alarm=60 Readnum=128 Read returned 1 bytes
00
Calling read: alarm=60 Readnum=128 Read returned 1 bytes
43
Xmodem sectors/kbytes sent: 0/ 0kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 8/ 1kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 16/ 2kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 24/ 3kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 32/ 4kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 40/ 5kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 48/ 6kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 56/ 7kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 64/ 8kCalling read: alarm=60 Readnum=128 Read returned 1 bytes
06
Xmodem sectors/kbytes sent: 72/ 9kCalling read: alarm=60 Readnum=128


We change different boards and different chip samples, the issue always happens. Do you know what the problem might be? Is there any constrains for HS-SE chipset to handle the X-Modem data, or is there any special verification flows for the HS-SE samples in the R5 BootROM?

For your information, the tiboot3.bin image has been signed by the "pdk_jacinto_07_00_00/packages/ti/build/makerules/k3_dev_mpk.pem".

----------------------- Attach the x509 info FYI ----
TDA4_EMMC$ openssl x509 -in tiboot3.bin -inform der -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 17778271195802784235 (0xf6b91b75926251eb)
Signature Algorithm: sha512WithRSAEncryption
Issuer: C=US, ST=SC, L=Dallas, O=Texas Instruments., Inc., OU=PBU, CN=Albert/emailAddress=Albert@ti.com
Validity
Not Before: Sep 7 12:57:34 2020 GMT
Not After : Oct 7 12:57:34 2020 GMT
Subject: C=US, ST=SC, L=Dallas, O=Texas Instruments., Inc., OU=PBU, CN=Albert/emailAddress=Albert@ti.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:bf:14:ae:49:d8:7f:72:d3:6b:23:cd:eb:48:0e:
65:dc:22:4d:f2:0e:4f:82:f6:ed:b5:f2:dd:db:7c:
91:fa:6e:59:ff:d5:f7:b6:de:04:1d:8a:cc:d2:95:
d9:d1:e0:c4:c1:f8:50:bf:ff:48:0c:91:22:50:9a:
4c:7b:8b:f3:96:0a:28:26:b3:a4:d9:e0:a9:55:41:
1a:fb:3e:5b:27:6c:bf:ca:c0:71:af:2f:72:22:ee:
46:01:25:62:ad:3e:c7:04:f6:b1:18:b6:2c:c0:12:
6e:0f:e2:9b:3e:e5:a6:a0:a8:06:45:03:41:17:4e:
16:1f:a9:74:d6:84:4e:d6:79:a7:10:b8:11:a9:0e:
92:1f:25:dd:7f:b1:f2:d1:b9:f2:68:d8:33:59:4b:
82:7d:77:cc:d1:9c:fa:23:b4:fb:58:88:f2:cd:ea:
d5:16:f2:2c:75:2d:fa:62:c3:c1:09:6e:e0:06:70:
e0:b5:07:09:99:62:d9:d6:e4:e7:6c:6d:c8:82:07:
50:93:f7:e2:d8:ed:d1:5f:e3:d0:9e:cf:93:54:d9:
5f:dd:5d:ce:37:60:f1:ab:14:8a:04:7b:65:a7:ba:
7f:df:45:45:7c:4b:a1:5b:ae:4e:c6:94:3d:8c:4e:
87:d2:94:3c:a4:f3:9f:da:fc:f2:36:7c:e7:0d:ad:
5a:42:37:f1:2a:81:d0:6e:a1:a7:67:03:1e:87:ed:
00:bb:73:4a:68:28:31:a2:82:9a:a3:04:c1:e8:87:
ff:45:7e:aa:c1:9f:d4:3b:05:c7:83:fd:21:71:fe:
bd:7f:38:c9:16:19:52:0e:e6:03:33:8d:1d:1e:c9:
36:1c:cd:4e:9d:82:29:88:cd:9b:2a:be:6c:5f:7b:
b2:b2:3a:79:00:6a:7d:f5:ad:1a:9d:1e:cd:58:2a:
cf:5e:f4:4e:80:ab:3b:4f:dd:f8:d4:de:34:a2:c4:
20:d9:59:19:2d:85:02:5e:1f:68:b1:4c:8d:b9:11:
06:e9:2d:76:b5:58:8c:50:a8:37:6e:66:78:6f:83:
30:46:4d:34:9f:b4:18:4a:b9:bb:fa:7b:c5:ae:d6:
32:10:84:84:6c:3f:9a:80:33:35:fc:4d:bc:d5:6e:
60:54:50:cf:7e:6d:80:97:04:fa:8f:0b:20:fd:bd:
98:2b:a1:37:bd:59:fd:4a:ec:45:a1:09:8b:17:c9:
72:14:33:b7:05:5e:12:5d:e2:5a:1d:ce:21:54:f6:
e1:ea:d5:55:aa:27:eb:4d:09:df:19:40:82:2e:66:
89:17:65:d9:6e:b3:d6:38:4e:8d:61:16:d6:74:d4:
de:16:5f:51:19:d5:42:b8:83:d2:c8:de:4b:a9:69:
97:b6:8d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE
1.3.6.1.4.1.294.1.3:
0....
1.3.6.1.4.1.294.1.34:
0R..`.H.e.....@.\.{.@.o..8l...)9O.Eo8..vg.m..N...e.#.[...r*`.c.....1...&..T..N......
1.3.6.1.4.1.294.1.35:
0...A......
1.3.6.1.4.1.294.1.1:
0............A........
1.3.6.1.4.1.294.1.2:
0M..`.H.e.....@.\.{.@.o..8l...)9O.Eo8..vg.m..N...e.#.[...r*`.c.....1...&..T..N.
1.3.6.1.4.1.294.1.8:
0+. .........................................
Signature Algorithm: sha512WithRSAEncryption
04:a0:c7:6d:01:63:d2:e5:97:ff:71:33:71:00:e8:47:7b:b1:
77:07:fb:0f:fc:f1:7f:6a:6a:63:6b:b8:12:ce:08:16:1e:db:
b7:22:b8:3f:ed:db:65:7a:bd:70:a3:7e:02:39:32:a0:0a:eb:
6b:58:68:ab:34:38:22:ca:ba:2e:4c:00:2e:0e:1b:b4:84:e5:
28:44:f0:4b:f2:1a:c4:5b:af:73:76:31:c9:45:b3:3d:c9:8a:
a5:69:97:bb:0d:bd:24:3a:5e:eb:5b:4a:1a:d5:b8:8f:b2:8a:
11:e9:12:2f:0c:36:ba:62:09:88:64:c8:34:12:3b:cc:16:0e:
52:1f:dc:c8:09:56:c4:d6:06:a8:f7:b3:bc:9b:ba:f1:29:6c:
92:64:76:92:da:d5:35:1d:3e:24:34:6f:18:f0:8e:a8:21:98:
8a:8f:95:7f:d8:ee:eb:db:3f:24:dc:55:5d:03:ff:da:5f:7f:
76:0d:2f:ce:81:84:a0:d6:72:63:25:d5:99:e4:f3:ad:32:b4:
a5:4e:58:94:7d:9d:3b:ae:88:4c:c0:9f:c3:8c:41:1f:59:16:
31:22:53:cb:f0:65:41:10:5d:70:48:40:49:c4:8b:b5:fc:f4:
2e:db:3a:93:c7:33:a8:69:4f:34:c5:f7:4e:7e:56:b5:cf:69:
a7:86:93:9c:c1:97:7a:f0:e2:9a:00:66:05:9e:94:9c:08:e7:
db:58:47:3c:b6:e0:d3:90:2d:f7:df:b2:0d:6c:01:d7:48:52:
db:13:71:da:21:c4:c7:83:6c:bc:f3:e5:f9:15:47:fd:b0:d6:
40:86:1c:f3:b0:9c:3a:51:b3:16:fe:b9:b8:40:6a:da:c7:7b:
0d:a6:81:90:f7:fa:1f:df:67:5b:34:87:4d:0e:61:ea:68:a7:
99:5c:a0:11:8f:9c:33:fd:d7:44:1c:be:ea:50:df:cd:b9:9f:
00:51:c6:a4:bc:65:88:39:00:0e:8b:d7:c9:59:1b:18:c3:74:
bb:2e:77:f5:81:e1:5d:57:62:71:78:60:67:86:2d:bb:98:cd:
2d:2f:3a:10:76:78:44:ea:f2:c3:0a:17:f7:c5:26:45:21:91:
8a:71:cc:51:8d:06:b8:18:af:62:b3:f0:26:ee:d4:5a:ca:2c:
df:8a:75:e7:1f:db:ef:6a:65:c8:54:99:dd:68:28:b7:c9:7c:
99:ef:50:ff:39:af:6b:d8:3e:8b:57:e5:71:7e:6d:b8:29:9d:
11:2e:5e:c2:11:7c:64:31:58:a2:e9:65:b9:b0:56:08:28:9d:
fe:99:de:4a:07:c1:24:4d:52:60:cd:a1:63:16:f7:6f:28:d1:
b9:93:9b:1e:8d:1e:44:6a

Regards,
Raymond.

  • 0
    TI__Expert 5725 points

    Hi Raymond,

    UART boot mode is supported on this device type. If you are seeing issues with xmodem transfer halting, it is likely due to authentication failure in the certificate header for the binary.

    Is your boot image based on PDK SBL or is it Linux/u-boot based? Can you please describe the procedure you are using to build your HS-SE image to boot?

    Thanks,
    Stephen

  • 0 in reply to Stephen Molfetta
    Intellectual 300 points

    Hi Stephen,

    Many thanks for your quick reply. My 1st boot image (tiboot3.bin) is Linux/u-boot based (i.e, the r5-uboot-spl), and then it is signed with the "pdk_jacinto_07_00_00/packages/ti/build/makerules/k3_dev_mpk.pem". 

    Today we move a little bit forward than yesterday -- we found an interesting and weird issue:

    Yesterday we configured the Primary Boot Mode to be EMMC and the Backup Boot Mode is UART. As our EMMC is empty, so it boots from the UART as I showed you in the above logs. However, the x-modem transfer halts after only partial data are transferred. You said it's likely due to the certificate header authentication failure. At first I guessed so as you, but in fact it is not true.

    Because today we configure the Primary Boot Mode to be UART directly and the Backup Mode is still UART, the same tiboot3.bin are transferred completely through X-modem and it run successfully !! The tiboot3 can further loads sysfw.itb through Y-modem, but it seems the sysfw.itb authentication failure.

    ------------------------------See the logs printed by tiboot3.bin ---

     k3_sysctrler_load_response: Firmware certificate authentication failed.

    So now we have 2 questions:

    1. Why with same device/uart cable/firmware etc, the x-modem transfer halts after a while, when we configure EMMC as Primary boot and UART as the Backup boot? This boot mode configuration works well in the GP devices. (Note that we cannot configure the boot pins in the field products). 

    2. Where can we get the authenticated sysfw.itb for the HS device?

    Thanks for your support !

    Regards.

    Raymond.

  • 0 in reply to Raymond Zhang2
    Intellectual 300 points

    Hi Stephen,

    I forgot to describe the procedures to build tiboot3.bin. It's made by following steps and it works:

    cd board-support/u-boot-2020.01+gitAUTOINC+f9b0d030d3-gf9b0d030d3

make mrproper; 
make ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- j721e_hs_evm_r5_defconfig O=output/r5 
make ARCH=arm CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf- O=output/r5 KEY=~/psdk_rtos_auto_j7_07_00_00_11/pdk_jacinto_07_00_00/packages/ti/build/makerules/k3_dev_mpk.pem

    Now the sysfw.itb verification is failed, so I'm trying to build the sysfw image by:

    cd sdk7.0/ti-processor-sdk-linux-automotive-j7-evm-07_00_00
make sysfw-image HS=1

    But It gives an error that TI_SECURE_DEV_PKG should be set for HS. We don't have such TI_SECURE_DEV_PKG.

    =============================
Building SYSFW Image
=============================
make[1]: Entering directory '/home/dji/work/sdk7.0/ti-processor-sdk-linux-automotive-j7-evm-07_00_00/board-support/k3-image-gen-2020.04a'
Makefile:56: TI_SECURE_DEV_PKG should be set for HS, defaults may not work

    Could you tell us how we could get or generate the sysfw.itb for the HS device?

    Regards,
    Raymond.

  • 0 in reply to Raymond Zhang2
    TI__Expert 5725 points

    Hi Raymond,

    Thanks for providing the detailed response. This is very helpful in determining the next steps.

    On question #1, I will have to double-check this on my end to see if I can reproduce and/or better explain

    On question #2, I will have to get somebody more familiar with Linux SDK to chime in. With that recipe, hopefully that will unblock in the near term until we can figure out the issue with #1.

    -Stephen

  • 0 in reply to Stephen Molfetta
    TI__Expert 6596 points

    Raymond,

    w.r.t HS signing , i followed these steps and was able to build the signed image with the expected keys.

    Download the secdev:

    git clone git://git.ti.com/security-development-tools/core-secdev-k3.git

    export TI_SECURE_DEV_PKG=<path>/core-secdev-k3

    Download the K3-image-gen:

    git clone git://git.ti.com/k3-image-gen/k3-image-gen.git -b 07.00.00.005
    cd k3-image-gen
    make ARCH=arm64 CROSS_COMPILE=<path_to_tc>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- SOC=j721e HS=1

    This should generate the needed signed sysfw.itb file ( copy in the prefered boot method thru uart or MMC/SD boot partition)

    --

    sidenote-1:

    If you see any boot issues, rebuild sysfw.itb as the following and send sysfw log (it should be on a different 

    make ARCH=arm64 CROSS_COMPILE=<path_to_tc>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- SOC=j721e HS=1 ENABLE_TRACE=1

    sidenote-2:

    if you see any proxy issues download the hs binaries in k3-image-gen repo as follows and then reissue the mentioned build command.

    wget --no-proxy  https://git.ti.com/processor-firmware/ti-linux-firmware/blobs/raw/c8decf64be551dfd1244cd1d231a97eb2255fb80/ti-sysfw/ti-sci-firmware-j721e-hs-cert.bin

    wget --no-proxy https://git.ti.com/processor-firmware/ti-linux-firmware/blobs/raw/c8decf64be551dfd1244cd1d231a97eb2255fb80/ti-sysfw/ti-sci-firmware-j721e-hs-enc.bin 

    ---

  • 0 in reply to Praneeth Bajjuri
    Intellectual 300 points

    Dear Stephen,

    Thank you very much for the solution! It works!!

    With the core-secdev-k3 package, we successfully pass the sysfw/bl31/bl32/tispl/uboot authentications. Now we boot the device to the uboot, having a working uboot command shell. Thanks a again!

    So now we still have the boot mode issue unsolved (the question #1), please help to clarify ^_^.

    Regards

    Raymond.

  • 0 in reply to Raymond Zhang2
    Intellectual 300 points

    Hi Stephen,

    It seems this ticket has been marked as "Resolved" (Maybe because I clicked the green button "This resolved my issue" in your reply).

    But in fact, we still have the boot mode issue (the question #1) unsolved, are you still checking this? Can we still trace this issue in this "Resolved" ticket, or should I open another new ticket for it?

    ---------------------------------------------------------------------

    1. Why with same HS device/uart cable/firmware etc, the x-modem transfer halts after a while when we configure EMMC as Primary boot and UART as the Backup boot? This boot mode configuration works well in the GP devices but it doesn't work in HS devices. (Note that we cannot configure the boot pins in the field products). 

    ---------------------------------------------------------------------

    Regards,

    Raymond

  • 0 in reply to Raymond Zhang2
    TI__Guru**** 170880 points

    Hi Raymond,

    Have you tried UART as primary boot mode on the HS device? Is it working for you?
    Can you please try that?


    Best Regards,
    Keerthy

  • 0 in reply to Keerthy J
    Intellectual 300 points

    Hi Keerthy,

    Yes, we tried. It is working if we configure UART as the primary boot mode on the HS device.

    Moreover, it is also working if we configure the EMMC as primary and UART as the backup on the GP device.

    It's not working if we configure the EMMC as primary and UART as the backup on the HS device.

    Regards,

    Raymond

  • 0 in reply to Raymond Zhang2
    TI__Guru**** 170880 points

    Raymond,

    Thanks for the information. I will check with the internal teams and get back. I believe
    for tracking purpose it would be best if you can resolve this thread and create a new one
    as this shows up as resolved from the other question's resolution.

    Best Regards,
    Keerthy

  • 0 in reply to Keerthy J
    Intellectual 300 points

    Thanks Keerthy,

    Yes, I have created a new thread in the e2eprivate security group yesterday, no one has responded yet. It seems I cannot paste the private link here.

    #Removing private e2e link

    I will resolved this thread and open a new if you cannot access the above link.

    Regards,

    Raymond.