Before the BSD Kernel Starts: Part One on AMD64 | Hacker News Reader

Before the BSD Kernel Starts: Part One on AMD64

moritz.systems

96 pointsfcambus16 comments

Obsolete. How does UEFI achieve the same thing, booting?

For those of us who still prefer to use legacy BIOS on current hardware when possible, the article is not obsolete.

I suspect the downvotes were because your comment comes across as unreasonably negative.

Why are you using legacy BIOS? It has been obsolete for a long time and is disappearing https://arstechnica.com/gadgets/2017/11/intel-to-kill-off-th...

I still haven't seen much compelling about UEFI. If the enduring standard of BIOS boot is no longer available, I guess that's compelling.

I can see that secure boot is compelling to the right audience, but it doesn't add much for me.

I guess the only other compelling thing is that UEFI works the same across multiple CPU architectures like x86, POWER and ARM64

I don't believe there are any POWER machines using UEFI. The standard POWER boot process uses OPAL (Open Power Abstraction Layer) instead. But POWER does use GPT disk partitioning, which is from the UEFI standard.

Someone has ported TianoCore to powerNV, but I've never looked into it. You could replace the hostboot payload with any binary, it's basically just an ELF file with a payload delivered, an initramfs in the case of skiboot/petitboot.

Not a lot of advantages in UEFI over petitboot, though.

Edit: here it is. https://github.com/andreiw/ppc64le-edk2 mocks the presence of ACPI tables using the equivalent OPAL calls.

Yeah, that's potentially compelling; if you've got UEFI enabled boards for those platforms. A quick search says maybe raspberry pi 4 supports uefi booting, which would be interesting.

All ARM64 servers use UEFI and any SystemReady compliant board too. Sadly no desktop computers yet.

This is like asking why do you prefer to start your engine with a key when we have buttons that scan your fingerprint and authenticate you with Apple?

If the BIOS is sufficient and simpler... why not?

You can't boot from NVMe with BIOS, not interested in running systems that don't boot off NVMe

I wonder why? I would expect that it is possible technically just that "the powers that be" made a policy decision not to allow it.

If it were possible would you use the BIOS?

There are a handful of drives that support booting via bios - Samsung 950 Pro is the most common.

> Why are you using legacy BIOS? It has been obsolete for a long time

It's simpler. That's sufficient reason for me.

Yeah I think Linux does all of this plus has a UEFI stub. I'd like to see a low-level breakdown of what goes into going from kernel -> bootable ISO (that works on BIOS and UEFI).

UEFI is much like MS-DOS. It is capable of loading programs from the FAT filesystem into memory and running them. The entry point, EFIMain() is passed a couple of pointers that point to system tables that can be queried to find the address of various services. These include things like reading or writing from the system console, get the system memory map, reading/writing files or even things like reading and writing from network adapters. It's really pretty elaborate. An EFI program runs in 64-bit long mode, with paging set up as an identity map (logical address X maps to physical address X).

An EFI program can exit and return control to the EFI shell. A kernel, however, makes an EFI call to terminate EFI services. After that, it can only call a tiny set of certain EFI functions, but the kernel is considered to have control of the machine. At that point, it will relocate itself from where EFI loaded it to where it wants to live, initialize new page tables, switch to those table, and proceed with its regular initialization.

The Linux EFI stub is a bunch bytes at the start of the kernel image that make it a legal EFI program.

Reply on news.ycombinator.com