DRA829J-Q1: HS-FS device: SYSFW -> Firmware certificate authentication failed

Hi Wolfram,

The DRA829JMT0BALFQ1 device is a SR1.1 device (SR = Silicon Revision) and not a SR2.0 device.

Wolfram Stumpf said:

Do I need a dedicated SYSFW for DRA829JMT0BALFQ1 HS-FS? Any other requirements I my have missed?

Yes, each of the Silicon Revisions requires you to use only the appropriate TIFS firmware file for HS-FS and HS-SE, as the TI MPK keys are different on each of them. This mandates that you only use the appropriate signed binary. A GP device can use the same binary across different Silicon Revisions.

Following is a snapshot of the latest TIFS firmwares from the ti-linux-firmware git tree.

The HS-FS binaries for SR1.1 is not present in the 8.6 SDK. The HS-FS binaries for SR1.0 and SR1.1 were added only in the 9.1 SDK.

Wolfram Stumpf said:

$ make SOC=j721e_sr2 SOC_TYPE=hs-fs SYSFW_DIR=../prebuilt-images

You are using a command applicable for Silicon Revision 2.0, so this will not work, and has resulted in the failed authentication for you.

regards

Suman

Hi Suman, thank you for your fast response. I am working together with Wolfram on this topic.

As you suggested, we have tried the SR1.1 HS-FS binaries together with the latest k3-image-gen and core-secdev-k3 from git.

The image (sysfw-j721e_sr1_1-hs-fs-evm.itb) is built successfully as follows:

> make SOC=j721e_sr1_1 SOC_TYPE=hs-fs SYSFW_DIR=../sysfw


./gen_its.sh j721e_sr1_1 hs-fs evm out/soc/j721e/evm/sysfw.bin-hs-fs out/soc/j721e/evm/board-cfg.bin-signed out/soc/j721e/evm/pm-cfg.bin-signed out/soc/j721e/evm/rm-cfg.bin-signed out/soc/j721e/evm/sec-cfg.bin-signed > out/soc/j721e/evm/sysfw-j721e_sr1_1-hs-fs-evm.its
Signing the SYSFW inner certificate with /home/lubuntu/Downloads/tistuff/core-secdev-k3/keys/custMpk.pem key...
./gen_x509_cert.sh -d -c m3 -b ../sysfw/ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin -o ti-fs-firmware-j721e_sr1_1-hs-fs-certs.bin -l 0x40000 -k /home/lubuntu/Downloads/tistuff/core-secdev-k3/keys/custMpk.pem -r 1;
Certificate being generated :
LOADADDR = 0x00040000
IMAGE_SIZE = 1684
CERT_TYPE = 3
SUCCESS: Image ti-fs-firmware-j721e_sr1_1-hs-fs-certs.bin generated.
cat ti-fs-firmware-j721e_sr1_1-hs-fs-certs.bin ../sysfw/ti-fs-firmware-j721e_sr1_1-hs-fs-enc.bin > out/soc/j721e/evm/sysfw.bin-hs-fs
/home/lubuntu/Downloads/tistuff/core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/board-cfg.bin out/soc/j721e/evm/board-cfg.bin-signed
/home/lubuntu/Downloads/tistuff/core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/pm-cfg.bin out/soc/j721e/evm/pm-cfg.bin-signed
/home/lubuntu/Downloads/tistuff/core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/rm-cfg.bin out/soc/j721e/evm/rm-cfg.bin-signed
/home/lubuntu/Downloads/tistuff/core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/sec-cfg.bin out/soc/j721e/evm/sec-cfg.bin-signed
mkimage -f out/soc/j721e/evm/sysfw-j721e_sr1_1-hs-fs-evm.its -r sysfw-j721e_sr1_1-hs-fs-evm.itb
FIT description: SYSFW and Config Fragments
Created: Mon Jan 29 09:43:38 2024
Image 0 (sysfw.bin)
Description: sysfw
Created: Mon Jan 29 09:43:38 2024
Type: Firmware
Compression: uncompressed
Data Size: 265542 Bytes = 259.32 KiB = 0.25 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable
Image 1 (board-cfg.bin)
Description: board-cfg
Created: Mon Jan 29 09:43:38 2024
Type: Firmware
Compression: uncompressed
Data Size: 1676 Bytes = 1.64 KiB = 0.00 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable
Image 2 (pm-cfg.bin)
Description: pm-cfg
Created: Mon Jan 29 09:43:38 2024
Type: Firmware
Compression: uncompressed
Data Size: 1649 Bytes = 1.61 KiB = 0.00 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable
Image 3 (rm-cfg.bin)
Description: rm-cfg
Created: Mon Jan 29 09:43:38 2024
Type: Firmware
Compression: uncompressed
Data Size: 5358 Bytes = 5.23 KiB = 0.01 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable
Image 4 (sec-cfg.bin)
Description: sec-cfg
Created: Mon Jan 29 09:43:38 2024
Type: Firmware
Compression: uncompressed
Data Size: 1997 Bytes = 1.95 KiB = 0.00 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable

