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

Amaan Cheval amaan.cheval at gmail.com
Wed Jul 18 07:41:47 UTC 2018


Hey!

On Wed, Jul 18, 2018 at 11:01 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Hello Amaan,
>
> On 17/07/18 19:18, Amaan Cheval wrote:
>>
>> Hi!
>>
>> Now that I'm working on the clock driver, we need to pick what we
>> support first. Our options in brief are:
>
>
> The clock driver needs an interrupt. What is the status of the interrupt
> controller support in the BSP?

TL;DR: There is none. We've been using the idle-thread simulation and
left interrupts disabled from the get-go.

>
> For timekeeping we use a port of the FreeBSD timecounter in RTEMS. You may
> have a look at the FreeBSD timecounter for this architecture, e.g.
> sys/x86/x86/tsc.c. I looks quite complicated.

Right, it goes to show the flaw with the TSC - it needs calibration
(FreeBSD seems to try to use CPUID and model names, etc. to detect the
frequency instead of using the PIT), and synchronization across
different cores in SMP configurations.

The APIC timers are local to each core, but are also synchronized
because they are based on a common bus signal.

(See this for more pros/cons of each timer:
https://www.halobates.de/timers2.pdf)

> I would not take to much care
> about legacy support, e.g. ignore hardware which is older than five years?.

That's a fair guideline, thanks!

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



More information about the devel mailing list