Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
They have a custom bootloader https://github.com/oxidecomputer/phbl that runs without AGESA or any of the normal stack of stuff. From they podcast it sounds like it was quite a bit of work to get it working.
Rust as a pure language perhaps not, but Rust as an ecosystem, has a standard UEFI alloc/dealloc system: https://github.com/rust-lang/rust/blob/master/library/std/sr...
One could, of course, write their own allocator and heap tracking system as part of the UEFI firmware, or reimplement the entire thing without any of the standard library and simply relying on the core library, but if you want to deal with fallibility, you'll have to reimplement every part of the language toolkit and use Option<> or Result<> for every API call, which would only complicate the rewrite more.
Even better, dump that UEFI crap.
Just directboot a static Linux kernel and kexec() the real kernel, like petitboot does: https://github.com/open-power/petitboot/blob/master/README.m...
Device trees are what you get if you don't implement ACPI.
While there are alternatives, you generally seem to get "device trees and a barebones bootloader" on ARM and "UEFI + ACPI" on amd64.
ACPI will list hardware and necessary hardware properties based on some basic API calls to the system interface. UEFI initialises the ACPI data structure and exposes it to the bootloader so the appropriate drivers can be loaded and configured.
With device trees, you basically configure and build the drivers and configuration into the kernel/OS you're trying to load. That's why compiling Linux on amd64 is generally easy and produces a single image, while for many other devices (smartphones, some SBCs) you need to compile a kernel per device. The device trees only need to be imported/written once per device (or device type, depending on how nice the manufacturers are), but that's how you get stuff like this: https://github.com/torvalds/linux/tree/master/arch/arm64/boo...
On ARM there are actually a few devices that implement UEFI, but most of them have Secure Boot locked in and configured to only boot Windows.
ACPI is not perfect and it's not technically required to have UEFI to implement something better than device trees, but I'm not sure if reinventing the wheel here is necessary or even preferable. UEFI already has open source implementations ready to go, with kernels and other tools already containing code to interact with those APIs, whereas a custom ACPI replacement protocol would need more implementation work,
> someone would have to pay a team of engineers to rewrite everything
A partial effort has already been made a while back: https://github.com/tianocore/edk2-staging/tree/edkii-rust
However, this uses uefi-rs, which is incompatible with TianoCore's BSD+Patent licensing, and therefore cannot be used as reference material, as the wiki page states: https://github.com/tianocore/tianocore.github.io/wiki/Tasks-...
More recent efforts have also been mentioned in the mailing list: https://edk2.groups.io/g/devel/search?p=recentpostdate%2Fsti...
> someone would have to pay a team of engineers to rewrite everything
A partial effort has already been made a while back: https://github.com/tianocore/edk2-staging/tree/edkii-rust
However, this uses uefi-rs, which is incompatible with TianoCore's BSD+Patent licensing, and therefore cannot be used as reference material, as the wiki page states: https://github.com/tianocore/tianocore.github.io/wiki/Tasks-...
More recent efforts have also been mentioned in the mailing list: https://edk2.groups.io/g/devel/search?p=recentpostdate%2Fsti...