x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

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

> On 20/03/2018 16:21, Amaan Cheval wrote:
> > 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.)
> I would prefer less rather than more and we settle on just 64bit and
support
> that. We have 32bit with the PC BSP in the 4.11 release branch.

Amen.


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

> I think this is the best way to go. It will make it easier to remove the
32bit
> support when the time comes.

> >
> >>>>  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
> >

> Thanks.

> > (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.)

> I was thinking about the SMP tables. SMP is not part of this work at the
moment
> so what ever is needed in this area to make the BSP work. Is the Local
Vector
> Table included in the list of tables?

Oh, did you mean the MP Table / ACPI MADT as mentioned in the 2nd bullet
here? (From volume 3 of Intel's IA32 and 64 manual.)
https://i.imgur.com/elZIlfy.png

One of those tables will need to be parsed to configure boot for SMP
systems correctly, yes. I thought you meant the tables that need to be
setup for the local APIC to be initialized and used correctly (which is
also necessary to be able to send Startup Inter-Proessor Interrupts (SIPI)
for SMP boot to work).


> One area the current PC BSP is poor is extended interrupt support past the
> master and slave legacy PICs.

> >
> >
> >>>
> >>>> 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.

> Great.

> >
> >>> 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).

> Agreed, this mirrors the tier system in RTEMS where tier 1 is hardware as
you
> need valid test results posted to have a BSP and arch placed in tier 1.

> See https://docs.rtems.org/branches/master/user/hardware/tiers.html

> >
> >
> >>>
> >>> 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?

> Yes, I have a minnow board, an ITX atom board and other box. With
something like
> iPXE and network booting the rtems-test command can run the tests. PC test
> results from the ITX box:

> https://lists.rtems.org/pipermail/build/2017-October/000012.html

That's great! Glad to hear it!


> > 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.

> Yeah that is sensible.

> Chris