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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
