PROCESSOR-SDK-AM62X: OTP keywriter

Hi Cyra

We regret the delay as E2E was down. Are you trying the OTP writer on a TI EVM or your own board?

on TI EVM

I tried on my own board also, as well as the TI EVM

Hi Cyra,

The OTP keywriter only requires the tiboot3.bin which does all the work. You should be getting logs on the UART port corresponding to the R5 SBL once the tiboot3.bin is booted.

Regards,

Prashant

Yes, but i am not getting any output as shown in the log.

Below is the procedure i followed as mentioned in the user guide.

To Program OTP Word 31
./construct_ext_otp_data.sh -extotp 0x6507C8EB -indx 992 -size 32
./gen_keywr_cert.sh -t tifek/ti_fek_public.pem --ext-otp ext_otp_data.bin --ext-otp-indx 992 --ext-otp-size 32
To Program OTP Word 30
./construct_ext_otp_data.sh -extotp 0xB9A72CB0 -indx 960 -size 32
./gen_keywr_cert.sh -t tifek/ti_fek_public.pem --ext-otp ext_otp_data.bin --ext-otp-indx 960 --ext-otp-size 32
To Program OTP Word 29
./construct_ext_otp_data.sh -extotp 0x0000418D -indx 928 -size 32
./gen_keywr_cert.sh -t tifek/ti_fek_public.pem --ext-otp ext_otp_data.bin --ext-otp-indx 928 --ext-otp-size 32

python3 keycert.h KEYCERT

make -sj clean PROFILE=debug
make -sj PROFILE=debug

Hi Cyra,

Are you not getting any logs at all? I mean not even the following?

Starting Keywriting

The above log is dumped by the tiboot3.bin and it is independent of the key writing procedure. If we are at least getting the above log, we can be sure that the tiboot3.bin at least got booted correctly.

Regards,

Prashant

Yes, no output at all.

Cables are connected to J11, J13 and J15

Cyra - said:

Cables are connected to J11, J13 and J15

This looks ok.

Can we once try booting tiboot3.bin via UART. The procedure is for the same is stated in  section 4.1.1 For Linux Users in the User Guide.

Hi Cyra,

I have one question: I see you are trying to program the extended OTP. So, I would like to know if you have already converted your device to HS-SE by programming the keys earlier and now you are trying to program the extended OTP.

If in doubt, you can quickly check the device type following 5 Checking Device State (HS-FS/HS-SE) section of the user guide.

Regards,
Prashant

I have not pragram the keys before. This is the first time using OTP keywriter to flash.

Prashant Shivhare said:

Can we once try booting tiboot3.bin via UART. The procedure is for the same is stated in  section 4.1.1 For Linux Users in the User Guide.

cyra@linux:~/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/tools$ python3 uart_bootloader.py -p "/dev/ttyUSB0" -b '/home/cyra/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/am62x-sk/r5fss0-0_nortos/ti-arm-clang/tiboot3.bin' 
Sending the UART bootloader /home/cyra/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/am62x-sk/r5fss0-0_nortos/ti-arm-clang/tiboot3.bin ...
Sending /home/cyra/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/am62x-sk/r5fss0-0_nortos/ti-arm-clang/tibootSending /home/cyra/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/am62x-sk/r5fss0-0_nortos/ti-arm-clang/tibootSending /home/cyra/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/am62x-sk/r5fss0-0_nortos/ti-arm-clang/tibootSending /home/cyra/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/am62x-sk/r5fss0-0_nortos/ti-arm-clang/tibootSending /home/cyra/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/am62x-sk/r5fss0-0_nortos/ti-arm-clang/tibootSending /home/cyra/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/am62x-sk/r5fss0-0_nortos/ti-arm-clang/tiboot
Sent bootloader /home/cyra/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/am62x-sk/r5fss0-0_nortos/ti-arm-clang/tiboot3.bin of size 278555 bytes in 28.54s.

cyra@linux:~/mcu+sdk/mcu_plus_sdk_am62x_09_00_00_19_v2/source/security/sbl_keywriter/tools$ minicom

Welcome to minicom 2.7.1

OPTIONS: I18n 
Compiled on Dec 23 2019, 02:06:26.
Port /dev/ttyUSB0, 11:21:44

Press CTRL-A Z for help on special keys     

Hi Cyra,

I realize the UART boot via uart_bootloader.py is not a reliable way to see SBL logs. You see by the time we connect to the UART port, the tiboot3.bin would have already booted and dumped the logs already. So, we can try to see if we are getting any M3 logs on the corresponding UART.

Let's do the following:

