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

[Wayne Warren <wwarren@emacinc.com>]

Yeah, this is actually an OMAP3 processor, except the kernel tree you
are using (if it is the Adeos I-Pipe one) I think was branched from the
vanilla kernel whereas the one we are using is branched from a TI kernel
released specifically for the AM3517 (previously known as OMAP3517, I
think? still confused about that).

The current problem is in __ipipe_stall_root(). After analyzing the
GDB-disassembled function, I can see that there are three "ldr" and one
"str" instructions that might be the cause of the Data Abort exception
that leads into the kernel panic. These instructions all load or store
values related to the __ipipe_percpu_darray variable. Specifically, they
deal with the first entry in this array, clear the status member (ldr,
bic) and write it back (str), check the value of irqpend_himap (ldr,
cmp) to determine if __ipipe_sync_stage should be called (the answer is
no), then try to re-enable interrupts using "cpsie"

The Data Abort exception actually occurs on the "cpsie" instruction, but
according to the ARMv7-A/ARMv7-R architecture reference manual, the
"CPS" type instructions do not generate any exceptions. However, the
manual also indicates that in Debug mode the behavior of the processor
when this instruction is called can be unpredictable.

Anyway, I am somewhat at a loss. The "ldr" and "str" instructions used
perform the operations as expected according to printouts of
__ipipe_cpu_darray.

Wayne

On Mon, 2012-10-22 at 23:12 +0200, Gilles Chanteperdrix wrote:
> On 10/22/2012 09:34 PM, Wayne Warren wrote:
> 
> > 
> >>
> >> 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.
> > 
> > In the code I am looking at, local_irq_enable() is called after
> > ipipe_init().
> > 
> > Are you saying that the __set_irq_handler() service should not be called
> > before ipipe_init() also? Cause it is called after ipipe_init_early()
> > but before ipipe_init().
> 
> 
> The same order happens on OMAP3 for the primary interrupt controller.
> So, that should work.
>