Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 10/22/2012 09:22 PM, Wayne Warren wrote:

> This code is the __set_irq_handler function which, given an interrupt
> number/id, appears to set up an entry in an irq_desc array. This
> structure (irq_desc) appears to be the place to go for information
> related to a given IRQ id.
> 
> We seem to have discovered the problem, which was that this array was
> not initialized with enough slots...in
> arch/arm/plat-omap/include/play/irqs.h OMAP_GPMC_NR_IRQS was defined as
> 7 rather than 8 (there are actually 8 GPMC chip selects). In a
> roundabout way, this macro is used to calculate the array size for
> irq_desc.
> 
> Since gpmc_init() was using GPMC_CS_NUM as a bound in the for loop that
> was calling __set_irq_handler and the "irq" variable in that same
> function was initialized using OMAP_GPMC_IRQ_BASE, it seems like:
> 
>   - OMAP_GPMC_NR_IRQS should be used in the for loop instead of
> GPMC_CS_NUM,
>   - GPMC_CS_NUM should be used to define OMAP_GPMC_NR_IRQS,
>   - or at the very least, GPMC_CS_NUM and OMAP_GPMC_NR_IRQS should be
> set to the same constant value (8).
> 
> I think maybe the first two of those together should be the fix, but I
> am still fairly lost here. Temporarily, we have set OMAP_GPMC_NR_IRQS to
> 8 which eliminates the data abort exception that was occurring in
> __set_irq_handler.
> 
> But we still have a kernel panic. Stepping further through the
> start_kernel function in GDB leads to local_irq_enable() which after
> some investigation is preprocessed into __ipipe_unstall_root().
> 
> It is the last line of this function, "local_irq_enable_hw()" where the
> next data abort exception occurs. This line translates into the
> assembler instruction "cpsie i" which is the last instruction before
> __dabt_svc(). Any idea what might be going on there? 
> 
> Thanks again for your help and prompt replies, they are very helpful.


Chances are you are calling into Adeos code too early. Normally, the
first call to local_irq_enable() happens in init/main.c, after the call
to __ipipe_init() (you should see both in function start_kernel). I
suspect you can not call services such as __set_irq_handler too early in
the boot process.

-- 
                                                                Gilles.