If I understand, the issue is that unlike x86, ARM did not standardised the board support package. And thus mainlining of device support in linux is hampered by the fragmented hardware device drivers.
Has there been an active effort to avoid this curse on the RISCV ecosystem? At least for chips powerful enough to run linux.
Hi. We’re definitely planning to maintain our current positive relationship with the upstream Linux maintainers (and with upstream open source projects in general). We’d also like to make sure that Linux supports as many RISC-V devices, emulators, and architectural features as makes sense. There’s no doubt that figuring out how to cleanly support the vast range of variation and capability in modern non-x86 hardware has been a challenge, historically, in the upstream Linux community. The good news is that many of the folks working on Linux RISC-V code have been through the ARM and ARM64 upstreaming process. We’re following those same guidelines and rules as we work on RISC-V Linux code. We’re also working on ways to take some of those lessons and work with hardware designers to minimize the load on the Linux upstreaming process.
These are still early days for RISC-V software support, but I think the outlook is very optimistic. And we hope you’ll get involved and contribute! Much of the initial Linux work was done on freely-available emulators, so there’s a very low barrier to joining in and helping us develop outstanding support - not only in Linux, but across the vast world of open-source software that folks would like to run on RISC-V and other open-hardware devices. Here’s hoping you’ll join in!
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 Reddit - Dive into anything
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?
There is a precedent for creating a kind of ID without hardware reliance in the Merkle Tree. It is the complex father of blockchain and other crypto chain designs. Crypto chain can track any version up hashed and codified into the repository seed and keep for open examination for all time.
Linux fragmented because there was no way to keep track of the fragments. It became and still is for legacy systems, expensive chaos. Chain technology is essentially audit signatures (FDA 21CFR11) attached by Merkle tree methods thus assuring each sequential step is tracked with embedded metadata for maintaining track step identity.
It’s always the simplest ideas that give industries a step up. Remember the paper clip.
While that may seem like a mundane simplicity, the Merkle Tree structure is the backbone of all manner of automation. That backbone is embodied in the folder architecture by which humans keep artifacts. Each node/branch can be a metric for valuation if audit technology is done right. Fragmentation is the enemy. Cooperative standard(s) approach is the friend.
So how will this work in practice @cap_popper?
Say i slot in an sd card with the standardised riscv linux… does it call a CPUID like instruction that returns an ID number for the board? If so then, that is not enough as you would still need to know what drivers to load and it’s configurations. If you say that the driver tree is stored in the os image, then that can get bloated very quickly as you need to start adding more and more device trees for each board id type over time.
However it does seem more plausible if the returned structure is not a simple single ID, but rather a device structure tree. If that’s what you mean in your description, then that will make sense. However I would like to ask, why not just reuse https://www.devicetree.org/ standard instead? What’s special about your Merkle Tree proposal?
Anyway to summarise again what I am thinking of. I am thinking that the ideal method is to encourage board manufacturer to standardised the loading in of device tree structure and enumeration method into the board itself. Rather than loading the device tree into the firmware image. Keeping the device tree into the board, would then allow the ideal of a single linux image which would then be able to work out what device drivers to use (or copy across).
I think the equivalent to this in the x86 world is ACPI if I recall correctly.
I would call CPUID a dashboard for chip performance. ACPI is a standard to again watch chip performance for energy management so a dashboard for the OS. A metadata bank is more important to fragmentation then a performance interface.
Devicetree is a great place to start as it makes device component structure available to the system. But in all of this we’re just talking chip construct and not chip behavior. It is the behavior that is the problem - that which will arise most seriously because of architectural fragmentation.
If devicetree were integrated with snapshots of internal processor state-space emitted out in a blockchain fashion harnessed to the devicetree blob, systems would have a picture of behavioral/construct personality that is needed to differentiate one chip from another to track riscv fragentation.