Thanks, I am certainly keeping a close eye as I build up my skills in hardware design.
Anyway to help make this thread easier to expand upon, I did a quick research on why x86 is easier to code for compared to ARM. And this redditor tso seems to have a good answer https://www.reddit.com/r/linux/comments/56eo2o/why_linux_pioneer_linus_torvalds_prefers_x86/d8ixjdt/
Anyways, the reason, as i have come to understand it, for x86 being “lovely” to work with from a kernel point of view is PCI. Specifically that the kernel, once the handover from the BIOS is complete, can go out and look up every device on the bus with a vendor specific id code.
ARM to a large extent do not have this. The various parts of a SoC just dangle off some opaque data bus, and if you guess wrong you may well trigger some kind of non-recoverable mode via whatever signal you send.
Key points to consider on why PCI is not used in ARM ecosystem based on his observations, is that board developers do not need the more complex dynamic enumeration feature of PCI. And thus they often opt for device tree instead, which is easier to use.
Except, vendors often compile the device tree right into the firmware blob. Thus killing off the idea of a single bootable linux.
So it sounds like on the upstreaming of drivers is being sorted by sifive, but…
What is the current direction however of the ideal of a single bootable linux rom, that does not have to be recompiled for every board?
Could there be perhaps something like a CPUID but for device trees stored in a locked rom? e.g. BRDNFO that returns a memory pointer to a device tree list perhaps?