• Open all four ports mapped to the connected board.
• Boot the tiboot3.bin in DFU boot mode and see if we are getting the logs on any of the UART port. Ideally, we should be getting on two different UART ports.
• Boot the tiboot3.bin in UART boot mode by disconnecting the /dev/ttyUSB0 and see if we are getting the logs on UART port mapped to M3.

Regards,

Prashant

Prashant Shivhare said:

Boot the tiboot3.bin in DFU boot mode and see if we are getting the logs on any of the UART port. Ideally, we should be getting on two different UART ports.

nope, nothing on all ports except for ttyUSB0 which is connected to J15. cables are connected to J11, J13 and J15, J16

minicom -D /dev/ttyUSB0

Welcome to minicom 2.7.1

OPTIONS: I18n 
Compiled on Dec 23 2019, 02:06:26.
Port /dev/ttyUSB0, 14:23:46

Press CTRL-A Z for help on special keys                                                
                                                                                       
CCC01000000011a0000616d36327800000000000000475020200100010001000100CCCCCCCCCCCCCCCCCCCCCCCC�01000000011a0000616d36327800000000000000475020200C
                                                                                       
                                                                                       

Hi Cyra,

I see you are working with a GP board which does not support secure boot and thus OTP keywriter is not meant to be run on this device type. Here is the dump of the SoC info which I get by parsing the UART string dumped by ROM available in the last response.

-----------------------
SoC ID Header Info:
-----------------------
NumBlocks            : 1
-----------------------
SoC ID Public ROM Info:
-----------------------
SubBlockId           : 1
SubBlockSize         : 26
DeviceName           : am62x
DeviceType           : GP
DMSC ROM Version     : [0, 1, 0, 1]
R5 ROM Version       : [0, 1, 0, 1]

You should have a HS-FS board with you to try the OTP keywriter and turn the device into HS-SE which then supports full secure boot. Here are the product links for the AM62X-SK HS-FS board

https://www.ti.com/tool/SK-AM62B

www.ti.com/.../SK-AM62B-P1

Regards,

Prashant

Hi,

Just to clarify, what you are saying is this am62x board does not support secure boot and hence cannot use OTP keywriter to write. is that correct?

May i know how to parse the UART string?

Oh, i found the document to switch from GP to the HS-SE. i will follow the document.

Hi,

Cyra - said:

Just to clarify, what you are saying is this am62x board does not support secure boot and hence cannot use OTP keywriter to write. is that correct?

Yes. You need a HS-FS version of AM62X for secure boot.

Cyra - said:

May i know how to parse the UART string?

You can follow the below guides:

1.  5 Checking Device State (HS-FS/HS-SE) section of the User Guide.

2. FAQ: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1228618/faq-am6xx-how-to-check-if-device-type-is-hs-se-hs-fs-or-gp

Cyra - said:

Oh, i found the document to switch from GP to the HS-SE. i will follow the document.

Please note this is not possible. There is no conversion from GP device to HS device.

Regards,

Prashant

Prashant Shivhare said:

Please note this is not possible. There is no conversion from GP device to HS device

Oh, i misunderstood the following document then. https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/08_06_00_42/exports/docs/linux/Foundational_Components_Migration_Guide.html

Thanks for pointing it out. i will check whether my custom board is GP or HS-SE and test on it if it's HS-SE.

how do i check it if the board doesn't support uart boot mode?

Hi,

The way to do this is:

• Connect to the /dev/ttyUSB0 port.
• Put the board in UART boot mode via the bootmode switches.
• Observe the 'C' characters gettings printed on the /dev/ttyUSB0 UART port.

If you see the above then it means the ROM is waiting for an image to receive and boot the same.

Regards,

Prashant

but how do i check that if my board doesn't support uart boot mode

Hi,

Please note the AM62X ROM itself supports UART boot irrespective of the board. The ROM does the UART boot using UART0. So, if you have the means to put your board into UART bootmode and UART0 is available on your board then you should be able to boot an image using UART otherwise probably you can't use UART bootmode.

my custom board that is based on am62x (am623) does not support UART bootmode. (means cannot put the board in UART boot mode via the bootmode switches)

So how do i check the device type?

does this device state, GP or HS-FE, depends on MCU/SoC or the board?

Hi,

is there any update on this?

Thank you, i was able to get the device type with the commands you sent.

cyra@linux:~$ xxd ./socid.bin
00000000: 0100 0000 011a 0000 616d 3632 7800 0000  ........am62x...
00000010: 0000 0000 4750 2020 0100 0100 0100 0100  ....GP  ........