On 07/08/2018 09:27, Joel Sherrill wrote: > On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval <amaan.che...@gmail.com > <mailto:amaan.che...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
