x86_64 port and BSP (GSoC 2018)

[Joel Sherrill]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180406/99d480ae/attachment.html>