"100% Free" GNU Boot Discovers Again They Have Been Shipping Non-Free Code

[ahrs]

I doubt that you have understood me correctly. now UEFI has taken over all the work of the loader. the kernel does not load on its own. and it won't be able to do it for a long time.

The Linux kernel is not a UEFI, it is an EFI (assuming built with EFI_STUB support). There are people like Google that propose replacing bootloaders with Linux that then does nothing but kexec into the thing you actually want to use but even then you still need some sort of firmware to get to this stage.

[intelfx]

This is not fully correct, many operations rely on ACPI tables, runtime services or SMM.

ACPI is not part of UEFI, and neither is SMM. UEFI Runtime Services are not used to "load" the kernel, either.

[user556]

SMM is evil.

[archkde]

Big surprise, that’s exactly how it works right now.

This is not fully correct, many operations rely on ACPI tables, runtime services or SMM.

[brad0]

can't people teach the kernel to boot on its own without loaders? such an approach would solve many problems.

If you don't understand how anything works that might make sense.

[ssokolow]

You didn't understand. The Linux kernel will receive all the necessary information from UEFI to boot. but the Linux kernel will load on its own. The linux kernel will need UEFI only to provide the boot information. then we won't be afraid of who and when and how UEFI is written and what it contains.

The "hard part" that these UEFI replacements need to cover, which the Linux kernel doesn't, is the low-level bring-up. You wanna know why ARM devices are such a shitshow and Snapdragon X doesn't yet Just Work™ with Linux? Because the model you're advocating for was applied, so each device needs to have a description of which pins connect to which chips and which states to set them into in which order hard-coded into the kernel build for them to work.

You're advocating for the motherboard equivalent of what a mess hard drive support used to be before we got Integrated Drive Electronics and Logical Block Addressing.

Abstraction is good, mmm-kay.

...or, alternatively, if you're arguing for something with less glitzy mouse-driven config UI:

1. That won't solve the problem because that's not where the problematic binary blobs that Coreboot has and GNU Boot rejects are.
2. The because Bob needs a bonus factor will never let motherboard manufacturers do that.

[intelfx]

You didn't understand. The Linux kernel will receive all the necessary information from UEFI to boot. but the Linux kernel will load on its own. The linux kernel will need UEFI only to provide the boot information. then we won't be afraid of who and when and how UEFI is written and what it contains.

Big surprise, that’s exactly how it works right now.

But if you had any kind of clue, you’d have already known that.

[Espionage724]

You didn't understand. The Linux kernel will receive all the necessary information from UEFI to boot. but the Linux kernel will load on its own. The linux kernel will need UEFI only to provide the boot information. then we won't be afraid of who and when and how UEFI is written and what it contains.

Tianocore?

[royce]

Where my LILO vets at?

[pgeorgi]

can't people teach the kernel to boot on its own without loaders? such an approach would solve many problems.

That was the original plan in 1999, which is why coreboot was called LinuxBIOS. It was, in fact, a Linux kernel extended with just enough init code to bring up the mainboard it was running on. Various factors (including ever more complex hardware bringup routines) eventually made LinuxBIOS diverge from that model, and so it was renamed to coreboot around 2008.

There's the LinuxBoot project these days that wants to bring the old concept back in some way: still using a butchered UEFI or even coreboot for early init, but then jumping into Linux (from flash) as soon as possible.