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;
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.
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
I got an update from the expert:
Just an update about the switch settings. By checking the table below I noticed the following configuration:
So the correct would be:
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.
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