Re: [Xenomai-core] Porting xenomai to AT91RM9200

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- 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 --]