Doesn’t surprise me: The ARM (SoC) ecosystem is a fucking mess!
Until ARM hardware is as generic as regular PCs, it will always have issues like this.
Note that I didn’t say, “ARM Linux”. This is because it’s a fucking mess for all operating systems!
“Will my program run on this ARM chip? It runs on other ARM chips.”
“Probably? Maybe? Who TF knows‽”
This is at least in some part due to the difference between ARM and x86. The R in ARM stands for RISC which itself stands for Reduced Instruction Set Computing, this is diametrically opposed to how x86 works with things like MMX that you may have heard of over the years being instruction sets. As a result I am not sure that we will ever see the kind of hardware abstraction in ARM that we have seen in x86.
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:
- 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.
In Linux land, “not supported on” and “doesn’t work on” are two very different things.
Ran into this the other day, when an update broke a game I was playing. Checked the game forum and the developer said that the workaround was to move a DLL up one level in the directory. When people asked if that solution would work for every distro, the developer would only say that it’s supported on steam deck, since that’s what they are testing on. Of course, that solution works on all distros, as far as I can tell, but the developer isn’t going to test and verify that.
You can’t say all distros because there’s always some asshole using some obscure version that makes it impossible to move a file or the correct location is different. Then everything devolves into how dare you not know this thing attacks.
Temple os gang 🤘
Ran into this the other day, when an update broke a game I was playing. Checked the game forum and the developer said that the workaround was to move a DLL up one level in the directory.
Hello, fellow Elder Scrolls Online player.
That’s not exclusive to Linux. That’s what it means everywhere.
I’m my experience, “Not supported on Mac” or “Not supported on Windows” very much means that it won’t work.
In my past live I used to be a video editor for a tv network and remember one of the technicians walking by with the Avid guy (video editing software) and telling him that he was able to install and work with Avid {version number} in Windows {version number} and the Avid guy was like not supported doesn’t mean isn’t going to work, it’s mean that if broke in the middle of a project and you lost everything done we’re going to close your ticket without giving you any support
“I didn’t test that scenario”
I mean yes. This means that they won’t support it, at the very least for now. Big surprise.
deleted by creator
“bricked”… “Had to reflash”… That’s not what bricked means
(For future readers: bricked means completely and irrevocably ceasing to function, unrecoverable, as useful as a brick)
It’s not what jump the shark means either
