<div dir="ltr">That's it! I didn't get that dual handler design from the implementation on your blog. <br>You should also transition to "user mode" before calling the RTEMS handler. <br><br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Aug 18, 2013 at 7:33 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>
why only talking about it and not implementing it right away? ;)<br>
<br>
POK administers now one meta_handler per HW IRQ line. Each meta_handler<br>
consists of a vector number and table of the size<br>
POK_CONFIG_NB_PARTITION + 1. So the meta_handler can administer one<br>
handler per partition and one handler for the kernel. The clock tick,<br>
for instance, needs a kernel handler and can now be forwarded to a<br>
partition.<br>
The kernel handler is invoked on each interrupt before the partition<br>
handler is called.<br>
So there is no overruling of the POK kernel.<br>
<br>
As far as I tested it, the partition handler runs side by side with the<br>
kernel handler with a constant offset, as it is registered later in time.<br>
<br>
Cheers,<br>
Philipp<br>
<div class="im"><br>
<br>
<br>
<br>
On 08/18/2013 08:01 PM, Cláudio Silva wrote:<br>
> Ok. That clarifies the next steps.<br>
> You are correct; POK should be tested first without RTEMS integration.<br>
> My question was more about the separation between the RTEMS part of the<br>
> interrupt handler and the POK part. If RTEMS registers a handler it will<br>
> monopolize it; i.e. there is no possibility to run a POK handler and<br>
> then an RTEMS handler. This is required to maintain segregation and to<br>
> prevent RTEMS from interfering with POK. If RTEMS registers a handler<br>
> for a vector already user by POK (e.g. clock tick interrupt), POK cannot<br>
> be overruled and be dependent on RTEMS to run its own code. But for a<br>
> first iteration it's OK to ignore this.<br>
><br>
><br>
> Cláudio<br>
><br>
><br>
><br>
> On Sun, Aug 18, 2013 at 3:03 PM, Philipp Eppelt<br>
> <<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de">philipp.eppelt@mailbox.tu-dresden.de</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de">philipp.eppelt@mailbox.tu-dresden.de</a>>> wrote:<br>
><br>
> 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>
><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<br>
> (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>
> <mailto:<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de">philipp.eppelt@mailbox.tu-dresden.de</a>><br>
</div></div>> > <mailto:<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de">philipp.eppelt@mailbox.tu-dresden.de</a><br>
<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<br>
> the RTEMS<br>
> > partition running on POK. Therefore the interrupt handling<br>
> 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>
> ><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>
> > <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>
</div>> <mailto:<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>
><br>
<br>
</blockquote></div><br></div>