Booting always from the secondary image with eMMC v5.0 and imx6 Quad Plus

[corentinmorisse]

Hi Community,

We have a custom board designed for a imx6DL using a design imx6qsabresd, booting from a eMMC v4.41, which is working fine.

We replaced the processor with a imx6 Quad Plus and use a eMMC v5.0

We use Linux 4.1.15 and u-boot 2016.03-r0.

But now, when we boot, the board boot from the secondary image almost all the time.

We created a secondary image (the same as the first) and booting from the second IVT table is always successful, so the u-boot and kernel seem correct.

Using Boot_Tester.exe, it show that when it boot from the secondary image the PERSIST_SECONDARY_BOOT is set (src_gpr10 = 0x40000000), but no software code seem to write it :

*********************************************

Boot Debug (106.1) for MX6DQ or MX6DQplus

Build: Nov 10 2015, 21:43:53

Freescale Semiconductor, Inc.

*********************************************

WDOG Fuse Disabled

Boot_cfg_1 = 0x6a

Boot_cfg_2 = 0x50

Boot_cfg_3 = 0x00

Boot_cfg_4 = 0x4b

SBMR2 = 0x0a000001

BMOD = 10 Boot from GPIO/Fuses

BT_FUSE_SEL = 0

DIR_BT_DIS = 0

SEC_CONFIG = 01

Persistent Reg Value: 0x40000000

iROM Version = 0x20

USB_ANALOG_DIGPROG = 0x00630100

Device = MX6 Dual/Quad Plus

Si Revision = 2.0

Log Entry #0 (0x00010002) BOOTMODE - Internal/Override

Log Entry #1 (0x000200f0) Security Mode - Open

Log Entry #2 (0x00030000) DIR_BT_DIS = 0

Log Entry #3 (0x00040000) BT_FUSE_SEL = 0

Log Entry #4 (0x00050001) Secondary Image Selected

Log Entry #5 (0x00060001) USDHC Boot

Log Entry #6 (0x00070000) Device INIT Call

Log Entry #7 (0x000700f0) Device INIT Pass

Log Entry #8 (0x00080000) Device READ Data Call Address: 0x00000000

Log Entry #10 (0x000800f0) Device READ Data Pass

Log Entry #11 (0x00080000) Device READ Data Call Address: 0x00000320

Log Entry #13 (0x000800f0) Device READ Data Pass

Log Entry #14 (0x00090000) HAB Authentication Status Code:

(0x000a0533) Invalid IVT

Log Entry #16 (0x00061004) Recovery Mode ECSPI

Log Entry #17 (0x00080000) Device READ Data Call Address: 0x00000000

Log Entry #19 (0x000800f0) Device READ Data Pass

Log Entry #20 (0x00090000) HAB Authentication Status Code:

(0x000a0533) Invalid IVT

Log Entry #22 (0x000c0000) Serial Downloader Entry

Log Entry #23 (0x00090000) HAB Authentication Status Code:

(0x000a0533) Invalid IVT

Log Entry #25 (0x000d0000) Serial Downloader Call

(0x0091712c) Address: 0x0091712c

Anybody have the same behavior and how to manage that ?

[corentinmorisse]

Hello,

It seems in fact that the problem isn’t completely solved: the machine start on the secondary image approximatively 40% of the time (so it better than before, but not totally solved).

[Yuri]

Hello,

  Is HAB used in the case ?
From the log we can see SEC_CONFIG = 01 (but Security Mode - Open),
also Invalid IVT as HAB status are detected.

 According to section 8.5.3.5 (Redundant Boot Support for Expansion Device)

of the i.MX6QP RM :

  For Closed mode, if there are failures during primary image authentication, the boot

ROM will turn on PERSIST_SECONDARY_BOOT bit (see Table 8-6) and perform

software reset. (After software reset, secondary image will be used.)

http://www.nxp.com/assets/documents/data/en/reference-manuals/iMX6DQPRM.pdf

Have a great day,
Yuri

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

[corentinmorisse]

Hello,

We don’t use HAB (the SEC_CONFIG is the eFUSE (section 8.3.1) and 01 is Open).

We install a valid IVT and the board always boot, but most of the time from the secondary.

[Yuri · Accepted solution]

Hello,

1.  

  Is it possible to look at detailed mapping (including IVT) information of both primary

and secondary boot images ? 

2.

  To be fully sure - is the system checked with the DDR Stress test ? 

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

Regards,

Yuri.

[corentinmorisse]

Hello,

Thanks for your answer.

We recalibrated the DDR and this solved the problem : our board now always start from the primary image.