x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

On Tue, Mar 20, 2018 at 8:23 AM Chris Johns <chrisj at rtems.org> wrote:

> On 19/03/2018 18:36, Amaan Cheval wrote:
> > Thanks for checking the tool status!
> >
> > TLS support for the tool seems okay to me as well - I see the TLS
program header
> > and the "T" flag for the ".tbss" section header, as you'd expect in the
ELF. I
> > haven't looked into the run-time support for TLS in RTEMS yet - is there
> > something I need to dig into there?
> >
> > How do we determine if we need multilib support?
> >

> GCC should be able to dump it configuration, try adding
`--print-multi-lib`.

No multilibs were found for me, in that case. Output was ".;".
What determines whether we need it or not? Is it based on whether we think
of x86_64 as a BSP for the i386 arch vs. it being its own, new arch + BSP?
(Since multilib, the way I understand it, would allow us to compile for
32-bit as well.)

In that case, I believe we've settled on new arch + new BSP, right?


> >>  I'd encourage you to flesh out
> >> the plan for one of the "bonus" areas for this phase. That way, if you
> >> reach it, you will be prepared to undertake it without having to think
> >> too hard about the design aspects.
> >
> > I've added a few bullets about SMP support and it's SMP-specific APIC
related tasks.

> This requires bringing code in from FreeBSD which includes Intel code to
manage
> these tables.

Good point. I've added what seem to be the relevant FreeBSD sources to the
resources listed in the proposal:

-
https://github.com/freebsd/freebsd/blob/master/sys/x86/x86/local_apic.c#L498-L503
-
https://github.com/freebsd/freebsd/blob/master/sys/amd64/amd64/apic_vector.S

(Assuming that by tables you meant the Local Vector Table, etc., and not
the ACPI's MADT, which is relevant to SMP in that it contains a list of
LAPICs, thereby letting us find how many cores are available.)


> >
> >> FYI one step I do for new ports is to get to the point where I can
link all tests with stubs or first quick cuts at the port and bsp.
> >
> > That's a good tip! I've added that to the phase 1 deliverable, since it
seems
> > like an important step - I'll aim to get here much sooner, though.
> >
> >> I have always thought the first part of this project would be to get
> >> an UEFI "hello world" running on Qemu. That is the entry point to the
> >> BSP and as Chris pointed out, there is a fair amount of work just
> >> to ensure you can do prints to the optional video and later serial
port.
> >
> > The UEFI "hello world" would be achievable through a minimal BSP
(primarily
> > boot/init code) and stubs for the rest (console, idle thread clock, fake
> > context-switching & ISR handling), right?

> In theory. We need to resolve the way we build the UEFI header as listed
in the
> ticket for this task.

> >> All that should be doable and testable on qemu.
> >
> > Sweet! A question about hardware requirements; how do you guys usually
test and
> > debug hardware problems?

> What is involved in booting on qemu with UEFI + 64bit?

Besides needing OVMF for UEFI, I don't think there should be any issues in
that regard. I'm also familiar enough with QEMU (since we use it a fair bit
as an "oracle" to be compared to our x86 emulator at work), so I think we
should be able to resolve this setup before the GSoC coding period starts.


> > Is there any equipment I'll likely need or should look
> > into (JTAG)?

> Not that I know of. Intel has a different JTAG like protocol on it's Atom
> devices available under NDA some commercial debuggers support.

> Qemu is nice because you get a built in debugger that lets you step
around these
> early bootloader instructions.

Ah, yes. I'm particularly wary of issues we run into where it runs in QEMU
but not on actual hardware - I imagine we'll need to go old school and just
stare hard at the code, throw in "printf"-likes (speaker, VGA, whatever we
have control over, depending on what stage the issue occurs at).


> >
> > Besides, what should I verify about the computers I do have, besides
them having
> > UEFI firmware?
> >

> Not too much. Being about to run on a Minnow board would be nice.

I don't own a Minnow board. Would testing through someone in the RTEMS
community who does be okay?
I believe my primary desktop (64-bit) does include UEFI firmware. My
secondary MacBook (64-bit) has EFI, I believe. Understandably, I'd rather
not have to tinker too much with my primary desktop, but I'm okay to for
when we have to, given that I have backups in place.


> Chris