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

[Gedare Bloom]

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.
>
> 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.
>

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

>>
>>
>> [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