What timing i.MX6 ERR006282 is occurred on Linux boot sequence?

[satoshishimoda]

Hi community,

On our board, sometimes i.MX6 is fail to boot when subject back-to-bck reboot.

I guess, the root cause is ERR006282 "PFD in an unknown state" in IMX6DQCE (Rev.3), but I want to confirm whether this issue is caused by ERR006282 or not.

Then, could you let me know when this issue is occurred on Linux boot sequence?

1. Immediately after reboot and when no log is output to serial console.

2. When u-boot is working with some log on serial console.

3. When loading and umcompression kernel.

4. After boot Linux rootfs correctly.

Best Regards,

Satoshi Shimoda

[satoshishimoda]

Can someone reply to me?

[AnsonHuang · Accepted solution]

Hi, Satoshi

     When this issue occur, any PFD may not output correct clock signal, so it will cause failure if any module is using that failed PFDs. But in out uboot, we have a patch to fix this issue after uboot boot up, that means, if your uboot can boot up, then this issue will be fixed by the patch, the patch is as below. And when you meant reboot failed, did you see any log in debug console? And what test did you do, just using "reboot" command in kernel console, or power cycle the board everytime? As we need to identify where did it failed, in kernel or in ROM. BTW, you are using i.MX6Q, right? and which revision? Can you paste your uboot debug message?

commit b7c5badf94ffbe6cd0845efbb75e16e05e3af404

Author: Anson Huang <b20788@freescale.com>

Date:   Wed Dec 5 13:58:34 2012 -0500

    ENGR00235821 mx6: correct work flow of PFDs

    PFDs need to be gate/ungate after PLL lock to reset

    PFDs to right state. Otherwise PFDs may lose correct

    state in state-machine, then no output clock.

    For i.MX6DL and i.MX6SL, ROM have taken care of PFD396

    already since the bus clock needs it.

    Signed-off-by: Anson Huang <b20788@freescale.com>

[JithCR]

Hi Yongcai Huang,

We are facing a non-reboot issue with imx-android-r13.4-ga software in i.MX6Q.

We are doing a reboot test by giving "reboot" command in console and getting non-rebooting issue if we are repeating the test for 12 Hours.

The issue occurrence is not stable.But in long run,the issue is occurring.

Log below

reboot <..reboot command in console..>

SysRq : Emergency Remount R/O

sd 0:0:0:0: [sda] Synchronizing SCSI cache

Restarting system. <---Stops here....>

[AnsonHuang]

Hi, Jith

     I think first you need to identify whether the issue occur in kernel's reboot flow or in ROM/u-boot. I guess you can try adding some logs right before setting wdog to issue reboot in our BSP, or you can make cpufreq stay at 1GHz, then when issue occurs, you can measure the VDDARM_CAP's voltage to see whether it is 1GHz's voltage or lower, as in ROM, ARM is running at 792MHz/396MHz, the voltage is lower than 1GHz's. After you figure out the system hang point, we can do further debug.

[JithCR]

Hi Yongcai Huang,

We have measured VDDARM_CAP voltage at hang condition and observed 1.169V.

VDDARM_CAP voltage at normal/running condition is 1.270V

Based on the observation,Can we conclude that the hang point is in ROM?

[AnsonHuang]

Hi, Jith

     At normal running condition, did you mean you use performance governor? As if you use other cpufreq governor, then cpufreq is keeping changing according to its loading, there is chance that when hang, the cpufreq is running at 792MHz, its volatge for VDDARM is 1.175V as well. So, unless you force cpufreq stay at setpoint which VDDARM volatge is NOT 1.175V, but when hang, you got 1.175V on VDDARM_CAP, then we can say the hang point is in ROM or uboot.

[JithCR]

Hi Yongcai Huang,

I am using performance governor in Kernel.

[AnsonHuang]

OK, then I think the hang point is in ROM/u-boot. You can try using JTAG to attach the ARM core when hang.

[JithCR]

Hi Yongcai Huang,

Now we are considering the hang point can be in ROM or in U-boot.

Is it possible to isolate hang point again?

If we are checking the boot log can see below log

U-Boot 2009.08 (Oct 01 2014 - 14:29:27)

CPU: Freescale i.MX6 family TO1.2 at 996 MHz

Can we assume that in u-boot level also CPU frequency near to 1GHz.So the expected VDDARM_CAP voltage is 1.270Vso the hang point can be ROM?

[AnsonHuang]

The uboot log means your uboot increase CPU freq to 1GHz, but there is still chance that the hang point is in uboot but right before the point of increasing CPU freq. One method is to add GPIO or debug LED or debug message at the beginning of uboot, as when system hang, you did NOT see "U-Boot 2009.08 (Oct 01 2014 - 14:29:27)" at the console, so I guess it is very likely hang in ROM.

[JithCR]

Hi Yongcai Huang,

OK..I understand that we need to make use of GPIO/Debug LED at the initial stage of U-boot.So that we can come to know whether the hang point in Uboot or in ROM.

As of now can we conclude that the hang point can be in ROM/Uboot and not in Kernel?

[JithCR]

Hi Yongcai Huang,

We are trying to locate the hang point using a GPIO and update.

We would like to inform one more test update regarding the non-reboot issue.

Normally,we are giving reboot command using a script file,this script file will listen for  a particular string in the debug console and if the string is occurred,

then the reboot command will deliver to the debug console after 1 second delay.

flexcan imx6q-flexcan.1: writing ctrl=0x0e312005

request_suspend_state: wakeup (3->0) at 8491009337 (1970-01-02 00:06:04.795683668 UTC)

eth0: Freescale FEC PHY driver [Micrel KSZ9021 Gigabit PHY] (mii_bus:phy_addr=1:03, irq=-1)

ADDRCONF(NETDEV_UP): eth0: link is not ready <<--reboot command will be delivered and observed non-reboot issue.

In one test case,we have increased the delay to 10 seconds,so that after the particular string,the reboot command will be given after 10 second.In that case we are not getting the non-reboot issue.This we have tested around 41 hours.

We would like to know that whether there is any time delay concern with reboot command.

[AnsonHuang]

Hi, Jith

     As far as I know, there is no time delay concern with reboot command, all th reboot process is done by kernel common code, kernel will send our reboot notification for all drivers if some drivers need to handle something specific, our platform code only control the wdog to do reset, this is my understanding.

[JithCR]

Hi Yongcai Huang,

From our analyzing,we came to know that void arch_reset(char mode, const char *cmd) is reponsible for rebooting the system when we are delivering reboot command to the system.

For locating hang point we are switching ON a LED after configuring the watchdog control register.

(The LED will be off in Uboot and Linux booting  stage.So the LED will get ON from arch_reset function alone)

At the issue condition,the LED is keep on glowing.

So we are concluding that,the system reset is not done properly with watchdog controller because of some reason .(0x4 is configring to Watchdog controller register).

Please let us know your valuable comment on the same.

[satoshishimoda]

Hi Yongcai Huang,

Than you for your reply.

OK, I understand this erratum does not after if uboot can boot up.

And please see the attached file, it is the log when I executed "reboot stress test".

I used MCIMX6Q-SDP (silicon revision 1.2) and L3.0.35_4.1.0 BSP u-boot, kernel, and ubuntu oneiric image.

I made a script that executes "reboot NOW" and call it from /etc/init.d/rc.local.

So after power-up MCIMX6Q-SDP, reboot is repeated all the time.

According to the log, this issue occurred in the shutdown process.

Best Regards,

Satoshi Shimoda

[YixingKong]

Satoshi

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Yixing