That definitely makes sense, yes. I'll look into the parts we need for ACPI and how we can match them up to ACPICA. I've added it to my proposal as a reminder / roadmap item of sorts for something to evaluate in during phase 1, since I believe the essential bits of ACPI will be involved during initialization / boot, so the earlier we have ACPICA going, the better.
Thanks! On Sat, Apr 7, 2018 at 1:52 AM Joel Sherrill <j...@rtems.org> wrote: > On Fri, Apr 6, 2018 at 3:09 PM, Amaan Cheval <amaan.che...@gmail.com> wrote: >> 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. > I would assume a huge amount of it is unnecessary in most RTEMS > deployments. But hacking something new to hit the minimum or > getting the features we need of this to work are two approaches > to the same end. One leaves a growth path and shared maintenance. > The other leaves us with our own beast to maintain. > And if we outgrow it, we switch to the other in the end anyway. >> 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
