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

Amaan Cheval amaan.cheval at gmail.com
Mon Jul 30 19:27:31 UTC 2018


Quick status update: in working on the APIC timer, as a prerequisite,
I've had to setup access to the Interrupt Descriptor Table (which is
great because it helps us have the basic interrupt support we need at
least).

Another minor issue I've run into is the fact that the APIC is located
at physical address 0xfee00000 by default on most x86 processors - per
the FreeBSD bootloader's paging scheme, they map every GiB of virtual
memory to the first 1 GiB of physical memory (0x40000000).

As a workaround, I'll probably just move the APIC address to within
this accessible range (through a Model Specific Register) with an
"XXX" comment about creating a better paging scheme later.

Let me know if anyone thinks better paging support should also come
first! If not, what's next is initializing the PIT to calibrate the
APIC timer, and then we should have a pretty nice and self-contained
clock driver for the x86_64 port too.

On Wed, Jul 18, 2018 at 7:53 PM, Gedare Bloom <gedare at rtems.org> wrote:
> On Wed, Jul 18, 2018 at 10:17 AM, Joel Sherrill <joel at rtems.org> wrote:
>>
>>
>> On Wed, Jul 18, 2018 at 12:31 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?
>>>
>>> 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. I would not take to much care
>>> about legacy support, e.g. ignore hardware which is older than five years?.
>>
>>
>> That's not a good rule for PCs at all. The APIC was first introduced as an
>> external controller with the i486,
>> Based on your rule, we wouldn't support it even though it is the most likely
>> choice.
>>
>
> I believe he meant ignore hardware that is not available from products
> in the last five years.
>
>
>> Avoid things that are deemed legacy. The starting point for this is the old
>> PC
>> System Design Guide.
>>
>> https://en.wikipedia.org/wiki/PC_System_Design_Guide
>>
>> If it was deemed obsolete in PC2001, then you definitely want to avoid it.
>> Those
>> things are just now really disappearing.
>>
>
> This is consistent with my interpretation.
>
>> --joel
>>
>>>
>>>
>>>
>>> --
>>> 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