DRA829V: keywriter - OTP. Follow-up questions

Bo Mellberg

Part Number: DRA829V
Other Parts Discussed in Thread: TEST2

Hi experts,

We have started the procedure to swap the five GP variants that was wrongly mounted to HS variants. I will get the first two samples tomorrow. We have decided to go for UART boot in factory for the programming of OTP and hence we have rerouted mcu_uart0 to follow TI standard pinmux.

Until then, we have four questions:

Is the OTP writing being done solely by uploading the keywriter-bin with the VPP_MCU voltage set to 1.8V? I.e. there is no need to further communicate with the keywriter application, other than getting the debug output for verification?
What is written is a result of the settings in the x509-certificate in the keywriter-bin only. Is this correct?
Is RSA4096 still the only supported variant for the hashes?
Is it possible, using extended OTP, to change the VID, PID and serialnumber that is presented to the host at USB boot? We would like to use our own, so that our customers are not presented with a TI-product.

Regards,

/Bo

2 months ago

0 Suman Anna 2 months ago

TI__Guru* 81245 points

Hi Bo,

Bo Mellberg said:
Is the OTP writing being done solely by uploading the keywriter-bin with the VPP_MCU voltage set to 1.8V? I.e. there is no need to further communicate with the keywriter application, other than getting the debug output for verification?

The KeyWriter application would typically need to be adjusted for enabling the Efuse VPP voltages. The Keywriter certificate containing the efuses to be programmed is embedded within the overall keywriter application firmware image, and is sent by the KeyWriter application to the KeyWriter binary running on TIFS.

If you have different certificates, and doing a multi-pass configuration, then the application image will also vary due to the different embedded certificates.

Bo Mellberg said:
What is written is a result of the settings in the x509-certificate in the keywriter-bin only. Is this correct?

Yes, correct. The certificate will only have contents relevant to the command-line arguments you used to generate the certificate.

Bo Mellberg said:
Is RSA4096 still the only supported variant for the hashes?

Yes

Bo Mellberg said:
Is it possible, using extended OTP, to change the VID, PID and serialnumber that is presented to the host at USB boot? We would like to use our own, so that our customers are not presented with a TI-product.

Extended OTP efuse bits are completely left to the end-customer. Once the device is converted to HS-SE, you need to use the run-time API alongside enabling the relevant VPPs to program the Extended OTP keys.

regards

Suman

0 Bo Mellberg 2 months ago in reply to Suman Anna

Prodigy 241 points

Hi Suman,

Thanks for the answers.

Suman Anna said:
The KeyWriter application would typically need to be adjusted for enabling the Efuse VPP voltages.

This is not our intention. The voltage will be applied externally in the factory.

I have now received the modified devices, and they are now checked to be HS devices (HS-FS). We have also made possible for bootstrapping to uart boot, and communication on mcu_uart0 via the standard pinmux.

When I start the device, I get this:

02000000011a00006a376573000000000000000048534653010101000101010002a6000000000000aa1f8e3095042e5c71ac40ede5b4e8c85fa87e03305ae0ea4f47933e89f4164aeb5a12ae13778f49de0622c1a578e6e747981d8c44a130f89a336a887a7955eead0bc40b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000364000e7c724968f5cfff2033d6a77963a4994d7671c17c2b85c8bd1939e9a8eCCCCCC

I can then send the keywriter binary:

Xmodem sectors/kbytes sent: 0/ 0kRetry 0: NAK on sector
Retry 0: NAK on sector
Bytes Sent: 521856 BPS:11439

Transfer complete

*** exit status: 0 ***
OTP Keywriter Version: 02.00.00.00 (Feb 27 2024 - 15:59:59)

The log stops there, and I see no output on the wkup_uart0.

I have not yet applied the OTP_VppEN voltage; might this be the reason for no logs?

One observation is that the programming over uart takes very long (~40 s), which is not acceptable for factory purposes. Therefore I transferred the keywriter binary using usb boot instead, but then the mcu_uart0 is completely silent. Is it not possible to get uart output when using usb boot?

One last observation: obviously the files that we have used for booting the GP variant does no longer work. Binman creates tiboot3-j721e_sr1_1-hs-evm.bin and tiboot3-j721e_sr2-hs-fs-evm.bin files (and sysfw correspondants). None of these files works on my HS device (DRA829JMT0BALFQ1) which as I understand is an sr1.1 device. How can I get hs-fs files for the sr1.1 variant?

I have sent you a private message about a virtual meeting. If you could accommodate that it would be very helpful.

Regards,

/Bo

0 Suman Anna 2 months ago in reply to Bo Mellberg

TI__Guru* 81245 points

