Chris, I've blogged a summary of the 2 approaches we can take in integrating gnu-efi in case you missed the discussions earlier, btw. The FreeBSD approach isn't as fleshed out, but I'll let you all know what I find there.
https://blog.whatthedude.com/post/gnu-efi-kernel-so/ On Wed, Jun 6, 2018 at 2:30 PM, Amaan Cheval <amaan.che...@gmail.com> wrote: > I don't know yet, but I'll look into it. I'll pause the "hello.efi" approach > work until we settle on a direction, yes? For now, primarily improving the > stub, looking into the FreeBSD ld-elf.so, etc. Sound good? > > On Wed, Jun 6, 2018, 1:01 PM Chris Johns <chr...@rtems.org> wrote: >> >> On 6/6/18 5:22 pm, Amaan Cheval wrote: >> > On Wed, Jun 6, 2018 at 12:45 PM, Chris Johns <chr...@rtems.org> wrote: >> >> On 6/6/18 5:06 pm, Amaan Cheval wrote: >> >>> On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns <chr...@rtems.org> wrote: >> >>>> On 4/6/18 7:49 pm, Amaan Cheval wrote: >> >>>>> Please let me know if that approach doesn't make sense - given that >> >>>>> there is no dynamic loader in the RTEMS kernel as far as I know, >> >>>> >> >>>> There is a dynamic loader in RTEMS called libdl. It is not based >> >>>> around the ELF >> >>>> standard loader used for shared libraries and will not be. GOT and >> >>>> PLT do not >> >>>> add value to RTEMS because we do not have an active virtual address >> >>>> space with >> >>>> paging. >> >>>> >> >>>> The libdl code is currently supported with the i386 static builds. I >> >>>> would hope >> >>>> this would continue to be supported without major refactoring of that >> >>>> code. >> >>>> There are tests in the testsuite under libtests. >> >>> >> >>> Hm, so libdl can load static ELFs and handle those relocations itself? >> >>> In that case we could go the "FreeBSD" way more easily as I outlined >> >>> earlier; a loader UEFI application image (loader.efi) + the >> >>> application image to be found on the filesystem and loaded through >> >>> libdl, which we somehow call through loader.efi. >> >>> >> >>> loader.efi -> libdl -> hello.exe (static executable ELF now) >> >>> >> >> >> >> libdl is not designed to do this and do not think it could be made too. >> >> It needs >> >> a full RTEMS kernel located to run. >> > >> > Ah, I see. In that case porting FreeBSD's ELF loader is the only >> > viable option in this direction, I believe, since the ELF to be loaded >> > would be the RTEMS kernel+the user app. >> > >> >> Do we need to port it or can we use a released version from an installed >> FreeBSD? >> >> >> >> >>>> >> >>>>> what >> >>>>> we really want _is_ a static file, but for it to be a relocatable >> >>>>> PE, >> >>>>> we need to convince GCC to spit out a relocatable but fully resolved >> >>>>> shared library. >> >>>> >> >>>> It is not clear to me yet making the kernel relocatable is free of >> >>>> other >> >>>> possible issues. I will need to find time to review all the low level >> >>>> parts here >> >>>> and my time is currently limited. >> >>>> >> >>>> Does this UEFI work effect the score context switcher, interrupts, >> >>>> etc? If is >> >>>> does we will need to resolve what happens and if not should we >> >>>> consider leaving >> >>>> it if we can? >> >>> >> >>> It affects it in the sense that it's all compiled with fPIC, yes. It >> >>> needs to be if we're bundling it all together (creating hello.efi, >> >>> which includes the UEFI boot code, all of RTEMS, and the user app). >> >>> >> >>>> For example can iPXE chain load a multiboot image? >> >>> >> >>> Yes, we could just use Multiboot too. One thing to note, though - >> >>> Multiboot will drop us in 32-bit protected mode, whereas 64-bit UEFI >> >>> firmware will load is into 64-bit protected mode. >> >> >> >> Ah OK this is a good point and boards like a Minnow have a 32bit or >> >> 64bit BIOS >> >> or what ever it is called on those boards so this may not work. >> >> >> >>> Supporting Multiboot >> >>> too will involve adding some code to move to 64-bit mode before >> >>> actually calling into the generalized 64-bit mode code. >> >> >> >> Can it be used as a step towards another solution? >> > >> > Not sure what you mean - like if it would be useful anywhere outside >> > of the Multiboot work? If so, no, likely not, unless we also want >> > legacy BIOS support eventually, in which case it could be part of the >> > real mode->protected mode->long mode transition chain, but that's >> > unlikely :P >> > >> >> I was just wondering if a temporary short cut can be taken so we do not >> spend >> all our time on booting an image. >> >> Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
