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 <j...@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.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