Unfortunately, we are still facing the same issue and getting the "Firmware certificate authentication failed" error.

Is there anything else to take into account?

Thanks and best regards,

Daniel

Hi Daniel,

Your steps look alright from a quick glance.

The ti-fs-firmware-j721e_sr1_1-hs-fs-enc.bin and ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin come in pairs, so please ensure that you have copied/used the corresponding ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin image as well.

Please copy over both the files into the k3-image-gen folder itself, and skip passing in the SYSFW_DIR, and see if the results change.

regards

Suman

Hi Suman, thanks.

I have downloaded both binaries ti-fs-firmware-j721e_sr1_1-hs-fs-enc.bin and ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin directly to the k3-image-gen folder and built again.

MD5 checksums for reference:

> md5sum ti-fs-firmware-j721e_sr1_1-hs-fs-enc.bin
13a1d45d4daf04918d25bc34c1c47743 ti-fs-firmware-j721e_sr1_1-hs-fs-enc.bin

> md5sum ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin
d8e492f203cfd59c4d135f858f40ef7d ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin

Build image log:

> make SOC=j721e_sr1_1 SOC_TYPE=hs-fs

./gen_its.sh j721e_sr1_1 hs-fs evm out/soc/j721e/evm/sysfw.bin-hs-fs out/soc/j721e/evm/board-cfg.bin-signed out/soc/j721e/evm/pm-cfg.bin-signed out/soc/j721e/evm/rm-cfg.bin-signed out/soc/j721e/evm/sec-cfg.bin-signed > out/soc/j721e/evm/sysfw-j721e_sr1_1-hs-fs-evm.its
Signing the SYSFW inner certificate with /home/lubuntu/Downloads/tistuff/core-secdev-k3/keys/custMpk.pem key...
./gen_x509_cert.sh -d -c m3 -b ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin -o ti-fs-firmware-j721e_sr1_1-hs-fs-certs.bin -l 0x40000 -k /home/lubuntu/Downloads/tistuff/core-secdev-k3/keys/custMpk.pem -r 1;
Certificate being generated :
LOADADDR = 0x00040000
IMAGE_SIZE = 1684
CERT_TYPE = 3
SUCCESS: Image ti-fs-firmware-j721e_sr1_1-hs-fs-certs.bin generated.
cat ti-fs-firmware-j721e_sr1_1-hs-fs-certs.bin ti-fs-firmware-j721e_sr1_1-hs-fs-enc.bin > out/soc/j721e/evm/sysfw.bin-hs-fs
/home/lubuntu/Downloads/tistuff/core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/board-cfg.bin out/soc/j721e/evm/board-cfg.bin-signed
/home/lubuntu/Downloads/tistuff/core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/pm-cfg.bin out/soc/j721e/evm/pm-cfg.bin-signed
/home/lubuntu/Downloads/tistuff/core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/rm-cfg.bin out/soc/j721e/evm/rm-cfg.bin-signed
/home/lubuntu/Downloads/tistuff/core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/sec-cfg.bin out/soc/j721e/evm/sec-cfg.bin-signed
mkimage -f out/soc/j721e/evm/sysfw-j721e_sr1_1-hs-fs-evm.its -r sysfw-j721e_sr1_1-hs-fs-evm.itb
FIT description: SYSFW and Config Fragments
Created: Tue Jan 30 10:34:50 2024
Image 0 (sysfw.bin)
Description: sysfw
Created: Tue Jan 30 10:34:50 2024
Type: Firmware
Compression: uncompressed
Data Size: 265542 Bytes = 259.32 KiB = 0.25 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable
Image 1 (board-cfg.bin)
Description: board-cfg
Created: Tue Jan 30 10:34:50 2024
Type: Firmware
Compression: uncompressed
Data Size: 1676 Bytes = 1.64 KiB = 0.00 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable
Image 2 (pm-cfg.bin)
Description: pm-cfg
Created: Tue Jan 30 10:34:50 2024
Type: Firmware
Compression: uncompressed
Data Size: 1649 Bytes = 1.61 KiB = 0.00 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable
Image 3 (rm-cfg.bin)
Description: rm-cfg
Created: Tue Jan 30 10:34:50 2024
Type: Firmware
Compression: uncompressed
Data Size: 5358 Bytes = 5.23 KiB = 0.01 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable
Image 4 (sec-cfg.bin)
Description: sec-cfg
Created: Tue Jan 30 10:34:50 2024
Type: Firmware
Compression: uncompressed
Data Size: 1997 Bytes = 1.95 KiB = 0.00 MiB
Architecture: ARM
OS: Unknown OS
Load Address: unavailable