Hi Bo,

Bo Mellberg said:
The voltage will be applied externally in the factory.

Bo Mellberg said:
I have not yet applied the OTP_VppEN voltage; might this be the reason for no logs?

Yes, please ensure that the voltage is applied then before you run the KeyWriter. The VPP_EFUSE needs to be on before TIFS can attempt to program the efuses from the certificate that is passed to it.

Bo Mellberg said:
Therefore I transferred the keywriter binary using usb boot instead, but then the mcu_uart0 is completely silent. Is it not possible to get uart output when using usb boot?

There should be no issues with this. The PinMux configurations and UART configurations may need to be done within the KeyWriter image for this in USB Boot.

Bo Mellberg said:
Binman creates tiboot3-j721e_sr1_1-hs-evm.bin and tiboot3-j721e_sr2-hs-fs-evm.bin files (and sysfw correspondants). None of these files works on my HS device (DRA829JMT0BALFQ1) which as I understand is an sr1.1 device. How can I get hs-fs files for the sr1.1 variant?

SR1.1 HS-FS requires separate TIFS binaries which are made available only from 9.1 SDK onwards. You may want to add a similar binman entry as tiboot3-j721e_sr2-hs-fs-evm.bin for tiboot3-j721e_sr1_1-hs-fs-evm.bin

Bo Mellberg said:
I have sent you a private message about a virtual meeting. If you could accommodate that it would be very helpful.

I am out next week, so will check if someone else can help you guys.

regards

Suman

0 Bo Mellberg 2 months ago in reply to Suman Anna

Prodigy 241 points

Hi Suman,

Suman Anna said:
Yes, please ensure that the voltage is applied then before you run the KeyWriter. The VPP_EFUSE needs to be on before TIFS can attempt to program the efuses from the certificate that is passed to it.

That explains it. I don't want to convert it into a HS-SE device just yet though.

Suman Anna said:
There should be no issues with this. The PinMux configurations and UART configurations may need to be done within the KeyWriter image for this in USB Boot.

Strange. The pinmux for the keywriter has not been changed at all as I reverted all changes from my previous tests.

Suman Anna said:
SR1.1 HS-FS requires separate TIFS binaries which are made available only from 9.1 SDK onwards. You may want to add a similar binman entry as tiboot3-j721e_sr2-hs-fs-evm.bin for tiboot3-j721e_sr1_1-hs-fs-evm.bin

I did this and ended up with this file:

-rw-r--r-- 2 bomellberg bomellberg 5890 Feb 28 17:21 sysfw-j721e_sr1_1-hs-fs-evm.itb

As you see it's only 5890 bytes and boot complained about it not containing a fit-image.

EDIT: The small file was a result of the build system not being able to find the files for sr1_1. Since they are marked "optional" in binman.dts, they were simply discarded. I have now successfully booted to linux on my sr1_1 device.

Suman Anna said:
I am out next week, so will check if someone else can help you guys.

Thank you!

Regards,

/Bo

+1 Suman Anna 2 months ago in reply to Bo Mellberg

TI__Guru* 81245 points

Hi Bo,

Bo Mellberg said:
That explains it. I don't want to convert it into a HS-SE device just yet though.

Yes, definitely. I always recommend that you use a very simple certificate that programs just the MSV (without read-protect or write-protect) efuse to hash out the KeyWriter process and not brick the HS-FS device.

This does not impact any authentication.

Bo Mellberg said:
Strange. The pinmux for the keywriter has not been changed at all as I reverted all changes from my previous tests.

I don't think this is a concern actually. Your UART is actually working fine as evidenced by the trace from your log above

OTP Keywriter Version: 02.00.00.00 (Feb 27 2024 - 15:59:59)

This is the first UART printf from the KeyWriter application.

regards

Suman

0 Bo Mellberg 2 months ago in reply to Suman Anna

Prodigy 241 points

Hi Suman,

After getting access to the OTP Keywriter Addon I have now successfully managed to run the first kw_test01.tiimage validation test:

mcu_uart0:

