Hacker News
points by cowlevel 1 day ago | 0 comments
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.
[–] za_creature 21 hours ago
I fail to see how the relevant UEFI service wouldn't be affected by the same inaccuracy in the hardware description, if it exists.