<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval <span dir="ltr"><<a href="mailto:amaan.cheval@gmail.com" target="_blank">amaan.cheval@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div><br></div><div>That patch is quite simple so shouldn't be a problem if this is the direction</div><div>that gets consensus. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The blog post is here:<br>
<a href="https://blog.whatthedude.com/post/uefi-app-options/" rel="noreferrer" target="_blank">https://blog.whatthedude.com/<wbr>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></blockquote><div><br></div><div>Does using gnu-efi add code that runs on the target? Can you point</div><div>us to the files, if so.</div><div><br></div><div>Can you tell which approach FreeBSD takes?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- 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></blockquote><div><br></div><div>GNU-efi would be built like qemu or the device tree compiler would</div><div>be my guess and x86_64-rtems toolset might add that to the standard</div><div>set of tools. License on host tools being GPL isn't an issue.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- 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></blockquote><div><br></div><div>That's a good question. For GSoC, I think UEFI is fine and perhaps a ticket</div><div>under the general "modern PC support" ticket for multiboot support. Unless</div><div>that eliminates a LOT of PCs.</div><div><br></div><div>I don't want you to spend all summer getting an image to boot both</div><div>ways. Personally, I want you to have a working BSP one way. :)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] <a href="https://www.sourceware.org/ml/binutils/2018-05/msg00197.html" rel="noreferrer" target="_blank">https://www.sourceware.org/ml/<wbr>binutils/2018-05/msg00197.html</a><br>
[2] <a href="https://sourceforge.net/projects/gnu-efi/" rel="noreferrer" target="_blank">https://sourceforge.net/<wbr>projects/gnu-efi/</a><br>
</blockquote></div><br></div><div class="gmail_extra">--joel</div></div>