On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval <amaan.che...@gmail.com> wrote:
> 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 > Congratulations! But why is the date 5/12/1990? I think it is supposed to be 12/31/1989. :) > > (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.) > This means your "outer" assembly language _ISR_Handler does not yet deal with "needs dispatch". On the 5 second tick, a task is unblocked and set up to preempt. The end of the ISR path has to be right to make this work. --joel > > 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
