[GSoC - x86_64] Clock driver - which hardware source to support primarily?

[Joel Sherrill]

On Tue, Jul 17, 2018 at 12:18 PM, Amaan Cheval <amaan.cheval at gmail.com>
wrote:

> Hi!
>
> Now that I'm working on the clock driver, we need to pick what we
> support first. Our options in brief are:
>
> - rdtsc; will need calibration through the PIT or one of the other options
>

Can this generate an interrupt?

This is currently used to get the offset since the last tick and
there is calibration code in pc386. Of course, that likely uses
the PIT so is just a guide.


> - PIT; likely not given how legacy it is, but it may be quite simple
>

Legacy. Preferably off the table as a permanent solution.

How legacy is it? It doesn't seem to have disappeared like IO ports,
non-UEFI booting, etc.


> - APIC timer[1]; better for long-term as it's independent of multiple
> core time sync problems in general, and it also has multiple modes,
> including having the timer generate deadline interrupts instead of the
> "polled" ticking method. It'll need better interrupt support and ACPI
> to detect/use.
>

I had hoped we would end up here.

Looks like it needs to be calibrated and likely you can read the
counter to see how long it has been running since the IRQ was
generated. Plus you can read it for the time since last IRQ.

Good and self-contained I think.


>
> - HPET[2] (high-precision event timer); may be the "best" option -
> it's fairly modern, highly accurate. Only downside is it needing ACPI
> to detect and use (as opposed to usually CPUID for the others)
>

Is this present on all CPUs? What's the lowest model? Would this
be a limiting a factor?

Another consideration is that this may best be left alone since
it may make sense to have it available for applications needing
a secondary timer.

Finally, it simply looks fairly complex to deal with. You have to
detect it, can be at different IO addresses, and (worst) may not
be present at all and you have to have APIC timer support anyway.


>
> - RTC; legacy real-time clock - not really a good option in my
> understanding because it's often too slow for real use-cases needing
> the high precision
>

This is a bad option and was even for pc386. I don't recall if it
could even generate an interrupt but the granularity was bad.


>
> I suspect using rdtsc+pit (option 1) is likely the best for now in
> providing us with speed (rdtsc is much faster than the PIT, I've read)
> and ease-of-development (for the port, that is).
>

If speed == ease-of-development, this is the best option since you
have code to reuse.

APIC timer has to be there even if in the future, the HPET is
supported.


>
> Using the APIC timer may work well as well since basic ACPI and
> interrupt support are likely important for this port (for eg.
> currently, the port doesn't know how to reset the system at all, until
> we look into ACPI more). This will likely take a while but help the
> port be much more well-rounded for future growth.
>

I think this is most likely the preferred option.

Is the TSC needed for time since last interrupt or can that be
determined directly from the APIC timer?


>
> The HPET option is great if the high-precision is important - from
> other ports, it doesn't look like we need _such_ high precision, but
> let me know if that's wrong (especially given that most other BSPs are
> not usually as beefy as x86_64 systems may be too).
>
> For now, I'm probably working on setting the PIT up regardless since
> it'll likely be useful as a fallback no matter what (and it can be
> used for some of the other methods too).
>

This isn't a bad decision. You can probably get it working quickly.

I think the APIC timer is likely the best long-term solution.

The hardware chosen needs to generate periodic square wave
type interrupts at a fixed rate that is easily programmable
for say 100 microseconds to 25 milliseconds. Random range
there with 100 microseconds being 1/10 of what I think is used
on many RTEMS targets and 25 milliseconds being over the
upper limit of what I think a tick should be.

The second requirement is to be able to determine the
amount of time since the last interrupt. This is use to
give accurate timestamps. Sometimes the timer interrupt
source can be used, other times you need something like
the TSC.

Please try to write this from scratch using the old code only as a
reference. It would be nice to have clean BSD licensing on this
BSP. The pc386 has a long history with many contributors.

Does that all make sense? Great discussion!

--joel


>
> Cheers!
>
> [1] https://wiki.osdev.org/APIC_timer
> [2] https://wiki.osdev.org/HPET
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180717/6368a586/attachment-0002.html>