Addition to status: it doesn't seem like the RTEMS Interrupt's call to _Thread_Dispatch functions either - ticker.exe has outputs like the following (yeah, the counter is running too quickly right now):
*** BEGIN OF TEST CLOCK TICK *** *** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified *** TEST STATE: EXPECTED-PASS *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0) TA1 - rtems_clock_get_tod - 11:34:12 05/12/1990 TA2 - rtems_clock_get_tod - 11:34:12 05/12/1990 TA3 - rtems_clock_get_tod - 11:34:12 05/12/1990 (And then the _Thread_Idle_body is never preempted due to the interrupt dispatching a new thread - not sure if it just thinks it's "too late" to even bother or if simply never even tries. I'll keep investigating.) On Thu, Aug 9, 2018 at 6:03 PM, Amaan Cheval <amaan.che...@gmail.com> wrote: > Hi everyone! > > Good news! The APIC timer _does_ work now (after implementing 1GiB > pages)! I see Clock_isr_ticks increasing steadily, though I don't have > tc_get_timecount implemented yet - I've yet to figure out the > specifics of the clock driver (how > rtems_configuration_get_microseconds_per_tick influences the > counter_ticks, specifically). > > I suspect we'll barely just make ticker.exe work by EOD tomorrow, > leaving just the weekend for me to clean the patches up and Monday to > actually merge them. > > Would someone be willing to have a meeting on Hangouts (or whatever) > with me to speed up the process of (1) upstreaming my patches and (2) > checking that my "work package" looks good enough at any convenient > time on Monday? > > (I'm a bit busy on Monday, so I'd really prefer to have this whole > thing done by EOD Monday for me.) > > On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom <ged...@rtems.org> wrote: >> 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