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

[Joel Sherrill]

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/20180730/1071bfcc/attachment-0002.html>