ersion: 02.00.00.00 (Mar  1 2024 - 08:29:59)

 OTP Keywriter ver: 21.5.2--v2021.05b (Terrific Lla
OTP_VppEn
test_pmic_i2c_lld_intf_setup(): 487: PMIC_MAIN_INST I2C Setup...
test_pmic_i2c_lld_intf_setup(): 529: done...
I2C1: Passed for address 0x4c !!!
I2C1: Passed for address 0x13 !!!
INT STAT[0]: 0x00000000
INT STAT[1]: 0x00000002
INT STAT[2]: 0x00000000
INT STAT[3]: 0x00000000

Pmic_gpioSetValue ret: 0 Works!!!
Key programming sequence initialted
Taking OTP certificate from 0x41c7f004
Debug response: 0x0
Key programming sequence completed

wkup_uart0:

#
# Decrypting extensions..
#
MPK Options:  0x0
MEK Options:  0x0
MPK Opt P1:  0x0
MPK Opt P2:  0x0
MEK Opt   :  0x0
SMPKH extension disabled
SMEK extension disabled
EXT OTP extension disabled
* BCH code & MSV: fe0fac8b

KEY CNT extension disabled

KEY REV extension disabled

SWREV extension disabled

FW CFG REV extension disabled

* KEYWR VERSION:  0x20000

#
# Programming Keys..
#

* MSV:
[u32] bch + msv:  0x0
Programmed 2/2 rows successfully
[u32] bch + msv:  0x8BAC0FFE

* SWREV:
[u32] SWREV-SYSFW:  0x1
[u32] SWREV-SBL  :  0x1
SWREV extension disabled
[u32] SWREV-SYSFW:  0x1
[u32] SWREV-SBL  :  0x1

* FW CFG REV:
[u32] SWREV-FW-CFG-REV:  0x1
SWREV SEC BCFG extension disabled
[u32] SWREV-FW-CFG-REV:  0x1

* EXT OTP:
EXT OTP extension disabled

* BMPKH, BMEK:
BMPKH extension disabled
BMEK extension disabled

* SMPKH, SMEK:
SMPKH extension disabled
SMEK extension disabled

* KEYCNT:
[u32] keycnt:  0x0
KEY CNT extension disabled
[u32] keycnt:  0x0

* KEYREV:
[u32] keyrev:  0x0
KEY REV extension disabled
[u32] keyrev:  0x0

NB: I only get this output when downloading the keywriter binary via uart boot. If I try to do it from usb boot both uart ports are still silent. This is a show-stopper for us, since we need to get the "Debug response: 0x0" in factory to validate the OTP programming.

EDIT: I implemented the patch changes mentioned in this thread:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1172177/tda4vm-tda4vm-is-there-a-patch-for-keywriter-to-output-logs-when-boot-from-sd-card

ubuntu:~/tda4vm-08-00/ti-processor-sdk-rtos-j721e-evm-08_00_00_12/pdk_jacinto_08_00_00_37/packages/ti$ git diff boot/keywriter/main.c
diff --git a/packages/ti/boot/keywriter/main.c b/packages/ti/boot/keywriter/main.c
index 3fea7d7..202b98b 100644
--- a/packages/ti/boot/keywriter/main.c
+++ b/packages/ti/boot/keywriter/main.c
@@ -180,13 +180,37 @@ static void mmr_unlock(uint32_t base, uint32_t partition){
        HW_WR_REG32(part_base + CTRLMMR_LOCK_KICK1, CTRLMMR_LOCK_KICK1_UNLOCK_VAL);
 }
 
+#define SBL_UART_PLL_BASE                   (CSL_MCU_PLL0_CFG_BASE)
+#define SBL_UART_PLL_KICK0_OFFSET           (CSL_MCU_PLL_MMR_CFG_PLL1_LOCKKEY0)
+#define SBL_UART_PLL_KICK1_OFFSET           (CSL_MCU_PLL_MMR_CFG_PLL1_LOCKKEY1)
+#define SBL_UART_PLL_DIV_OFFSET             (CSL_MCU_PLL_MMR_CFG_PLL1_HSDIV_CTRL3)
+#define SBL_UART_PLL_DIV_VAL                (0x00008031)
+#define SBL_UART_PLL_KICK0_UNLOCK_VAL       (0x68EF3490)
+#define SBL_UART_PLL_KICK1_UNLOCK_VAL       (0xD172BC5A)
+#define SBL_UART_PLL_KICK_LOCK_VAL          (0x0)
+
+static void J721E_UART_InitPwrClk(void)
+{
+    HW_WR_REG32(SBL_UART_PLL_BASE + SBL_UART_PLL_KICK0_OFFSET, SBL_UART_PLL_KICK0_UNLOCK_VAL);
+    HW_WR_REG32(SBL_UART_PLL_BASE + SBL_UART_PLL_KICK1_OFFSET, SBL_UART_PLL_KICK1_UNLOCK_VAL);
+
+    HW_WR_REG32(SBL_UART_PLL_BASE + SBL_UART_PLL_DIV_OFFSET, SBL_UART_PLL_DIV_VAL);
+
+    HW_WR_REG32(SBL_UART_PLL_BASE + SBL_UART_PLL_KICK0_OFFSET, SBL_UART_PLL_KICK_LOCK_VAL);
+    HW_WR_REG32(SBL_UART_PLL_BASE + SBL_UART_PLL_KICK1_OFFSET, SBL_UART_PLL_KICK_LOCK_VAL);
+}
+
+
+
 int main()
 {
        int32_t status = CSL_EFAIL;
        uint32_t debug_response = 0;
        uint32_t *keywriter_cert = &keywr_end + 1;
        UART_HwAttrs uart_cfg;
-       
+
+       J721E_UART_InitPwrClk();
+
        /* padconfig unlock */
        mmr_unlock(WKUP_CTRL_BASE, 7);
        /* pinmux for R5 logs */

This enabled debug output on both mcu_uart0 and wkup_uart0. Note that the patch was for PDK version 8.0, and I have downloaded version 9.1, in which the patch is still not implemented. I think it would be wise to include it as default.

Many thanks for all help, Suman! I will mark this as resolved now.

Regards,

/Bo

0 Bo Mellberg 2 months ago in reply to Bo Mellberg

Prodigy 241 points

Hi Suman,

Since I have problems to get my first HS-SE device booting, I decided to try another device. It is still HS-FS.

I'm having trouble getting all the test images to work. For instance, when I transfer test 11 that tests the backup key programming:

./gen_keywr_cert.sh -t ti_fek_public.pem -b keys/bmpk.pem --bmek keys/bmek.key -b-wp --bmek-wp --mek-opt 0x1 --mpk-opt 0x21

$ dfu-util -a 0 -D kw_test11.tiimage

Generates the following logs:

OTP Keywriter Version: 02.00.00.00 (Mar 1 2024 - 12:13:38)

OTP Keywriter ver: 21.5.2--v2021.05b (Terrific Lla
OTP_VppEn
test_pmic_i2c_lld_intf_setup(): 487: PMIC_MAIN_INST I2C Setup...
test_pmic_i2c_lld_intf_setup(): 529: done...
I2C1: Passed for address 0x4c !!!
I2C1: Passed for address 0x13 !!!
INT STAT[0]: 0x00000000
INT STAT[1]: 0x00000000
INT STAT[2]: 0x00000000
INT STAT[3]: 0x00000000

Pmic_gpioSetValue ret: 0 Works!!!
Key programming sequence initialted
Taking OTP certificate from 0x41c7f004
Sciclient_otpProcessKeyCfg returns: -1
Debug response: 0x20
Key programming sequence completed

#
# Decrypting extensions..
#
MPK Options:  0x0
MEK Options:  0x0
MPK Opt P1:  0x0
MPK Opt P2:  0x0
MEK Opt   :  0x0
SMPKH extension disabled
SMEK extension disabled
EXT OTP extension disabled
* BCH code & MSV: fe0fac8b

KEY CNT extension disabled

KEY REV extension disabled

SWREV extension disabled

FW CFG REV extension disabled

* KEYWR VERSION:  0x20000

#
# Programming Keys..
#

* MSV:
[u32] bch + msv:  0x8BAC0FFE
Skipping programming
[u32] bch + msv:  0x8BAC0FFE

* SWREV:
[u32] SWREV-SYSFW:  0x1
[u32] SWREV-SBL  :  0x1
SWREV extension disabled
[u32] SWREV-SYSFW:  0x1
[u32] SWREV-SBL  :  0x1

* FW CFG REV:
[u32] SWREV-FW-CFG-REV:  0x1
SWREV SEC BCFG extension disabled
[u32] SWREV-FW-CFG-REV:  0x1

* EXT OTP:
EXT OTP extension disabled

* BMPKH, BMEK:
BMPKH extension disabled
BMEK extension disabled

* SMPKH, SMEK:
SMPKH extension disabled
SMEK extension disabled

* KEYCNT:
[u32] keycnt:  0x0
KEY CNT extension disabled
[u32] keycnt:  0x0

* KEYREV:
[u32] keyrev:  0x0
KEY REV extension disabled
[u32] keyrev:  0x0
0x400002
0x800004
0x4003005
0x4401552
0x40000B
0x800004
0x4003005
0x4401552
0x40000D
0x800004
0x20800000
0x20800001
0x400002
0x800004
0x4003005
0x4401552
0x409031
0x800004
0x20C00001
0x20C00002
Internal Operation Error
debug_response:  0x20
Internal Operation Error
debug_response:  0x20

Apparently this OTP keywriting goes wrong.

Regards,

/Bo

0 Suman Anna 2 months ago in reply to Bo Mellberg

TI__Guru* 81245 points

Hi Bo,

What is the size of the certificate?

regards

Suman

0 Bo Mellberg 2 months ago in reply to Suman Anna

Prodigy 241 points

Hi Suman,

You might be onto something. Even though it is just the backup key to be programmed, the size of the certificate is 7106 bytes.

Test 1 certificates:

-rw-r--r-- 1 bomellberg bomellberg    4025 Mar  6 14:13 cert-kw_test01.bin
-rw-r--r-- 1 bomellberg bomellberg    4025 Mar  6 14:13 cert-kw_test02.bin
-rw-r--r-- 1 bomellberg bomellberg    4025 Mar  6 14:13 cert-kw_test03.bin
-rw-r--r-- 1 bomellberg bomellberg    4024 Mar  6 14:13 cert-kw_test04.bin
-rw-r--r-- 1 bomellberg bomellberg    4025 Mar  6 14:13 cert-kw_test05.bin
-rw-r--r-- 1 bomellberg bomellberg    4025 Mar  6 14:13 cert-kw_test06.bin
-rw-r--r-- 1 bomellberg bomellberg    4025 Mar  6 14:13 cert-kw_test07.bin
-rw-r--r-- 1 bomellberg bomellberg    4058 Mar  6 14:13 cert-kw_test08.bin
-rw-r--r-- 1 bomellberg bomellberg    4058 Mar  6 14:13 cert-kw_test09.bin
-rw-r--r-- 1 bomellberg bomellberg    4058 Mar  6 14:13 cert-kw_test10.bin
-rw-r--r-- 1 bomellberg bomellberg    7106 Mar  6 14:13 cert-kw_test11.bin
-rw-r--r-- 1 bomellberg bomellberg    7106 Mar  6 14:13 cert-kw_test12.bin
-rw-r--r-- 1 bomellberg bomellberg    4022 Mar  6 14:13 cert-kw_test13.bin
-rw-r--r-- 1 bomellberg bomellberg    4022 Mar  6 14:13 cert-kw_test14.bin
-rw-r--r-- 1 bomellberg bomellberg    4027 Mar  6 14:13 cert-kw_test15.bin
-rw-r--r-- 1 bomellberg bomellberg    4028 Mar  6 14:13 cert-kw_test16.bin

Test 2 certificate:

-rw-r--r-- 1 bomellberg bomellberg    7114 Mar  6 14:13 cert-kw_test01.bin

The compund "test2/test01.tiimage" also fails (size is 7114).

The other device I have was converted to HS-SE using test case 13, which works fine.

Surely the tests are meant to work "out of the box"?

Regards,

/Bo

0 Suman Anna 2 months ago in reply to Bo Mellberg

TI__Guru* 81245 points

Hi Bo,

What is the version of your Ubuntu and OpenSSL?

The KeyWriter and test sequences were all verified on SDK 8.x and Ubuntu 18.04. The OpenSSL version in newer Ubuntu has increased the certificate size, and some of them are resulting in having the certificate cross-over the size supported by TIFS.

regards

Suman

0 Bo Mellberg 2 months ago in reply to Suman Anna

Prodigy 241 points

Hi Suman,

bomellberg@bosse-buildcom:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy

bomellberg@bosse-buildcom:~$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Regards,

/Bo

0 Suman Anna 1 month ago in reply to Bo Mellberg

TI__Guru* 81245 points

Hi Bo,

Bo Mellberg said:
bomellberg@bosse-buildcom:~$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Suman Anna said:
The OpenSSL version in newer Ubuntu has increased the certificate size, and some of them are resulting in having the certificate cross-over the size supported by TIFS.

Thanks for the confirmation. As I mentioned previously, the newer OpenSSL version is exceeding the certificate size for certain options, and this does create failures.

The above cert-kw_testXX.bin files are the final certificate sizes. You should be able to confirm this by looking at the individual kw_testXX.log files. All the certificate sizes are well within limits, with the exception of kw_test11.log and kw_test12.log.

You should see something like this in the <RTOS SDK>/<PDK>/packages/ti/boot/keywriter/binary/j721e/test_images/test1/kw_test11.log

Below excerpt is from 9.1 SDK on a Ubuntu 18.04 machine, but the primary_cert.bin will exceed on Ubuntu 22.04 marginally. The individual certificate size limit is 5400 bytes.

# encrypt bmek (sym key) using aes256 key
1668    secondary_cert.bin
5374    primary_cert.bin
7042    ../x509cert/final_certificate.bin

Please also see the discussion on this thread from a different SoC: SK-AM69: Keywriter Error validating BMPK key specifically this response.

regards

Suman

Processors

Processors forum

DRA829V: keywriter - OTP. Follow-up questions