<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 17, 2018 at 12:18 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">Hi!<br>
<br>
Now that I'm working on the clock driver, we need to pick what we<br>
support first. Our options in brief are:<br>
<br>
- rdtsc; will need calibration through the PIT or one of the other options<br></blockquote><div><br></div><div>Can this generate an interrupt?</div><div><br></div><div>This is currently used to get the offset since the last tick and</div><div>there is calibration code in pc386. Of course, that likely uses</div><div>the PIT so is just a guide.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- PIT; likely not given how legacy it is, but it may be quite simple<br></blockquote><div><br></div><div>Legacy. Preferably off the table as a permanent solution.</div><div><br></div><div>How legacy is it? It doesn't seem to have disappeared like IO ports,</div><div>non-UEFI booting, etc.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- APIC timer[1]; better for long-term as it's independent of multiple<br>
core time sync problems in general, and it also has multiple modes,<br>
including having the timer generate deadline interrupts instead of the<br>
"polled" ticking method. It'll need better interrupt support and ACPI<br>
to detect/use.<br></blockquote><div><br></div><div>I had hoped we would end up here.</div><div><br></div><div>Looks like it needs to be calibrated and likely you can read the</div><div>counter to see how long it has been running since the IRQ was</div><div>generated. Plus you can read it for the time since last IRQ.</div><div><br></div><div>Good and self-contained I think.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- HPET[2] (high-precision event timer); may be the "best" option -<br>
it's fairly modern, highly accurate. Only downside is it needing ACPI<br>
to detect and use (as opposed to usually CPUID for the others)<br></blockquote><div><br></div><div>Is this present on all CPUs? What's the lowest model? Would this</div><div>be a limiting a factor?</div><div><br></div><div>Another consideration is that this may best be left alone since</div><div>it may make sense to have it available for applications needing</div><div>a secondary timer.</div><div><br></div><div>Finally, it simply looks fairly complex to deal with. You have to</div><div>detect it, can be at different IO addresses, and (worst) may not</div><div>be present at all and you have to have APIC timer support anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- RTC; legacy real-time clock - not really a good option in my<br>
understanding because it's often too slow for real use-cases needing<br>
the high precision<br></blockquote><div><br></div><div>This is a bad option and was even for pc386. I don't recall if it</div><div>could even generate an interrupt but the granularity was bad.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I suspect using rdtsc+pit (option 1) is likely the best for now in<br>
providing us with speed (rdtsc is much faster than the PIT, I've read)<br>
and ease-of-development (for the port, that is).<br></blockquote><div><br></div><div>If speed == ease-of-development, this is the best option since you</div><div>have code to reuse. </div><div><br></div><div>APIC timer has to be there even if in the future, the HPET is</div><div>supported. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Using the APIC timer may work well as well since basic ACPI and<br>
interrupt support are likely important for this port (for eg.<br>
currently, the port doesn't know how to reset the system at all, until<br>
we look into ACPI more). This will likely take a while but help the<br>
port be much more well-rounded for future growth.<br></blockquote><div><br></div><div>I think this is most likely the preferred option. </div><div><br></div><div>Is the TSC needed for time since last interrupt or can that be</div><div>determined directly from the APIC timer?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The HPET option is great if the high-precision is important - from<br>
other ports, it doesn't look like we need _such_ high precision, but<br>
let me know if that's wrong (especially given that most other BSPs are<br>
not usually as beefy as x86_64 systems may be too).<br>
<br>
For now, I'm probably working on setting the PIT up regardless since<br>
it'll likely be useful as a fallback no matter what (and it can be<br>
used for some of the other methods too).<br></blockquote><div><br></div><div>This isn't a bad decision. You can probably get it working quickly.</div><div><br></div><div>I think the APIC timer is likely the best long-term solution. </div><div><br></div><div>The hardware chosen needs to generate periodic square wave</div><div>type interrupts at a fixed rate that is easily programmable</div><div>for say 100 microseconds to 25 milliseconds. Random range</div><div>there with 100 microseconds being 1/10 of what I think is used</div><div>on many RTEMS targets and 25 milliseconds being over the</div><div>upper limit of what I think a tick should be.</div><div><br></div><div>The second requirement is to be able to determine the</div><div>amount of time since the last interrupt. This is use to</div><div>give accurate timestamps. Sometimes the timer interrupt</div><div>source can be used, other times you need something like</div><div>the TSC.</div><div><br></div><div>Please try to write this from scratch using the old code only as a<br></div><div>reference. It would be nice to have clean BSD licensing on this</div><div>BSP. The pc386 has a long history with many contributors.</div><div><br></div><div>Does that all make sense? Great discussion!</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers!<br>
<br>
[1] <a href="https://wiki.osdev.org/APIC_timer" rel="noreferrer" target="_blank">https://wiki.osdev.org/APIC_<wbr>timer</a><br>
[2] <a href="https://wiki.osdev.org/HPET" rel="noreferrer" target="_blank">https://wiki.osdev.org/HPET</a><br>
</blockquote></div><br></div></div>