Secure boot issue for i.MX6DL custom board

cancel
Showing results for 
Search instead for 
Did you mean: 

Secure boot issue for i.MX6DL custom board

244 Views
shunnianzhai
Contributor III

Hi Yuri and all,

As you may noticed, with help from Liu Kui, I managed to resolve the HAB_INV_ADDRESS issue.

However, my first custom board was locked (bricked) after programming to close the device. Although everything looks correct per the doc and no any event showed for command hab_status, the board cannot boot anymore after I program SEC_CONFIG[1] fuse bit.

Do you have any idea or suggestion if there is any way to recover and make the device boot again?

Furthermore, to avoid to lock or brick another board, I put on-hold my testing for other boards.

Please advise on what could be the root cause for this issue and what suggestion I should try to resolve the issue.

FYI: 

I am using the 2048-bit certificate, not 4096-bit.

Followed is detailed contents in my CSF file.

Do I need to change any settings, like:

Engine = ANY  --->  Engine = CAAM

#Illustrative Command Sequence File Description
[Header]
Version = 4.1
Hash Algorithm = sha256
Engine = ANY
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS

[Install SRK]
File = "../crts/SRK_1_2_3_4_table.bin"
# Index of the key location in the SRK table to be installed
Source index = 0

[Install CSFK]
# Key used to authenticate the CSF data
File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate CSF]

[Install Key]
# Key slot index used to authenticate the key to be installed
Verification index = 0
# Target key slot in HAB key store where key will be installed
Target Index = 2
# Key to install
File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate Data]
# Key slot index used to authenticate the image data
Verification index = 2
# Address Offset Length Data File Path
Blocks = 0x177ff400 0x00000000 0x0005FC00 "../u-boot_dir_ap/u-boot.imx"

#Blocks = 0x177ff400 0x00000000 0x0005FC00 "../u-boot_dir_ap/u-boot.imx", \
# 0x00910000 0x0000002c 0x00000238 "../u-boot_dir_ap/u-boot.imx"

If you find anything needed to change, please feel free to let me know.

Thanks in advance for your help and suggestion.

Best regards,

Shunnian

4 Replies

194 Views
Yuri
NXP TechSupport
NXP TechSupport

shunnianzhai 

Hello,

If there is no HAB event in open mode, but your board cannot bootup after program SEC_CONFIG

to close mode, please check if you have unlocked RNG in CSF script.

    [Unlock]

    Engine = CAAM

    Features = RNG

     For the reason to unlock RNG, pleases refer to Q&A: HAB on i.MX6

Regards,

Yuri.

194 Views
shunnianzhai
Contributor III

Hi Yuri,

Thank your for creating a new thread to track this issue and sharing your information.

It may be the root cause for my case since I notice the following information in doc (AN4581.pdf):

On HAB 4.2.0 and later the RNG is not instantiated by default, for older versions choose one of two methods, or the chip will not boot when the device is Closed.   

The HAB version in my custom board is 4.1.

If this is case, it may resolve my issue by one of ways below:

1) change the engine to CAAM:

[Header]
Engine = CAAM

2) Defer RNG instantiation :

In case that Engine must be set to other configuration value, RNG can be deferred by using the Unlock command:
[Unlock]
Engine = CAAM
Features = RNG

Pls help confirm that both method could resolve my issue, right?

In the meantime, before I try this on a new board, I want to confirm with you on if it is possible to recovery my first bricked board. Do you have any suggestions?

Followed is detailed information abstracted from the doc for reference (maybe useful for other people as well).

------------------------------------------------------------------------------------------------------------------------------------------

3.3.2. RNG trim fuses
HAB provides two options for managing the hardware RNG available in CAAM. HAB can initialize the RNG, or defer the initialization for the CAAM Operating System driver to manage.
RNG trim fuses provide HAB with a value to program in CAAM. This value setting causes a delay so that sufficient entropy can be generated on the chip. This ensures that the RNG self-test passes during RNG initialization. If the self-test fails, HAB does not allow the device to continue booting if it is Closed. Only HAB sources the RNG Trim Fuse value. The CAAM driver needs to perform a similar RNG trim configuration, but the values it uses are built into the driver software.
NOTE
On HAB 4.2.0 and later the RNG is not instantiated by default, for older versions choose one of two methods, or the chip will not boot when the device is Closed.
3.3.2.1. Option 1 – Defer RNG instantiation for post HAB software (recommended)
Deferring the RNG instantiation is done by adding a command to the CSF signature data. This command informs HAB to skip the instantiation. As of all CST versions 2.3 and greater, this command is included in the CSF signature by default if CAAM engine is defined, unless it is overridden by the CSF description file. When deferring the RNG instantiation any operation that requires the RNG is not available during ROM boot, if necessary RNG can be instantiated in a later boot stage in U-Boot or Kernel. Although encryption and blob generation are not available, the HAB-signed or encrypted boot features are not affected.
The CSF configuration file is discussed later and you can find examples in Appendix D HAB4 CSF examples. Deferring RNG instantiation is done by adding the following line in CSF Header:
[Header]
Engine = CAAM
In case that Engine must be set to other configuration value, RNG can be deferred by using the Unlock command:
[Unlock]
Engine = CAAM
Features = RNG

Thanks and best regards,

Shunnian

0 Kudos

194 Views
Yuri
NXP TechSupport
NXP TechSupport

shunnianzhai 

Hello,

   I think it makes sense to use both simultaneously :

1) change the engine to CAAM:

[Header]
Engine = CAAM

  2)
[Unlock]
Engine = CAAM
Features = RNG

 Note, alas - the "fused" board cannot be restored.

Regards,

Yuri.

194 Views
shunnianzhai
Contributor III

Hi Yuri,

Thanks for your information and confirmation. It is really helpful.

I will try your suggestions in a new board when it is available and keep you posted on the progress.

Hope that I will not brick another board with all these changes.

Thanks and regards,

Shunnian