<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, May 25, 2018, 11:15 AM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey!<br>
<br>
Skippable details about how FreeBSD handles the UEFI boot process!<br>
--------------------------------------------------------------------------------<br>
<br>
Having looked into it a bit more, my understanding of how FreeBSD<br>
handles this process is:<br>
- They build a two-stage bootloader for EFI, called boot1.efi and loader.efi[1]<br>
- loader.efi is an interactive prompt which may autoboot, or a "boot<br>
kernelImg" command can be used to load the actual kernel<br>
- The kernel is loaded as an ELF through helper functions. The<br>
command_boot[2] function drives this:<br>
  - In brief, through calls go through:<br>
    command_boot -> mod_loadkld -> file_load -><br>
file_formats[i]->l_load (actually the loadfile function in<br>
load_elf.c[3])<br>
  - The loadfile function parses the program and section headers of<br>
the ELF file (through more function detours that are not really<br>
important)<br>
  - Once the ELF has been loaded at the correct entry_addr that it<br>
expects to be loaded at in memory, the l_exec[4] function is called,<br>
which is actually elf64_exec in elf64_freebsd.c[5], at which hopefully<br>
through trampolining magic, the control flow will transfer to the<br>
kernel or ELF module<br>
<br>
--------------------------------------------------------------------------------<br>
<br>
What this means for RTEMS if we go with gnu-efi is essentially 2<br>
options, given that the objcopy method of converting from ELF->PE<br>
requires the ELF to be a position-independent shared library:<br>
<br>
- Using -fPIC to compile all of RTEMS, including the RTEMS user's<br>
application code. This way we'd have librtemsbso.so, librtemscpu.so,<br>
etc. which would then be linked into user_app.c through -fPIC and<br>
-shared flags still, creating one singular hello.so, which can then<br>
finally be converted into hello.efi and put on a FAT filesystem and<br>
booted. This seems doable, but I'm fairly concerned about it further<br>
complicating our build system and likely being quite singular in its<br>
focus on EFI.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I'm using PIC on the Deos BSP. RTEMS is still a .a and exes are linked with our static libraries and Deos .so. </div><div dir="auto"><br></div><div dir="auto">Unless the loader forces something, you can use PIC with no build system changes.</div><div dir="auto"><br></div><div dir="auto">note that thread local storage is different on i386 with and without PIC.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- The FreeBSD way of a (loader.efi) and a hello.exe (ELF64) put on<br>
possibly the same partition on the FAT filesystem required for UEFI<br>
application images anyway. The loader.efi can find the hello.exe file<br>
through perhaps a config file it can read or by having a magic-name<br>
like rtems.exe or something. This effectively means we need an ELF<br>
dynamic linker / loader (akin to ld.so) within RTEMS' source. I think<br>
using FreeBSD's code for this should be fine. One added benefit of<br>
this method is that librtems* and user applications remain as ELF64s,<br>
which in the future could also be used with Multiboot with a slightly<br>
modified "loader" (i.e. one which generates the apt Multiboot magic<br>
header, and boots the PC from 32-bit protected mode to 64-bit long<br>
mode).<br>
<br>
I prefer the latter approach personally. If both of these seem too<br>
complicated, we can of course go back to considering generating the PE<br>
header format in ASM the way Linux distros use EFISTUB and the code<br>
Chris shared (as I mentioned in my original blog post) for wimboot.<br>
Those approaches may be significantly simpler in a sense, but may<br>
limit how we use UEFI Services - I'm not sure about the details of<br>
this yet - I can investigate if y'all aren't fond of the option I laid<br>
down above.<br>
<br>
Let me know!<br>
<br>
[1] <a href="https://www.freebsd.org/cgi/man.cgi?query=loader&apropos=0&sektion=8&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html" rel="noreferrer noreferrer" target="_blank">https://www.freebsd.org/cgi/man.cgi?query=loader&apropos=0&sektion=8&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html</a><br>
[2] <a href="https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L53" rel="noreferrer noreferrer" target="_blank">https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L53</a><br>
[3] <a href="https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/common/load_elf.c#L150" rel="noreferrer noreferrer" target="_blank">https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/common/load_elf.c#L150</a><br>
[4] <a href="https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L107" rel="noreferrer noreferrer" target="_blank">https://github.com/freebsd/freebsd/blob/433bd38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L107</a><br>
[5] <a href="https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/efi/loader/arch/amd64/elf64_freebsd.c#L93" rel="noreferrer noreferrer" target="_blank">https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/efi/loader/arch/amd64/elf64_freebsd.c#L93</a><br>
<br>
On Sun, May 20, 2018 at 10:52 PM, Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a>> wrote:<br>
><br>
><br>
> On Sun, May 20, 2018, 12:10 PM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com" target="_blank" rel="noreferrer">amaan.cheval@gmail.com</a>> wrote:<br>
>><br>
>> On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a>> wrote:<br>
>> > On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a>> wrote:<br>
>> >><br>
>> >><br>
>> >> On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com" target="_blank" rel="noreferrer">amaan.cheval@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Hi everyone!<br>
>> >>><br>
>> >>> I've written a quick blog post summarizing the options I've considered<br>
>> >>> to make the x86_64 port work with UEFI firmware - the primary winner<br>
>> >>> seems to be in my eyes to use "gnu-efi" and to add support for the<br>
>> >>> target "pei-x86-64" (aliased to "efi-app-x86_64") to<br>
>> >>> "x86_64-rtems5-objcopy" in binutils. I've submitted a patch for this<br>
>> >>> here[1].<br>
>> >><br>
>> >><br>
>> >> That patch is quite simple so shouldn't be a problem if this is the<br>
>> >> direction<br>
>> >> that gets consensus.<br>
>> >>><br>
>> >>><br>
>> >>> The blog post is here:<br>
>> >>> <a href="https://blog.whatthedude.com/post/uefi-app-options/" rel="noreferrer noreferrer" target="_blank">https://blog.whatthedude.com/post/uefi-app-options/</a><br>
>> >>><br>
>> >>> I'd appreciate all feedback (and please do let me know if I haven't<br>
>> >>> provided enough context)!<br>
>> >>><br>
>> >>> Specifically, some concerns I'd like to discuss are:<br>
>> >>><br>
>> >>> - Does everyone agree with me on choosing gnu-efi + objcopy as our<br>
>> >>> method of choice?<br>
>> >><br>
>> >><br>
>> >> Does using gnu-efi add code that runs on the target? Can you point<br>
>> >> us to the files, if so.<br>
>><br>
>> Sure. The files would run on the target, yes. These are the ones<br>
>> listed here (as linked to in my blog post, perhaps without sufficient<br>
>> emphasis):<br>
>> <a href="https://wiki.osdev.org/UEFI#Developing_with_GNU-EFI" rel="noreferrer noreferrer" target="_blank">https://wiki.osdev.org/UEFI#Developing_with_GNU-EFI</a><br>
>><br>
>> >><br>
>> >> Can you tell which approach FreeBSD takes?<br>
>><br>
>> FreeBSD takes the gnu-efi approach I see as the "winner" here (also a<br>
>> link in the post):<br>
>><br>
>> <a href="https://github.com/freebsd/freebsd/blob/996b0b6d81cf31cd8d58af5d8b45f0b4945d960d/stand/efi/loader/Makefile#L98-L1" rel="noreferrer noreferrer" target="_blank">https://github.com/freebsd/freebsd/blob/996b0b6d81cf31cd8d58af5d8b45f0b4945d960d/stand/efi/loader/Makefile#L98-L1</a><br>
><br>
><br>
> This is (no surprise) appropriately licensed and IMO the winning solution.<br>
> Knowing it is what FreeBSD does makes it an easy choice.<br>
><br>
> A comment in the readme mentions there is a i386 version of this code so<br>
> that could be used to let pc386 boot from UEFI.<br>
><br>
>><br>
>><br>
>> >><br>
>> >>><br>
>> >>> - How do we integrate gnu-efi into our build process? A part of the<br>
>> >>> RSB, making sure the path to the libraries are in an exported<br>
>> >>> variable? Or perhaps a part of the RTEMS kernel itself if the licenses<br>
>> >>> are compatible (I don't see any on the project[2], only copyright<br>
>> >>> notices within the source files of the release versions).<br>
>> >><br>
>> >><br>
>> >> GNU-efi would be built like qemu or the device tree compiler would<br>
>> >> be my guess and x86_64-rtems toolset might add that to the standard<br>
>> >> set of tools. License on host tools being GPL isn't an issue.<br>
>> >><br>
>> ><br>
>> > It appears to be a standard 2-clause BSD released by Intel as<br>
>> > specified in the README file of gnu-efi.<br>
>> ><br>
>> >><br>
>> >>><br>
>> >>> - Regardless of how we manage UEFI, do we require Multiboot support<br>
>> >>> too? Multiboot drops us in a 32-bit protected mode environment,<br>
>> >>> whereas 64-bit UEFI firmware will boot us into 64-bit long mode - this<br>
>> >>> would mean the kernel would need to support separate code-paths for<br>
>> >>> the 2 if we want to support both methods.<br>
>> >><br>
>> >><br>
>> >> That's a good question. For GSoC, I think UEFI is fine and perhaps a<br>
>> >> ticket<br>
>> >> under the general "modern PC support" ticket for multiboot support.<br>
>> >> Unless<br>
>> >> that eliminates a LOT of PCs.<br>
>> >><br>
>> >> I don't want you to spend all summer getting an image to boot both<br>
>> >> ways. Personally, I want you to have a working BSP one way. :)<br>
>> > +1<br>
>> ><br>
>><br>
>> Noted, thanks!<br>
>><br>
>> >>><br>
>> >>><br>
>> >>> [1] <a href="https://www.sourceware.org/ml/binutils/2018-05/msg00197.html" rel="noreferrer noreferrer" target="_blank">https://www.sourceware.org/ml/binutils/2018-05/msg00197.html</a><br>
>> >>> [2] <a href="https://sourceforge.net/projects/gnu-efi/" rel="noreferrer noreferrer" target="_blank">https://sourceforge.net/projects/gnu-efi/</a><br>
>> >><br>
>> >><br>
>> >> --joel<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> devel mailing list<br>
>> >> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
>> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>