hehe, this is exactly how x86 machines start - CPU executes the memory mapped code in the SPI flash. and, as you can see, it doesn't give you any "trust" you want. you don't trust it, am I correct?
and nothing more elegant in that method. it's just a more cut off variant not giving flexibility in choosing the boot way at this level. for PCs, it's ok, because they conventionally all have such SPI chips for firmware and all boot OSes from the same source - beefy HDDs/SSDs. for mobile, SPI NOR (NAND. eMMC etc) may be not present all, there is no single conventional source of booting, even for firmware, it may be any of those mentioned, it's decided later on the board design level, so SoC vendors need to devise a little bit smarter way of choosing where to go next - this is what ROM code is for and what it does. it chooses, based on board configuration what to boot from - SPI, NAND, SD, eMMC and proceeds. it's a minimalistic, yet pretty capable piece of code and it's always there, always guaranteed to work - much better, much flexible. you want SPI for FW - get it, another one wants to boot from boot areas of eMMC - okay! your "elegant method" is not able to satisfy this as easy (it's more restricted - requires SPI that narrows choices for board makers - pins are shared), but moreover, - it is not suitable for end users, since it lets them break things easy, but for fixing it, they would need to learn what the fsck "pinmux" is and get some soldering skills.
again, it's not a "tinkerer workshop" or classes for learning, SoC vendors sell products, the products cannot be breakable easily. all SoCs I am aware of have this model and it's a good model.
Pine doesn't have any influence on the boot flow of the firmware.
other ARM SoCs aren't "more open source friendly." as you call them. lol, Apple is so "friendly", that one barely can know about their phone SoC anything but ad blurb. often you won't get even a TRM for the SoC, say mediatek or marvel, qualcomm. nothing available. we must be thankful, that these fabless vendors from china making their SoCs mostly for android OTT boxes (and not for SBC tinkerers overly bothered with "trust"), provide some documentation at all.
in the end, on the example of the discussed ROM code, we see, that its openness is not needed - 1) there are no secrets over there, it's basic boot initializing and choice decision for the boot source and 2) it's made permanent inside an SoC for reliability, but the permanence makes opensourcing it pointless. however, there are fileds where there are secrets*. just look at this hidden GPU land - total lack of information, vendors are afraid of losing their technological achievements, this is what matters, not the imaginary "trust". why do you want this trust in computers and not in, for example gasoline? why don't you demand that all the technological process of gasoline production had been disclosed? or food. beer. why not demand all breweries over the world open recipes of their products? come on, it's not serious.
* - actually, ROM code as well may need to be kept secret, it starts in Secure mode after all! there might be things related to providing security - ironically, ROM code then would be what is called The Root Of Trust - and obviously, it should not be modifiable or even readable outside of Secure world, definitely it's not the same "trust" you want. and here, I suspect, you, freedom guys, and hw vendors, have different understanding of who should own this root. the former apparently would say - if we bought a device, everything related to it, should be at our discretion (which is not true). the latter would say, it's security, we care about you (you are important to us ), security isn't being done this way, if we let everybody modify it, no security will be available and you will become a target of attackers. their power is ability to make it, yours is ability to not buy, what is stronger?
and nothing more elegant in that method. it's just a more cut off variant not giving flexibility in choosing the boot way at this level. for PCs, it's ok, because they conventionally all have such SPI chips for firmware and all boot OSes from the same source - beefy HDDs/SSDs. for mobile, SPI NOR (NAND. eMMC etc) may be not present all, there is no single conventional source of booting, even for firmware, it may be any of those mentioned, it's decided later on the board design level, so SoC vendors need to devise a little bit smarter way of choosing where to go next - this is what ROM code is for and what it does. it chooses, based on board configuration what to boot from - SPI, NAND, SD, eMMC and proceeds. it's a minimalistic, yet pretty capable piece of code and it's always there, always guaranteed to work - much better, much flexible. you want SPI for FW - get it, another one wants to boot from boot areas of eMMC - okay! your "elegant method" is not able to satisfy this as easy (it's more restricted - requires SPI that narrows choices for board makers - pins are shared), but moreover, - it is not suitable for end users, since it lets them break things easy, but for fixing it, they would need to learn what the fsck "pinmux" is and get some soldering skills.
again, it's not a "tinkerer workshop" or classes for learning, SoC vendors sell products, the products cannot be breakable easily. all SoCs I am aware of have this model and it's a good model.Pine doesn't have any influence on the boot flow of the firmware.
other ARM SoCs aren't "more open source friendly." as you call them. lol, Apple is so "friendly", that one barely can know about their phone SoC anything but ad blurb. often you won't get even a TRM for the SoC, say mediatek or marvel, qualcomm. nothing available. we must be thankful, that these fabless vendors from china making their SoCs mostly for android OTT boxes (and not for SBC tinkerers overly bothered with "trust"), provide some documentation at all.
in the end, on the example of the discussed ROM code, we see, that its openness is not needed - 1) there are no secrets over there, it's basic boot initializing and choice decision for the boot source and 2) it's made permanent inside an SoC for reliability, but the permanence makes opensourcing it pointless. however, there are fileds where there are secrets*. just look at this hidden GPU land - total lack of information, vendors are afraid of losing their technological achievements, this is what matters, not the imaginary "trust". why do you want this trust in computers and not in, for example gasoline? why don't you demand that all the technological process of gasoline production had been disclosed? or food. beer. why not demand all breweries over the world open recipes of their products? come on, it's not serious.
* - actually, ROM code as well may need to be kept secret, it starts in Secure mode after all! there might be things related to providing security - ironically, ROM code then would be what is called The Root Of Trust
- and obviously, it should not be modifiable or even readable outside of Secure world, definitely it's not the same "trust" you want. and here, I suspect, you, freedom guys, and hw vendors, have different understanding of who should own this root. the former apparently would say - if we bought a device, everything related to it, should be at our discretion (which is not true). the latter would say, it's security, we care about you (you are important to us ), security isn't being done this way, if we let everybody modify it, no security will be available and you will become a target of attackers. their power is ability to make it, yours is ability to not buy, what is stronger?
ANT - my hobby OS for x86 and ARM.