i.MX7D secure boot is hang without any message

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

i.MX7D secure boot is hang without any message

2,083 Views
jordan_chen
Contributor II

Hello,

    I studied secure boot doc (e.g. AN4581.pdf, AN12056.pdf) and tried to download signed boot image to device via mfgtool according to Step 4 ~ Step 6 of attached test procedures, but it was hang (for LED is not on) and console does not show any message after HW switch from serial download mode to internal mode. 

   Detailed info are listed in below. Could anyone provide advice which steps are wrong or how to debug it?

Thanks a lot.

No matter SRK fuses are blown or not,  DCD address is set to 0x910000 or 0x911000, it has the same symptom.

The device is not closed for I just blow SRK (and it can work if I download unsigned boot image).

1. [Device info] CPU: i.MX7D rev1.3, Boot code version: U-Boot 2017.03-nxp/imx_v2017.03_4.9.11_1.0.0

2. Refer to http://www.voidcn.com/article/p-rwpukyng-bdq.html and revised it for i.MX7D as attached.

    (1) Most of them are the same except u-boot image does not need to pad by ourselves.

    (2) According to Appendix F. i.MX manufacturing tool, user must set the image start address >= 0x911000 for i.MX7D Rev D.   

    (3) I don't set BOOT mode via command as step 6.4. (I set it via HW jump switch).

3. Download image via mfgtool

    (1) Replace signed boot image into mfgtools\Profiles\Linux\OS Firmware\files

    (2) Switch HW jump to serial download mode and download image to device.

         It would blow fuse for SRK and dump SRK via cat cat /sys/fsl_otp/HW_OCOTP_SRK0 ~ 7. (The SRK values are the same as we set)

    (3) Switch HW jump to internal mode

         => But LED is not on (device is hang?) and console does not show any message (e.g. boot version, CPU info, etc) after power on.

Regards,

Jordan

Labels (1)
0 Kudos
10 Replies

1,711 Views
jordan_chen
Contributor II

Hi Yuri,

     Thanks a lot for your help. It would show Invalid IVT Header as below. 

I also dump IVT Table via "od" command, it seems like IVT Header "0x402000d1" is the same with unsigned boot image and "E.1. Dumping U-boot binary" of AN4581.pdf.

BTW, I am not sure whether it would be impacted or not for the content of cst-3.1.0/keys/serial would be changed after executing hab4_pki_tree.sh script.

(e.g. echo 12345678 > serial, ./hab4_pki_tree.sh and generate keys, cat serial file, it would be changed to 12345684. My environment is Ubuntu 14.04, openssl 1.1.0j.)

[Dump IVT Table]

od -X -N 0x20 u-boot-imx7dsabresd.imx-nand
0000000 402000d1 87800000 00000000 00000000
0000020 877ff420 877ff400 8789e000 00000000

[Log Buffer Listing:]
Invalid IVT Header!

2409b827
1d090c08
c0f7a7be
57c3d702
dbd3afac
00000000
00000000
00000000

invalid_IVT_Header.jpg

Regards,

Jordan

0 Kudos

1,711 Views
Yuri
NXP Employee
NXP Employee

Hello,

  Image Vector Table Offset in i.MX7 is 0x400. 

Can You verify data on boot media?  

Regards,

Yuri.

0 Kudos

1,711 Views
jordan_chen
Contributor II

Hi Yuri,

     OK, I will get help from our EE to rework socket, then dump content of 0x400 from flash later.

BTW, I use Hexedit to change DCD and length which marked with BLUE color to be the same as unsigned boot image.

Then download this modified signed boot image via mfgtool, it can boot successfully.

I check hab_status at boot mode, it has error event.

I am not sure whether this is helpful to clarify original issue or not.

 Hardcode_DCD_and_Length.jpg

Regards,

Jordan

0 Kudos

1,711 Views
Yuri
NXP Employee
NXP Employee

Hello,

  have You tried exactly the procedures, described in Appendix F ( i.MX manufacturing tool) of

https://www.nxp.com/docs/en/application-note/AN4581.pdf 

