i.MX53 hangs up in software reboot

[qiangluo]

We found an issue about iMX534 that it hangs in the reset state after we do software reboot. The probability is about one in 300 times. It can be duplicated by typing "reboot" at the command console or run a script that sends a "reboot" command to the console every 15 seconds for 1000 times. The failure indication is the iMX processor is stuck in the reset state and does not exit until power off and power on.

Are you aware of this issue? And is there a work-around for it?

[qiangluo]

This is the relevant DCD section in the flash_header.S for our board. Please see if this helps isolate the issue.

dcd_hdr:          .word 0x40A001D2 /* Tag=0xD2, Len=51*8 + 4 + 4, Ver=0x40 */

write_dcd_cmd:    .word 0x049C01CC /* Tag=0xCC, Len=51*8 + 4, Param=4 */

/* DCD */

MXC_DCD_ITEM(1, IOMUXC_BASE_ADDR + 0x554, 0x00300000)

MXC_DCD_ITEM(2, IOMUXC_BASE_ADDR + 0x558, 0x00300040)

MXC_DCD_ITEM(3, IOMUXC_BASE_ADDR + 0x560, 0x00300000)

MXC_DCD_ITEM(4, IOMUXC_BASE_ADDR + 0x564, 0x00300040)

MXC_DCD_ITEM(5, IOMUXC_BASE_ADDR + 0x568, 0x00300040)

MXC_DCD_ITEM(6, IOMUXC_BASE_ADDR + 0x570, 0x00300000)

MXC_DCD_ITEM(7, IOMUXC_BASE_ADDR + 0x574, 0x00300000)

MXC_DCD_ITEM(8, IOMUXC_BASE_ADDR + 0x578, 0x00300000)

MXC_DCD_ITEM(9, IOMUXC_BASE_ADDR + 0x57c, 0x00300040)

MXC_DCD_ITEM(10, IOMUXC_BASE_ADDR + 0x580, 0x00300040)

MXC_DCD_ITEM(11, IOMUXC_BASE_ADDR + 0x584, 0x00300000)

MXC_DCD_ITEM(12, IOMUXC_BASE_ADDR + 0x588, 0x00300000)

MXC_DCD_ITEM(13, IOMUXC_BASE_ADDR + 0x590, 0x00300040)

MXC_DCD_ITEM(14, IOMUXC_BASE_ADDR + 0x594, 0x00300000)

MXC_DCD_ITEM(15, IOMUXC_BASE_ADDR + 0x6f0, 0x00300000)

MXC_DCD_ITEM(16, IOMUXC_BASE_ADDR + 0x6f4, 0x00000000)

MXC_DCD_ITEM(17, IOMUXC_BASE_ADDR + 0x6fc, 0x00000000)

MXC_DCD_ITEM(18, IOMUXC_BASE_ADDR + 0x714, 0x00000000)

MXC_DCD_ITEM(19, IOMUXC_BASE_ADDR + 0x718, 0x00300000)

MXC_DCD_ITEM(20, IOMUXC_BASE_ADDR + 0x71c, 0x00300000)

MXC_DCD_ITEM(21, IOMUXC_BASE_ADDR + 0x720, 0x00300000)

MXC_DCD_ITEM(22, IOMUXC_BASE_ADDR + 0x724, 0x04000000)

MXC_DCD_ITEM(23, IOMUXC_BASE_ADDR + 0x728, 0x00300000)

MXC_DCD_ITEM(24, IOMUXC_BASE_ADDR + 0x72c, 0x00300000)

MXC_DCD_ITEM(25, ESDCTL_BASE_ADDR + 0x088, 0x35343535)

MXC_DCD_ITEM(26, ESDCTL_BASE_ADDR + 0x090, 0x4d444c44)

MXC_DCD_ITEM(27, ESDCTL_BASE_ADDR + 0x07c, 0x01370138)

MXC_DCD_ITEM(28, ESDCTL_BASE_ADDR + 0x080, 0x013b013c)

MXC_DCD_ITEM(29, ESDCTL_BASE_ADDR + 0x018, 0x00011740)

/* MXC_DCD_ITEM(30, ESDCTL_BASE_ADDR + 0x000, 0xc3190000) */

