i.MX6SL Failure of Recovery Boot from SPI NOR After HAB fails on SD

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6SL Failure of Recovery Boot from SPI NOR After HAB fails on SD

1,078 Views
wb_CN
Contributor II

Hi,

Can you help to confirm when HAB authentication fails, the boot ROM of i.MX6SL will eventually jump to recovery SPI NOR flash? Or it just stuck there forever?

 

My evaluation on i.MX6SLEVK shows that it would stuck there, this is contradictory with what the "High level boot sequence" has illustrated.

 

Details:

1.  My intention is to use SD card as primary boot device, use HAB to check the data integrity of u-boot on SD card, if authentication fails, boot ROM should jump to SPI NOR;

 

2. The setup, note the "EEPROM Recovery Enable" bit is 1;

i.MX6SLEVK;

SW3/BOOTCFG1_0~7: 0000 0010

SW4/BOOTCFG2_0~7: 0011 0100

SW5/BOOTCFG4 _0~7: 00010010

 

3. The problem:

- Managed to go through the workflow of generating keys, burning the SRK fuses, compiling the HAB u-boot.imx, and then flashed the SD card and on-board 4MB NOR flash, and then "close" the SEC_CONFIG for HAB. Verified HAB works fine:

 

=> hab_status

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99
=>

 

- But I found the yellow path doesn't work.  If I modify 1 bit in the u-boot image then flash it into SD card, then turn on the power switch, the board will get stuck forever, with nothing shown-up on serial console;

 

- Only the red path works, meaning I have to unplug the SD card then toggle the power switch of the EVK, then the boot ROM can jump to the SPI NOR to boot;

 

 

recovery_boot_not_work_with_HAB.png

5 Replies

592 Views
jimmychan
NXP TechSupport
NXP TechSupport

I got the result from the expert team:

To reproduce it I followed the following steps:

 

-> Generated a signed u-boot and flashed in a SD card

-> Stopped in u-boot, checked hab_status and flashed the SPI NOR by the following commands:

sf probe 0:0
setenv serverip $SERVERIP
setenv ipaddr $BOARDIP
tftp 0x80000000 u-boot.imx
sf erase 0x0 0x400000
sf write 0x80000000 0x400 $IMAGESIZE

 

-> Checked the IVT Entry Value in the signed image

$ od -x -N 48 u-boot-signed.bin
0000000 00d1 4020 0000 8780 0000 0000 f42c 877f
0000020 f420 877f f400 877f 7000 8785 0000 0000
0000040 f000 877f c000 0005 0000 0000 02d2 4080
0000060

 

-> Modified the IVT Entry value to 0x0 using the hexedit tool

$ od -x -N 48 u-boot-signed-modified.bin
0000000 00d1 4020 0000 0000 0000 0000 f42c 877f
0000020 f420 877f f400 877f 7000 8785 0000 0000
0000040 f000 877f c000 0005 0000 0000 02d2 4080
0000060

 

-> By booting this image the boot sequence goes through the yellow path. The image on the SDCard fails and the boot ROM jumps to the SPI NOR.

-> If I remove the SDCard the boot sequence goes through the red path and it's also working.

 

Please let me know if this works in the customer side so we can investigate more.

592 Views
wb_CN
Contributor II

Hi Jimmy and Bio_TICFSL,

Thank you for confirming that the yellow and red paths both work. Turned out the "stuck" happens due to DDR settings in DCD.

Can you please help to review the change I made in DCD script? also I'm wondering why problem only happens on my board which is the official EVK. Is there any other settings that need to be checked?

Details:

1. I'm using i.MX6SLEVK , the chip revision is 1.2, and the u-boot is compiled from official fsl-release-bsp as can be found in the U-Boot debug print-out:

U-Boot 2015.04imx_v2015.04_4.1.15_1.2.0_ga+gede7538 (May 11 2017 - 17:11:12)

CPU: Freescale i.MX6SL rev1.2 at 792 MHz

2.  Programmed a modified signed image to both SD and SPI NOR, found the device can be enumerated from USB, meaning the yellow path indeed should work, so in my case the code should be stuck somewhere after it has successfully authenticated the image on SPI NOR;

3. After some debug, found that by running-through the same DCD script twice in a single u-boot image, the boot code will also hang. Eventually, fix this hang-up problem by adding a single line  in imximage.cfg--to always clear the DDR control bytes before running the rest DDR initialization. Please help to review and comment:

DATA 4 0x020c4018 0x00260324

DATA 4 0x020c4068 0xffffffff
DATA 4 0x020c406c 0xffffffff
DATA 4 0x020c4070 0xffffffff
DATA 4 0x020c4074 0xffffffff
DATA 4 0x020c4078 0xffffffff
DATA 4 0x020c407c 0xffffffff
DATA 4 0x020c4080 0xffffffff

/* added for HAB, clear the control bits, otherwise the boot code will get stuck */
DATA 4 0x021b0000 0x03110000

DATA 4 0x020e0344 0x00003030
DATA 4 0x020e0348 0x00003030
DATA 4 0x020e034c 0x00003030
DATA 4 0x020e0350 0x00003030
DATA 4 0x020e030c 0x00000030
DATA 4 0x020e0310 0x00000030
DATA 4 0x020e0314 0x00000030

0 Kudos

592 Views
jimmychan
NXP TechSupport
NXP TechSupport

I got an update from the expert:

Just an update about the switch settings. By checking the table below I noticed the following configuration:

sw5conf.png

 

So the correct would be:

 

SW3[1-8]/BOOTCFG1_7~0: 0100 0000
SW4[1-8]/BOOTCFG2_7~0: 0010 1100
SW5[1-8]/BOOTCFG4_7~0: 0100 1000
Or
SW3[8-1]/BOOTCFG1_0~7: 0000 0010
SW4[8-1]/BOOTCFG2_0~7: 0011 0100
SW5[8-1]/BOOTCFG4_0~7: 0001 0000
0 Kudos

592 Views
wb_CN
Contributor II

Thanks Jimmy,

The LSB-first and MSB-first version don't match in your reply.

We currently use:

i.MX6SLEVK;

SW3/BOOTCFG1_0~7: 0000 0010

SW4/BOOTCFG2_0~7: 0011 0100

SW5/BOOTCFG4 _0~7: 00010010

We verified on i.MX6SLEVK that the "BT_CFG4_6 bit" needs to be set to 1 for EEPROM Recovery Enable, otherwise when the SD card is not present,  boot ROM will skip the SPI NOR and run to the state of "enumerated as USB HIB device and waiting for USB serial download".

Please help to review and confirm the DCD fix.

0 Kudos

592 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hi Wenbo,

Make sure that your board does not include the chip revision 1.3, if that the case please check if you need the HAB plugin patch:  http://cache.nxp.com/assets/documents/data/en/engineering-bulletins/EB803.pdf

Please look at example in the following thread that migh be helpful:

 https://community.nxp.com/thread/430948  

Regards

0 Kudos