Hacker News Reader

> Modern PC EUFI bootloaders are bigger and more bloated than any uboot build in existence, and things like device tree support in linux means that you can support various boards with the same kernel (including boards that don't exist yet). Sure you'll probably still need custom bootloaders for most boards, but it's not like you can swap your motherboard BIOS/UEFI chips and expect them to work either.

This feels like, at best, getting back to where PCs already were, at least as a user. If a device tree can be embedded in firmware and fed to the booting system, then that's fine, it's just a minor implementation detail. If you need to go get a file and put it on your boot media, then that's extra friction. Likewise, I don't really care what the hardware's boot firmware looks like, but if I need a different bootloader per-device then that's a problem - can you imagine if Dell laptops and HP laptops needed different GRUB builds to work?

I feel like we're kind of mixing up a bunch of things here, or maybe I am.

The reason you don't need to mess with GRUB or you BIOS when you change your hardware is that modern hardware interfaces have built-in discovery and resource allocation features. Before that you had to deal with pesky low level details like IRQ allocations and the like (which was a thing on PC not that long ago).

That's not really a feature of "PC" per se, it's a feature of USB, PCI etc... That stuff works exactly the same on ARM or anywhere else.

The things that need to be described in the device tree are generally internal components of the SoC and motherboard, things like IO expanders, SPI interfaces, serial interfaces, and of course the USB/PCI/... controllers themselves.

I think there maybe some confusion because of the term "bootloader". It's true that both u-boot and GRUB are bootloaders, but bootloaders in the ARM world have a lot more to do than PC bootloaders, they're effectively the equivalent of UEFI + GRUB, not just GRUB. You can write a simplistic boot sector loader for PC in a few hundred ASM opcodes, that would be a lot more difficult for the average ARM bootloader because there's a lot more to do before you can just call into Linux. In general you won't even have RAM or caches available when u-boot begins executing.

And I think it's actually a better design, because it means that proprietary built-in firmware crap is usually kept to a minimum on ARM: the BOOTROM usually just initializes the bare minimum to be able to load u-boot (or some other loader) into on-chip SRAM and then it's over. Of course that means that the loader is significantly more complex, but that complexity has to be some place or an other.

The practical upshot is: On PC, I can take a single disk with a single GRUB version and boot it on an arbitrary machine. If ARM machines can do that with their own UEFI/ACPI/ServerReady setup, then great. But if I need to alter that disk for each machine I want to use it on (inject board.dtb, add a custom u-boot, whatever), then that's not okay. I would happily accept u-boot and whatever else being on an onboard flash chip that I could update but didn't need to care about otherwise - that would get us back to "your PC boots via a UEFI system that's a whole OS unto itself, but it chainloads GRUB via standard interface so who cares".

We completely agree here. If ARM desktop becomes mainstream there will probably be some kind of abstraction layer needed at this level that doesn't really exist at this moment. I'm fairly optimistic that it will happen when it's really needed though.

Ah, okay, yeah. And honestly, the tech may already exist - I'm a little unclear on whether it's sufficient or not, but ARM UEFI is a thing - but I definitely look forward to seeing things standardize and have boards that actually work like that without extra hacks.

> You can write a simplistic boot sector loader for PC in a few hundred ASM opcodes, that would be a lot more difficult for the average ARM bootloader because there's a lot more to do before you can just call into Linux. In general you won't even have RAM or caches available when u-boot begins executing.

This is exactly the point OP's getting at though, and the exact "discovery" features you handwave away. If I write an OS (or bootloader) on x86 w/ BIOS/uEFI, I can easily query available memory and start using it. Meanwhile u-boot has to be told via an external resource how much RAM is available before it begins initializing. This is fine for embedded/bespoke development (since you'll know the hardware you're developing for and can make assumptions), but a pain for general OS development where you have to inform the bootloader/OS of every devices capabilities.

In the 1980s, the IBM PC standardized the entire industry around ISA ("Industry Standard Architecture") which was pushed forward by the manufacturers of IBM-compatible hardware ("clones").

The consortium of like-minded manufacturers later went to help develop develop all the subsequent variants that persist to this day (PCI and ATX form-factor etc). The standardization benefited them greatly.

Now that ARM Holdings is owned by NVidia I hope Jensen Huang sees that if ARM is to take over the desktop it makes sense to bring that same level of standardization that allowed the PC industry (and NVidia) to dominate.

I think ARM Holdings needs to be the one to spearhead the initiative. It will help industry-wide adoption of ARM (for desktops, laptops and servers) which will benefit them greatly.

> if desktop ARM becomes mainstream things could settle fairly quickly. It's less of a technical problem and more of a "why bother?" problem.

This is exactly right, but I fear the incentives have changed and we'll never again see something like the x86/IBM-compatible/Wintel world of "standard" inter-compatible systems.

As you say, it's a "why bother?" problem, and no manufacturer will want to bother: Apple has no interest in making it easy to run other OSes, Microsoft wants to sell you "Windows Surface" devices, not general-purpose computers, corporate buyers want a "secure" locked-down environment with a signed bootloader...

Are there any powerful stakeholders who benefit from interoperability?

>Apple has no interest in making it easy to run other OSes

I'm not convinced that this is necessarily true. They advertised running Linux VMs during their presentation, they made a tool specifically for installing Windows on Macs and they even recently stated how Windows on ARM Macs is really up to Microsoft. If you could run Windows on an M1 Mac, it'd really turn it into a powerful and power-efficient "do-it-all" machine, since you could still boot into Windows and run that niche Windows software that you need from time to time.

Of course but obviously they don't and probably will never allow you to replace MacOS, rather just to run something else on top of it in one form or another.

Notably the PC standard meant things were interchangeable, not "interlayerable". You picked a CPU, you picked an OS, you did not have to emulate or virtualize whatever you wanted on top of what was imposed on you. Imagine that 30 years ago someone pitched a PC that only runs a specific OS and the only way to run anything else is on top of that like an app. You'd think "ridiculous".

Today having a device that runs as sealed monolith both HW and SW wise, and all you can do is run stuff on top of that without the ability to replace anything is considered a good sign. Tells you where we're going.

Untrue, Apple does permit you to replace your kernel on Apple Silicon macs. Hector Martin has a Patreon where you can sponsor and follow his work towards making Linux usable on these systems: https://www.patreon.com/marcan

That's great, let's wait and see when this actually happens and if it turns into a compelling alternative. I think Apple hit it out of the park with their ARM line so I'd love to use the hardware with an OS of my choosing, like I would historically on a standard PC.

Yeah - I'm backing the patreon and very excited for this work. I don't need it often, but when I do, being able to boot natively into Linux is tremendously useful.

Bootcamp is not virtualization, so your point is moot.

Friend, the comment I replied to referenced Linux in VMs, and my point is clear and was made in good faith: Today I cannot reasonably run any Apple device without the Apple base software.

Your answer is dismissive and misses the point because you nitpicked on one particular word I used that doesn't fulfill one particular and currently irrelevant scenario: Windows in Bootcamp. What about every other scenario?

Bootcamp doesn't run on ARM Macs so your point is moot.

That's not really because Apple hates allowing you to install Windows, but rather because you can't actually acquire a Windows for ARM license. Once again, Apple has stated that Bootcamp for Apple Silicon is "up to Microsoft". And ARM Macs are still just a minority of the computers that Apple sells. The rest have Bootcamp, which allows you to just turn your Mac into a Windows machine.

Saying that "Apple will never allow you to replace macOS" is just plain wrong when they've been allowing you to do that for the past 14 years.

You might as well argue how Bootcamp doesn't run on iPads.

> but rather because you can't actually acquire a Windows for ARM license

You'd still have to develop all the device drivers required for this custom SoC. After all, Linux doesn't need a license but without extensive documentation and support from Apple it's like saying you're free to challenge your boss openly, it's pedantically true, but it is impossibly impractical for most.

Unless Apple provides extensible documentation for 3rd party drivers to be developed for their SoCs it's just cheap talk from their side.

> You might as well argue how Bootcamp doesn't run on iPads.

This isn't much of a "gotcha" - I do think it's outrageous that Apple gets away with selling these gimped iOS devices that only run Apple-approved software.

Would consumers stand for this with any other devices? A stapler where you had to buy staples from the manufacturer? A car that only drives on manufacturer-approved roads? A dishwasher that will only wash approved plates?

Microsoft selling Windows to DELL, HP, ... they will not start writing their own operating system. And at that point the same effect will start like it did with Microsoft/Intel/computer manufacturer.

If Microsoft however succeed with their Surfaces like Apples does .. than maybe we are screwed. Luckily, they do not.

They do actually. Outside Apple heavens like US, Windows tablets and 2-1 laptops are the to go option, as Google keeps failing to move the Android ecosystem beyond phone apps on bigger screen.

I think OP was referring to Microsoft's hardware brand Surface, not OEM Windows installs.

Yes ;)

> Are there any powerful stakeholders who benefit from interoperability?

All those companies selling motherboards for gamers etc?

So firms that sell speciality hardware direct to consumers? Are they big players?

I'd definitely consider companies like ASUS, MSI, etc. to be big players.