<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 31, 2018 at 3:05 PM, Amaan Cheval <span dir="ltr"><<a href="mailto:amaan.cheval@gmail.com" target="_blank">amaan.cheval@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hm, I'm not sure what to look for in the other ports specifically, really. The BSP porting documentation doesn't have a section on interrupts, so I'm doing this on more of an "as it comes up" basis.<div dir="auto"><br></div><div dir="auto">What I've got right now (the interrupt handlers in C) are what I need for calibrating the APIC timer (through the PIT) - so simply hooking IRQ0 (for the timer) and IRQ7 (spurious vector), since those are needed for the timer work to continue.</div><div dir="auto"><br></div><div dir="auto">What constitutes as a requirement for basic interrupt support?</div></div></blockquote><div><br></div><div>There used to be a generic porting guide. I can see that this particular section</div><div>has bit rotted some but the interrupt dispatching section. Some of this</div><div>will have evolved to support SMP and fine grained locking but the pseudo-code</div><div>here will give you a push toward the right line of thinking:</div><div><br></div><div><a href="https://docs.rtems.org/releases/rtemsdocs-4.10.2/share/rtems/html/porting/porting00034.html">https://docs.rtems.org/releases/rtemsdocs-4.10.2/share/rtems/html/porting/porting00034.html</a><br></div><div><br></div><div>The idea is that you need to ensure RTEMS knows it is inside an interrupt</div><div>and the current locking scheme (old was dispatching, new is ...) is honored.</div><div><br></div><div>
<div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">The ARM and PowerPC (plus RISCV) are good ports to look at for how SMP</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">plays into this. But the CPU supplement is thin for their interrupt processing.</div>
<br></div><div><br></div><div>This is the CPU Architecture supplement section for the m68k. This is a relatively simple</div><div>architecture to describe. There is also a section for the i386 which reads similarly.</div><div><br></div><div><a href="https://docs.rtems.org/branches/master/cpu-supplement/m68xxx_and_coldfire.html#interrupt-processing">https://docs.rtems.org/branches/master/cpu-supplement/m68xxx_and_coldfire.html#interrupt-processing</a><br></div><div><br></div><div>Personally, I find the m68k a fairly easy processor to read assembly in.</div><div>Look at cpukit/score/cpu/m68k/cpu_asm.S and _ISR_Handler to see what</div><div>is done there w/o SMP. On the m68k _ISR_Handler is directly put into the</div><div>vector table. But this isn't the most similar example for you.</div><div><br></div><div>For the i386 (better example), it is in bsps/i386/shared/irq/irq_asm.S with the</div><div>same name. There _ISR_Handler is installed via the DISTINCT_INTERRUPT_ENTRY</div><div>macros at the bottom of the file where some prologue jumps to the common</div><div>_ISR_Handler and then the actions are similar. Usually _ISR_Handler type of </div><div>code ends up invoking a PIC decode method in normal C without an</div><div>interrupt attribute.</div><div><br></div><div>Long and multi-architecture answer but maybe that makes sense. The goal</div><div>in ticker.exe is to take a number of tick interrupts which don't schedule and </div><div>then take one that does -- it schedules a preemption of the idle thread.</div><div><br></div><div>Hope this helps.</div><div><br></div><div>--joel</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 1, 2018, 1:29 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 31, 2018 at 2:52 PM, Amaan Cheval <span dir="ltr"><<a href="mailto:amaan.cheval@gmail.com" rel="noreferrer" target="_blank">amaan.cheval@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris!<br>
<br>
I currently have code like this in c/src/lib/libbsp/x86_64/amd64/<wbr>Makefile.am:<br>
<br>
librtemsbsp_a_SOURCES +=<br>
../../../../../../bsps/x86_64/<wbr>amd64/interrupts/handlers.c<br>
# XXX: Needed to use GCC "interrupt" attribute directives - can we<br>
pass these<br>
# flags only for the handlers.c source file (compile to an object<br>
file first and<br>
# then link with the rest for librtemsbsp.a?)<br>
librtemsbsp_a_CFLAGS = -mgeneral-regs-only<br>
<br>
The CFLAGS arg is required to allow us to use<br>
"__attribute__((interrupt))" to setup interrupt handlers in C. (See<br>
[1] and ctrl+f "interrupt" for more.)<br>
<br>
Is there a way to not force the CFLAGS for _all_ of librtemsbsp, but<br>
to limit it only to handlers.c?<br>
<br>
If not, is the above code something that would be acceptable to have upstream?<br>
<br>
[1] <a href="https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes" rel="noreferrer noreferrer" target="_blank">https://gcc.gnu.org/<wbr>onlinedocs/gcc/x86-Function-<wbr>Attributes.html#x86-Function-<wbr>Attributes</a></blockquote><div><br></div><div>Are we basically talking about the outermost layer of your interrupt dispatching?</div><div><br></div><div><br></div><div>Have you looked at the basic approach taken by the other ports? They end</div><div>up switching the stack pointer to a dedicated stack on the outermost interrupt</div><div>and, if a context switch/dispatch is needed, arrange for the interrupted</div><div>task to call _Thread_Dispatch.But tinker with its stack so some registers</div><div>are saved and it looks like it made the call itself.</div><div><br></div><div>If you can do it in C, I am ok with an attribute. I just don't think you</div><div>can pull off all the stack and return to dispatch magic that way.</div><div><br></div><div>--joel</div></div><br></div></div>
</blockquote></div>
</div></div></blockquote></div><br></div></div>