RISC has nothing to do with it. It’s because there’s no universal hardware discovery (e.g. ACPI or PCIe) for ARM. That feature is what enables Linux on x86 to enumerate what’s connected (peripherals) and do things like dynamically load the necessary drivers as-needed (in addition to knowing which IRQs do what and where the registers live).
Because ARM chips lack that (and necessary documentation!) each Linux kernel put out by a SoC vendor includes binary blobs that take care of all those things (and hardware device tree files, but more on that below). They call these “hardware support packages” and they’re almost always tied to a specific kernel version that never gets updates once the hardware is released.
Also, the vendors like Qualcomm, Mediatek, etc license ARM but then include their own proprietary stuff like video decoders, HDMI interfaces, etc that need proprietary drivers in order to work. If they just open sourced these drivers (aka “doing the right thing”) that would make huge inroads towards better Linux adoption of their chips but apparently, management at these companies thinks their very, very specific code to drive their chips is some how a “trade secret” that their competitors could somehow take advantage of if they had access (which is bullshit).
That would give Linux the necessary ACPI equivalent and standardize their device trees (DT).
These vendors also need to work with the Linux maintainers while their chips are still in development (like AMD and Intel already do). That way, all the necessary drivers and kernel configuration steps will be “mainlined” which means everything you need to run their hardware will be built-in to the Linux kernel. You’d then be able to download the source from kernel.org, configure it for your ARM hardware, then build it—all ready to go on launch day!
Other nice things they should do:
Fund FOSS development for their shit. For every SoC there’s some poor developer out there that’s writing a driver or fixing bugs. SEND THEM SOME FUCKING MONEY YOU GREEDY BASTARDS.
Decouple the firmware from the OS media. On a lot of cheap SoCs, you need a specifically-formatted/configured microSD (or whatever) which means you can’t just replace the OS without potentially fucking up the boot process. They need to adopt standard SPI flash or dedicated eMMC boot partitions so they can decouple the OS/firmware from the boot process.
The fact that it’s drivers for everything instead of instruction sets for at least some things is the problem I was eluding to. I just didn’t want to go into as much detail.
Obviously it would be better if companies would treat ARM like x86 but they have a capitalistic incentive to not do so. Part of the point of switching to ARM is to prevent you from being able to do the things on future devices that you could do in the past.
RISC has nothing to do with it. It’s because there’s no universal hardware discovery (e.g. ACPI or PCIe) for ARM. That feature is what enables Linux on x86 to enumerate what’s connected (peripherals) and do things like dynamically load the necessary drivers as-needed (in addition to knowing which IRQs do what and where the registers live).
Because ARM chips lack that (and necessary documentation!) each Linux kernel put out by a SoC vendor includes binary blobs that take care of all those things (and hardware device tree files, but more on that below). They call these “hardware support packages” and they’re almost always tied to a specific kernel version that never gets updates once the hardware is released.
Also, the vendors like Qualcomm, Mediatek, etc license ARM but then include their own proprietary stuff like video decoders, HDMI interfaces, etc that need proprietary drivers in order to work. If they just open sourced these drivers (aka “doing the right thing”) that would make huge inroads towards better Linux adoption of their chips but apparently, management at these companies thinks their very, very specific code to drive their chips is some how a “trade secret” that their competitors could somehow take advantage of if they had access (which is bullshit).
The fix is for these chip vendors to get on board with the Arm SystemReady program: https://www.arm.com/architecture/system-architectures/systemready-compliance-program
That would give Linux the necessary ACPI equivalent and standardize their device trees (DT).
These vendors also need to work with the Linux maintainers while their chips are still in development (like AMD and Intel already do). That way, all the necessary drivers and kernel configuration steps will be “mainlined” which means everything you need to run their hardware will be built-in to the Linux kernel. You’d then be able to download the source from kernel.org, configure it for your ARM hardware, then build it—all ready to go on launch day!
Other nice things they should do:
The fact that it’s drivers for everything instead of instruction sets for at least some things is the problem I was eluding to. I just didn’t want to go into as much detail.
Obviously it would be better if companies would treat ARM like x86 but they have a capitalistic incentive to not do so. Part of the point of switching to ARM is to prevent you from being able to do the things on future devices that you could do in the past.