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

[Amaan Cheval]

Cool, that's the plan.

Yes, I believe it will limit the accessible RAM since page-faults never
occur (due to the repetitive mapping), and we never map anything beyond the
first 1 GiB of physical memory.

I think the simplest paging scheme later will be identity mapping virtual
to physical addresses. I'm just not sure of unintended consequences due to
this (for eg. with the linker script's structure influencing memory-mapped
devices). I guess we'll look into this when we come to it, though.

On Tue, Jul 31, 2018, 1:28 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Mon, Jul 30, 2018, 2:27 PM Amaan Cheval <amaan.cheval at gmail.com> wrote:
>
>> 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.
>>
>
> Make the clock tick and timer driver work first.
>
> Will this have any impact on the amount of RAM accessible until this is
> fixed?
>
>>
>> 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.
>> >>>
>> >>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180731/09f125b3/attachment-0002.html>