x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

Thanks for sharing your thoughts! I did have a brief look since it's
mentioned in the original ticket, but I've left it in the bonus features
since from what I understand, a lot of the ACPI features to be implemented
are not really essential. It should definitely be a resource to consider
for the features we _will_ have to implement, though, so I'll add it to my
list.

Let me know if you disagree about a lot of ACPI seeming unessential!

On Sat, Apr 7, 2018 at 1:30 AM Joel Sherrill <joel at rtems.org> wrote:

> I hate to pile on late but following the link to osdev.org in an earlier
message
> led me to Google for something like Intel's reference implementation.

> https://github.com/acpica

> This os_specific directory has adapters for Linux, BSD, and Windows.
> I don't think there are that many methods in the OS specific files.

> I am unsure of the scope of this package but it looks promising.  It
> seems like a good foundation.

> --joel

> On Fri, Apr 6, 2018 at 3:24 AM, Amaan Cheval <amaan.cheval at gmail.com>
wrote:

>> Status update time!

>> # Completed:
>> [x] Get my QEMU environment setup
>>       - Documented on the RTEMS wiki[1]
>> [x] Read more of RTEMS' no_cpu code, and the BSP porting guide
>>       - Read most of the guide - things have been in flux with the
>> refactorings, but I think most of it makes sense, especially after having
>> found the tickets on Trac - the reorganization of folders (to bsps from
all
>> over) and simplified build systems are helping make it easier to
understand
>> for sure. I haven't quite figured out what initialization happens where
>> since we have a fair number of "init" spots and the delineation isn't
>> crystal clear yet, but I'll ask about that if I don't figure it out soon.
>> (In particular, we've got start.S for boot, boot_card, _CPU_Initialize,
>> etc. - I'll likely know soon enough from looking at other architectures.)

>> # In progress:
>> [-] Create a stub port and BSP simply to link with testsuite, as Joel
>> suggested to surface any issues with the tools.
>>       - I simply copied no_cpu and parts of i386 into x86_64 directory,
>> updated "/c/src/aclocal/rtems-cpu-subdirs.m4" and off I went.
>>       - Would we be interested in patches to update no_bsp to make this
"port
>> by starting from no_bsp" method easier? For eg. interrupts.h doesn't
exist
>> in no_bsp, but is assumed in other parts of RTEMS.
>> I imagine we'll also want no_cpu to be reorganized into the root "bsps"
>> folder (per ticket #3285) to be the go-to reference structure for a new
>> port, so these patches may be better after that does happen to avoid
>> conflicts. (I already sent a patch for a fairly simple issue here[2], but
>> let me know if you'd rather have the others after the reorganization or
now
>> - I haven't started work on them per-se, only as a byproduct of trying to
>> get the stub x86_64 port to compile.)
>>       - I ran into an issue (seems minor) with the x86_64 tools (gcc);
>> thought I'd put that in its own thread[3], since not everyone may be
>> interested in this status update.

>> [-] Continue to read Intel's manual on system programming (volume 3)
>>       - In progress - there's a lot, so I'm skimming a fair bit, looking
for
>> key things that I may not have accounted for.

>> # Incomplete:
>> [ ] Read / skim FreeBSD's code for UEFI, APIC support, SMP, etc.
>>       - Doing this as soon as I've made enough progress on the stub port
>> mentioned above.
>> [ ] Read / skim UEFI specification
>> [ ] Figure out how testing on community hardware


>> [1]

https://devel.rtems.org/wiki/Developer/Simulators/QEMU#QEMUandUEFIusingOVMFEDKII
>> [2] https://lists.rtems.org/pipermail/devel/2018-April/020857.html
>> [3] https://lists.rtems.org/pipermail/devel/2018-April/020858.html