Hacker News
points by za_creature 1 day ago | 0 comments
Unfortunately, there's plenty of vendors that suck at writing firmware, and most usually give up on updating it immediately after they've EOL'd the hardware revision. The hackintosh project mostly works by replacing the bugs from the vendor firmware into the bugs that apple expected from their x86 line of pcs.

If most vendors suck at writing firmware, it might be a problem with the spec though.

[–] jeroenhd 1 day ago
BIOS didn't have a spec at all, it was hacks stapled to reverse-engineered chips that were Good Enough To Ship for IBM decades ago.

Most of the alternatives require brand+model specific kernels and boot mechanisms, at least UEFI has a standard. I dream of the day smartphones run UEFI instead of the weird factory bootloader + custom uBoot mess that we're in right now.

[–] za_creature 1 day ago
Look, it's a step in the right direction for sure. It's just too big of a leap for my taste.

To boot an OS you need to initialize core 0, RAM and some storage controller. Throw in a serial port for debugging. Everything else should probably be left to whatever is running at the initialization vector of the storage. Which, if you'd like, can be a complete UEFI implementation.

Having a display, mouse, keyboard or network is an opinion. GUID partitions are an opinion. And if it comes to opinions, I'd rather all of the extras be handled by third parties instead of within a giant spec that will be vibe-conformed to.

[–] jeroenhd 1 day ago
Initializing core 0 on a modern system requires a Pentium CPU preconfiguring Minix to bootstrap the CPU. Training RAM is a whole new challenge. The simplistic designs of the 20th century don't apply anymore. Having USB to control boot is a necessity now and with Thunderbolt offering DMA access, configuring trust at a low level has also become a requirement.

There are plenty of things I don't like about UEFI. Going for pseudo-Windows APIs, for instance, or using FAT as a filesystem while better open-source filesystems are available.

I do applaud the efforts of people like the Coreboot team, trying to take control back for their devices, but the cut-down minimal boot manager they provide has yet to convince me to even try switching, to be honest.

[–] za_creature 1 day ago
Yeah, and booting the raspberry pi is done via the GPU. What was that you were saying about shitty vendors?

USB is a value-added feature (with a spec that rivals UEFI in complexity), and despite having owned 5 apple machines, I'm not sure I have ever used thunderbolt... EVER

With regards to trust, the only reasonable approach is "can be overridden by the legitimate owner" with a "delete everything on request by whomever has physical access to the device" fallback. Yeah, theft will be a problem but 1984 would be a bigger problem.

[–] yjftsjthsd-h 1 day ago
> Everything else should probably be left to whatever is running at the initialization vector of the storage. Which, if you'd like, can be a complete UEFI implementation.

Putting it all in a single location on the storage device means that 1. Multibooting will always suck because Windows will unconditionally overwrite whatever is there with its own bootloader that only boots Windows, and 2. you now have to have local storage, which would be somewhat annoying to those of us trying to do diskless network boot (or anything else more interesting than "always boot internal disk0").

[–] za_creature 1 day ago
You always have local storage, even if it's a 128Mbit flash chip that stores the firmware. There's no network boot implemented in hardware.
[–] yjftsjthsd-h 1 day ago
I mean, basically just sounds like the status quo but with a smaller initial firmware chaining to a user-flashable second stage. Which I'd certainly support, but that... just sounds like coreboot? (Which is an initial firmware that usually gets combined with tianocore to provide UEFI or seabios or ...)
[–] za_creature 21 hours ago
Sadly, coreboot is not a standard, though I guess it could very well become one since I doubt there are many uefi implementations that diverge significantly from tianocore.

Even then, I'd rather have a modular mix-and-match approach (e.g. vendors only provide drivers, completely independent from the stage 2 payload) rather than the current fork, tweak, add kitchen sink, compile & forget status quo.

[–] cowlevel 1 day ago
That's how it works on ARM, but other people in this same comments section are complaining about having to build u-boot and Linux differently for every device model because there's no commonality.

Also why initialize RAM? Isn't cache-as-RAM enough for a stage zero bootloader?

[–] za_creature 1 day ago
Eh, I was thinking more along the lines of populating the memory regions mapped to hardware.

Having to build u-boot for every device model is a good thing, it means that there's less functionality abstracted-away by some never-to-be-updated vendor-provided firmware.

[–] cowlevel 1 day ago
It's good from the hardware designer's perspective since less things are their problem. It's bad for the software creator since more things are their problem, and for the user since it's hard to find compatible software for their hardware.

It's also the normal way the entire history of computers has always worked, except for the IBM PC and its derivatives. If you want to install an OS on a 2025 OnePlus Blahdy Blahdy Blah you need to find an OS explicitly built for a 2025 OnePlus Blahdy Blahdy Blah - one for a 2025 OnePlus Blahdy Blahdy or for a 2026 Blahdy Blahdy Blah will not work and will likely just brick your phone. And nobody is out there building every OS for every phone model. But I can install Linux built for a Lenovo laptop onto a Dell desktop or a SuperMicro server.

[–] za_creature 1 day ago
We are in agreement that phones (and embedded devices in general) are worse. My claim is that they are worse because UEFI is too fucking complicated to implement, so nobody bothered. Which resulted in linux being built with the hardware descriptor table for the device in question, itself implemented by the vendor and published (and eventually merged upstream) due to gpl restrictions. It's also not uncommon for the 2026 edition to use a completely different SoC than the 2025 version (as in different vendor and even CPU arch) - routers even do this for the same model with a different hardware revision.

As to your other point, software is always easier to change than hardware, even if easy means hooking up a ch341a chip. Hardware however always transitions from sand to electron prison to rock to sand.

[–] cowlevel 1 day ago
If you used a standard UEFI interface you'd either imprison the OS within the UEFI using UEFI interfaces to hardware, or you'd imprison it within an inaccurate hardware description (either DT or ACPI) that it would be forced to adhere to. The current situation is complete OS freedom (except for TrustZone and secure boot) but it turns out that isn't actually what we wanted.