x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

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 <joel at rtems.org> wrote:



> On Fri, Apr 6, 2018 at 3:09 PM, Amaan Cheval <amaan.cheval at 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 <joel at 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.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