On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote: > > > On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval <amaan.che...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
