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