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

[Amaan Cheval]

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) {}
}

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.

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