TDA4VM-Q1: TDA4VM-Q1: TDA4VM88T5BALFQ1: SR1.1: HS-FS: How to build and flash KeyWriter

Hi, Suman,

Thanks for your support!

As you said before, hs-fs device was supported at sdk 9.0+, it means that if i try to build keywritter app at sdk 8.4,  It definitely won't work？

BRs.

Tahm

Should I try below ways:

1 build keywriter app at 9.1 sdk

2 change the keywriter app file name to tiboot3.bin, and copy to SD card /BOOT

3 and boot from SD card and flash the dummy key, change the the device form HS-FS -> HS-SE-TIDK

4 encrypt and signed the boot images at 8.4 sdk env, and then verify the secure boot

BRs.

Hi  Xie 

Please refer to the one of the older response on keywrter test application in pdk.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1335355/j784s4xevm-secure-boot-question-about-tda4vh-platform-j784s4xevm/5084166#5084166

Do let us know if you still have any further question on this.

Regards
Diwakar

Hi, Diwakar,

My sdk version is linux 8.4. 

I got the OTP_KEYWRITER_ADD_ON_j721e_sr1_1_v2021.05b-linux-installer.run, and install the add on package in my workspace.

${PDK_PATH} = ../../../../../../../psdkra/pdk_jacinto_08_04_00_21

1. cp addon/ti_fek_public.pem  ${PDK_PATH}/pdk_jacinto_08_04_00_21/packages/ti/boot/keywriter/scripts/

2. cp addon/ti-fs-keywriter.bin  ${PDK_PATH}/pdk_jacinto_08_04_00_21/packages/ti/boot/keywriter/tifs_bin/j721e/

3. ./gen_keywr_cert.sh -g && rm keys/smpk.pem keys/smek.key 

4. cp ${PDK_PATH}/packages/ti/build/makerules/k3_dev_mpk.pem ${PDK_PATH}/packages/ti/boot/keywriter/scripts/keys/smpk.pem

5. xxd -p -r ${PDK_PATH}/packages/ti/build/makerules/k3_dev_mek.txt ${PDK_PATH}/packages/ti/boot/keywriter/scripts/keys/smek.key

6. cp ${PDK_PATH}/packages/ti/boot/keywriter/scripts/ti_fek_public.pem ${PDK_PATH}/packages/ti/boot/keywriter/scripts/keys/tifekpub.pem

7.     cd ${PDK_PATH}/packages/ti/boot/keywriter/scripts/
    ./gen_keywr_cert.sh -s keys/smpk.pem --smek keys/smek.key -t keys/tifekpub.pem -a keys/aes256.key

8. cd ${PDK_PATH}/packages/ti/build
    make keywriter_img_clean -j8
    make keywriter_img -j

9. cp {PDK_PATH}/packages/ti/boot/keywriter/binary/j721e/keywriter_img_j721e_release.tiimage /home/media/BOOT/tiboot3.bin

and then boot from SD card, and the MCU UART has no output, is there something wrong in my operation?

BRs.

Tahm

Hi, Diwakar,

I found the keywriter build will fail when i use the ti-fs-keywriter.bin from addon package.

BRs. 

Tahm

Hi, Diwakar,

I download https://www.ti.com/tool/download/PROCESSOR-SDK-RTOS-J721E/08.00.00.12, and replace the patch: https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-bA0wfI4X2g/08.00.00.12/keywriter_patch.tar.gz

use the same proccess to build, now the build is ok, but still no output from the MCU_UART, can you give me some help?

BRs.

Hi Xie,

The KeyWriter build image failure is due to a result of insufficient linker section placements, which should have already been fixed in a later SDK release.

Rather than going back to 8.0 SDK, I recommend that you move to the last SDK in the 8.x SDK stream - 8.6.1.

Your steps look ok overall, though I would recommend you to not rename the ti_fek_public.pem.

