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.che...@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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
