<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 6, 2018 at 8:13 AM, 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">Thanks for all the help! I have a simple test using the RTEMS<br>
interrupt manager working successfully (tested by calling<br>
rtems_interrupt_handler_<wbr>install for vector 0, and then triggering a<br>
divide-by-0 exception).<br></blockquote><div><br></div><div>Yeah! </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Could someone shed any light on why the i386 only hooks the first 17<br>
vectors as "RTEMS interrupts"?<br></blockquote><div><br></div><div>You are making me feel very old especially since I have the real</div><div>IBM manual in my office which corresponds to the answer.</div><div>It is dated Sept 1985. In fairness, I saved it from the garbage heap</div><div>years later when someone was cleaning out their office. :)</div><div><br></div><div>The x86 architecture is really vectored and the original i386</div><div>port actually used simple direct vectoring since the first BSP wasn't</div><div>a PC. Imagine that!  Another board using an i386 which didn't</div><div>look like a PC at all. </div><div><br></div><div>For better or worse, the PC/AT (286) and later used two i8259 PICs </div><div>in a master and slave configuration. The slave PIC cascaded off the </div><div>master PIC. This all fed into one CPU IRQ so many of the direct</div><div>vectors were unused. The PIC arrangement is described here:</div><div><br></div><div><a href="https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)">https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)</a><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">
<br>
Here's what I'm aiming to get done before the GSoC deadline:<br>
<br>
- Remap PIC (masking/disabling the PIC doesn't stop it from generating<br>
spurious interrupts (IRQ7), which would look like exceptions to us)<br>
- Disable PIC<br>
- Enable APIC (done already, but confirm it plays well with the recent<br>
changes to the IDT)<br>
- Enable the PIT timer and use it to calibrate the APIC timer<br>
- Clock driver using the APIC timer - (1) generate interrupts on ticks<br>
and (2) tc_get_timecount function which calculates total time passed<br>
through calculating (number of IRQs occured * time_per_irq +<br>
time_passed_since_last_irq (through tick counter))<br>
<br>
This does seem a bit ambitious given how short we are on time - I'll<br>
finish this up even after the deadline if need be.<br>
<br>
What should our minimum deliverable be for this period? Should we try<br>
to upstream the interrupt support before I finish the clock driver? (I<br>
think we can have this discussion on Wednesday or so, since by then<br>
I'll likely know how much progress on the clock driver remains.)<br></blockquote><div><br></div><div>We could but do you think it is likely to have major changes based </div><div>on getting the tick working?</div><div><br></div><div>Try to see what gets done and post what you can by the end of GSoC.</div><div><br></div><div>Then we will all wait patiently for you to get it working if it isn't then.</div><div><br></div><div>You do need to do a final report.</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">
<br>
Sorry about the rush near the deadline - getting the APIC functioning<br>
had a bunch more yak-shaving style issues than I anticipated.<br></blockquote><div><br></div><div>The x86 architecture is years of hack upon hack.</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>
On Wed, Aug 1, 2018 at 10:51 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
> I have started to reply twice but you jumped in ahead. :)<br>
><br>
> On Wed, Aug 1, 2018 at 12:12 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
> wrote:<br>
>><br>
>> If my previous email _is_ in fact correct, could someone confirm?<br>
>> Because this excerpt in the documentation here seems to contradict it<br>
>> (which was what lead to the confusion in the first place):<br>
>><br>
>><br>
>> <a href="https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#establishing-an-isr" rel="noreferrer" target="_blank">https://docs.rtems.org/<wbr>branches/master/c-user/<wbr>interrupt_manager.html#<wbr>establishing-an-isr</a><br>
>><br>
>> With my emphasis:<br>
>><br>
>> > The rtems_interrupt_catch directive establishes an ISR for the system.<br>
>> > The address of the ISR and its associated CPU vector number are specified to<br>
>> > this directive. This directive installs the **RTEMS interrupt wrapper in the<br>
>> > processor’s Interrupt Vector Table and the address of the user’s ISR in the<br>
>> > RTEMS’ Vector Table**. This directive returns the previous contents of the<br>
>> > specified vector in the RTEMS’ Vector Table.<br>
><br>
><br>
> Almost but Gedare and I left out a detail. rtems_interrupt_catch is ONLY<br>
> used on pure simple vectored architectures which do not use the<br>
> bsp_interrupt_*<br>
> or <rtems/irq.h> interfaces. Some embedded MCUs are so simple and have<br>
> plenty of vectors so you don't need the complexity of supporting a PIC. For<br>
> example, the m68k family had 256 direct vectors and I don't recall ever<br>
> seeing<br>
> a PIC.[1]<br>
><br>
> You should assume that you can ignore rtems_interrupt_catch and simple<br>
> vectored support for x86_64. See cpukit/rtems/intrcatch.c and I hope you<br>
> see an ifdef that results in the code disappearing on your port. Simple<br>
> vectored is FACE is your cpu.h. :)<br>
><br>
> [1] Disclaimer: The support for the <rtems/irq.h> interfaces is critical to<br>
> the<br>
> libbsd stack. We haven't discussed it but any architecture that is<br>
> sufficient<br>
> to run the new stack will have to support this interface. If someone wants<br>
> the<br>
> new stack on a 68040 VME board or a Coldfire board, we will have to find<br>
> the simplest, non-bloated way to support this. When doing the MIPS Malta,<br>
> we just converted the MIPS architecture away from simple vectored.<br>
><br>
> So support the bsp_interrupt_* infrastructure. :)<br>
><br>
> --joel<br>
><br>
>><br>
>><br>
>> On Wed, Aug 1, 2018 at 10:39 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>> wrote:<br>
>> > Okay, I think I understand finally. Sorry about the rambling!<br>
>> ><br>
>> > When rtems_interrupt_catch is called, that's installing a "raw" ISR by<br>
>> > modifying the processor specific table itself, so _ISR_Handler is<br>
>> > never called, but the user ISR is.<br>
>> ><br>
>> > When rtems_interrupt_handler_<wbr>install is called, that's an "RTEMS<br>
>> > interrupt", and we go through the _ISR_Handler -> dispatch route I<br>
>> > laid out earlier, leading to eventually the user's ISR.<br>
>> ><br>
>> > Thank you for letting me rubber-duck with you, everyone (let me know<br>
>> > if anything above sounds off, though!) :P<br>
>> ><br>
>> > On Wed, Aug 1, 2018 at 10:20 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>> > wrote:<br>
>> >> Thanks for the background!<br>
>> >><br>
>> >> Let's use the gen5200 as the ongoing example - my confusion arises<br>
>> >> here (correct me if any of the following points is incorrect!). In<br>
>> >> overly simplified call chains:<br>
>> >><br>
>> >> Register interrupt handler:<br>
>> >> -  bsp_interrupt_facility_<wbr>initialize() -> ppc_exc_set_handler(vec,<br>
>> >> C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] =<br>
>> >> C_dispatch_irq_handler<br>
>> >><br>
>> >> Interrupt handler called:<br>
>> >> - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch<br>
>> >> (irq-generic.h) -> bsp_interrupt_handler_table[<wbr>index].handler()<br>
>> >><br>
>> >> What I'm confused about is how the bsp_interrupt_handler_table is<br>
>> >> updated at all - I just haven't found the link between how the entries<br>
>> >> in the two tables are synchronized, where the tables are:<br>
>> >><br>
>> >> 1) the ppc_exc_handler_table (the processor IDT) and<br>
>> >> 2) the bsp_interrupt_handler_table (the RTEMS interrupt table)<br>
>> >><br>
>> >> ------------------------------<wbr>------------------------------<br>
>> >> Another similar chain of confusion for i386 is:<br>
>> >> - rtems_interrupt_catch (intrcatch.c) -> _ISR_Install_vector (isr.h)<br>
>> >> -> _CPU_ISR_install_vector (i386/idt.c) -> idt_entry_tbl[vector]<br>
>> >> updated<br>
>> >><br>
>> >> But the i386 dispatch code chain is:<br>
>> >> - _ISR_Handler (i386/irq_asm.S) -> BSP_dispatch_isr (i386/irq.c) -><br>
>> >> bsp_interrupt_handler_dispatch (irq-generic.h) -><br>
>> >> bsp_interrupt_handler_table[<wbr>index].handler()<br>
>> >><br>
>> >> But I don't see any updates to bsp_interrupt_handler_table that would<br>
>> >> let this work.<br>
>> >> ------------------------------<wbr>------------------------------<wbr>-<br>
>> >><br>
>> >> Would you happen to know what that "missing link" is?<br>
>> >><br>
>> >> On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
>> >>><br>
>> >>><br>
>> >>> On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>> >>>> wrote:<br>
>> >>>> > That's definitely very illuminating, thank you so much for all the<br>
>> >>>> > details!<br>
>> >>>> ><br>
>> >>>> > A few more questions that have arisen for me. Feel free to skip<br>
>> >>>> > over<br>
>> >>>> > them (I'll likely figure them out given enough time, so I'm only<br>
>> >>>> > asking in case any of them are obvious to anyone):<br>
>> >>>> ><br>
>> >>>> > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it<br>
>> >>>> > stores some of the data onto the stack?<br>
>> >>>> ><br>
>> >>>> the interrupt frame structure was introduced during 4.11 development.<br>
>> >>>> probably i386 never got updated to use a struct to encapsulate the<br>
>> >>>> interrupt frame. the interrupt frame should contain the registers<br>
>> >>>> that<br>
>> >>>> are preserved by the interrupt entry code I believe.<br>
>> >>><br>
>> >>><br>
>> >>> +1<br>
>> >>><br>
>> >>> Historically, there was no structure to represent the set of<br>
>> >>> registers and information saved on interrupt entry. Over time<br>
>> >>> this has been added.<br>
>> >>><br>
>> >>> i386  also is missing the SMP synchronization check in the<br>
>> >>> middle of the context which ensures it is safe for a thread to<br>
>> >>> be migrated.<br>
>> >>><br>
>> >>>><br>
>> >>>> > - There used to be defines in cpu.h regarding hardware/software<br>
>> >>>> > based<br>
>> >>>> > interrupt stacks, and how they'd be setup, which were made<br>
>> >>>> > superfluous[1] - I'm not quite sure how these are meant to work - I<br>
>> >>>> > see references to "stack high" and "stack low" and I'm not quite<br>
>> >>>> > sure<br>
>> >>>> > what the code is referencing when using those.<br>
>> >>>> ><br>
>> >>>><br>
>> >>>> a hardware interrupt stack is one that the hardware switches to<br>
>> >>>> during<br>
>> >>>> an interrupt. i think m68k has such.<br>
>> >>>><br>
>> >>>> most interrupt stacks in RTEMS are software-managed, meaning that<br>
>> >>>> RTEMS explicitly switches the stack region off the task stack and to<br>
>> >>>> an interrupt stack region.<br>
>> >>>><br>
>> >>>> some stacks start high and grow down, and some stacks start low and<br>
>> >>>> grow up. maybe this is what the "stack high" and "stack low" you<br>
>> >>>> mention are in relation to?<br>
>> >>><br>
>> >>><br>
>> >>> They are used to denote the top and bottom of the memory reserved<br>
>> >>> for the interrupt stack. One important use is in<br>
>> >>> cpukit/libmisc/stackchk/check.<wbr>c<br>
>> >>> to report on usage.<br>
>> >>><br>
>> >>>><br>
>> >>>><br>
>> >>>> > - c/src/lib/libbsp/no_cpu/no_<wbr>bsp/Makefile.am doesn't include<br>
>> >>>> > <a href="http://irq-sources.am" rel="noreferrer" target="_blank">irq-sources.am</a>, by the way (this is part of why I used to think a<br>
>> >>>> > lot<br>
>> >>>> > of what your email mentioned was unnecessary, until you...ahem,<br>
>> >>>> > pre-empted that line of thought and helped clarify it :P). Should I<br>
>> >>>> > add a ticket to update the no_bsp code to be more in line with<br>
>> >>>> > current<br>
>> >>>> > use?<br>
>> >>>> ><br>
>> >>>> Sure. I don't know that anyone is in particular maintaining<br>
>> >>>> no_cpu/no_bsp since we can't compile it, it is basically best effort<br>
>> >>>> stuff that sometimes we miss updating.<br>
>> >>><br>
>> >>><br>
>> >>> +1<br>
>> >>><br>
>> >>> Also there are variations based on simple vectored and PIC vectored<br>
>> >>> architectures.<br>
>> >>><br>
>> >>> The architecture is responsible for the managing the minimal actions<br>
>> >>> based on what the CPU does for an interrupt/exception. Logically<br>
>> >>> a PIC is part of the BSP even if it comes integrated with the CPU as<br>
>> >>> is common on x86 and SoCs. The PIC could fairly easily change<br>
>> >>> and the architecture is harder to change.<br>
>> >>><br>
>> >>>><br>
>> >>>><br>
>> >>>> > - My understanding of _ISR_Handler is that it'll be the handler for<br>
>> >>>> > _all_ interrupt vectors by default - it'll then dispatch interrupts<br>
>> >>>> > to<br>
>> >>>> > user-handlers (or internal handlers, for the timer, for eg.). Is<br>
>> >>>> > that<br>
>> >>>> > right? (I don't quite understand its interaction with the RTEMS<br>
>> >>>> > interrupt manager yet, but irq-generic's<br>
>> >>>> > "bsp_interrupt_handler_table"<br>
>> >>>> > seems to be the RTEMS equivalent to the processor-specific vector<br>
>> >>>> > table, and "bsp_interrupt_handler_<wbr>dispatch" seems to call the<br>
>> >>>> > actual<br>
>> >>>> > handler within that table as appropriate. Accurate? (I just haven't<br>
>> >>>> > found how that table actually gets its handlers setup besides<br>
>> >>>> > during<br>
>> >>>> > initialization, since rtems_interrupt_catch just calls<br>
>> >>>> > _CPU_install_vector, which updates the processor vector table, not<br>
>> >>>> > the<br>
>> >>>> > RTEMS interrupt manager vector table.)<br>
>> >>>> ><br>
>> >>>><br>
>> >>>> You have discovered a couple of different but related interrupt<br>
>> >>>> processing code bases.  I can see why you get confused.<br>
>> >>>><br>
>> >>>> Basically, a CPU port should support two kinds of interrupts that may<br>
>> >>>> be installed, "RTEMS" and "Raw" interrupts. The "Raw" interrupts are<br>
>> >>>> installed directly in the processor's vector table. For processors<br>
>> >>>> that use simple vectored interrupts, the "RTEMS" interrupts install a<br>
>> >>>> call to the _ISR_Handler() function in the processor's vector table,<br>
>> >>>> and will put the user's isr function pointer in the<br>
>> >>>> _ISR_Vector_table(), which is the RTEMS Interrupt Manager's vector<br>
>> >>>> table.<br>
>> >>>><br>
>> >>>> I'm not really familiar with the processors that use a different<br>
>> >>>> model<br>
>> >>>> for interrupt handling besides simple vectored. Probably, you will<br>
>> >>>> have to study one of them.<br>
>> >>>><br>
>> >>>> This irq-generic bsp_interrupt_* code is used by the "IRQ Server"<br>
>> >>>> that<br>
>> >>>> builds from the CPU port capabilities to allow for some advanced<br>
>> >>>> features like chaining multiple isrs from the same source. I don't<br>
>> >>>> think you want to be focusing on those right now, but I could be<br>
>> >>>> mistaken. I haven't spent much time looking at the IRQ Server<br>
>> >>>> codebase.<br>
>> >>><br>
>> >>><br>
>> >>> For the most part, the bsp_interrupt_* code is hung off of one<br>
>> >>> (or more) of the simple vectored sources. On many architectures,<br>
>> >>> you have very few "CPU vectors" and the bsp_interrupt_* is<br>
>> >>> the secondary layer managing the PIC. Notice that it is all<br>
>> >>> in C and thus isn't first level processing. And it doesn't deal<br>
>> >>> with RTEMS critical section, interrupt entry/exit, and dispatching..<br>
>> >>><br>
>> >>> For example, in its original form, the PowerPC didn't have many<br>
>> >>> "exceptions" (e.g. CPU vectors) at all. In fact, there was a single<br>
>> >>> External Exception which was always tied to a board dependent<br>
>> >>> PIC. The first level processing of PPC exceptions is in assembly<br>
>> >>> and deals with what I pointed you to in various _ISR_Handler's.<br>
>> >>> The External Exception handler now process bsp_interrupt_*.<br>
>> >>> The gen5200 BSP irq.c file has a bsp_interrupt_* implementation<br>
>> >>> which registers for two "exceptions" which both go to<br>
>> >>> C_dispatch_irq_handler() which reads the PIC, determines<br>
>> >>> the source(s), and dispatches (via bsp_interrupt_handler_<wbr>dispatch()<br>
>> >>> the registered IRQ.<br>
>> >>><br>
>> >>> If you think of this as two levels of processing, it should help.<br>
>> >>><br>
>> >>> The two levels of processing is for RTEMS interrupts which can<br>
>> >>> unblock threads, etc. The first level ensures that locking and<br>
>> >>> dispatching is handled.<br>
>> >>><br>
>> >>> As Gedare stated, there are also Raw interrupts which ignore<br>
>> >>> RTEMS and can't use RTEMS services. These should never<br>
>> >>> be anything but the highest priority interrupt in a system. The<br>
>> >>> RTEMS first level processing can switch to a dedicated<br>
>> >>> interrupt stack and mixing RTEMS and Raw IRQs can<br>
>> >>> screw up the stack handling as well as the interrupt nesting<br>
>> >>> count.<br>
>> >>><br>
>> >>> --joel<br>
>> >>><br>
>> >>>><br>
>> >>>><br>
>> >>>> Gedare<br>
>> >>>><br>
>> >>>> > - My understanding of the interaction between RTEMS' interrupt<br>
>> >>>> > manager<br>
>> >>>> > (i.e. support for nested interrupts and thread dispatch once an<br>
>> >>>> > interrupt ends) and the BSP's processor-specific interrupt manager<br>
>> >>>> > (code to use the APIC and IDT in my case) is that they're tied<br>
>> >>>> > together through the use of irq-generic.c's<br>
>> >>>> > "bsp_interrupt_initialize"<br>
>> >>>> > - is that right? (m68k never seems to call it, though, so perhaps<br>
>> >>>> > not?)<br>
>> >>>> ><br>
>> >>>> > Sorry about the rambling! To reiterate, I'll likely figure it out<br>
>> >>>> > given enough time, so if the answers aren't at the top of your<br>
>> >>>> > head, I<br>
>> >>>> > can figure it out without wasting your time :)<br>
>> >>>> ><br>
>> >>>> > [1] <a href="https://devel.rtems.org/ticket/3459#comment:11" rel="noreferrer" target="_blank">https://devel.rtems.org/<wbr>ticket/3459#comment:11</a><br>
>> >>>> ><br>
>> >>>> > On Wed, Aug 1, 2018 at 3:18 AM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>><br>
>> >>>> > wrote:<br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >> On Tue, Jul 31, 2018 at 3:05 PM, Amaan Cheval<br>
>> >>>> >> <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>> >>>> >> wrote:<br>
>> >>>> >>><br>
>> >>>> >>> Hm, I'm not sure what to look for in the other ports<br>
>> >>>> >>> specifically,<br>
>> >>>> >>> really.<br>
>> >>>> >>> The BSP porting documentation doesn't have a section on<br>
>> >>>> >>> interrupts, so<br>
>> >>>> >>> I'm<br>
>> >>>> >>> doing this on more of an "as it comes up" basis.<br>
>> >>>> >>><br>
>> >>>> >>> What I've got right now (the interrupt handlers in C) are what I<br>
>> >>>> >>> need<br>
>> >>>> >>> for<br>
>> >>>> >>> calibrating the APIC timer (through the PIT) - so simply hooking<br>
>> >>>> >>> IRQ0<br>
>> >>>> >>> (for<br>
>> >>>> >>> the timer) and IRQ7 (spurious vector), since those are needed for<br>
>> >>>> >>> the<br>
>> >>>> >>> timer<br>
>> >>>> >>> work to continue.<br>
>> >>>> >>><br>
>> >>>> >>> What constitutes as a requirement for basic interrupt support?<br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >> There used to be a generic porting guide. I can see that this<br>
>> >>>> >> particular<br>
>> >>>> >> section<br>
>> >>>> >> has bit rotted some but the interrupt dispatching section. Some of<br>
>> >>>> >> this<br>
>> >>>> >> will have evolved to support SMP and fine grained locking but the<br>
>> >>>> >> pseudo-code<br>
>> >>>> >> here will give you a push toward the right line of thinking:<br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >> <a href="https://docs.rtems.org/releases/rtemsdocs-4.10.2/share/rtems/html/porting/porting00034.html" rel="noreferrer" target="_blank">https://docs.rtems.org/<wbr>releases/rtemsdocs-4.10.2/<wbr>share/rtems/html/porting/<wbr>porting00034.html</a><br>
>> >>>> >><br>
>> >>>> >> The idea is that you need to ensure RTEMS knows it is inside an<br>
>> >>>> >> interrupt<br>
>> >>>> >> and the current locking scheme (old was dispatching, new is ...)<br>
>> >>>> >> is<br>
>> >>>> >> honored.<br>
>> >>>> >><br>
>> >>>> >> The ARM and PowerPC (plus RISCV) are good ports to look at for how<br>
>> >>>> >> SMP<br>
>> >>>> >> plays into this. But the CPU supplement is thin for their<br>
>> >>>> >> interrupt<br>
>> >>>> >> processing.<br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >> This is the CPU Architecture supplement section for the m68k. This<br>
>> >>>> >> is a<br>
>> >>>> >> relatively simple<br>
>> >>>> >> architecture to describe. There is also a section for the i386<br>
>> >>>> >> which<br>
>> >>>> >> reads<br>
>> >>>> >> similarly.<br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >> <a href="https://docs.rtems.org/branches/master/cpu-supplement/m68xxx_and_coldfire.html#interrupt-processing" rel="noreferrer" target="_blank">https://docs.rtems.org/<wbr>branches/master/cpu-<wbr>supplement/m68xxx_and_<wbr>coldfire.html#interrupt-<wbr>processing</a><br>
>> >>>> >><br>
>> >>>> >> Personally, I find the m68k a fairly easy processor to read<br>
>> >>>> >> assembly<br>
>> >>>> >> in.<br>
>> >>>> >> Look at cpukit/score/cpu/m68k/cpu_asm.<wbr>S and _ISR_Handler to see<br>
>> >>>> >> what<br>
>> >>>> >> is done there w/o SMP. On the m68k _ISR_Handler is directly put<br>
>> >>>> >> into<br>
>> >>>> >> the<br>
>> >>>> >> vector table. But this isn't the most similar example for you.<br>
>> >>>> >><br>
>> >>>> >> For the i386 (better example), it is in<br>
>> >>>> >> bsps/i386/shared/irq/irq_asm.S<br>
>> >>>> >> with<br>
>> >>>> >> the<br>
>> >>>> >> same name. There _ISR_Handler is installed via the<br>
>> >>>> >> DISTINCT_INTERRUPT_ENTRY<br>
>> >>>> >> macros at the bottom of the file where some prologue jumps to the<br>
>> >>>> >> common<br>
>> >>>> >> _ISR_Handler and then the actions are similar. Usually<br>
>> >>>> >> _ISR_Handler<br>
>> >>>> >> type of<br>
>> >>>> >> code ends up invoking a PIC decode method in normal C without an<br>
>> >>>> >> interrupt attribute.<br>
>> >>>> >><br>
>> >>>> >> Long and multi-architecture answer but maybe that makes sense. The<br>
>> >>>> >> goal<br>
>> >>>> >> in ticker.exe is to take a number of tick interrupts which don't<br>
>> >>>> >> schedule<br>
>> >>>> >> and<br>
>> >>>> >> then take one that does -- it schedules a preemption of the idle<br>
>> >>>> >> thread.<br>
>> >>>> >><br>
>> >>>> >> Hope this helps.<br>
>> >>>> >><br>
>> >>>> >> --joel<br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >>><br>
>> >>>> >>><br>
>> >>>> >>> On Wed, Aug 1, 2018, 1:29 AM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>><br>
>> >>>> >>> wrote:<br>
>> >>>> >>>><br>
>> >>>> >>>><br>
>> >>>> >>>><br>
>> >>>> >>>> On Tue, Jul 31, 2018 at 2:52 PM, Amaan Cheval<br>
>> >>>> >>>> <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>> >>>> >>>> wrote:<br>
>> >>>> >>>>><br>
>> >>>> >>>>> Hi Chris!<br>
>> >>>> >>>>><br>
>> >>>> >>>>> I currently have code like this in<br>
>> >>>> >>>>> 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 -<br>
>> >>>> >>>>> can<br>
>> >>>> >>>>> we<br>
>> >>>> >>>>> pass these<br>
>> >>>> >>>>>     # flags only for the handlers.c source file (compile to an<br>
>> >>>> >>>>> 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.<br>
>> >>>> >>>>> (See<br>
>> >>>> >>>>> [1] and ctrl+f "interrupt" for more.)<br>
>> >>>> >>>>><br>
>> >>>> >>>>> Is there a way to not force the CFLAGS for _all_ of<br>
>> >>>> >>>>> librtemsbsp, but<br>
>> >>>> >>>>> to limit it only to handlers.c?<br>
>> >>>> >>>>><br>
>> >>>> >>>>> If not, is the above code something that would be acceptable to<br>
>> >>>> >>>>> have<br>
>> >>>> >>>>> upstream?<br>
>> >>>> >>>>><br>
>> >>>> >>>>> [1]<br>
>> >>>> >>>>><br>
>> >>>> >>>>><br>
>> >>>> >>>>> <a href="https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes" rel="noreferrer" target="_blank">https://gcc.gnu.org/<wbr>onlinedocs/gcc/x86-Function-<wbr>Attributes.html#x86-Function-<wbr>Attributes</a><br>
>> >>>> >>>><br>
>> >>>> >>>><br>
>> >>>> >>>> Are we basically talking about the outermost layer of your<br>
>> >>>> >>>> interrupt<br>
>> >>>> >>>> dispatching?<br>
>> >>>> >>>><br>
>> >>>> >>>><br>
>> >>>> >>>> Have you looked at the basic approach taken by the other ports?<br>
>> >>>> >>>> They<br>
>> >>>> >>>> end<br>
>> >>>> >>>> up switching the stack pointer to a dedicated stack on the<br>
>> >>>> >>>> outermost<br>
>> >>>> >>>> interrupt<br>
>> >>>> >>>> and, if a context switch/dispatch is needed, arrange for the<br>
>> >>>> >>>> interrupted<br>
>> >>>> >>>> task to call _Thread_Dispatch.But tinker with its stack so some<br>
>> >>>> >>>> registers<br>
>> >>>> >>>> are saved and it looks like it made the call itself.<br>
>> >>>> >>>><br>
>> >>>> >>>> If you can do it in C, I am ok with an attribute. I just don't<br>
>> >>>> >>>> think<br>
>> >>>> >>>> you<br>
>> >>>> >>>> can pull off all the stack and return to dispatch magic that<br>
>> >>>> >>>> way.<br>
>> >>>> >>>><br>
>> >>>> >>>> --joel<br>
>> >>>> >>>><br>
>> >>>> >><br>
>> >>><br>
>> >>><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>