[Xenomai-core] Porting xenomai to AT91RM9200

[Xenomai-core] Porting xenomai to AT91RM9200

[Yann.LEPROVOST]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

Hi all,

I try to port xenomai/adeos to CSB637 Cogent Board featuring an AT91RM9200 
cpu.
My work is based on the integrator and the recent freescale port of adeos 
2.6.14 patch.

Concerning timer's interrupt, the system timer of the AT91RM9200 shares 
IRQ 1 with other peripherals (unlike freescale and integrator)
When I activate adeos ipipe feature in the kernel config, i obtain a 
report_bad_irq concerning IRQ 1.
When I activate xenomai, the kernel seems to freeze after calling idle 
task.

I wonder if adeos irq handling can deal with interrupt sharing ?
Any advice on xenomai porting to arm at91 are welcome.

Regards

Yann Leprovost

[-- Attachment #2: Type: text/html, Size: 1078 bytes --]

Re: [Xenomai-core] Porting xenomai to AT91RM9200

[Marco Cavallini]

Yann.LEPROVOST@wavecom.fr ha scritto:
> Hi all,
> 
> I try to port xenomai/adeos to CSB637 Cogent Board featuring an AT91RM9200 
> cpu.
> My work is based on the integrator and the recent freescale port of adeos 
> 2.6.14 patch.

Hi Yann,
Any news about such port ?

Ciao

/marco

Re: [Xenomai-core] Porting xenomai to AT91RM9200

[Yann.LEPROVOST]

Hi marco,

There is an issue with porting adeos to AT91RM9200. As i understood, adeos
handles system timer interrupt directly to keep real time "tsc" up to date.
To do that, porting xenomai to AT91RM9200 means coding the correct tsc
handling functions in arch/arm/mach-at91rm9200/time.c (in the same way as
integrator board).
That's what i tried to do...

But on AT91RM9200, the system interrupt timer line is shared among other
system peripherals such as watchdog, serial debug unit, memory controller,
...
I try to demux the interrupt sharing by modifying code of adeos irq
handling but there are specificities with the interrupt controller I can't
deal with...
I have lots of difficulties to understand the overall architecture of the
adeos/xenomai source code...

At this time, I have an adeos/xenomai patched kernel which freezes when
launching the idle process... and I 'm a bit lost !?!
Probably something wrong with the interrupt timer handling...
I'd like to continue to work on xenomai port to AT91RM9200 but I need
support from people with good knowledge of adeos internals... or a good
documentation starting point on adeos internal.

I currently stopped working on xenomai/adeos to study ingo molnar
patches...

Regards

Yann

xenomai-core-bounces@domain.hid a écrit sur 07/06/2006 15:24:47 :

> Yann.LEPROVOST@wavecom.fr ha scritto:
> > Hi all,
> >
> > I try to port xenomai/adeos to CSB637 Cogent Board featuring an
AT91RM9200
> > cpu.
> > My work is based on the integrator and the recent freescale port of
adeos
> > 2.6.14 patch.
>
> Hi Yann,
> Any news about such port ?
>
> Ciao
>
> /marco
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Porting xenomai to AT91RM9200

[Marco Cavallini]

Yann.LEPROVOST@wavecom.fr ha scritto:
> Hi marco,
> 
> There is an issue with porting adeos to AT91RM9200. As i understood, adeos
> handles system timer interrupt directly to keep real time "tsc" up to date.
> To do that, porting xenomai to AT91RM9200 means coding the correct tsc
> handling functions in arch/arm/mach-at91rm9200/time.c (in the same way as
> integrator board).
> That's what i tried to do...
> 
> But on AT91RM9200, the system interrupt timer line is shared among other
> system peripherals such as watchdog, serial debug unit, memory controller,
> ...
> I try to demux the interrupt sharing by modifying code of adeos irq
> handling but there are specificities with the interrupt controller I can't
> deal with...
> I have lots of difficulties to understand the overall architecture of the
> adeos/xenomai source code...
> 
> At this time, I have an adeos/xenomai patched kernel which freezes when
> launching the idle process... and I 'm a bit lost !?!

Could I please try testing your patch here ?

TIA
-- 
Marco Cavallini
Koan s.a.s. - Bergamo - ITALIA
Embedded and Real-Time Software Engineering
www.KoanSoftware.com   |    www.KaeilOS.com

Re: [Xenomai-core] Porting xenomai to AT91RM9200

[Yann.LEPROVOST]

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

Here is my patch against 2.6.15-at91 (including at91 patch from
http://maxim.org.za/AT91RM9200/2.6)
My patch include the ipipe patch found in xenomai 2.1.0 for ARM
architecture + my own modification and tests (sorry, lots of poor code for
debuging purpose).
I've changed the asm idle function specific to arm920 to disable use of
interrupt wakeup, just to see the behavior, but this is not the normal way
of running...

I will try to clear my code soon to produce a more comprehensive patch...
Here is a first watch.

Regards

Yann

(See attached file: 2.6.15-at91-ipipe-modified.patch.bz2)

xenomai-core-bounces@domain.hid a écrit sur 07/06/2006 17:45:27 :

> Yann.LEPROVOST@wavecom.fr ha scritto:
> > Hi marco,
> >
> > There is an issue with porting adeos to AT91RM9200. As i understood,
adeos
> > handles system timer interrupt directly to keep real time "tsc" up to
date.
> > To do that, porting xenomai to AT91RM9200 means coding the correct tsc
> > handling functions in arch/arm/mach-at91rm9200/time.c (in the same way
as
> > integrator board).
> > That's what i tried to do...
> >
> > But on AT91RM9200, the system interrupt timer line is shared among
other
> > system peripherals such as watchdog, serial debug unit, memory
controller,
> > ...
> > I try to demux the interrupt sharing by modifying code of adeos irq
> > handling but there are specificities with the interrupt controller I
can't
> > deal with...
> > I have lots of difficulties to understand the overall architecture of
the
> > adeos/xenomai source code...
> >
> > At this time, I have an adeos/xenomai patched kernel which freezes when
> > launching the idle process... and I 'm a bit lost !?!
>
> Could I please try testing your patch here ?
>
> TIA
> --
> Marco Cavallini
> Koan s.a.s. - Bergamo - ITALIA
> Embedded and Real-Time Software Engineering
> www.KoanSoftware.com   |    www.KaeilOS.com
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

[-- Attachment #2: 2.6.15-at91-ipipe-modified.patch.bz2 --]
[-- Type: application/octet-stream, Size: 392957 bytes --]

Re: [Xenomai-core] Porting xenomai to AT91RM9200

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

Yann.LEPROVOST@wavecom.fr wrote:
> Hi marco,
> 
> There is an issue with porting adeos to AT91RM9200. As i understood, adeos
> handles system timer interrupt directly to keep real time "tsc" up to date.
> To do that, porting xenomai to AT91RM9200 means coding the correct tsc
> handling functions in arch/arm/mach-at91rm9200/time.c (in the same way as
> integrator board).
> That's what i tried to do...
> 
> But on AT91RM9200, the system interrupt timer line is shared among other
> system peripherals such as watchdog, serial debug unit, memory controller,
> ...
> I try to demux the interrupt sharing by modifying code of adeos irq
> handling but there are specificities with the interrupt controller I can't
> deal with...
> I have lots of difficulties to understand the overall architecture of the
> adeos/xenomai source code...

Then please ask questions.

> 
> At this time, I have an adeos/xenomai patched kernel which freezes when
> launching the idle process... and I 'm a bit lost !?!
> Probably something wrong with the interrupt timer handling...
> I'd like to continue to work on xenomai port to AT91RM9200 but I need
> support from people with good knowledge of adeos internals... or a good
> documentation starting point on adeos internal.
> 
> I currently stopped working on xenomai/adeos to study ingo molnar
> patches...

Ah, I just remembered your thread on LKML. Then you may know that the
problem is the same with PREEMPT_RT. Thomas pointed out the only
solution: Write stubs to manage shared non-RT IRQ sources in RT context
(in PREEMPT_RT terms: create SA_NODELAY stubs for the otherwise threaded
drivers).

This problem pops up quite regularly, here is my standard reference for
a realisation of such a stub. It actually worked once over RTAI:

http://www.mail-archive.com/xenomai@xenomai.org
(grab the idea, not the API from this code)

The way I would go today: register a real-time IRQ handler for the
non-RT driver, silence the IRQ source in that handler (switch off IRQ
generation for the particular piece of hardware), save any required
information, and issue a soft-IRQ to the Linux domain. Attach the Linux
IRQ handler to the soft-IRQ then. In that handler, you could pick up the
reasons for the suppressed IRQ, handle it as usual and re-enable the IRQ
generation by the hardware. This way, the influence on the RT part
remains bounded.

The reason why this never made it into some real-time Linux variant:
it's too-hardware specific, there is not much you can do in the OS to
help solving this issue.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Porting xenomai to AT91RM9200

[Yann.LEPROVOST]

jan.kiszka@domain.hid a écrit sur 07/06/2006 18:34:24 :

> Yann.LEPROVOST@wavecom.fr wrote:
> > Hi marco,
> >
> > There is an issue with porting adeos to AT91RM9200. As i understood,
adeos
> > handles system timer interrupt directly to keep real time "tsc" up to
date.
> > To do that, porting xenomai to AT91RM9200 means coding the correct tsc
> > handling functions in arch/arm/mach-at91rm9200/time.c (in the same way
as
> > integrator board).
> > That's what i tried to do...
> >
> > But on AT91RM9200, the system interrupt timer line is shared among
other
> > system peripherals such as watchdog, serial debug unit, memory
controller,
> > ...
> > I try to demux the interrupt sharing by modifying code of adeos irq
> > handling but there are specificities with the interrupt controller I
can't
> > deal with...
> > I have lots of difficulties to understand the overall architecture of
the
> > adeos/xenomai source code...
>
> Then please ask questions.
>

__ipipe_handle_irq seems to dispatch each incoming interrupt to each domain
and acknowledge the interrupt controller with the incoming irq.
I think that "domain->irqs[irq].acknowledge(irq)" calls the irq
acknowledgement function of the specific AT91RM9200 irq chip... which
disables the
corresponding irq line on the interrupt controller. I have seen that the
call to the ack function has been removed from the do_level_IRQ...which
seems coherent.
The irq line is then reenabled on the interrupt controller when
do_level_IRQ is called from the Linux domain.

However, on the AT91RM9200 irq chip, we need to do a write to a special
register to indicate the end of the current interrupt handling (allowing
the controller
to reassert the cpu irq line if needed). This special write is handled by
irq_finish function. I though it had been the role of __ipipe_handle_irq to
call irq_finish. But the call
is done in asm_do_IRQ which I think is only called when running an irq of
the linux domain...
It could explain why my kernel freeze, doesn't it ?

Can anyone tell me if I'm totally wrong, or give me just a summary of how
irqs are normally handled between adeos domain and the irq controller ?


> >
> > At this time, I have an adeos/xenomai patched kernel which freezes when
> > launching the idle process... and I 'm a bit lost !?!
> > Probably something wrong with the interrupt timer handling...
> > I'd like to continue to work on xenomai port to AT91RM9200 but I need
> > support from people with good knowledge of adeos internals... or a good
> > documentation starting point on adeos internal.
> >
> > I currently stopped working on xenomai/adeos to study ingo molnar
> > patches...
>
> Ah, I just remembered your thread on LKML. Then you may know that the
> problem is the same with PREEMPT_RT. Thomas pointed out the only
> solution: Write stubs to manage shared non-RT IRQ sources in RT context
> (in PREEMPT_RT terms: create SA_NODELAY stubs for the otherwise threaded
> drivers).
>
> This problem pops up quite regularly, here is my standard reference for
> a realisation of such a stub. It actually worked once over RTAI:
>
> http://www.mail-archive.com/xenomai@xenomai.org
> (grab the idea, not the API from this code)
>
> The way I would go today: register a real-time IRQ handler for the
> non-RT driver, silence the IRQ source in that handler (switch off IRQ
> generation for the particular piece of hardware), save any required
> information, and issue a soft-IRQ to the Linux domain. Attach the Linux
> IRQ handler to the soft-IRQ then. In that handler, you could pick up the
> reasons for the suppressed IRQ, handle it as usual and re-enable the IRQ
> generation by the hardware. This way, the influence on the RT part
> remains bounded.
>
> The reason why this never made it into some real-time Linux variant:
> it's too-hardware specific, there is not much you can do in the OS to
> help solving this issue.
>

Well, I have not enough knowledge to appreciate your solution...
I though about some kind of irq line demultiplexing in the low level
function
in order to avoid irq line sharing. The idea was to change __ipipe_grab_irq
to demultiplex
each peripheral sharing the line and modifying the irq value send to
__ipipe_handle_irq in order
to have each peripheral a unique irq number...

Yann

Re: [Xenomai-core] Porting xenomai to AT91RM9200

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4966 bytes --]

Hi Yann,

short on time, short answer:

Yann.LEPROVOST@wavecom.fr wrote:
> jan.kiszka@domain.hid a écrit sur 07/06/2006 18:34:24 :
> 
>> Yann.LEPROVOST@wavecom.fr wrote:
>>> Hi marco,
>>>
>>> There is an issue with porting adeos to AT91RM9200. As i understood,
> adeos
>>> handles system timer interrupt directly to keep real time "tsc" up to
> date.
>>> To do that, porting xenomai to AT91RM9200 means coding the correct tsc
>>> handling functions in arch/arm/mach-at91rm9200/time.c (in the same way
> as
>>> integrator board).
>>> That's what i tried to do...
>>>
>>> But on AT91RM9200, the system interrupt timer line is shared among
> other
>>> system peripherals such as watchdog, serial debug unit, memory
> controller,
>>> ...
>>> I try to demux the interrupt sharing by modifying code of adeos irq
>>> handling but there are specificities with the interrupt controller I
> can't
>>> deal with...
>>> I have lots of difficulties to understand the overall architecture of
> the
>>> adeos/xenomai source code...
>> Then please ask questions.
>>
> 
> __ipipe_handle_irq seems to dispatch each incoming interrupt to each domain
> and acknowledge the interrupt controller with the incoming irq.
> I think that "domain->irqs[irq].acknowledge(irq)" calls the irq
> acknowledgement function of the specific AT91RM9200 irq chip... which
> disables the
> corresponding irq line on the interrupt controller. I have seen that the
> call to the ack function has been removed from the do_level_IRQ...which
> seems coherent.
> The irq line is then reenabled on the interrupt controller when
> do_level_IRQ is called from the Linux domain.
> 
> However, on the AT91RM9200 irq chip, we need to do a write to a special
> register to indicate the end of the current interrupt handling (allowing
> the controller
> to reassert the cpu irq line if needed). This special write is handled by
> irq_finish function. I though it had been the role of __ipipe_handle_irq to
> call irq_finish. But the call
> is done in asm_do_IRQ which I think is only called when running an irq of
> the linux domain...
> It could explain why my kernel freeze, doesn't it ?
> 
> Can anyone tell me if I'm totally wrong, or give me just a summary of how
> irqs are normally handled between adeos domain and the irq controller ?
> 
> 
>>> At this time, I have an adeos/xenomai patched kernel which freezes when
>>> launching the idle process... and I 'm a bit lost !?!
>>> Probably something wrong with the interrupt timer handling...
>>> I'd like to continue to work on xenomai port to AT91RM9200 but I need
>>> support from people with good knowledge of adeos internals... or a good
>>> documentation starting point on adeos internal.
>>>
>>> I currently stopped working on xenomai/adeos to study ingo molnar
>>> patches...
>> Ah, I just remembered your thread on LKML. Then you may know that the
>> problem is the same with PREEMPT_RT. Thomas pointed out the only
>> solution: Write stubs to manage shared non-RT IRQ sources in RT context
>> (in PREEMPT_RT terms: create SA_NODELAY stubs for the otherwise threaded
>> drivers).
>>
>> This problem pops up quite regularly, here is my standard reference for
>> a realisation of such a stub. It actually worked once over RTAI:
>>
>> http://www.mail-archive.com/xenomai@xenomai.org
>> (grab the idea, not the API from this code)
>>
>> The way I would go today: register a real-time IRQ handler for the
>> non-RT driver, silence the IRQ source in that handler (switch off IRQ
>> generation for the particular piece of hardware), save any required
>> information, and issue a soft-IRQ to the Linux domain. Attach the Linux
>> IRQ handler to the soft-IRQ then. In that handler, you could pick up the
>> reasons for the suppressed IRQ, handle it as usual and re-enable the IRQ
>> generation by the hardware. This way, the influence on the RT part
>> remains bounded.
>>
>> The reason why this never made it into some real-time Linux variant:
>> it's too-hardware specific, there is not much you can do in the OS to
>> help solving this issue.
>>
> 
> Well, I have not enough knowledge to appreciate your solution...

The topic is fairly complex, we pulled hairs earlier. ;)

> I though about some kind of irq line demultiplexing in the low level
> function
> in order to avoid irq line sharing. The idea was to change __ipipe_grab_irq
> to demultiplex
> each peripheral sharing the line and modifying the irq value send to
> __ipipe_handle_irq in order
> to have each peripheral a unique irq number...

As long as your IRQ sources share the same *physical* line, this will
buy you nothing. The hardware of all involved devices has to release the
IRQ line first in order to re-enable it. Otherwise, you will die in IRQ
storms. That's at least true for level-triggered IRQs (I haven't checked
a scenario with edge-triggering hardware yet).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]