But we are still seeing the same issue.

Best regards
Daniel

Hi Daniel,

What boot media are you using? All the steps look good.

Do you have GP device equivalent of your board, or a TI EVM board with a HS-FS sample?

I am suspecting if there is data integrity issues with your board, and the contents of the loaded sysfw.itb is not matching the real contents.

We can try couple of different steps depending on what you have available.

regards

Suman

Hi Suman,

we have developed a full custom board, initially equipped with a DRA829JMTGBALFR.

To prepare the HS-FS flow, we changed the SoC to a DRA829JMT0BALFQ1. This is the baseline for this boot issue.

The primary boot device is QSPI, the secondary can be USB or UART (assembly-selectable).

We are currently talking about a boot with an unpopulated QSPI flash, so the secondary boot device is used.

We had no issues regarding boot from USB or UART with the GP type boards.

In the current setup, USB boot is used to have additional output on the WKUP UART:

•     MCU BOOTMODE (CTRLMMR_WKUP_DEVSTAT = 0x00000113)
•     BOOTMODE (CTRLMMR_MAIN_DEVSTAT = 0x000000c2)

I'm not sure if this is a data integrity issue, as the R5 SPL (U-Boot/tiboot3.bin) is loaded and executed without any issues.

Talking about opportunities:

• USB boot is possible
• UART boot is possible
• we can attach a JTAG probe for debugging

We are open for your suggestions.

Best regards

   Wolfram

Hi Wolfram,

Thank you for all the details.

Wolfram Stumpf said:

We had no issues regarding boot from USB or UART with the GP type boards.

I am assuming that the DDR part is the same between the boards, with the only difference being the sample type.

Wolfram Stumpf said:

I'm not sure if this is a data integrity issue, as the R5 SPL (U-Boot/tiboot3.bin) is loaded and executed without any issues

tiboot3.bin would be loaded into the on-chip MCU SRAM, so there is no DDR involvement there.

Have you fully vetted the DDR using memtester? If your GP board is sane, and you have reached U-Boot prompt, I suggest that you fetch the sysfw.itb file into memory, and can run the crc command to compute and check the integrity of the loaded sysfw.itb against the crc on your host machine.

Please also provide your sysfw.itb (may need to rename to .txt if you cannot upload) and I can check against a HS-FS J721E EVM (may need couple of days to gather a HS-FS sample/board). 

regards

Suman

Hi Suman,

to be more precise regarding our setup:

• we took a board with the GP type assembled DRA829JMTGBALFR
• we used our Linux-based acceptance test software to assure that the board is fully functional
• we had our production department replace the SoC on that board with a 0 type DRA829JMT0BALFQ1
• we started our HS-FS integration campaign

So yes, the DDR is same. We had no issues with the DDR so far, including temperature testing (with the GP type assembled).

Regarding our current problem, I'm not sure, DDR should be of interest. We are currently not passing DMSC:

• R5 SPL loads SYSFW (sysfw.itb) in the R5 SRAM
• R5 SPL tries to start SYSFW on DMSC and hangs

As DDR initialization has not happend yet, DMSC should not have an issue with the DDR (red bar marking the hang):

Daniel will append the generated files.

I think we need to find the reason for the authorization failure...

Best regards

   Wolfram

Suman Anna said:

Please also provide your sysfw.itb (may need to rename to .txt if you cannot upload) and I can check against a HS-FS J721E EVM (may need couple of days to gather a HS-FS sample/board). 

Hi Suman,

please find attached a tarball containing the built sysfw-j721e_sr1_1-hs-fs-evm.itb image file.

sysfw-j721e_sr1_1-hs-fs-evm.tar

Thanks,

Daniel

Hi Daniel,

Thank you for providing the file. I will get back to you once I acquire a board either on Wed or Thu next week.

regards

Suman

Hi Suman,

we received our new MK3 board with the DRA829JMT5BALFQ1 assembled in the meantime.

Luckily, the board bring up was quite fast. The SoC ROM boot loader is already active and we received the following header infos via WKUP_UART (which is configured as backup boot device):

-----------------------
SoC ID Header Info:
-----------------------
NumBlocks            : 2
-----------------------
SoC ID Public ROM Info:
-----------------------
SubBlockId           : 1
SubBlockSize         : 26
DeviceName           : j7es
DeviceType           : HSFS
DMSC ROM Version     : [0, 1, 1, 1]
R5 ROM Version       : [0, 1, 1, 1]
-----------------------
SoC ID Secure ROM Info:
-----------------------
Sec SubBlockId       : 2
Sec SubBlockSize     : 166
Sec Prime            : 0
Sec Key Revision     : 0
Sec Key Count        : 0
Sec TI MPK Hash      :  aa1f8e3095042e5c71ac40ede5b4e8c85fa87e03305ae0ea4f47933e89f4164aeb5a12ae13778f49de0622c1a578e6e747981d8c44a130f89a336a887a7955ee
Sec Cust MPK Hash    : ad0bc40b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sec Unique ID        : db539aa36f860e887ed3c0961e2e7c9e50faabf332f8cdaef1effc3e7f408fcf

Unfortunately, we got stuck at the very same point as with the type 0 SoC boards with an DMSC authentication error.

Currently, we observe the following situation:

• MK2 GP type : up and running (bootloader & Linux)
• MK2 type 0: DMSC authentication error (SDK 8.6 and SDK 9.1)
• MK3 type 5: DMSC authentication error (SDK 8.6)

We are really looking forward to further observations or inputs from your side. Its currently a "TI signed firmware blamed by a TI hardware block" style issue, wich makes it hard for us to develop new ideas to sovle the issue.

If it is easier on your side, we can continue further activities in scope of the DRA829JMT5 as this is our target device anyway. What ever is the most effective way to go.

Best regards

   Wolfram

Hi Suman, thank you for your help.

The double-signing of the TIFS binary for HS-FS is indeed the issue in our case!

Your manual regeneration of the sysfw.itb is working fine and the file size is a good indicator.
I have patched the Makefile of k3-image-gen as follows, which also does the trick:

diff --git a/Makefile b/Makefile
index 5220dbe..3292059 100644
--- a/Makefile
+++ b/Makefile
@@ -194,12 +194,17 @@ $(SYSFW_HS_INNER_CERT_PATH):
        @echo "Download SUCCESS!"
 
 ifneq ($(SOC_TYPE),gp)