?

Regards,

Yuri.

0 Kudos

1,711 Views
jordan_chen
Contributor II

Hi Yuri,

     Do I have to patch 0001-iMX7D-SabreSD-enable-HAB-boot-for-plugin-mode.patch and follow steps which mentioned in following link?

         https://community.nxp.com/docs/DOC-332725

         iMX7D Plugin mode HAB (High Assurance Boot)

     I tried to patch it according to our FAE's comment, but it's failed at patching imximage.cfg, mx7dsabresd.h, imximage.c.

It seems like my boot source code is different with this patch for L4.1.15_ga_1.2.0. (e.g. I can not find code with CONFIG_USE_PLUGIN as patch file for imximage.cfg in our sdk.)

Do you have this patch for "L4.9.11_1.0.0" or where can I download it? Thanks.

Regards,

Jordan

0 Kudos

1,711 Views
Yuri
NXP Employee
NXP Employee

Hello,

  Documentation in U-boot repo may be helpful:

https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx?h=imx_v2018.03_4.14.78_1.0.0_ga

Regards,

Yuri.

0 Kudos

1,711 Views
jordan_chen
Contributor II

Hi Yuri,

     Yes, I follow these procedures as attached "Appendix F Info.rar", except following items.

1. I just execute following items without

   (1) padding u-boot.bin firstly (for building with CONFIG_SECURE_BOOT will correctly pad the U-Boot image as mentioned in 3.4 of NA4581. I dump IVT table and the CSF address - Entry address is the same with build boot size).

   (2) And I don't pad for final image (to 0x4000 because it's option as mentioned in Figure 1. of NA4581. I ever tried to pad it, but the result is the same.)

     $ ./mod_4_mfgtool.sh clear_dcd_addr u-boot.bin 

     $ ../linux64/bin/cst -o csf_u-boot.bin -i csf_u-boot_mfg.txt

     $ ./mod_4_mfgtool.sh set_dcd_addr u-boot.bin

     $ cat u-boot.bin csf_u-boot.bin > u-boot-imx7dsabresd.imx-nand

2. I append SRK fuse blow in the end of block in ucl2.xml script (it can boot up successfully if I replaced signed boot image of "OS Firmware\files" folder to unsigned boot image.)

     I tried to set DCD address to be 0x910000 or 0x911000 in CSF, but the result is the same.

The NOTE of this Appendix mentioned "i.MX7D Rev D". I am not sure whether it means board ID or not (or CPU ID).

If board ID must be set to the same with EVK (Board is Rev. D), maybe I have to check with agent how to do it.

Regards,

Jordan

0 Kudos

1,711 Views
Yuri
NXP Employee
NXP Employee

Hello,

   The i.MX7D Rev D means i.MX7D Rev 1.3 Look at Figure 1 (Part number nomenclature) 

of i.MX7 Datasheet(s). This is the recent rev, where erratum e11166 [OCRAM: The first 4K of

OCRAM (0x910000 - 0x910fff) is not available during boot time] takes place.

Regards,

Yuri.

0 Kudos

1,711 Views
jordan_chen
Contributor II

Hi Yuri,

     Thanks a lot for this info that Rev D means the Silicon Revision.

My chip's part number is MCIMX7D7DVMIOSD and unsigned boot up with "CPU:   Freescale i.MX7D rev1.3". So that I have to set DCD address to 0x911000.

     I am not sure whether my ucl2_xml.txt of attached "Appendix F Info.rar" in previous reply is correct or not. The sample codes of NA4581  or forum are major based on i.MX6. I also tried to add "timeout" as NA4581's sample. Or, revise "BootStrap" to "Recovery", but it's failed to boot up with any message too.

<CMD state="BootStrap" type="find" body="BootStrap" timeout="180"/>

...

<CMD state="BootStrap" type="find" body="Updater" timeout="180"/>

Regards,

Jordan

0 Kudos

1,711 Views
Yuri
NXP Employee
NXP Employee

Hello,

  Would You please analyze boot log, using the utility I have sent You directly.


Have a great day,
Yuri

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos