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