[GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

Chris Johns chrisj at rtems.org
Tue Aug 7 00:33:01 UTC 2018


On 07/08/2018 09:27, Joel Sherrill wrote:
> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval <amaan.cheval at gmail.com
> <mailto:amaan.cheval at gmail.com>> wrote:
> 
>     Thanks for all the help! I have a simple test using the RTEMS
>     interrupt manager working successfully (tested by calling
>     rtems_interrupt_handler_install for vector 0, and then triggering a
>     divide-by-0 exception).
> 
> Yeah! 
> 
>     Could someone shed any light on why the i386 only hooks the first 17
>     vectors as "RTEMS interrupts"?
> 
> You are making me feel very old especially since I have the real
> IBM manual in my office which corresponds to the answer.

Grandchildren, grey hair or Sebastian posting he is feeling old do not make you
feel old? Interesting! ;) :)

> It is dated Sept 1985. In fairness, I saved it from the garbage heap
> years later when someone was cleaning out their office. :)

Ah the good old days before the internet and search engines!!

> The x86 architecture is really vectored and the original i386
> port actually used simple direct vectoring since the first BSP wasn't
> a PC. Imagine that!  Another board using an i386 which didn't
> look like a PC at all. 
> 
> For better or worse, the PC/AT (286) and later used two i8259 PICs 
> in a master and slave configuration. The slave PIC cascaded off the 
> master PIC. This all fed into one CPU IRQ so many of the direct
> vectors were unused. The PIC arrangement is described here:
> 
> https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)
> 
>     Here's what I'm aiming to get done before the GSoC deadline:
> 
>     - Remap PIC (masking/disabling the PIC doesn't stop it from generating
>     spurious interrupts (IRQ7), which would look like exceptions to us)
>     - Disable PIC
>     - Enable APIC (done already, but confirm it plays well with the recent
>     changes to the IDT)
>     - Enable the PIT timer and use it to calibrate the APIC timer
>     - Clock driver using the APIC timer - (1) generate interrupts on ticks
>     and (2) tc_get_timecount function which calculates total time passed
>     through calculating (number of IRQs occured * time_per_irq +
>     time_passed_since_last_irq (through tick counter))
> 
>     This does seem a bit ambitious given how short we are on time - I'll
>     finish this up even after the deadline if need be.
> 
>     What should our minimum deliverable be for this period? Should we try
>     to upstream the interrupt support before I finish the clock driver? (I
>     think we can have this discussion on Wednesday or so, since by then
>     I'll likely know how much progress on the clock driver remains.)
> 
> We could but do you think it is likely to have major changes based 
> on getting the tick working?
> 
> Try to see what gets done and post what you can by the end of GSoC.
> 
> Then we will all wait patiently for you to get it working if it isn't then.

I think this BSP code in our repo is the best place for it to be worked on.

Chris



More information about the devel mailing list