[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