On Mon, May 14, 2018 at 10:20 AM, Gedare Bloom <ged...@rtems.org> wrote:

> On Mon, May 14, 2018 at 9:30 AM, Sebastian Huber
> <sebastian.hu...@embedded-brains.de> wrote:
> > On 14/05/18 15:20, Amaan Cheval wrote:
> >>
> >> For now, do we all agree to x86_64 as the arch, and x86_64_generic as
> the
> >> BSP?
> >
> >
> > I would drop the _generic. I don't think there will be a non-generic BSP
> on
> > this architecture.
> >
>
> I agree. Use x86_64 for the arch. The BSP name can also be x86_64, or
> a variant of the generic such as (please don't hit me): amd64, x86 :)
>

amd64's not awful. :)

Another direction which is dated now but I think FreeBSD has directories
with these names is the "PCxxx" standards. These are the PC System
Design Guide editions from Intel and Microsoft.

https://en.wikipedia.org/wiki/PC_System_Design_Guide

Unfortunately, the last was PC2001.

http://tech-insider.org/windows/research/2000/1102.html

But that predates UEFI so wouldn't be the best option.

The PCxxx specifications show that the PC evolved slowly but has had
changes over the years. Don't assume that just because some peripherals
are part of the "CPU" component now that they aren't shared or won't
change in the future. For example, the PC/AT included the cascaded
part of i8259s which are still emulated today in "legacy" mode. However,
the APIC is the preferred interrupt controller now and it has been through
a couple of revisions as I recall.  This is leading up to putting this
support
code in bsps/x86_64/shared and have BSP variants use various combinations.
You could start with a "legacy" BSP (bad name) which uses old style
interrupts, etc. As more code for "non-legacy" comes into being, use
it in another BSP variant.

--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.hu...@embedded-brains.de
> > PGP     : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
> > _______________________________________________
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to