<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 9, 2018 at 7:43 AM, 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">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></blockquote><div><br></div><div>Congratulations! But why is the date 5/12/1990? I think it is supposed</div><div>to be 12/31/1989. :) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>This means your "outer" assembly language _ISR_Handler does not</div><div>yet deal with "needs dispatch". On the 5 second tick, a task is unblocked</div><div>and set up to preempt. The end of the ISR path has to be right to</div><div>make this work.</div><div><br></div><div>--joel </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 6:03 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> 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>> 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 triggering a<br>
>>>>>     divide-by-0 exception).<br>
>>>>><br>
>>>>> Yeah!<br>
>>>>><br>
>>>>>     Could someone shed any light on why the i386 only hooks the 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 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 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 generating<br>
>>>>>     spurious interrupts (IRQ7), which would look like exceptions to us)<br>
>>>>>     - Disable PIC<br>
>>>>>     - Enable APIC (done already, but confirm it plays well with the 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 ticks<br>
>>>>>     and (2) tc_get_timecount function which calculates total time 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 - 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 we try<br>
>>>>>     to upstream the interrupt support before I finish the clock driver? (I<br>
>>>>>     think we can have this discussion on Wednesday or so, since by 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 isn't then.<br>
>>>><br>
>>>> I think this BSP code in our repo is the best place for it to be worked on.<br>
>>>><br>
>>>> Chris<br>
</div></div></blockquote></div><br></div></div>