[GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

Thu Aug 9 14:42:12 UTC 2018

On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval <amaan.cheval at 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.cheval at 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 <gedare at rtems.org> wrote:
> >> On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval <amaan.cheval at 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 <chrisj at rtems.org> wrote:
> >>>> 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! ;) :)
> >>>>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180809/77b3e5c4/attachment-0002.html>