Are you trying this on TI EVM or your custom board? Do you have MCU and WKUP UARTs available on your board? Are you sure the board is in SDCard bootmode?

regards

Suman

Hi, Suman,

Suman Anna said:

Rather than going back to 8.0 SDK, I recommend that you move to the last SDK in the 8.x SDK stream - 8.6.1.

I will try this sdk

Suman Anna said:

Are you trying this on TI EVM or your custom board? Do you have MCU and WKUP UARTs available on your board? Are you sure the board is in SDCard bootmode?

I am trying on our custom board, the WKUP UART is ok, and the bootmode is sdcard mode(because we can boot using other company's software(black box))

BRs

Hi，Suman, 

the build is ok on 8.6 sdk, but still no output from MCU_UART

BRs

Hi, Suman,

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1329098/dra829v-keywriter---otp-follow-up-questions?tisearch=e2e-sitesearch&keymatch=keywriter%25252520no%25252520ouput#

should I check VP_EFUSE before run keywriter?

BRs.

Hi Xie,

Yes. The KeyWriter application may need customization depending on how the VP_EFUSE is controlled on your board.

You would need to compare your board schematics against TI EVM's to see if there are differences in how the VP_EFUSE is controlled from PMIC or discrete regulator, and if they are using the same I2C addresses and GPIO pins etc.

regards

Suman

Hi, Suman, 

I think there should show the keywriter version before VP_EFUSE pulled to 1.8v,  am i right?

BRs

Hi Xie,

xie jc said:

I think there should show the keywriter version before VP_EFUSE pulled to 1.8v,  am i right?

Yes, it should.

Are you using the same pins for MCU UART on your board as the TI EVM? Also, are you seeing any traces on Wkup UART at all or not? If you are not seeing any traces, the image may not have been booted at all.

I will recommend that you connect to the MCU1_0 core using debugger and see where it is stuck at, to get an idea. 

regards

Suman

Hi, Suman,

Suman Anna said:

Are you using the same pins for MCU UART on your board as the TI EVM?

Yes.

Suman Anna said:

are you seeing any traces on Wkup UART at all or not? If you are not seeing any traces, the image may not have been booted at all.

I can not see any trace from the MCU UART.  the keywriter app we are using run at another project board, it can show the keywriter version. 

Suman Anna said:

I will recommend that you connect to the MCU1_0 core using debugger and see where it is stuck at, to get an idea. 

I connect the board to the ccs, and try to load keywriter app to MCU1_0, get below prompt:

BRs

Hi, Suman,

I have considered the following possible reasons:

1. Keywriter was not executed at all, so there is no log on the serial port.
   Possible reasons:
                ① The firmware format compiled may be incorrect - I placed the same Keywriter app in another project with an hs-fs chip (not the hardware we developed), and could see version number printing, indicating that the software format should be fine.
                ② Incorrect bootmode - The hardware board we are currently debugging is produced by another company. We can run tiboot3.bin, which is compatible with TI EVM (GP) board, and can also boot from an SD card. Moreover, SBL printing can be seen on MCU_UART, indicating that the serial port is default and not modified. This also confirms that there is no issue with the bootmode.

What other reasons could cause Keywriter not to be loaded or not to run? This phenomenon is really strange.

BRs

Hi Xie,

xie jc said:

I connect the board to the ccs, and try to load keywriter app to MCU1_0, get below prompt:

No, you cannot load the KeyWriter application from within CCS when you are already trying to run it.

When you run the KeyWriter application, just connect to CCS and check where the PC for MCU_R5F is? The PC should be in 0x41Cxxxxx something (MCU SRAM) and not in 0x418xxxxx (MCU ROM).

xie jc said:

What other reasons could cause Keywriter not to be loaded or not to run? This phenomenon is really strange.

Both of your reasons seem sane.

Are you sure the board you are trying to run is a HS-FS device? Can you put your board into UART bootmode, and check the output of MCU and WKUP UARTs? You should see a hex string printed on one of the UARTs.

regards

Suman

Hi, Suman,

Suman Anna said:

No, you cannot load the KeyWriter application from within CCS when you are already trying to run it.

When you run the KeyWriter application, just connect to CCS and check where the PC for MCU_R5F is? The PC should be in 0x41Cxxxxx something (MCU SRAM) and not in 0x418xxxxx (MCU ROM).

check below picture. 

Suman Anna said:

Both of your reasons seem sane.

Are you sure the board you are trying to run is a HS-FS device?

This is the chip silk screen

Suman Anna said:

Can you put your board into UART bootmode, and check the output of MCU and WKUP UARTs? You should see a hex string printed on one of the UARTs.

sorry, I can not do this until i get the board schematic. (*/ω＼*)

Hi, Suman, 

Is there a register to get the boot mode status or to check the ROM code run status?

BRs

Hi. Suman,

We found that the chip model with log output when running keywriter is XJ721E5BALF, and the chip model without log output is TDA4VM88T5BALFQ1. They both use the same keywriter software. Are there any differences between these two chips?

Thanks

Hi Xie,

XJ721E5BALF is the pre-production superset part, while TDA4VM88T5BALFQ1 is the proper production part. The TI EVMs use the superset part, while customers go to production using the production parts.

They both are type 5, so are both HS-FS devices. The KeyWriter functionality is agnostic of pre-production or production parts, it works in the same fashion on both the devices.

xie jc said:

Is there a register to get the boot mode status or to check the ROM code run status?

The Boot Mode will be captured in a CTRL_MMR register. 

regards

Suman

Hi, Suman,

Thank you for the clarfication.

We found someone else had met the same problem as us:https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1342715/tda4vm-hs-fs-variant-does-not-boot 

Is there any way to troubleshoot this problem?

Thanks

Hi Xie,

The referenced thread is about booting on a HS-FS device.

xie jc said:

Is there any way to troubleshoot this problem?

I have given all the base checklist. You need to check the UART bootmode output to ensure that your sample is properly seated/soldered.

I suspect your board may not be in proper boot-mode. Can you boot a HS-FS bootloader on your board?

Read the register CTRLMMR_WKUP_DEVSTAT register and ensure that the board is in proper boot-mode.

regards

Suman

Hi, Suman,

Thank you for your patient support.

Here are the register information read after I used another company's software to enable the HS-FS board to boot from an SD card.

sbl log:

SBL Revision OSPI: 01.00.10.00
TIFS  ver: 20.8.5-w2020.23-am64x-14-g7409e
current TDA4 is not flashed key: HSFS
 --> DDR material: EI11100020 MT53E1G32D2FW-046 AAT:B
Starting Sciserver..... PASSED

MCU R5F App started at 0 usecs
Calling Sciclient_procBootRequestProcessor, ProcId 0x6...
Calling Sciclient_procBootRequestProcessor, ProcId 0x7...
Loading BootImage

 MMCBootImageLate: fp 0x 0x41cc9428, fileName is 0:/lateapp1

 Called SBL_MulticoreImageParse, status = 0
BootImage completed, status = 0
Sciclient_procBootReleaseProcessor, ProcId 0x6...
Sciclient_procBootReleaseProcessor, ProcId 0x7...
SBL_SlaveCoreBoot completed for Core ID#6, Entry point is 0x0
SBL_SlaveCoreBoot completed for Core ID#7, Entry point is 0x0
Calling Sciclient_procBootRequestProcessor, ProcId 0x8...
Calling Sciclient_procBootRequestProcessor, ProcId 0x9...
Calling Sciclient_procBootRequestProcessor, ProcId 0x3...
Calling Sciclient_procBootRequestProcessor, ProcId 0x4...
Calling Sciclient_procBootRequestProcessor, ProcId 0x30...
Loading BootImage

 MMCBootImageLate: fp 0x 0x41cc9428, fileName is 0:/lateapp2

 Called SBL_MulticoreImageParse, status = 0
BootImage completed, status = 0
Sciclient_procBootReleaseProcessor, ProcId 0x8...
Sciclient_procBootReleaseProcessor, ProcId 0x9...
Sciclient_procBootReleaseProcessor, ProcId 0x3...
Sciclient_procBootReleaseProcessor, ProcId 0x4...
Sciclient_procBootReleaseProcessor, ProcId 0x30...
SBL_SlaveCoreBoot completed for Core ID#8, Entry point is 0x0
SBL_SlaveCoreBoot completed for Core ID#9, Entry point is 0x0
SBL_SlaveCoreBoot completed for Core ID#10, Entry point is 0xae200000
SBL_SlaveCoreBoot completed for Core ID#11, Entry point is 0xb2200000
SBL_SlaveCoreBoot completed for Core ID#12, Entry point is 0xb6200000
Calling Sciclient_procBootRequestProcessor, ProcId 0x20...
Loading BootImage

 MMCBootImageLate: fp 0x 0x41cc9428, fileName is 0:/atf_optee.appimage

 Called SBL_MulticoreImageParse, status = 0

 MMCBootImageLate: fp 0x 0x41cc9428, fileName is 0:/tikernelimage_linux.appimage

 Called SBL_MulticoreImageParse, status = 0
log_task start

 MMCBootImageLate: fp 0x 0x41cc9428, fileName is 0:/tidtb_linux.appimage
[MCU1_1:1->3]:
Power On Completed.

 Called SBL_MulticoreImageParse, status = 0
BootImage completed, status = 0
Sciclient_procBootReleaseProcessor, ProcId 0x20...
SBL_SlaveCoreBoot completed for Core ID#0, Entry point is 0x70000000
Boot App: Started at 3230 usec
Boot App: Total Num booted cores = 8
Boot App: Booted Core ID #6 at 2344223 usecs
Boot App: Booted Core ID #7 at 2407223 usecs
Boot App: Booted Core ID #8 at 3748223 usecs
Boot App: Booted Core ID #9 at 3811223 usecs
Boot App: Booted Core ID #10 at 3882223 usecs
Boot App: Booted Core ID #11 at 3953223 usecs
Boot App: Booted Core ID #12 at 4024223 usecs
Boot App: Booted Core ID #0 at 12307223 usecs

MCU Boot Task started at 3228 usecs and finished at 12758223 usecs

Hi Xie,

Your WKUP_DEVSTAT register is all zeros. Can you also get the MAIN_DEVSTAT register output?

If that is also all zeros, then it is an invalid bootmode.

What bootmode are you trying to run your board in - SDCard?

regards

Suman

Hi, Suman,

Suman Anna said:

Your WKUP_DEVSTAT register is all zeros. Can you also get the MAIN_DEVSTAT register output?

Suman Anna said:

What bootmode are you trying to run your board in - SDCard?

I don't know the explicit configuration of systemboot pins as I haven't got the schematic yet

Thanks 

Hi, Suman, 

I also read the 0x00100030, by the way, what's the difference between proxy0 physical address and proxy1 physical address?

Suman Anna said:

Are you sure the board you are trying to run is a HS-FS device? Can you put your board into UART bootmode, and check the output of MCU and WKUP UARTs? You should see a hex string printed on one of the UARTs.

Hi, Suman,

Below bytes is print from the uart (from another bot using the chip TDA4VM88T,  which also have no output when run the same keywriter), can you help to check？ although the device type is HSSE, i think the keywriter should have the version print.

02000000011a00006a376573000000000000000048535345010101000101010002a6000001000100aa1f8e3095042e5c71ac40ede5b4e8c85fa87e03305ae0ea4f47933e89f4164aeb5a12ae13778f49de0622c1a578e6e747981d8c44a130f89a336a887a7955eedaa6aecf62447fd5f8af27ec45f58281a4e78637dd75a95000f4e51ddf36c588c20bcb404d07992d4cbc3cc81c6ce02177f2c42fa4277a713b415a3a47d4ace3ccc75baed1a7cc0f4f3e9c005d70c424426d63e12233780cc9df71e20f0da141CC

Thanks,

BRs.

Hi Xie,

You can't run a Keywriter image on the HS-SE device.

Regards
Diwakar

Hi, Diwakar,

The key efuse proccess may failed, but i think I can at least see the error message if the key is matched, Am I right?

BRs

Hi, Diwakar,

We can boot from uart on the board that we are testing, the devicde type is HS-FS, the uart print:

02000000011a00006a376573000000000000000048534653010101000101010002a6000000000000aa1f8e3095042e5c71ac40ede5b4e8c85fa87e03305ae0ea4f47933e89f4164aeb5a12ae13778f49de0622c1a578e6e747981d8c44a130f89a336a887a7955eead0bc40b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000313804d099f1737b046dec8371e1300cf029c9e288acbdde3718e4981371fcf1C

BRs

Hi Xie,

xie jc said:

The key efuse proccess may failed, but i think I can at least see the error message if the key is matched, Am I right?

You cannot run a KeyWriter on a HS-SE device. You won't even get to the trace print, because that only happens when the MCU1_0 KeyWriter application has been jumped to. 

A HS-SE device expects the bootloader binaries to be signed with the HS-SE Customer Private-Key, and the KeyWriter image is not. It is not an application that is designed to be run on a HS-SE device.

xie jc said:

We can boot from uart on the board that we are testing, the devicde type is HS-FS, the uart print:

Yes, on this you should be able to run the KeyWriter application. You need to ensure the voltage is being supplied properly on your board.

xie jc said:

I don't know the explicit configuration of systemboot pins as I haven't got the schematic yet

Were you able to get the schematic for this, so that you can compare it with the TI EVM logic, and even check the bootmode pin configuration.

regards

Suman

Hi, Suman,

Thanks for your reply.

Suman Anna said:

You cannot run a KeyWriter on a HS-SE device. You won't even get to the trace print, because that only happens when the MCU1_0 KeyWriter application has been jumped to. 

A HS-SE device expects the bootloader binaries to be signed with the HS-SE Customer Private-Key, and the KeyWriter image is not. It is not an application that is designed to be run on a HS-SE device.

I can really run kyewriter on  HS-SE dvice, although i will see errors, i can at least see print from the serial output. (As you said, the key must be matched)

Suman Anna said:

Yes, on this you should be able to run the KeyWriter application. You need to ensure the voltage is being supplied properly on your board.

No, the keywriter can not run on this board.  As we discussed before，the keywriter can at least show the version number before pulled the voltage. 

Suman Anna said:

Were you able to get the schematic for this, so that you can compare it with the TI EVM logic, and even check the bootmode pin configuration.

Nop. I can boot from uart now, so we can confirm it is a HS-FS device  from the uart print which mentioned above.

BRs

Hi Xie,

xie jc said:

I can really run kyewriter on  HS-SE dvice, although i will see errors, i can at least see print from the serial output. (As you said, the key must be matched)

KeyWriter is intended to be run _only_ on a HS-FS device to convert it to a HS-SE device. It is not designed to run on a HS-SE device, and there is no value whatsoever for doing this.

xie jc said:

No, the keywriter can not run on this board.  As we discussed before，the keywriter can at least show the version number before pulled the voltage. 

As long as it is a HS-FS device, you should be able to run the KeyWriter. What changed with your setup?

xie jc said:

Nop. I can boot from uart now, so we can confirm it is a HS-FS device  from the uart print which mentioned above.

Given that you were able to confirm that UART boot is working, please send the KeyWriter binary using the UART boot.

regards

Suman