Board Not Booting After Secure Boot - SPL Not Reaching Console - i.MX8MPlus, Android 14

[mohamed_gaseen]

Hi NXP Team,

We are currently following the Secure Boot procedure on the i.MX8MPlus platform with Android 14 (L6.1.55_2.2.0), as outlined in the i.MX Security Reference Manual.

As part of this process, we followed the steps described in Section 3.1.2.4 – "Closing the Chip". After executing the relevant commands to close the device, the board is no longer booting to the U-Boot SPL console.

We have tested booting via:

• SD card

• eMMC

• Serial download (USB)

In all cases, the board fails to boot, and the host PC only detects a USB device, but no serial output appears from SPL.

Logs

 usb 1-2: new high-speed USB device number 29 using xhci_hcd

[20771.400772] usb 1-2: New USB device found, idVendor=1fc9, idProduct=0146, bcdDevice= 0.02

[20771.400777] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[20771.400780] usb 1-2: Product: SP Blank 865  

[20771.400782] usb 1-2: Manufacturer: NXP       SemiConductor Inc 

[20771.402886] hid-generic 0003:1FC9:0146.0086: hiddev0,hidraw0: USB HID v1.10 Device [NXP       SemiConductor Inc  SP Blank 865  ] on usb-0000:00:14.0-2/input0

When attempting to reflash the board using prebuilt Linux and Android images (via uuu), we observe the following error, I've attached the screenshot in the document format.

[Harvey021]

Hi,

Have you tested hab_status before closing the chip? if so and errors, please share.

You can also test (hab_status) the signed image on an open chip if there is one.

Please also share your steps.

Regards

Harvey

[santhana_kumar]

Harvey,

  Thanks for your support.

   I am unable to run any commands because the U-Boot console is not showing up. 

   Steps followed:

Generate AHAB SRK tables and eFuse hash.
Enter the directory of ${CST}/crts/, and execute the following command:
$ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c SRK1_sha256_2048_65537_v3_ca_crt.pem, SRK2_sha256_2048_65537_v3_ca_crt.pem, SRK3_sha256_2048_65537_v3_ca_crt.pem, SRK4_sha256_2048_65537_v3_ca_crt.pem

./linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c SRK1_sha256_2048_65537_v3_ca_crt.pem, SRK2_sha256_2048_65537_v3_ca_crt.pem, SRK1_sha256_2048_65537_v3_ca_crt.pem, SRK2_sha256_2048_65537_v3_ca_crt.pem

Dump the SRK hash value.
Change directory to crts/ in Code Signing Tool (CST). Execute the following command to dump the SRK
hash value:
hexdump -e '/4 "0x"' -e '/4 "%X""\n"' SRK_1_2_3_4_fuse.bin
0xB84A93A2
0x64C4C1CB
0x3B7DEC14
0x9368A85
0x620A07B5
0xD0AA76ED
0x253D7D1B
0x9DBA4893

fuse prog -y 6 0 0xB84A93A2 0x64C4C1CB 0x3B7DEC14 0x9368A85
fuse prog -y 6 0 0x620A07B5 0xD0AA76ED 0x253D7D1B 0x9DBA4893 -> mistaken Bank should be 7

=> hab_status

Not captured.

=> fuse prog -y 1 3 0x2000000  -> ran this.

[Harvey021]

Hi @santhana_kumar 

As per communication by email, please be careful about Fuse programming, that is One Time Programming and irreversible operation.

As this SRK hash is the basis for the root of trust. An error in SRK Hash results in a part that does not boot. The failure as re-flashing or boot is expected, when the chip closed.

Regards

Harvey