<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 6, 2018 at 3:09 PM, Amaan Cheval <span dir="ltr"><<a href="mailto:amaan.cheval@gmail.com" target="_blank">amaan.cheval@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for sharing your thoughts! I did have a brief look since it's<br>
mentioned in the original ticket, but I've left it in the bonus features<br>
since from what I understand, a lot of the ACPI features to be implemented<br>
are not really essential. It should definitely be a resource to consider<br>
for the features we _will_ have to implement, though, so I'll add it to my<br>
list.<br></blockquote><div><br></div><div>I would assume a huge amount of it is unnecessary in most RTEMS<br>deployments. But hacking something new to hit the minimum or </div><div>getting the features we need of this to work are two approaches</div><div>to the same end. One leaves a growth path and shared maintenance.</div><div>The other leaves us with our own beast to maintain.</div><div><br></div><div>And if we outgrow it, we switch to the other in the end anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Let me know if you disagree about a lot of ACPI seeming unessential!<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Apr 7, 2018 at 1:30 AM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
<br>
> I hate to pile on late but following the link to <a href="http://osdev.org" rel="noreferrer" target="_blank">osdev.org</a> in an earlier<br>
message<br>
> led me to Google for something like Intel's reference implementation.<br>
<br>
> <a href="https://github.com/acpica" rel="noreferrer" target="_blank">https://github.com/acpica</a><br>
<br>
> This os_specific directory has adapters for Linux, BSD, and Windows.<br>
> I don't think there are that many methods in the OS specific files.<br>
<br>
> I am unsure of the scope of this package but it looks promising.  It<br>
> seems like a good foundation.<br>
<br>
> --joel<br>
<br>
> On Fri, Apr 6, 2018 at 3:24 AM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
wrote:<br>
<br>
>> Status update time!<br>
<br>
>> # Completed:<br>
>> [x] Get my QEMU environment setup<br>
>>       - Documented on the RTEMS wiki[1]<br>
>> [x] Read more of RTEMS' no_cpu code, and the BSP porting guide<br>
>>       - Read most of the guide - things have been in flux with the<br>
>> refactorings, but I think most of it makes sense, especially after having<br>
>> found the tickets on Trac - the reorganization of folders (to bsps from<br>
all<br>
>> over) and simplified build systems are helping make it easier to<br>
understand<br>
>> for sure. I haven't quite figured out what initialization happens where<br>
>> since we have a fair number of "init" spots and the delineation isn't<br>
>> crystal clear yet, but I'll ask about that if I don't figure it out soon.<br>
>> (In particular, we've got start.S for boot, boot_card, _CPU_Initialize,<br>
>> etc. - I'll likely know soon enough from looking at other architectures.)<br>
<br>
>> # In progress:<br>
>> [-] Create a stub port and BSP simply to link with testsuite, as Joel<br>
>> suggested to surface any issues with the tools.<br>
>>       - I simply copied no_cpu and parts of i386 into x86_64 directory,<br>
>> updated "/c/src/aclocal/rtems-cpu-<wbr>subdirs.m4" and off I went.<br>
>>       - Would we be interested in patches to update no_bsp to make this<br>
"port<br>
>> by starting from no_bsp" method easier? For eg. interrupts.h doesn't<br>
exist<br>
>> in no_bsp, but is assumed in other parts of RTEMS.<br>
>> I imagine we'll also want no_cpu to be reorganized into the root "bsps"<br>
>> folder (per ticket #3285) to be the go-to reference structure for a new<br>
>> port, so these patches may be better after that does happen to avoid<br>
>> conflicts. (I already sent a patch for a fairly simple issue here[2], but<br>
>> let me know if you'd rather have the others after the reorganization or<br>
now<br>
>> - I haven't started work on them per-se, only as a byproduct of trying to<br>
>> get the stub x86_64 port to compile.)<br>
>>       - I ran into an issue (seems minor) with the x86_64 tools (gcc);<br>
>> thought I'd put that in its own thread[3], since not everyone may be<br>
>> interested in this status update.<br>
<br>
>> [-] Continue to read Intel's manual on system programming (volume 3)<br>
>>       - In progress - there's a lot, so I'm skimming a fair bit, looking<br>
for<br>
>> key things that I may not have accounted for.<br>
<br>
>> # Incomplete:<br>
>> [ ] Read / skim FreeBSD's code for UEFI, APIC support, SMP, etc.<br>
>>       - Doing this as soon as I've made enough progress on the stub port<br>
>> mentioned above.<br>
>> [ ] Read / skim UEFI specification<br>
>> [ ] Figure out how testing on community hardware<br>
<br>
<br>
>> [1]<br>
<br>
<a href="https://devel.rtems.org/wiki/Developer/Simulators/QEMU#QEMUandUEFIusingOVMFEDKII" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/<wbr>Developer/Simulators/QEMU#<wbr>QEMUandUEFIusingOVMFEDKII</a><br>
>> [2] <a href="https://lists.rtems.org/pipermail/devel/2018-April/020857.html" rel="noreferrer" target="_blank">https://lists.rtems.org/<wbr>pipermail/devel/2018-April/<wbr>020857.html</a><br>
>> [3] <a href="https://lists.rtems.org/pipermail/devel/2018-April/020858.html" rel="noreferrer" target="_blank">https://lists.rtems.org/<wbr>pipermail/devel/2018-April/<wbr>020858.html</a><br>
</div></div></blockquote></div><br></div></div>