MXC_DCD_ITEM(30, ESDCTL_BASE_ADDR + 0x000, 0x83190000)

MXC_DCD_ITEM(31, ESDCTL_BASE_ADDR + 0x00c, 0x9f5152e3)

MXC_DCD_ITEM(32, ESDCTL_BASE_ADDR + 0x010, 0xb68e8a63)

MXC_DCD_ITEM(33, ESDCTL_BASE_ADDR + 0x014, 0x01ff00db)

MXC_DCD_ITEM(34, ESDCTL_BASE_ADDR + 0x02c, 0x000026d2)

MXC_DCD_ITEM(35, ESDCTL_BASE_ADDR + 0x030, 0x009f0e21)

MXC_DCD_ITEM(36, ESDCTL_BASE_ADDR + 0x008, 0x12273030)

MXC_DCD_ITEM(37, ESDCTL_BASE_ADDR + 0x004, 0x0002002d)

/* Mode register writes, CSD0 */

MXC_DCD_ITEM(38, ESDCTL_BASE_ADDR + 0x01c, 0x00008032)

MXC_DCD_ITEM(39, ESDCTL_BASE_ADDR + 0x01c, 0x00008033)

MXC_DCD_ITEM(40, ESDCTL_BASE_ADDR + 0x01c, 0x00028031)

MXC_DCD_ITEM(41, ESDCTL_BASE_ADDR + 0x01c, 0x092080b0)

MXC_DCD_ITEM(42, ESDCTL_BASE_ADDR + 0x01c, 0x04008040)

/* Mode register writes, CSD1 */

MXC_DCD_ITEM(43, ESDCTL_BASE_ADDR + 0x01c, 0x0000803a)

MXC_DCD_ITEM(44, ESDCTL_BASE_ADDR + 0x01c, 0x0000803b)

MXC_DCD_ITEM(45, ESDCTL_BASE_ADDR + 0x01c, 0x00028039)

MXC_DCD_ITEM(46, ESDCTL_BASE_ADDR + 0x01c, 0x09208138)

MXC_DCD_ITEM(47, ESDCTL_BASE_ADDR + 0x01c, 0x04008048)

MXC_DCD_ITEM(48, ESDCTL_BASE_ADDR + 0x020, 0x00001800)

MXC_DCD_ITEM(49, ESDCTL_BASE_ADDR + 0x040, 0x04b80003)

MXC_DCD_ITEM(50, ESDCTL_BASE_ADDR + 0x058, 0x00022227)

MXC_DCD_ITEM(51, ESDCTL_BASE_ADDR + 0x01C, 0x00000000)

BR

Qiang Luo

[bfac]

Hello Qiang Luo,

I apologize, I just noticed my mistake and am now editing this post.

This looks like an issue I faced in the past, related to a necessary delay on the SDRAM device initialization that is missing. https://community.freescale.com/message/281759#281759

"The controller must keep the memory lines quiet (except for CK) for the ZQ calibration time as defined in the Jedec (512 cycles for ZQCL after reset, 256 for other ZQCL and 64 for ZQCS)."

First step, as stated by Fabio above, please use a newer version of u-boot, the BSP L2.6.35_11.09.01 contains u-boot-2009.08.

Basically, you need to include some delay after the line below on flash_header.S file.

REG_LD_AND_STR_OP(42, 0x01c, 0x04008040)

This is how it will look like when added:

REG_LD_AND_STR_OP(33, 0x014, 0x01ff00db)

REG_LD_AND_STR_OP(34, 0x02c, 0x000026d2)

REG_LD_AND_STR_OP(35, 0x030, 0x009f0e21)

REG_LD_AND_STR_OP(36, 0x008, 0x12273030)

REG_LD_AND_STR_OP(37, 0x004, 0x0002002d)

REG_LD_AND_STR_OP(38, 0x01c, 0x00008032)

REG_LD_AND_STR_OP(39, 0x01c, 0x00008033)

REG_LD_AND_STR_OP(40, 0x01c, 0x00028031)

REG_LD_AND_STR_OP(41, 0x01c, 0x052080b0)

REG_LD_AND_STR_OP(42, 0x01c, 0x04008040)

     ldr r2, =500000

1:  nop

     subs r2, r2, #1

     bcs 1b

