x86_64 port and BSP (GSoC 2018)

Tue Mar 20 06:13:59 UTC 2018

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.

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

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

> 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