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

Wed Jul 18 07:31:40 UTC 2018

Hi!

Thanks a ton for all the details, they definitely help clarify the
direction a fair bit. I think we're settling on working on interrupt
support and the APIC timer (and some PIT work to calibrate the APIC
timer) in the immediate future.

After ticker.exe passes through the APIC timer, we'll have a nearly
complete BSP and then the rtems-tools can be fixed up to let us run
tests more easily, and we can also look into alternate bootloaders for
UEFI-awareness instead of FreeBSD's.

Let me know if anyone disagrees with that?

On Tue, Jul 17, 2018 at 11:04 PM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> 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?

Nope, it's only an instruction that reads out the value held in the
timestamp counter. It can be used to determine the time since the last
interrupt - something as simple as:

    last_interrupt = rdtsc();
    // ...;
    time_since_last_interrupt = rdtsc() - last_interrupt;

I'm now leaning towards the APIC timer (read on), so this may not be
used at all.

>
> 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.

It's one of the "classic" timers - basically guaranteed to be there
(unlike _most_ of the other options in consideration). It's not our
ideal option, but I think we'll inevitably need it as a fallback, and
to synchronize the other timers during initialization. Our support may
not need to be full-fledged if we can assume processors recent enough
to support APIC timers, which really _should_ be the case on just
about anything modern enough to include UEFI firmware anyway.

>
>>
>> - 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.

Agreed - if interrupts are an absolute must, the APIC timer can do
everything we need, with only a little help during calibration from
the PIT.

>
>>
>>
>> - 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?

I don't really know, nor do I know how to find it out without much
more research.

>
> 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.
>

Right, I think I'm leaning away from even considering this for the
reasons you listed.

>>
>>
>> - 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?

I think it can be determined from the APIC timer directly with a
little calculation to convert ticks to time.

>
>>
>>
>> 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.

With the APIC timer, I've seen granularities in nanoseconds, so this
should be fine too.

>
> 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.

The manual states that the APIC timer's current count register is
read-only, which means we _can_ read it and determine how far off it's
come from the initial count register, telling us how long it's been
since the last interrupt with a little calculation.

>
> 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
>
>