4 ms·

I'm curious to learn more about "real" handoffs and the EFI environment. If you had any suggestions about where to start I'd be grateful.

ajross 6y ago
There's sort of a paucity of tutorials in that space. You're pretty much stuck reading specs and studying source code. Here's the UEFI specification and a link to the "gnu-efi" project, which provide a reasonably clean (if... idiosyncratic) environment for building and running EFI binaries with a free toolchain: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8... https://sourceforge.net/projects/gnu-efi/ https://sourceforge.net/projects/gnu-efi/ Broadly: EFI is a simple C environment (albeit one based on windows-style PE binaries and not ELF). The firmware will load and run your application binary and jump to its entry point, passing a giant table of API hooks and callbacks for you to use to interact with its services. You then read and assemble your own OS image using these tools and jump into it.
- sjtindell 6y ago
  Thanks for sharing on HN.
- moonchild 6y ago
  Personally, I haven't found the gnu efi toolchain very helpful. I just use clang with the appropriate flags, which are: -target x86_64-unknown-windows -ffreestanding -fno-builtin -fshort-wchar -mno-red-zone And link, again with clang, using these flags: -target x86_64-unknown-windows -nostdlib -Wl,-entry:efi_main -Wl,-subsystem:efi_application -fuse-ld=lld-link I believe you can do the same with gcc and gold|gnu ld without much more effort. The toolchain doesn't really justify its complexity at all. The headers, on the other hand, are invaluable. I use c-efi[1]'s headers, but would probably use gnu efi another time; c-efi has some bugs and missing structures. Worth noting: despite the name, gnu efi isn't gpl licensed. In fact, I don't think either (c-efi or gnu efi) can really be considered copyrightable; they're essentially direct translations of the spec. 1. https://github.com/c-util/c-efi https://github.com/c-util/c-efi
  - moonchild 6y ago
    Additionally, efi isn't useful for much beyond a bootloader, so you can use clang for the bootloader and gcc (or whatever else) for the OS itself. So you can depend on non-clang features.
- e12e 6y ago
  I'm guessing this might also be of interest: https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.... Seems to be a little bit out of date, though: > The code that modifies the bzImage header, along with the EFI-specific entry point that the firmware loader jumps to are collectively known as the “EFI boot stub”, and live in arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c I found: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/boot/header.S?h=v5.7.9 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... But no eboot.c - there's this however: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/boot/compressed/efi_thunk_64.S?h=v5.7.9 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
  - codetrotter 6y ago
    Another potential point of interest that I remember is that in the Zig 0.5.0 release notes, where UEFI support is mentioned [1], they provide a few links relating to UEFI programming with Zig: uefi-examples - tutorials https://github.com/nrdmn/uefi-examples https://github.com/nrdmn/uefi-examples uefi-paint - UEFI-bootable touch paint app https://github.com/nrdmn/uefi-paint https://github.com/nrdmn/uefi-paint uefi-freetype - changing the system BIOS to use Comic Sans https://github.com/nrdmn/uefi-freetype https://github.com/nrdmn/uefi-freetype https://twitter.com/andy_kelley/status/1176561072398098432 https://twitter.com/andy_kelley/status/1176561072398098432 [1]: https://ziglang.org/download/0.5.0/release-notes.html#UEFI-Support https://ziglang.org/download/0.5.0/release-notes.html#UEFI-S...
- javajosh 6y ago
  Thanks. That specification is almost 2800 pages long - and it covers far more specific technology than I would have expected. At the end of the day, couldn't the firmware just reserve a fixed chunk of system memory for IO and divide it up between all the attached devices? Then adopt a convention that memory is initialized with the first, say, 1MB available from every device (loaded asynchronously), and execution starts at memory region N - the N being optionally chosen by the user in a pre-boot, BIOS-like screen.
  - ZeikJT 6y ago
    Everyone starts with a simple idea. But by the time every hardware and software company has put in their input/requests/demands it'll end up at thousands of pages.

ajross 6y ago

There's sort of a paucity of tutorials in that space. You're pretty much stuck reading specs and studying source code. Here's the UEFI specification and a link to the "gnu-efi" project, which provide a reasonably clean (if... idiosyncratic) environment for building and running EFI binaries with a free toolchain: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8... https://sourceforge.net/projects/gnu-efi/ https://sourceforge.net/projects/gnu-efi/ Broadly: EFI is a simple C environment (albeit one based on windows-style PE binaries and not ELF). The firmware will load and run your application binary and jump to its entry point, passing a giant table of API hooks and callbacks for you to use to interact with its services. You then read and assemble your own OS image using these tools and jump into it.

sjtindell 6y ago
Thanks for sharing on HN.
moonchild 6y ago
Personally, I haven't found the gnu efi toolchain very helpful. I just use clang with the appropriate flags, which are: -target x86_64-unknown-windows -ffreestanding -fno-builtin -fshort-wchar -mno-red-zone And link, again with clang, using these flags: -target x86_64-unknown-windows -nostdlib -Wl,-entry:efi_main -Wl,-subsystem:efi_application -fuse-ld=lld-link I believe you can do the same with gcc and gold|gnu ld without much more effort. The toolchain doesn't really justify its complexity at all. The headers, on the other hand, are invaluable. I use c-efi[1]'s headers, but would probably use gnu efi another time; c-efi has some bugs and missing structures. Worth noting: despite the name, gnu efi isn't gpl licensed. In fact, I don't think either (c-efi or gnu efi) can really be considered copyrightable; they're essentially direct translations of the spec. 1. https://github.com/c-util/c-efi https://github.com/c-util/c-efi
- moonchild 6y ago
  Additionally, efi isn't useful for much beyond a bootloader, so you can use clang for the bootloader and gcc (or whatever else) for the OS itself. So you can depend on non-clang features.
e12e 6y ago
I'm guessing this might also be of interest: https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.... Seems to be a little bit out of date, though: > The code that modifies the bzImage header, along with the EFI-specific entry point that the firmware loader jumps to are collectively known as the “EFI boot stub”, and live in arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c I found: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/boot/header.S?h=v5.7.9 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... But no eboot.c - there's this however: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/boot/compressed/efi_thunk_64.S?h=v5.7.9 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
- codetrotter 6y ago
  Another potential point of interest that I remember is that in the Zig 0.5.0 release notes, where UEFI support is mentioned [1], they provide a few links relating to UEFI programming with Zig: uefi-examples - tutorials https://github.com/nrdmn/uefi-examples https://github.com/nrdmn/uefi-examples uefi-paint - UEFI-bootable touch paint app https://github.com/nrdmn/uefi-paint https://github.com/nrdmn/uefi-paint uefi-freetype - changing the system BIOS to use Comic Sans https://github.com/nrdmn/uefi-freetype https://github.com/nrdmn/uefi-freetype https://twitter.com/andy_kelley/status/1176561072398098432 https://twitter.com/andy_kelley/status/1176561072398098432 [1]: https://ziglang.org/download/0.5.0/release-notes.html#UEFI-Support https://ziglang.org/download/0.5.0/release-notes.html#UEFI-S...
javajosh 6y ago
Thanks. That specification is almost 2800 pages long - and it covers far more specific technology than I would have expected. At the end of the day, couldn't the firmware just reserve a fixed chunk of system memory for IO and divide it up between all the attached devices? Then adopt a convention that memory is initialized with the first, say, 1MB available from every device (loaded asynchronously), and execution starts at memory region N - the N being optionally chosen by the user in a pre-boot, BIOS-like screen.
- ZeikJT 6y ago
  Everyone starts with a simple idea. But by the time every hardware and software company has put in their input/requests/demands it'll end up at thousands of pages.