> It's because each phone SoC is essentially its own bespoke architecture.
Right, but that's a choice from manufacturers, not a requirement of building a mobile platform.
> It will always be cheaper for phone manufacturers to develop bespoke SoCs than it is for them to implement protocols and interfaces that make booting and hardware discovery standardized like they are on the PC.
This... seems suspect? I'm not doubting you, but I do wonder if it's a question of robbing Peter to pay Paul; perhaps it is cheaper to design a bespoke chip than it is to develop a standard for it, but over the course of many generations the benefits of standardizing would kick in?
I do know that RISC-V can support UEFI, so perhaps that's where we need to look to see how developments work out in the long run.
> Right, but that's a choice from manufacturers, not a requirement of building a mobile platform.
Yup, it's a cost thing.
Standardizing busses, protocols, discovery etc is costly, it adds a cost to every SoC, just wiring up components on PCBs is quick, cheap and takes up less space. All three are important in mobile.
The reason you'd implement the standards is for interoperability, which is not what mobile devices are going for. You're getting the OS the manufacturer chooses and that's it, the hardware doesn't have to support anything else.
Standards are also a commitment, and that commitment can be a cost in the future. It's not free for PCs to support all of the legacy hardware they do, for example. A lot of work goes into that.
The reason I bring up ARM servers and PCs is because both have a long legacy of standardization, and to be a real player in either space, you need to meet those expected standards, which ARM ISAs have. Mobile has no such legacy. If PCs had no such legacy, I think we'd see the same issues mobile does today (which we kind of already do on tablets, Chromebooks, etc).