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

Benoît Thébaudeau
2012-09-14T16:13:44Z

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@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