[U-Boot-Users] interrupts in general / Fix for mcf5329evb - spurious interrupts on Linux/uClinux kernel boot

[Wolfgang Wegner <wolfgang@leila.ping.de>]

Hi Stefan,

On Fri, Aug 10, 2007 at 03:15:00PM +0200, Stefan Roese wrote:
> On Friday 10 August 2007, Wolfgang Denk wrote:
> > > Please correct me if I am wrong, but should not interrupts be completely
> > > disabled before transferring control to the linux kernel to avoid any
> > > confusion?
> >
> > Right.
> 
> IIRC the function we are talking about here is do_bootm_linux() (m68k version) 
> which is called from the common do_bootm() function. Before calling 
> do_bootm_linux() the follwing code is called:
> 
>         /*
>          * We have reached the point of no return: we are going to
>          * overwrite all exception vector code, so we cannot easily
>          * recover from any failures any more...
>          */
> 
>         iflag = disable_interrupts();
> 
> So at the point of do_bootm_linux() the interrupts should already be off. If 
> this is not the case, then it is probably better to fix this in the 
> disable_interrupts implementation of the ColdFire.

you are completely right. Sorry for not recognizing the previous call
to disable_interrupts in the first place, I only had looked at
do_bootm_linux() itself.

In fact, I also tried calling disable_interrupts() before the call to the
kernel, and it did not work.

The problem is that disable_interrupts is in lib_m68k/interrupts.c and
simply sets the interrupt level mask to 0x7:
        sr = get_sr ();
        set_sr (sr | 0x0700);

interrupt_init() almost does the opposite:
int interrupt_init(void)
{
        volatile int0_t *intp = (int0_t *) (CFG_INTR_BASE);

        /* Make sure all interrupts are disabled */
        intp->imrh0 |= 0xFFFFFFFF;
        intp->imrl0 |= 0xFFFFFFFF;

        enable_interrupts();
        return 0;
}

There must be something in the kernel that relies on the interrupts
being masked in the interrupt controller and not only in the processor,
but I can not check right now because I do not have the sourcecode of
uClinux I use at work here at home right now.

I do not know if we should blame uClinux here for relying on the
interrupt controller being in the reset (all sources disabled) state,
or if we should try to fix this in u-boot.

> Best regards,
> Stefan

Best regards,
Wolfgang