[U-Boot] Don't get any interrupts once I boot into Linux

[Benoît Thébaudeau]

Hi Stefano,

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 at 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?

Best regards,
Benoît