<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 9, 2018 at 1:13 PM, Amaan Cheval <span dir="ltr"><<a href="mailto:amaan.cheval@gmail.com" target="_blank">amaan.cheval@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Haha, my tc_frequency was set all wrong, causing the date to be wonky.<br>
<br>
The dispatching issue turned out to be a (potential) QEMU bug where<br>
"decq" wouldn't set the ZF in EFLAGS even if it resulted in a 0 value,<br>
causing the "jne" to always be taken.<br>
<br>
Anyway, here's where we're at now:<br>
<br>
Start @ 0x1027f9 ...<br>
EFI framebuffer information:<br>
addr, size 0x80000000, 0x1d4c00<br>
dimensions 800 x 600<br>
stride 800<br>
masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000<br>
Filling 512 page tables<br>
1gib pages not supported!<br>
maxphysaddr = 48<br>
sidt = ff f a8 39 34 0 0 0 0 0<br>
us_per_tick = 10000<br>
Desired frequency = 100 irqs/sec<br>
APIC was at fee00000<br>
APIC is now at fee00000<br>
APIC ID at *fee00020=0<br>
APIC spurious vector register *fee000f0=10f<br>
APIC spurious vector register *fee000f0=1ff<br>
CPU frequency: 0x57c60<br>
APIC ticks/sec: 0x57c6qemu-system-x86_64: warning: I/O thread spun for<br>
1000 iterations<br>
<span class=""><br>
<br>
*** BEGIN OF TEST CLOCK TICK ***<br>
*** TEST VERSION: 5.0.0.<wbr>2f10634899719c2857e2c8dd5088fb<wbr>93a425fc83-modified<br>
*** TEST STATE: EXPECTED-PASS<br>
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API<br>
*** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB<br>
25f4db09c85a52fb1640a29f9bdc2d<wbr>e8c2768988, Newlib 3.0.0)<br>
</span>TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988<br>
TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988<br>
TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988<br>
TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988<br>
TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988<br>
TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988<br>
TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988<br>
TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988<br>
TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988<br>
TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988<br>
TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988<br>
TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988<br>
TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988<br>
TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988<br>
<br>
*** END OF TEST CLOCK TICK ***<br>
<br></blockquote><div><br></div><div>+1 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
*** FATAL ***<br>
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)<br>
fatal code: 0 (0x00000000)<br>
RTEMS version: 5.0.0.<wbr>2f10634899719c2857e2c8dd5088fb<wbr>93a425fc83-modified<br>
RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB<br>
25f4db09c85a52fb1640a29f9bdc2d<wbr>e8c2768988, Newlib 3.0.0)<br>
executing thread ID: 0x08a010002<br>
executing thread name: TA1<br>
qemu-system-x86_64: terminating on signal 2<br>
<br>
------------------------------<wbr>------------------------------<wbr>-----<br>
<br>
2 issues:<br>
- It isn't reliably this way - sometimes it may start at 9:00:01 (and<br>
then the rest are 6, 11, etc.). I'm using a very naive timecounter<br>
(number of IRQs occurred so far) right now - I'll have it account for<br>
the ticks since the last IRQ too, which I imagine may help with this?<br></blockquote><div><br></div><div>Some of the simulators are odd this way. But I would expect this to</div><div>behave better. It is probably a calibration issue. There should be more</div><div>than enough time to do the prints and handle the tick ISRs. On some</div><div>simulators, it isn't that way.</div><div><br></div><div>The initialization should program it to get an interrupt based on the</div><div>configured microseconds per tick. You need the calibration or truth</div><div>speed to do this. I assume that calibration that would work on real</div><div>HW would work on qemu.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- It is much slower than IRL time - I'm not sure if this is just due<br>
to QEMU or perhaps from ISRs piling over each other due to the handler<br>
taking too long. I'm not quite sure how to find out either.<br></blockquote><div><br></div><div>This is expected. I recall it is ~2x IRL time for pc386 ticker.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Let me know if you have any suggestions!<br>
<br>
Patches incoming soon too, so I'd appreciate reviews! :)<br></blockquote><div><br></div><div>Nearly working is a great sign!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Thu, Aug 9, 2018 at 8:12 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
><br>
><br>
> On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br>
>><br>
>> Addition to status: it doesn't seem like the RTEMS Interrupt's call to<br>
>> _Thread_Dispatch functions either - ticker.exe has outputs like the<br>
>> following (yeah, the counter is running too quickly right now):<br>
>><br>
>> *** BEGIN OF TEST CLOCK TICK ***<br>
>> *** TEST VERSION: 5.0.0.<wbr>2f10634899719c2857e2c8dd5088fb<wbr>93a425fc83-modified<br>
>> *** TEST STATE: EXPECTED-PASS<br>
>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API<br>
>> *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB<br>
>> 25f4db09c85a52fb1640a29f9bdc2d<wbr>e8c2768988, Newlib 3.0.0)<br>
>> TA1 - rtems_clock_get_tod - 11:34:12 05/12/1990<br>
>> TA2 - rtems_clock_get_tod - 11:34:12 05/12/1990<br>
>> TA3 - rtems_clock_get_tod - 11:34:12 05/12/1990<br>
><br>
><br>
> Congratulations! But why is the date 5/12/1990? I think it is supposed<br>
> to be 12/31/1989. :)<br>
>><br>
>><br>
>> (And then the _Thread_Idle_body is never preempted due to the<br>
>> interrupt dispatching a new thread - not sure if it just thinks it's<br>
>> "too late" to even bother or if simply never even tries. I'll keep<br>
>> investigating.)<br>
><br>
><br>
> This means your "outer" assembly language _ISR_Handler does not<br>
> yet deal with "needs dispatch". On the 5 second tick, a task is unblocked<br>
> and set up to preempt. The end of the ISR path has to be right to<br>
> make this work.<br>
><br>
> --joel<br>
>><br>
>><br>
>> On Thu, Aug 9, 2018 at 6:03 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>> wrote:<br>
>> > Hi everyone!<br>
>> ><br>
>> > Good news! The APIC timer _does_ work now (after implementing 1GiB<br>
>> > pages)! I see Clock_isr_ticks increasing steadily, though I don't have<br>
>> > tc_get_timecount implemented yet - I've yet to figure out the<br>
>> > specifics of the clock driver (how<br>
>> > rtems_configuration_get_<wbr>microseconds_per_tick influences the<br>
>> > counter_ticks, specifically).<br>
>> ><br>
>> > I suspect we'll barely just make ticker.exe work by EOD tomorrow,<br>
>> > leaving just the weekend for me to clean the patches up and Monday to<br>
>> > actually merge them.<br>
>> ><br>
>> > Would someone be willing to have a meeting on Hangouts (or whatever)<br>
>> > with me to speed up the process of (1) upstreaming my patches and (2)<br>
>> > checking that my "work package" looks good enough at any convenient<br>
>> > time on Monday?<br>
>> ><br>
>> > (I'm a bit busy on Monday, so I'd really prefer to have this whole<br>
>> > thing done by EOD Monday for me.)<br>
>> ><br>
>> > On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>> >> On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>> >> wrote:<br>
>> >>> Status update: The code is at a point where the APIC timer _should_<br>
>> >>> work, but doesn't (it never starts ticking away, so when calibrating<br>
>> >>> with the PIT, and later starting the APIC timer to generate IRQs,<br>
>> >>> pretty much nothing happens).<br>
>> >>><br>
>> >>> I suspect the cause being the APIC base relocation not working (the<br>
>> >>> APIC is located at 0xfee00000 in physical memory by default, and in<br>
>> >>> the code we write to an MSR to relocate it, because the page-mapping<br>
>> >>> scheme FreeBSD setup doesn't let us access such high physical memory -<br>
>> >>> only the first 1GiB of physical memory).<br>
>> >>><br>
>> >>> On QEMU, the MSR accepts our write for the relocation and happily<br>
>> >>> spits it back out when read, but given the unresponsiveness of the<br>
>> >>> APIC timer despite enabling all the right bits, I suspect it's just a<br>
>> >>> "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our<br>
>> >>> changes to the APIC configuration either, supporting this theory).<br>
>> >>> QEMU _does_ reflect changes to the APIC by other operating systems<br>
>> >>> which don't relocate it, so I don't suspect its emulation being a<br>
>> >>> problem.<br>
>> >>><br>
>> >>> On VirtualBox, the MSR simply silently swallows the write, and upon a<br>
>> >>> read, returns the original 0xfee00000 value again. This means that if<br>
>> >>> we can't relocate it, we can't access it at the moment either.<br>
>> >>><br>
>> >>> The only real way to work around this is to have a paging scheme that<br>
>> >>> lets us access physical address 0xfee00000 - in that case, we could<br>
>> >>> support page-faults and dynamically map pages in, _or_ have static<br>
>> >>> pages that are absurdly large (such as 1GiB), letting the virtual<br>
>> >>> address do the heavy-lifting in terms of finding the<br>
>> >>> virtual-to-physical mapping.<br>
>> >>><br>
>> >><br>
>> >> I recommend a few static super pages to get it working. It is simple<br>
>> >> and fits the prevailing RTEMS model.<br>
>> >><br>
>> >>> Either way, I think this issue this close to the deadline basically<br>
>> >>> means the APIC timer won't be functional and make it upstream.<br>
>> >>><br>
>> >>> I'll clean things up and send patches tomorrow for everything so far,<br>
>> >>> including all the stub-code which will become usable once our paging<br>
>> >>> scheme works fine.<br>
>> >>><br>
>> >>> If anyone has any last-minute swooping ideas on how to save the APIC<br>
>> >>> timer, let me know! (Interrupts aren't masked, and as far as I can<br>
>> >>> tell, changing the "-cpu" flag on QEMU doesn't make a difference. I<br>
>> >>> don't have any ideas as to what else the problem could be.)<br>
>> >>><br>
>> >>> In my final report, I'll make sure I document what's remaining in<br>
>> >>> clearer terms than I have in this email, so it's easier for other<br>
>> >>> contributors to pick it up too, if any are interested.<br>
>> >>><br>
>> >>> </rant><br>
>> >>><br>
>> >>> On Tue, Aug 7, 2018 at 6:03 AM, Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br>
>> >>>> On 07/08/2018 09:27, Joel Sherrill wrote:<br>
>> >>>>> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a><br>
>> >>>>> <mailto:<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a><wbr>>> wrote:<br>
>> >>>>><br>
>> >>>>> Thanks for all the help! I have a simple test using the RTEMS<br>
>> >>>>> interrupt manager working successfully (tested by calling<br>
>> >>>>> rtems_interrupt_handler_<wbr>install for vector 0, and then<br>
>> >>>>> triggering a<br>
>> >>>>> divide-by-0 exception).<br>
>> >>>>><br>
>> >>>>> Yeah!<br>
>> >>>>><br>
>> >>>>> Could someone shed any light on why the i386 only hooks the<br>
>> >>>>> first 17<br>
>> >>>>> vectors as "RTEMS interrupts"?<br>
>> >>>>><br>
>> >>>>> You are making me feel very old especially since I have the real<br>
>> >>>>> IBM manual in my office which corresponds to the answer.<br>
>> >>>><br>
>> >>>> Grandchildren, grey hair or Sebastian posting he is feeling old do<br>
>> >>>> not make you<br>
>> >>>> feel old? Interesting! ;) :)<br>
>> >>>><br>
>> >> I feel old, too.<br>
>> >><br>
>> >>>>> It is dated Sept 1985. In fairness, I saved it from the garbage heap<br>
>> >>>>> years later when someone was cleaning out their office. :)<br>
>> >>>><br>
>> >>>> Ah the good old days before the internet and search engines!!<br>
>> >>>><br>
>> >>>>> The x86 architecture is really vectored and the original i386<br>
>> >>>>> port actually used simple direct vectoring since the first BSP<br>
>> >>>>> wasn't<br>
>> >>>>> a PC. Imagine that! Another board using an i386 which didn't<br>
>> >>>>> look like a PC at all.<br>
>> >>>>><br>
>> >>>>> For better or worse, the PC/AT (286) and later used two i8259 PICs<br>
>> >>>>> in a master and slave configuration. The slave PIC cascaded off the<br>
>> >>>>> master PIC. This all fed into one CPU IRQ so many of the direct<br>
>> >>>>> vectors were unused. The PIC arrangement is described here:<br>
>> >>>>><br>
>> >>>>> <a href="https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>Interrupt_request_(PC_<wbr>architecture)</a><br>
>> >>>>><br>
>> >>>>> Here's what I'm aiming to get done before the GSoC deadline:<br>
>> >>>>><br>
>> >>>>> - Remap PIC (masking/disabling the PIC doesn't stop it from<br>
>> >>>>> generating<br>
>> >>>>> spurious interrupts (IRQ7), which would look like exceptions to<br>
>> >>>>> us)<br>
>> >>>>> - Disable PIC<br>
>> >>>>> - Enable APIC (done already, but confirm it plays well with the<br>
>> >>>>> recent<br>
>> >>>>> changes to the IDT)<br>
>> >>>>> - Enable the PIT timer and use it to calibrate the APIC timer<br>
>> >>>>> - Clock driver using the APIC timer - (1) generate interrupts on<br>
>> >>>>> ticks<br>
>> >>>>> and (2) tc_get_timecount function which calculates total time<br>
>> >>>>> passed<br>
>> >>>>> through calculating (number of IRQs occured * time_per_irq +<br>
>> >>>>> time_passed_since_last_irq (through tick counter))<br>
>> >>>>><br>
>> >>>>> This does seem a bit ambitious given how short we are on time -<br>
>> >>>>> I'll<br>
>> >>>>> finish this up even after the deadline if need be.<br>
>> >>>>><br>
>> >>>>> What should our minimum deliverable be for this period? Should<br>
>> >>>>> we try<br>
>> >>>>> to upstream the interrupt support before I finish the clock<br>
>> >>>>> driver? (I<br>
>> >>>>> think we can have this discussion on Wednesday or so, since by<br>
>> >>>>> then<br>
>> >>>>> I'll likely know how much progress on the clock driver remains.)<br>
>> >>>>><br>
>> >>>>> We could but do you think it is likely to have major changes based<br>
>> >>>>> on getting the tick working?<br>
>> >>>>><br>
>> >>>>> Try to see what gets done and post what you can by the end of GSoC.<br>
>> >>>>><br>
>> >>>>> Then we will all wait patiently for you to get it working if it<br>
>> >>>>> isn't then.<br>
>> >>>><br>
>> >>>> I think this BSP code in our repo is the best place for it to be<br>
>> >>>> worked on.<br>
>> >>>><br>
>> >>>> Chris<br>
><br>
><br>
</div></div></blockquote></div><br></div></div>