<div dir="ltr">Ok. That clarifies the next steps. <br>You are correct; POK should be tested first without RTEMS integration.<div>My question was more about the separation between the RTEMS part of the interrupt handler and the POK part. If RTEMS registers a handler it will monopolize it; i.e. there is no possibility to run a POK handler and then an RTEMS handler. This is required to maintain segregation and to prevent RTEMS from interfering with POK. If RTEMS registers a handler for a vector already user by POK (e.g. clock tick interrupt), POK cannot be overruled and be dependent on RTEMS to run its own code. But for a first iteration it's OK to ignore this.<br>
<br><br>Cláudio<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 18, 2013 at 3:03 PM, Philipp Eppelt <span dir="ltr"><<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de" target="_blank">philipp.eppelt@mailbox.tu-dresden.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
currently I have no RTEMS partition running on POK, as these changes<br>
must first be validated with pure POK partitions. Also I haven't written<br>
the code to get a interrupt handler through the partition abstraction.<br>
CLOCK_HANDLER is a macro which is incrementing the tick counter and<br>
invoking the scheduler in the POK kernel.<br>
<br>
To register IRQ handlers from a partition, e.g. an RTEMS partition, I<br>
need to create a new syscall first, to get the callback function into<br>
the meta_handler list.<br>
<br>
So when RTEMS tries to attach to an interrupt, the virtualization layer<br>
implementation of POK is invoked and registers a predefined handler via<br>
a syscall with the meta_handler for this irq number. When the interrupt<br>
occurs the registered handler is invoked with the vector number as an<br>
argument. Then the handler invokes C_dispatch_isr() in RTEMS passing the<br>
vector number along.<br>
<br>
That's the plan, for the next week.<br>
<br>
Cheers,<br>
Philipp<br>
<div class="im"><br>
<br>
On 08/18/2013 02:45 PM, Cláudio Silva wrote:<br>
> Good job Philipp. It seems a nice first iteration for interrupt<br>
> virtualization. Did you get to try it?<br>
> If I got it right, the POK part of the interrupt handler (CLOCK_HANDLER<br>
> ??) is running after the virtualized RTEMS handler?<br>
><br>
> Regards,<br>
> Cláudio<br>
><br>
><br>
> On Sun, Aug 18, 2013 at 12:18 AM, Philipp Eppelt<br>
> <<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de">philipp.eppelt@mailbox.tu-dresden.de</a><br>
</div><div class="im">> <mailto:<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de">philipp.eppelt@mailbox.tu-dresden.de</a>>> wrote:<br>
><br>
> Hi,<br>
><br>
> lately I worked a lot to extend POK with necessary features to<br>
> accommodate an RTEMS partition.<br>
> Since hello world works, I need a way to pass clock ticks to the RTEMS<br>
> partition running on POK. Therefore the interrupt handling needs to<br>
> support custom handlers.<br>
><br>
> If everything works out, I can enable the virtualization layer to<br>
> register an interrupt vector and if it occurs RTEMS is notified by<br>
> invoking C_dispatch_isr().<br>
><br>
> Blog:<br>
> <a href="http://phipse.github.io/rtems/blog/2013/08/17/pok-hardware-interrupt-handling/" target="_blank">http://phipse.github.io/rtems/blog/2013/08/17/pok-hardware-interrupt-handling/</a><br>
><br>
> Source:<br>
> <a href="https://github.com/phipse/pok" target="_blank">https://github.com/phipse/pok</a><br>
><br>
> Cheers,<br>
> Philipp<br>
> _______________________________________________<br>
> rtems-devel mailing list<br>
</div>> <a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a> <mailto:<a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a>><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
><br>
><br>
<br>
</blockquote></div><br></div>