<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Sun, May 20, 2018, 12:10 PM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a>> wrote:<br>
> On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a>> wrote:<br>
>><br>
>><br>
>> On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com" target="_blank" rel="noreferrer">amaan.cheval@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi everyone!<br>
>>><br>
>>> I've written a quick blog post summarizing the options I've considered<br>
>>> to make the x86_64 port work with UEFI firmware - the primary winner<br>
>>> seems to be in my eyes to use "gnu-efi" and to add support for the<br>
>>> target "pei-x86-64" (aliased to "efi-app-x86_64") to<br>
>>> "x86_64-rtems5-objcopy" in binutils. I've submitted a patch for this<br>
>>> here[1].<br>
>><br>
>><br>
>> That patch is quite simple so shouldn't be a problem if this is the<br>
>> direction<br>
>> that gets consensus.<br>
>>><br>
>>><br>
>>> The blog post is here:<br>
>>> <a href="https://blog.whatthedude.com/post/uefi-app-options/" rel="noreferrer noreferrer" target="_blank">https://blog.whatthedude.com/post/uefi-app-options/</a><br>
>>><br>
>>> I'd appreciate all feedback (and please do let me know if I haven't<br>
>>> provided enough context)!<br>
>>><br>
>>> Specifically, some concerns I'd like to discuss are:<br>
>>><br>
>>> - Does everyone agree with me on choosing gnu-efi + objcopy as our<br>
>>> method of choice?<br>
>><br>
>><br>
>> Does using gnu-efi add code that runs on the target? Can you point<br>
>> us to the files, if so.<br>
<br>
Sure. The files would run on the target, yes. These are the ones<br>
listed here (as linked to in my blog post, perhaps without sufficient<br>
emphasis):<br>
<a href="https://wiki.osdev.org/UEFI#Developing_with_GNU-EFI" rel="noreferrer noreferrer" target="_blank">https://wiki.osdev.org/UEFI#Developing_with_GNU-EFI</a><br>
<br>
>><br>
>> Can you tell which approach FreeBSD takes?<br>
<br>
FreeBSD takes the gnu-efi approach I see as the "winner" here (also a<br>
link in the post):<br>
<a href="https://github.com/freebsd/freebsd/blob/996b0b6d81cf31cd8d58af5d8b45f0b4945d960d/stand/efi/loader/Makefile#L98-L119" rel="noreferrer noreferrer" target="_blank">https://github.com/freebsd/freebsd/blob/996b0b6d81cf31cd8d58af5d8b45f0b4945d960d/stand/efi/loader/Makefile#L98-L1</a></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is (no surprise) appropriately licensed and IMO the winning solution. Knowing it is what FreeBSD does makes it an easy choice.</div><div dir="auto"><br></div><div dir="auto">A comment in the readme mentions there is a i386 version of this code so that could be used to let pc386 boot from UEFI.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
>><br>
>>><br>
>>> - How do we integrate gnu-efi into our build process? A part of the<br>
>>> RSB, making sure the path to the libraries are in an exported<br>
>>> variable? Or perhaps a part of the RTEMS kernel itself if the licenses<br>
>>> are compatible (I don't see any on the project[2], only copyright<br>
>>> notices within the source files of the release versions).<br>
>><br>
>><br>
>> GNU-efi would be built like qemu or the device tree compiler would<br>
>> be my guess and x86_64-rtems toolset might add that to the standard<br>
>> set of tools. License on host tools being GPL isn't an issue.<br>
>><br>
><br>
> It appears to be a standard 2-clause BSD released by Intel as<br>
> specified in the README file of gnu-efi.<br>
><br>
>><br>
>>><br>
>>> - Regardless of how we manage UEFI, do we require Multiboot support<br>
>>> too? Multiboot drops us in a 32-bit protected mode environment,<br>
>>> whereas 64-bit UEFI firmware will boot us into 64-bit long mode - this<br>
>>> would mean the kernel would need to support separate code-paths for<br>
>>> the 2 if we want to support both methods.<br>
>><br>
>><br>
>> That's a good question. For GSoC, I think UEFI is fine and perhaps a ticket<br>
>> under the general "modern PC support" ticket for multiboot support. Unless<br>
>> that eliminates a LOT of PCs.<br>
>><br>
>> I don't want you to spend all summer getting an image to boot both<br>
>> ways. Personally, I want you to have a working BSP one way. :)<br>
> +1<br>
><br>
<br>
Noted, thanks!<br>
<br>
>>><br>
>>><br>
>>> [1] <a href="https://www.sourceware.org/ml/binutils/2018-05/msg00197.html" rel="noreferrer noreferrer" target="_blank">https://www.sourceware.org/ml/binutils/2018-05/msg00197.html</a><br>
>>> [2] <a href="https://sourceforge.net/projects/gnu-efi/" rel="noreferrer noreferrer" target="_blank">https://sourceforge.net/projects/gnu-efi/</a><br>
>><br>
>><br>
>> --joel<br>
>><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>