Hi Fabio, Greg,

On Friday, September 14, 2012 5:15:17 PM, Fabio Estevam wrote:

On Fri, Sep 14, 2012 at 12:04 PM, Greg Topmiller Greg.Topmiller@jdsu.com wrote:

...

I downloaded the V2012.07 version of u-boot from the git.denx.de repository and built it for our target. U-boot boots up properly and I can use the commands but now when I boot into Linux I don't seem to be getting interrupts. The Linux kernel hangs in the calculate_delay function waiting for ticks != jiffies. I do not get the interrupt for the timer. I have verified that our previous u-boot that is based on the 2009.12 version with Freescale patches does work. The timer interrupt occurs and jiffies is incremented allowing the loop to exit. Any help would be appreciated.

Which board are you using?

Same here with a custom i.MX51-based board and a FSL-based Linux. It works fine with the FSL-based U-Boot (2009.12).

Some debugging has shown that: - The Linux timer is based on GPT. - The GPT counter runs fine at 8 Mincrements/s as expected. - The interrupt handler is never called. - The interrupt is based on output compare, but forcing the OC value a little bit after the counter value does not trigger the interrupt handler. - Resetting the GPT and clearing its registers prior to Linux timer init does not help. - There does not seem to be any wait or sleep modes involved. - In this loop, CPSR shows supervisor mode with FIQ disabled and IRQ enabled (same for both U-Boot versions). - This version of Linux does not set VBAR. Neither does the older U-Boot contrary to the latest, but setting VBAR to 0 like with the older U-Boot does not help.

The differences in system registers between these U-Boots are really small and seem insignificant. The GPT clock source used by these versions is different, but that should not be an issue with proper reinitialization in Linux.

The i.MX51 errata don't mention any issue like that, at least for GPT. ENGcm09114 is similar, but in a very different context.

The next step is to dig into the interrupt controller settings and vectors to check that Linux sets up everything properly. This issue is very likely caused by this FSL Linux that unduly relies on the bootloader to initialize something.

Best regards, Benoît

On 14/09/2012 18:13, Benoît Thébaudeau wrote:

Hi Stefano,

Hi Benoît,

On Friday, September 14, 2012 6:06:16 PM, Benoît Thébaudeau wrote:

...

Hi Fabio, Greg,

On Friday, September 14, 2012 5:15:17 PM, Fabio Estevam wrote:

...

On Fri, Sep 14, 2012 at 12:04 PM, Greg Topmiller Greg.Topmiller@jdsu.com wrote:

...

I downloaded the V2012.07 version of u-boot from the git.denx.de repository and built it for our target. U-boot boots up properly and I can use the commands but now when I boot into Linux I don't seem to be getting interrupts. The Linux kernel hangs in the calculate_delay function waiting for ticks != jiffies. I do not get the interrupt for the timer. I have verified that our previous u-boot that is based on the 2009.12 version with Freescale patches does work. The timer interrupt occurs and jiffies is incremented allowing the loop to exit. Any help would be appreciated.

Which board are you using?

Same here with a custom i.MX51-based board and a FSL-based Linux. It works fine with the FSL-based U-Boot (2009.12).

Some debugging has shown that:

• The Linux timer is based on GPT.
• The GPT counter runs fine at 8 Mincrements/s as expected.
• The interrupt handler is never called.
• The interrupt is based on output compare, but forcing the OC value

a little bit after the counter value does not trigger the interrupt handler.

• Resetting the GPT and clearing its registers prior to Linux timer

init does not help.

• There does not seem to be any wait or sleep modes involved.
• In this loop, CPSR shows supervisor mode with FIQ disabled and IRQ

enabled (same for both U-Boot versions).

• This version of Linux does not set VBAR. Neither does the older

U-Boot contrary to the latest, but setting VBAR to 0 like with the older U-Boot does not help.

The differences in system registers between these U-Boots are really small and seem insignificant. The GPT clock source used by these versions is different, but that should not be an issue with proper reinitialization in Linux.

The i.MX51 errata don't mention any issue like that, at least for GPT. ENGcm09114 is similar, but in a very different context.

The next step is to dig into the interrupt controller settings and vectors to check that Linux sets up everything properly. This issue is very likely caused by this FSL Linux that unduly relies on the bootloader to initialize something.

As the maintainer of mx51evk, have you tested that it works fine with U-Boot 2012.07 with both mainline Linux and FSL's Linux?

I do not test with FSL Linux, sorry. Users should test themselves and report if they have problems - FSL's kernel is an ancient version respect kernel.org.

We discussed also in the past if u-boot should anyway support very old versions of the kernel. My simply position was that if patches do not hurt the current development, they can be integrated.

This issue was already seen for MX53 in the past, see the following Fabio's commit:

commit 54cd1dee8f9537c2e3d5bfe2029bf31b2b1cf2f3 Author: Fabio Estevam fabio.estevam@freescale.com Date: Tue May 8 03:40:49 2012 +0000

mx53loco: Add CONFIG_REVISION_TAG

FSL 2.6.35 kernel assumes that the bootloader passes the CONFIG_REVISION_TAG information.

The kernel uses this data to distinguish between Dialog versus mc34708 based boards, and also to distinguish between revA and revB of the mc34708 based boards.

Suggested-by: Yu Li yk@magniel.com Signed-off-by: Fabio Estevam fabio.estevam@freescale.com Acked-by: Stefano Babic sbabic@denx.de

Best regards, Stefano Babic