x86_64 port and BSP (GSoC 2018)

[Joel Sherrill]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180406/f43359f2/attachment-0002.html>