[GSoC] Ways to make the x86_64 port work with UEFI

Joel Sherrill joel at rtems.org
Fri May 18 21:53:40 UTC 2018


On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval <amaan.cheval at gmail.com>
wrote:

> Hi everyone!
>
> I've written a quick blog post summarizing the options I've considered
> to make the x86_64 port work with UEFI firmware - the primary winner
> seems to be in my eyes to use "gnu-efi" and to add support for the
> target "pei-x86-64" (aliased to "efi-app-x86_64") to
> "x86_64-rtems5-objcopy" in binutils. I've submitted a patch for this
> here[1].
>

That patch is quite simple so shouldn't be a problem if this is the
direction
that gets consensus.

>
> The blog post is here:
> https://blog.whatthedude.com/post/uefi-app-options/
>
> I'd appreciate all feedback (and please do let me know if I haven't
> provided enough context)!
>
> Specifically, some concerns I'd like to discuss are:
>
> - Does everyone agree with me on choosing gnu-efi + objcopy as our
> method of choice?
>

Does using gnu-efi add code that runs on the target? Can you point
us to the files, if so.

Can you tell which approach FreeBSD takes?


> - How do we integrate gnu-efi into our build process? A part of the
> RSB, making sure the path to the libraries are in an exported
> variable? Or perhaps a part of the RTEMS kernel itself if the licenses
> are compatible (I don't see any on the project[2], only copyright
> notices within the source files of the release versions).
>

GNU-efi would be built like qemu or the device tree compiler would
be my guess and x86_64-rtems toolset might add that to the standard
set of tools. License on host tools being GPL isn't an issue.



> - Regardless of how we manage UEFI, do we require Multiboot support
> too? Multiboot drops us in a 32-bit protected mode environment,
> whereas 64-bit UEFI firmware will boot us into 64-bit long mode - this
> would mean the kernel would need to support separate code-paths for
> the 2 if we want to support both methods.
>

That's a good question. For GSoC, I think UEFI is fine and perhaps a ticket
under the general "modern PC support" ticket for multiboot support. Unless
that eliminates a LOT of PCs.

I don't want you to spend all summer getting an image to boot both
ways. Personally, I want you to have a working BSP one way. :)

>
> [1] https://www.sourceware.org/ml/binutils/2018-05/msg00197.html
> [2] https://sourceforge.net/projects/gnu-efi/
>

--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180518/f8e6ef23/attachment-0002.html>


More information about the devel mailing list