[EMAIL PROTECTED] 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-core@gna.org/msg01797.html (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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