REG_LD_AND_STR_OP(43, 0x01c, 0x0000803a)

REG_LD_AND_STR_OP(44, 0x01c, 0x0000803b)

REG_LD_AND_STR_OP(45, 0x01c, 0x00028039)

REG_LD_AND_STR_OP(46, 0x01c, 0x05208138)

REG_LD_AND_STR_OP(47, 0x01c, 0x04008048)

REG_LD_AND_STR_OP(48, 0x020, 0x00005800)

REG_LD_AND_STR_OP(49, 0x040, 0x04b80003)

REG_LD_AND_STR_OP(50, 0x058, 0x00022227)

BR,

Bruno

[fabio_estevam · Accepted solution]

Thanks, Bruno.

I applied your suggestion against imx_v2009.08_12.09.01 version:

--- a/board/freescale/mx53_loco/flash_header.S

+++ b/board/freescale/mx53_loco/flash_header.S

@@ -124,6 +124,12 @@ plugin_start:

        REG_LD_AND_STR_OP(41, 0x01c, 0x00028031)

        REG_LD_AND_STR_OP(42, 0x01c, 0x052080b0)

        REG_LD_AND_STR_OP(43, 0x01c, 0x04008040)

+

+       ldr r2, =500000

+1:     nop

+       subs r2, r2, #1

+       bcs 1b

+

        REG_LD_AND_STR_OP(44, 0x01c, 0x0000803a)

        REG_LD_AND_STR_OP(45, 0x01c, 0x0000803b)

        REG_LD_AND_STR_OP(46, 0x01c, 0x00028039)

and I am not seeing the hang anymore.

I will try to fix this in mainline U-boot when I have a chance.

Regards,

Fabio Estevam

[qiangluo]

Thank you very much. The bug is solved.

[fabio_estevam]

Just wanted to follow-up on this topic by saying that I sent a patch to U-boot that fixes this hang issue:

http://git.denx.de/?p=u-boot.git;a=commitdiff;h=aee0013e53b339a573e2a8d66062fe87765aa3bd;hp=2d6286ab...

Regards,

Fabio Estevam

[fabio_estevam]

Hi Qiang Luo,

Unfortunately I don't have time to debug this, but I would like to help you.

Please try this old U-boot version:

uboot-imx.git - Freescale i.MX u-boot Tree

In this imx_v2009.08_12.09.01 the plugin method is used instead of DCD.

It will allow you to insert the required 'nop' delay as mentioned at:

HW Reset on i.MX53

Also, can you please ping the guy in that thread says he managed to provide a workaround?

Then if you manage to do the same, we can then try to fix mainline U-boot by converting the DDR initialization from DCD macro to C code that will run in SRAM via the SPL mechanism.

Regards,

Fabio Estevam

[fabio_estevam]

Hi Qiang,

I am testing the latest developmet branch for u-boot-imx (git.denx.de Git - u-boot/u-boot-imx.git/summary) and I do:

=> setenv bootcmd reset

=> save

=> reset

And then my mx53qsb (I am using the version with the Dialog DA9053 PMIC here) stays in reset loop.

I am running for an hour now and I don't see the hang.

Can you try running this same version?

Regards,

Fabio Estevam

[fabio_estevam]

Ok, I managed to reproduce the issue here as well.

Regards,

Fabio Estevam

[qiangluo]

Hi Fabio,

Glad to see your reply. You have also see the issue, right? What comments do you have?

BR

Qiang Luo

[fabio_estevam]

What is your U-boot version?

I think we need to do something like it was explained in the following thread

HW Reset on i.MX53

Regards,

Fabio Estevam

[qiangluo]

Hi Fabio,

U-Boot version:U-Boot 2009.08-20131016-ivmm99-00003-gdcc77f2-dirty (Feb 25 2014 - 14:57:25)

And the patch in HW Reset on i.MX53 is tried, but it did not seem to improve the reboot instability.

Is it verified ok on your side? And could you provide the modified flash_header.S file so avoid we may have some difference?

BR

Qiang Luo

[fabio_estevam]

Hi Qiang,

Does Bruno's suggestion help?

Regards,

Fabio Estevam

[fabio_estevam]

Looks like it is the same issue as reported here:

https://community.freescale.com/thread/319870

Regards,

Fabio Estevam