Hacker News Reader

Comment by ajross | Hacker News Reader

For those checking comments first: this is mostly a tutorial on how to build and link a 16/32 bit MBR loader and mode switch implementation in assembly. It's very similar to what you'll find on osdev.org. The Rust content is limited to a single function at the end which writes some characters to an assumed-pre-initialized EGA text console.

While modern hardware does continue to support these modes via various detection tricks, "real" handoff from the firmware happens in a 64 bit EFI environment these days, and the framebuffer tends to be in a graphics mode and expects to be accesesed initially via the exposed UEFI API (or to be reset from scratch by an OS graphics driver, of course).

This is fun and instructive, but not really reflective of the way modern hardware boots.

View on HN

For some reason (probably due to QEMU), these kinds of bootloader tutorials are still stuck in the BIOS era. UEFI remains completely under-taught, which is probably in part because it's hideously complex.

Note that modern computers are supposed to be dropping BIOS boot support this year[1].

[1] https://arstechnica.com/gadgets/2017/11/intel-to-kill-off-th...

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.

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.

Thanks for sharing 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.

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

Reply on news.ycombinator.com