x86_64 BSP : Status Update [ticket #2898]

[Karel Gardas]

On 3/29/21 12:08 PM, Amaan Cheval wrote:
> I wouldn't recommend running it on real hardware yet - I don't think
> anyone has tested it on hardware.

I did and reported to the mailing list. Generally speaking works on some
systems (both demos: hello/ticker) and another it causes general
protection fault on an attempt to disable legacy interrupt controller.
Advice on osdev was that using 1GB pages may be problematic so I should
switch to 2M pages at least for test. Still slacking on this one as I'm
overloaded in real life.

> Not all tests in the testsuite pass in QEMU either, from what I
> remember (some basic ones do), so that will likely be what you'll need
> to work on.
> 
> To run the BSP in QEMU, you'll need to follow these instructions:
> https://docs.rtems.org/branches/master/user/bsps/bsps-x86_64.html
> 
> Let me know if you run into any issues, since the setup can be a bit
> complicated. In summary, for the setup, you'll want to:
> 
> - Build RTEMS/RSB with x86-64 as the BSP (this should be the same as
> what you did for your GSoC proof in terms of building the BSP and
> samples/tests)
> - Get QEMU
> - Build OVMF's open-source UEFI firmware
> - Get FreeBSD booting in QEMU with UEFI, and then replace it's
> `kernel` with a built RTEMS application (such as the ticker tests or
> hello.exe, etc.)
> - Run FreeBSD image with RTEMS app as its kernel

Or! Install VirtualBox, install FreeBSD into it but before it make sure
you tick/switch on UEFI box and then install. Once done you do have FBSD
working in UEFI environment.
The advice on replacing kernel is not needed as you can select rtems
binary dynamically from the bootloader command line. Simply: boot to
boot loader and hit '3' to get into boot loader prompt then type:

boot <path to your rtems binary> and hit ENTER key

and it'll boot, e.g.:

boot /boot/rtems/hello.exe

works here.

> We need to do this because for the x86-64 BSP, we use FreeBSD's
> bootloader. This is slightly problematic, because FreeBSD's bootloader
> only supports UFS/ZFS for filesystems.
> I think ideally, we'll want a UEFI-compatible bootloader which can
> support more filesystems - FreeBSD's bootloader is functional, but
> perhaps not the best for a dev/prod environment long-term - maybe
> Joel/Chris can comment on this.

<rant>This is quite personal note, it basically depends where you
develop. If in FreeBSD, then its boot loader is best option since you
only need to copy rtems binary into /boot somewhere and reboot for
test.</rant>

Anyway, I've tested also bootboot but this has not worked well e.g. not
at all. GRUB probably requires multiboot support which is a step back
from UEFI. I have multiboot bits done here but not tested as I've moved
to real UEFI work later.

I've also investigated compiling RTEMS binary directly into PE+ but this
requires PIC for all code (which Chris does not like and which may be a
bit problematic -- e.g. asm needs to be fixed in some places). You have
written somewhere that you have been able to do that, but I was not able
to duplicate your success with it.

So I think the best option is to use current freebsd bootloader for now
and then perhaps test other real UEFI/64bit loaders (slimboot comes to
mind). If not satisfied then write own wrapper/boot loader support which
will be compiled together with rtems app and it'll then relocate its ELF
code properly and boot. Zephyr provides some python code for generating
such wrapper.
https://github.com/zephyrproject-rtos/zephyr/tree/master/arch/x86/zefi

Note: if would be fantastic if RTEMS have the capability to call UEFI so
it would be best if bootloader does not call ExitBootServices() before
booting RTEMS. Well if it does, then still calling UEFI is nice to have
to for example:
- grab resolution and address of framebuffer -- which is way much better
than VESA fb in pc386 BSP IMHO.
- grab IP address from possible network boot
- set/check for nvram values.

> If there's still time after that, I think we can figure out which
> specific portions need to be worked on (i.e. running on hardware,
> improving existing drivers, adding libbsd support, SMP support, etc.).

I think the issue summary summs that very well. What we need for working
amd64 support is we need to grab required ACPI regs/tables to get memory
ranges and APICs configuration details, better paging (e.g. hopefully 2M
below 4G and then 1GB pages on top of that? -- depends on experiment
above), LoAPIC/APIC support in minimum but rather MSI(-X) where
supported. Use available bsd code as much as possible... Note: I spent
some time in FBSD code, I'm most interested in passing r/xsdt + UEFI
addr from fbsd loader to RTEMS app due to a need to grab right memory
map and UEFI fb addr/resolution. I've seen a lot there, but so far not
materialized any code for it -- especially since fbsd boot loader is a
bit complex due to a need of supporting loadable modules (besides kernel).

Thanks,
Karel