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

[Joel Sherrill]

On Sun, May 20, 2018, 12:10 PM Amaan Cheval <amaan.cheval at gmail.com> wrote:

> On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom <gedare at rtems.org> wrote:
> > On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill <joel at rtems.org> wrote:
> >>
> >>
> >> 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.
>
> Sure. The files would run on the target, yes. These are the ones
> listed here (as linked to in my blog post, perhaps without sufficient
> emphasis):
> https://wiki.osdev.org/UEFI#Developing_with_GNU-EFI
>
> >>
> >> Can you tell which approach FreeBSD takes?
>
> FreeBSD takes the gnu-efi approach I see as the "winner" here (also a
> link in the post):
>
> https://github.com/freebsd/freebsd/blob/996b0b6d81cf31cd8d58af5d8b45f0b4945d960d/stand/efi/loader/Makefile#L98-L1
> <https://github.com/freebsd/freebsd/blob/996b0b6d81cf31cd8d58af5d8b45f0b4945d960d/stand/efi/loader/Makefile#L98-L119>


This is (no surprise) appropriately licensed and IMO the winning solution.
Knowing it is what FreeBSD does makes it an easy choice.

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.


>
> >>
> >>>
> >>> - 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.
> >>
> >
> > It appears to be a standard 2-clause BSD released by Intel as
> > specified in the README file of gnu-efi.
> >
> >>
> >>>
> >>> - 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
> >
>
> Noted, thanks!
>
> >>>
> >>>
> >>> [1] https://www.sourceware.org/ml/binutils/2018-05/msg00197.html
> >>> [2] https://sourceforge.net/projects/gnu-efi/
> >>
> >>
> >> --joel
> >>
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180520/8d755df3/attachment-0002.html>