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