On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval <amaan.che...@gmail.com> wrote: > Status update: The code is at a point where the APIC timer _should_ > work, but doesn't (it never starts ticking away, so when calibrating > with the PIT, and later starting the APIC timer to generate IRQs, > pretty much nothing happens). > > I suspect the cause being the APIC base relocation not working (the > APIC is located at 0xfee00000 in physical memory by default, and in > the code we write to an MSR to relocate it, because the page-mapping > scheme FreeBSD setup doesn't let us access such high physical memory - > only the first 1GiB of physical memory). > > On QEMU, the MSR accepts our write for the relocation and happily > spits it back out when read, but given the unresponsiveness of the > APIC timer despite enabling all the right bits, I suspect it's just a > "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our > changes to the APIC configuration either, supporting this theory). > QEMU _does_ reflect changes to the APIC by other operating systems > which don't relocate it, so I don't suspect its emulation being a > problem. > > On VirtualBox, the MSR simply silently swallows the write, and upon a > read, returns the original 0xfee00000 value again. This means that if > we can't relocate it, we can't access it at the moment either. > > The only real way to work around this is to have a paging scheme that > lets us access physical address 0xfee00000 - in that case, we could > support page-faults and dynamically map pages in, _or_ have static > pages that are absurdly large (such as 1GiB), letting the virtual > address do the heavy-lifting in terms of finding the > virtual-to-physical mapping. >
I recommend a few static super pages to get it working. It is simple and fits the prevailing RTEMS model. > Either way, I think this issue this close to the deadline basically > means the APIC timer won't be functional and make it upstream. > > I'll clean things up and send patches tomorrow for everything so far, > including all the stub-code which will become usable once our paging > scheme works fine. > > If anyone has any last-minute swooping ideas on how to save the APIC > timer, let me know! (Interrupts aren't masked, and as far as I can > tell, changing the "-cpu" flag on QEMU doesn't make a difference. I > don't have any ideas as to what else the problem could be.) > > In my final report, I'll make sure I document what's remaining in > clearer terms than I have in this email, so it's easier for other > contributors to pick it up too, if any are interested. > > </rant> > > On Tue, Aug 7, 2018 at 6:03 AM, Chris Johns <chr...@rtems.org> wrote: >> 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! ;) :) >> I feel old, too. >>> 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
