iMX6D Failure to Boot

[ericholmberg]

I am seeing an issue where some of our iMX6D boards are failing to boot from a Power-on-Reset (POR).  The failure rate for affected boards is between 3% and 10% of the POR.

The system is booting from eMMC and I changed U-Boot to use the Boot Rom Plug-in IVT which allows writing to the UART from the plug-in entry (plugin_start):

plugin_start:

push {r0-r4, lr}

/* UART Output */
// enable clock
ldr r0, =0x020c407c
ldr r1, =0xffffffff
str r1, [r0, #0]

// Setup PAD and MUX
ldr r0, =0x020e0000
ldr r1, =0x0001b0b1
str r1, [r0, #0x650]
str r1, [r0, #0x654]

ldr r1, =0x00000003
str r1, [r0, #0x280]
str r1, [r0, #0x284]

// Setup UART
ldr r0, =0x02020000
ldr r1, =0x00000000
str r1, [r0, #0x80]
str r1, [r0, #0x84]
ldr r1, =0x00004025
str r1, [r0, #0x84]

ldr r1, =0x00000004
str r1, [r0, #0x88]
ldr r1, =0x00008000
str r1, [r0, #0x8c]

ldr r1, =0x00000a00
str r1, [r0, #0x90]

ldr r1, =0x0000000f
str r1, [r0, #0xa4]

ldr r1, =0x00004025
str r1, [r0, #0x84]

ldr r1, =0x0000015b
str r1, [r0, #0xa8]
ldr r1, =0x00000001
str r1, [r0, #0x80]

// Send ROM->UBOOT
ldr r1, ='R'
str r1, [r0, #0x40]
ldr r1, ='O'
str r1, [r0, #0x40]
ldr r1, ='M'
str r1, [r0, #0x40]
ldr r1, ='-'
str r1, [r0, #0x40]
ldr r1, ='>'
str r1, [r0, #0x40]
ldr r1, ='P'
str r1, [r0, #0x40]
ldr r1, ='L'
str r1, [r0, #0x40]
ldr r1, ='U'
str r1, [r0, #0x40]
ldr r1, ='G'
str r1, [r0, #0x40]
ldr r1, ='I'
str r1, [r0, #0x40]
ldr r1, ='N'
str r1, [r0, #0x40]
ldr r1, ='\r'
str r1, [r0, #0x40]
ldr r1, ='\n'
str r1, [r0, #0x40]

// Setup DDR and clocks
imx6_ddr_setting
imx6_clock_gating
imx6_qos_setting

I do not see this output when the system fails, so it appears that the iMX6 either didn't boot or was unable to fetch data from the eMMC and never transfers control to the U-Boot plugin.

When the failure occurs, there is no USB serial loader on the USB port.  Power rails are all good and the 32.768 kHz and 24 MHz clocks are running.

I didn't find any known errata that matches this issue and I don't have access to the memory bus to check the eMMC.

Any suggestions on what else to look at?

[igorpadykov]

Hi Eric

if issue happens only with Plug-in IVT (seems it also configures clocks) one can consider EB790

Configuration of Phase Fractional Dividers

if issue happens even without Plug-in IVT one can consider below link

https://community.nxp.com/t5/i-MX-Processors/eMMC-8GB-to-4GB-crash-on-linux-yocto-boot/m-p/373231

Best regards
igor

[ericholmberg]

The issue happens both with the Plug-in IVT and with the DCD IVT approach.

I updated the UART code to only enable CG12 and CG14 in CCGR5 and there was no difference in the failure rate.

No PFDs are enabled at this point as the assembly code shown above is the first time control is passed from the iMX6 boot ROM to the IVT code in eMMC.

I looked at the drive strength issue in https://community.nxp.com/t5/i-MX-Processors/eMMC-8GB-to-4GB-crash-on-linux-yocto-boot/m-p/373231 and this is in the Linux kernel boot which is much later.  I am seeing a failure in the iMX6 boot ROM before control is transferred to U-Boot.

[ericholmberg]

Some further details on this.  This is a new failure that we have been seeing recently and our eMMC chip was changed to a eMMCv5.0 part.  I see this in the iMX6 manual -- is this still true or was this just because v5.0 had not been released yet?

Our board holds the reset pin for 250ms after power-up.  If I extend that delay to 750ms, then the 10% boot failure not longer occurs.

I have set fuse 0x460[21] WDOG_ENABLE in hopes that at least the system would reboot after a maximum of 90 seconds, but even that does not work.

Any more ideas?

[igorpadykov]

eMMCv5.0 are also supported as it is backward compatible with eMMCv4.4.

if issue happens without adding custom writing to the UART codes, with original dcd ?

Best regards
igor

[ericholmberg]

Yes, the issue occurs without the UART debug code in both the plug-in IVT and with the original DCD.  I just added the UART debug code since I do not have access to JTAG.  No USB devices is present when the failure occurs, so the iMX6 has not gone into serial download mode.  It seems to have locked in the boot ROM somewhere.  This only happens around 10% of the time on some hardware.  Power rails all look good.  If I hold the iMX6 reset pin low for 750ms, the issue no longer occurs.

eFuses for eMMC are set as follows.  Right now MMC Speed is set to high speed, not sure if changing the Normal speed is an option or if it would have any affect.

Any thoughts here would be appreciated.  There was a similar issue, but no resolution here:  https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/EMMC-5-0-and-EMMC-5-1-work-on-i-MX6/tac-...

Thanks,

Eric

[igorpadykov]

> If I hold the iMX6 reset pin low for 750ms, the issue no longer occurs.

There is ERR007926 ROM: 32 kHz internal oscillator timing inaccuracy may affect
SD/MMC, NAND, and OneNAND boot [i.MX 6Dual/6Quad Only] with workaround:

"4. Extend the assertion of POR_B until the 32 kHz crystal oscillator is running and stable."

Chip Errata for the i.MX 6Dual/6Quad and i.MX 6DualPlus/6QuadPlus - IMX6DQCE

Best regards
igor

[ericholmberg]

Could you confirm if ERR007926 is hit that the iMX6 will lock and not go into serial download mode?  If it does a watchdog timeout after 90 seconds, that will be better than never recovering.  So far, it looks like the clocks are running but the iMX6 is stuck and the watchdog is also not triggered even when the WDOG_ENABLE (fuse 0x460[21]) is set.

I could add an external 32.768 kHz clock to the board to verify if the issue goes a way to confirm if this is the case.  Is there any other delay that is possible to configure?

[igorpadykov]

>Could you confirm if ERR007926 is hit that the iMX6 will lock and not go into serial download mode?

yes. If clock is not stable (for example due to big start-up times of 32.768KHz crystal) i.MX6D/Q

will not be able to properly initialize internal modules, including wdog, usb and other modules

Best regards
igor

[ericholmberg]

Confirmed that removing the 32.768 kHz crystal and using a signal generator as a clock source resulted in no POR failures.  So this is ERR007926.

We will fix any new hardware, but now have to figure out if there is anything that can done for hardware already in the field that cannot be easily reworked.  Are there any fuses that could slow down the boot process by at least 250ms?

[igorpadykov]

>We will fix any new hardware, but now have to figure out if there is anything

>that can done for hardware already in the field that cannot be easily reworked.

one can try to add RC on POR circuit to extend it

>Are there any fuses that could slow down the boot process by at least 250ms?

not sorry.

Best regards
igor