On Sun, May 20, 2018, 12:10 PM Amaan Cheval <amaan.che...@gmail.com> wrote:
> On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom <ged...@rtems.org> wrote: > > 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. > > 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@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel