[zozbot234]

> ... Also your boot-chain is still closed and proprietary, and completely different than the one used by all other ARM vendors. Being the special snowflake is not helping your business or your customers. ...

Why does the boot-chain matter? Can't we just have a custom U-Boot implementation that interacts with the bespoke boot chain while providing standard UEFI support to the rest of the system? Isn't that how Asahi works?

[nrclark]

It matters when you're doing custom hardware, or when you're designing a product where boot speed matters, or when you need to implement something special.

A full-featured U-Boot implementation would be fine IMO. But for the generations that I've used, that's not on the table. What we get is a proprietary flow through a proprietary hypervisor into a fork of Android's bootloader (even if vanilla Linux is the target OS). There's no way to control startup boot options, and no way to use KVM, Xen or any hypervisor except the proprietary one that's also part of the boot chain.

This doesn't lend itself to flexible products, or to products that are easy for a company to design or support. That is why things like this happen: https://news.ycombinator.com/item?id=46008156

[eqvinox]

Aside from the sibling comments, it also matters that you need to be able to review it if you need to build a truly "secure" product. History is littered with broken, unfixable secure boot implementations.

[ryukoposting]

Because a computer isn't just a processor. It has to interact with an EC, IO controllers, and whatnot, and if you don't have control over the boot chain, all of that stuff becomes an even bigger PITA than it already is.