iMX6 - CPU Idle

[kars]

Hello,

In our custom board which is designed more closer to Sabrelite, I notice the following,

The Linux kernel boots successfully only when the hlt_counter in cpu_idle (arch/arm/kernel/process.c) is true.

Otherwise the kernel boot hangs when it boots the CPU-2

......

CPU1: Booted secondary processor

CPU2: Booted secondary processor

CPU2: failed to come online

However on the Sabrelite board the "hlt_counter++" addition is not needed. The kernel boots fine consistently without any modification.

I'm wondering why this condition is prevalent.  By adding this fix and going ahead, I notice that the temperature of the processor shoots very sharply (while in sabrelite this is not the case).

Any inputs to identify the cause and fix the same will be appreciated.

Thanks.

Regards,

Karthikeyan.

-----

Other details,

Processor - imx6Q Rev1.2 on both custom board and Sabrelite board

SW - Android JB4.2.2_1.1 BSP (released in July '13) from Freescale.

The SW fix added at the moment,

<source/arch/arm/kernel/process.c>

179 void cpu_idle(void)

180 {

              disable_hlt(); /*Added - KARS*/

181         local_fiq_enable();

182

183         /* endless idle loop with no priority at all */

184         while (1) {

[LeonardoSandova]

Hi,

I am not sure if that BSP version has been tested on sabre lite. For your specific product, Is it possible to test a Boundary Device BSP instead of a Freescale one?

EricNelson, any idea about this?

Leo

[EricNelson]

We haven't pulled in the JB 4.2.2_1.1 patches yet, and don't yet have that in our kernel.

My guess is that the reason this isn't needed for SABRE Lite is that we're supplying the kernel parameter enable_wait_mode=off because we don't get woken up properly from some interrupt sources (ethernet is a known issue).

[kars]

Hello,

Thanks Eric, for the thought on enable_wait_mode.

By not using "enable_wait_mode=off" in the booargs of the custom board, I could get over the CPU online issue.

The kernel booting goes ahead. But this is not consistent. It hangs after a while at random places.

When I add the disable_hlt() in cpu_idle() as mentioned in my earlier post, the kernel boot is successfully taken over by the RFS initialization.

What could be the reason for these random kernel hangs?

I do not want to use disable_hlt() as a permanent fix as this causes the temperature shoot up drastically.

Karthikeyan.

[LeonardoSandova]

I may be related to the DDR settings you have on your u-boot. How did you set these? When kernel hangs, do you get some useful log on logcat/console?

Leo

[EricNelson]

Hi Leo,

Why did you bring up DDR settings? TroyKisky and I have been working an issue related to the DDR settings and CPU idle on SABRE Lite/Nitrogen6x.

I believe it's a different thing from what karthikeyans is reporting because all CPUs come on-line.

Karthikeyan, if you'd like to test things out, we've found that this patch is necessary in one obscure case of a Timesys image with no displays active and haven't yet determined why. The patch essentially reverts a patch provided by Benoît Thébaudeau on the U-Boot list.

[EricNelson]

Through a lot of testing, it looks like the DDR change isn't needed. We're able to reproduce a lockup on a Timesys image using a 3.0.35_1.1.1 kernel, but nowhere else. Oddly, it shows up only when no displays are connected, and can be bypassed by adding additional CPU load to the system.

The latest Timesys image(s), using 3.0.35_4.0.0 don't exhibit the same issue.

It appears that there was some form of timing bug in that image/kernel that wasn't hit with the slightly slower memory timings.

[LeonardoSandova]

Hi EricNelson

We had a issue with a customer's board (similar to i.MX6 SabreSD) with random hangs on Android. At the end, they have to do a chip re-spin AND change its DDR settings.  BTW, what is the size of the DDR? 4G? Is it LPDDR? For this customer, we have exactly the latter configuration.

[EricNelson]

Thanks Leo,

1GB/DDR3. These settings are also used in SABRE SD with main-line U-Boot, but I haven't tested to see whether that board also exhibits the symptom.

See this patch for details.

     http://git.denx.de/?p=u-boot.git;a=commitdiff;h=7c92c540754a0c3756d467a9b0695f2a40d1fe86

[kars]

If it is related to faulty DDR configuration, why should it work with the modified cpu_idle()?

With the added line in cpu_idle which forces hlt_counter to be true, the board always mounts RFS and goes ahead.

When the system hangs (with the unmodified cpu_idle) I do not see any kernel panic or dumps.

It just hangs during the boot process. The boot messages (during hang) do not give any additional info when compared to successful boot log.

Karthikeyan