+
+ifneq ($(SOC_TYPE),hs-fs)
 $(SYSFW_HS_CERTS_PATH): $(SYSFW_HS_INNER_CERT_PATH)
        @echo "Signing the SYSFW inner certificate with $(KEY) key...";
        ./gen_x509_cert.sh -d -c m3 -b $< -o $@ -l $(LOADADDR) -k $(KEY) -r $(SW_REV);
 
 $(soc_objroot)/sysfw.bin-$(SOC_TYPE): $(SYSFW_HS_CERTS_PATH) $(SYSFW_PATH) | _objtree_build
        cat $^ > $@
+endif
+$(soc_objroot)/sysfw.bin-$(SOC_TYPE): $(SYSFW_HS_INNER_CERT_PATH) $(SYSFW_PATH) | _objtree_build
+       cat $^ > $@
 else
 $(soc_objroot)/sysfw.bin-$(SOC_TYPE): $(SYSFW_PATH) | _objtree_build
        @echo "Signing the SYSFW release image with $(KEY) key...";

The contents after regeneration looks like this:

> make SOC=j721e_sr1_1 SOC_TYPE=hs-fs
cat ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin ti-fs-firmware-j721e_sr1_1-hs-fs-enc.bin > out/soc/j721e/evm/sysfw.bin-hs-fs
../core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/board-cfg.bin out/soc/j721e/evm/board-cfg.bin-signed
../core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/pm-cfg.bin out/soc/j721e/evm/pm-cfg.bin-signed
../core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/rm-cfg.bin out/soc/j721e/evm/rm-cfg.bin-signed
../core-secdev-k3/scripts/secure-binary-image.sh out/soc/j721e/evm/sec-cfg.bin out/soc/j721e/evm/sec-cfg.bin-signed
mkimage -f out/soc/j721e/evm/sysfw-j721e_sr1_1-hs-fs-evm.its -r sysfw-j721e_sr1_1-hs-fs-evm.itb
FIT description: SYSFW and Config Fragments
Created:         Wed Feb 14 11:01:23 2024
 Image 0 (sysfw.bin)
  Description:  sysfw
  Created:      Wed Feb 14 11:01:23 2024
  Type:         Firmware
  Compression:  uncompressed
  Data Size:    263828 Bytes = 257.64 KiB = 0.25 MiB
  Architecture: ARM
  OS:           Unknown OS
  Load Address: unavailable
 Image 1 (board-cfg.bin)
[...]

Additionally, we have also ported the U-Boot 2023.04 from latest TI Linux SDK 9.1 today to our new MK3 hardware, which generates the sysfw.itb correctly without double signing for the HS-FS variant.

A previous test with U-Boot 2023.04 on a modified MK2 hardware with the HS-FS SoC (as Wolfram mentioned before), unfortunately failed due to a hardware failure in the same stage (R5 SPL) during DDR Initialization, which masked the error with SYSFW loading.

In short, your solution works and is applicable to SDK8.3, while SDK9.1 (U-Boot 2023.4) works out of the box.

Thank you!

Hi Daniel,

Daniel Grebe said:

Your manual regeneration of the sysfw.itb is working fine and the file size is a good indicator.

Yeah, this size is just the total of the sizes of the encrypted HS-FS binary ti-fs-firmware-j721e_sr1_1-hs-fs-enc.bin and its signed certificate using the TI MPK key, ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin.

Daniel Grebe said:

I have patched the Makefile of k3-image-gen as follows, which also does the trick:

Yeah, you will need a minor edit to put the new HS-FS block under the else of the new ifneq block, to avoid executing this for the HS-SE case, which does require the double-signing.

Daniel Grebe said:

Additionally, we have also ported the U-Boot 2023.04 from latest TI Linux SDK 9.1 today to our new MK3 hardware, which generates the sysfw.itb correctly without double signing for the HS-FS variant.

Glad that you were able to move to the latest U-Boot. The k3-image-gen project is no longer used with the 9.x SDK U-Boot (ti-u-boot-2023.04), the board configuration files and sysfw.itb files are now generated using the U-Boot's binman utility, and the newer SDKs support all the HS-FS Silicon Revisions properly. 

regards

Suman