[GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a
Joel Sherrill
joel at rtems.org
Thu Aug 9 19:30:31 UTC 2018
On Thu, Aug 9, 2018 at 1:13 PM, Amaan Cheval <amaan.cheval at gmail.com> wrote:
> Haha, my tc_frequency was set all wrong, causing the date to be wonky.
>
> The dispatching issue turned out to be a (potential) QEMU bug where
> "decq" wouldn't set the ZF in EFLAGS even if it resulted in a 0 value,
> causing the "jne" to always be taken.
>
> Anyway, here's where we're at now:
>
> Start @ 0x1027f9 ...
> EFI framebuffer information:
> addr, size 0x80000000, 0x1d4c00
> dimensions 800 x 600
> stride 800
> masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> Filling 512 page tables
> 1gib pages not supported!
> maxphysaddr = 48
> sidt = ff f a8 39 34 0 0 0 0 0
> us_per_tick = 10000
> Desired frequency = 100 irqs/sec
> APIC was at fee00000
> APIC is now at fee00000
> APIC ID at *fee00020=0
> APIC spurious vector register *fee000f0=10f
> APIC spurious vector register *fee000f0=1ff
> CPU frequency: 0x57c60
> APIC ticks/sec: 0x57c6qemu-system-x86_64: warning: I/O thread spun for
> 1000 iterations
>
>
> *** 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 - 09:00:00 12/31/1988
> TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988
> TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988
> TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988
> TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988
> TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988
> TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988
> TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988
> TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988
> TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988
> TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988
> TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988
> TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988
> TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988
>
> *** END OF TEST CLOCK TICK ***
>
>
+1
>
> *** FATAL ***
> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> fatal code: 0 (0x00000000)
> RTEMS version: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
> RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
> executing thread ID: 0x08a010002
> executing thread name: TA1
> qemu-system-x86_64: terminating on signal 2
>
> -----------------------------------------------------------------
>
> 2 issues:
> - It isn't reliably this way - sometimes it may start at 9:00:01 (and
> then the rest are 6, 11, etc.). I'm using a very naive timecounter
> (number of IRQs occurred so far) right now - I'll have it account for
> the ticks since the last IRQ too, which I imagine may help with this?
>
Some of the simulators are odd this way. But I would expect this to
behave better. It is probably a calibration issue. There should be more
than enough time to do the prints and handle the tick ISRs. On some
simulators, it isn't that way.
The initialization should program it to get an interrupt based on the
configured microseconds per tick. You need the calibration or truth
speed to do this. I assume that calibration that would work on real
HW would work on qemu.
> - It is much slower than IRL time - I'm not sure if this is just due
> to QEMU or perhaps from ISRs piling over each other due to the handler
> taking too long. I'm not quite sure how to find out either.
>
This is expected. I recall it is ~2x IRL time for pc386 ticker.
>
> Let me know if you have any suggestions!
>
> Patches incoming soon too, so I'd appreciate reviews! :)
>
Nearly working is a great sign!
>
> On Thu, Aug 9, 2018 at 8:12 PM, Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> > 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.2f10634899719c2857e2c8dd5088fb
> 93a425fc83-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/c6710e00/attachment-0001.html>
More information about the devel
mailing list