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
