Hacker News Reader

Comment by ajross | Hacker News Reader

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

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.

View on HN

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

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.

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.

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.

I'm guessing this might also be of interest:

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

But no eboot.c - there's this however:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

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

uefi-paint - UEFI-bootable touch paint app https://github.com/nrdmn/uefi-paint

uefi-freetype - changing the system BIOS to use Comic Sans https://github.com/nrdmn/uefi-freetype https://twitter.com/andy_kelley/status/1176561072398098432

[1]: https://ziglang.org/download/0.5.0/release-notes.html#UEFI-S...

Thanks for sharing on HN.

Reply on news.ycombinator.com