[GSoC - x86_64] Using FreeBSD's UEFI loader for RTEMS static binaries

[Gedare Bloom]

On Wed, Jun 13, 2018 at 11:33 AM, Amaan Cheval <amaan.cheval at gmail.com> wrote:
> Hi!
>
> As we discussed in the last thread on the topic[1], I'm trying to use
> FreeBSD's loader.efi directly with RTEMS' generated static binaries
> (since FreeBSD's loader.efi has an ELF loader).
>
> In brief, I did this by:
> - Installing FreeBSD in QEMU with UEFI firmware
> - Confirming that FreeBSD's loader.efi is in fact used
> - Replacing FreeBSD's ELF kernel with a "custom" kernel[2] with an RTEMS ELF
> - Verifying that the code running after FreeBSD's loader.efi is in
> fact the "RTEMS ELF" by attaching gdb to QEMU (the rtems ELF is simply
> a while(1) loop compiled with RTEMS' tools - see later on why I can't
> do something more elaborate)
>
> Some more details of the process I followed for testing this:
> https://gist.github.com/AmaanC/42faa131ee97a1d6c4c7c25c29f0fde9z
>
> I think this method is superior to the PIC RTEMS method because:
> - FreeBSD uses it
> - RTEMS retains static ELF binaries, which can likely easily be
> combined with a Multiboot header + protect mode starter code
> - FreeBSD has methods to provide ACPI related hints to their ELF
> kernel - this might make our implementation with regards to ACPI
> simpler too
>
> Regarding some concerns Chris had with linker options and whatnot,
> here's what FreeBSD uses:
> https://www.freebsd.org/doc/en/books/arch-handbook/boot-kernel.html
>
> Here's what I used (with the code being a simple while(1) loop):
>   x86_64-rtems5-gcc ktest.c -c -nostdlib
>   x86_64-rtems5-ld ktest.o -e main -o kernel
>
> -------------------------------------------------------------------------------------
>
> What I need input on:
> - Right now, we use the following RTEMS code for testing:
>
> int main() {
>   while(1) {}
> }
>

It's not really an RTEMS code, it is a C program (ktest.c) compiled
with the RTEMS-flavored toolchain, right?

It would be nice to get an RTEMS x86-64 BSP to start, at least to
confirm that you reach _start, and then even you can try to make it to
the "boot_card" startup sequence.

> That's literally it, because we have no access to standard libraries,
> and loader.efi calls ExitBootServices, after which we can't just
> easily directly access video memory (at 0xb8000 for eg.) to print to
> the screen. The way FreeBSD handles this is by initializing the
> console and printing to that - I haven't been able to easily port that
> yet.
>
> The question is - should I start with that effort (i.e. bringing
> printk console functionality to RTEMS) the way FreeBSD does? This way,
> we skip the bootloader for now by simply using the one built on the
> real FreeBSD - if the console prints and more elaborate linking tests
> work fine, we can be certain that this works. If _not_, I believe the
> console initialization code will likely still remain the same since
> we'll want to do it similar to how FreeBSD does it.
>

I think this approach to getting a console to work may be reasonable,
assuming the FreeBSD console is not much more complicated than what
RTEMS needs. For sure, you should not need/rely on the video at this
stage...

> What do you think?
>
> Cheers,
> Amaan
>
> [1] https://lists.rtems.org/pipermail/devel/2018-June/022052.html
> [2] https://www.freebsd.org/doc/handbook/kernelconfig-building.html