On Wed, Jun 13, 2018 at 11:33 AM, Amaan Cheval <amaan.che...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
