If I want to install Ubuntu Desktop on my Laptop vs my Desktop, I can download the same image from Ubuntu's website, and this applies for nearly every Linux distro I've heard of.

I'm currently shopping for various Raspberry Pi alternatives, and I noticed that each of them requires their own OS. For example, Armbian has a download for every board they support. In the same vein, why wouldn't Raspbian work out of the box on an OrangePi? I can understand that you might need different images for armv6/armv7/armv8, but why does every SBC need their own image?

  • You might find this interesting: raspberrypi.stackexchange.com/questions/98740/…. May 8, 2021 at 22:45
  • I believe that with the later raspberry pi's (3 and 4) several major distributions do now support them. May 8, 2021 at 22:46
  • 1
    Largely because SBCs tend to be cheap crap with a product life-cycle and product lifespan of 6-12 months. They're churned out as quickly as possible with little, if any, care for standardisation (and some are actively designed to thwart standardisation, for vendor lock-in), and a bare minimum token adherence to the kernel's GPL (at best). This is a shame, and it's why we don't have nice things like dirt-cheap ARM servers with PCI-e and similarly essential commodity technology that isn't just USB. Sure, good ARM servers exist, but they're stupidly expensive. Brand-name expensive.
    – cas
    May 9, 2021 at 5:18
  • 2
    just to be clear, it's not just ARM. there are several great non-x86/non-amd64 CPUs out there. and none of them are available as anything but cheap, disposable junk or absurdly overpriced brand-name servers. There is no equivalent to the "white box clone" / DIY middle-ground.
    – cas
    May 9, 2021 at 5:21
  • 1
    Long story short.. (as an example only): Manufacturer A wires the memory controller to address 0x37331. Manufacturer B wires their products to address 0xDEADBEEF. So the kernel has to be built adjust for these differences. Things like the IBM PC and it's clones/laptops have long standing standard configurations that the kernel does not need to worry about.
    – C. M.
    May 10, 2021 at 20:58

2 Answers 2


The answer to this is quite nuanced. But the fundamental reason is that while (x86 / x86_64) PCs might seem very diverse, they really aren't. SBCs (often ARM based) are much more diverse and even ARM the CPUs can be massively different from one to another.

PC History

The reason for the lack of diversity in PCs is perhaps a little opinion based but I'll hazard a guess that it has something to do with Microsoft DOS and then Microsoft Windows. They historically had strict requirements. I believe in the early days this was possible because "IBM Compatible PCs" were prevalent. Microsoft wrote their software to fit just that and nothing else. Later Microsoft was so dominant that they could simply demand what they liked and hardware vendors would have to follow.

Likewise Intel had such a dominance that when in order to compete, other manufacturers (eg AMD) had to make sure their CPUs were compatible with Intel's. Although a funny point of history is that what we now call x86_64 was actually AMD's invention AKA AMD64.


Most SBCs are ARM based and they don't have this same history behind them. Actually ARM don't manufacturer CPUs at all, they just licence designs to manufacturers. This has allowed many different manufacturers to customise these designs and there has been insufficient commercial pressure to standardise them.

Practical problems with diversity in ARM SBCs

Instruction sets

PCs have a very stable core instruction set. Yes different Intel / AMD CPUs have some additional instruction sets for certain advanced features but largely, to run an OS, these aren't so important. They might affect which applications you can run.

But with ARM SBCs there have been much more significant differences in instruction sets. As an example, when the first Raspberry PI was created, they used an ARM CPU with a hardware-float built in. At the time other major Linux distributions such as Debian had not been compiled to support this. Technically they would work but they would be much slower without it.

Now it's important to understand that core CPU features and instruction sets are not just used by the Kernel but every software package you install. If you want hardware-float support and the OS distribution wasn't compiled for it then you must re-compile every single package on the system.

Kernel configuration

Some tricky problems arise because of other CPU features. This means that many ARM SBCs need the Linux kernel to be modified. Now it does seem a bit over-the-top to ship a whole new distribution for the sake of a kernel. But one thing is true:

why wouldn't Raspbian work out of the box on an OrangePi

If you could get past the startup issues (below) then you may still find that it's missing important kernel overlays. The result might just be missing features or it might be a kernel that just wont boot.


Startup is typically less of a reason to ship an entire new OS. But it does have to be handled with care.

On PCs a lot of the hardware initialisation is either standardised or handled by the BIOS. The BIOS stores software shipped by the manufacturer and runs before the OS. This is then responsible for finding and running the bootloader.

On ARM SBCs there's no BIOS. The equivalent software is shipped with the OS. Now technically there's nothing to stop open source operating systems sharing this firmware between each other (see licence for Raspberry Ri's bootcode.bin). But that does mean each OS must have a copy of this firmware for every different SBC... and there are many different SBCs.

I believe other SBCs get round this by simply shipping their own ISO of an existing operating system. Beagleboard does that.

  • 2
    The open-ness of PCs was mostly because IBM was still smarting after being spanked with anti-trust action in the US. For years afterward, they avoided doing anything that would attract the attention of the DOJ again. This provided opportunities for clone PC makers and Phoenix and other BIOS developers. and, yes, Microsoft too. Anti-trust has since been nerfed to the nearly-useless "can you prove beyond any doubt that our monopoly causes consumer prices to increase?" so monopolist corporations are nowhere near as scared of it as they used to be/should be.
    – cas
    May 9, 2021 at 5:33
  • Once again, it is not about having a BIOS or not. Once again, Microsoft Surfaces that are ARM + UEFI machines perfectly shows you that you can't even use the same image for Surface 1 (RT) and Surface 2 to update them to Windows 8.1, let even aside Windows 10 that is not available at all. You really are the one pushing an opinion here. Also, no one ever refute dthat ARM isn't making CPUs yet you still insist on that point while this brings nothing on the table about the whole ARM CPUs not being able to have a standardized first stage boot sequence. ARM should have forced SBSA with their IPs.
    – X.LINK
    May 9, 2021 at 9:43
  • You are also insisting on hard float while this issue has been solved one year after RPB 1 got released thanks to Debian 7 in 2013 as I said earlier. Since then, A LOT of ARM CPUs started to be sold and armel going down. Having two isos for armel and armhf is fine, but being forced to have one iso for almost every armhf CPU is not, this is the issue. As OP said, he do understand that point: I can understand that you might need different images for armv6/armv7/armv8, which you seems to keep ignoring.
    – X.LINK
    May 9, 2021 at 9:51
  • @X.LINK did you even read my answer before writing that? I've claimed nothing of the sort. I gave not one but 3 reasons. Of those reasons only one was mismatched core CPU features. Of that one issue only one example is hard float. There are others. Other issues are documented on the Wikipedia page you shared with me. Yet you keep claiming it's nothing but the boot loader. Please try to understand what people are saying before posting such nonsense. May 9, 2021 at 10:28
  • @X.LINK and your windows 10 example doesn't really prove anything. Apple have used ARM silicon in their tablets for years and yet managed to support system upgrades. What you are quoting there is that Microsoft can't be bothered to support their old hardware and nothing more. May 9, 2021 at 10:39

That, is an excellent question that unfortunately very few people know the answer, but which knowledge is nonetheless very important. There is however no possible concise answer, so please bare with me.

Edit: This article sums things up to a point: "ARM finally defines a platform as it sets its sights on the server room" - Ars Technica

The basics:

In order to boot an operating system, every computer starts with these mandatory steps (please pay attention to acronyms):

  • Hardware Initialization Sequence (loads very bare "Basic Drivers" for FSB to complete)
  • First Stage Bootloader (BIOS, UEFI, U-BOOT, "the program", "the bootloader", etc)
  • Second stage bootloader (GRUB, LILO, SYSLINUX, BOOTMGR, etc)

Do note that the BDrivers are mostly for initializing some motherboard components and buses.

Where everything differs:

  • On AMD64/EM64T (Intel)/x64 platforms, the Hardware Initialization sequence is a very standardized procedure. This mandates computer manufacturers (OEMs) to embbed the BDrivers inside a standardized FSB so the CPU can be started.

Which means very diverse x64 hardware, but same FSB and why one iso can fits them all. This is why you are still able to upgrade your Windows XP 2005 PC/laptop to the latest Windows 10 or Linux from 2021 (and beyond) when OEMs already dropped software support around 2009 already.

  • ARM platforms, on the contrary, absolutely does not mandates such standardization and does not forces OEMs to embbed the BDrivers inside the FSB nor even embbed an FSB. This means that you have to embbed the BDrivers and your own FSB into your own image.

Due to extremely diverse hardware but also diverse FSB, no single iso can possibly fits them all. This explains why you will see some weird nonsensical FSB sequence like on the Raspberry 3, where the GPU starts the CPU (!).

Edit: Please note that I am NOT talking about everything (kernel, all system libraries, end user software) to be recompiled for an image to work on an ARM platform.

The issue, fragmentation:

Such differences on ARM platforms means that getting your hands on the BDrivers only depends on the OEMs good will so you can download them.

Unfortunately, we have already seen for a decade how things works with ARMs' mainstream devices (e.g Android/apple devices): Only OEMs can upgrade your OS version since they're the only ones to have the BDrivers.

Without those BDrivers, no one can possibly make a custom ROM or image easily. Hence why custom ROMs on Android devices takes so long and are so hard to make because of mandatory reverse-engineering, and that virtually no one knows how to make custom iOS or Android image for apple devices.

UEFI, U-Boot, etc won't even save you on ARM:

It's very easy to assume that all you need is to have some standardized FSB on ARM platforms so everything would work like on x64 ones:

  • Which has been proved to be 100% wrong... by Microsoft's very own hands with their Surface (RT, 2012) and Surface 2 (2013), where such devices do have some UEFI on them. Also note that those tablets do have their own separate image like any ARM device do, and are officially stuck on Windows 8.1 without any official upgrades to Windows 10 since Microsoft dropped support years ago.

Even 8 years later, it is virtually impossible to have a custom/community developped Windows 10 image for these Surfaces for the same reasons as any ARM devices: This is due to Microsoft not wanting to release the aforementionned BDrivers.

To date (2021), every other Microsoft Surface products has been then released on x64 platforms for almost a decade, that's 22 x64 devices for 4 ARM ones, this extremely says a lot...

A recent release exception is the Surface Pro X (October 2019) which still cannot boot a standard arm64 iso even 1.5 years later, despite having a UEFI: Linux on Surface Pro X Issues - Github

This means having a UEFI absolutely does not guarantees you to boot a standard image at all on ARM platforms.

  • Like UEFI on ARM, the situation is the same with U-Boot: No BDrivers, no image. Let even hopes about a standardized FSB.

  • On virtually every Android devices, it's even worse since what's commonly called "the bootloader" (an FSB) is locked by the OEM. iOS devices won't even gives you any chances to unlock that by official means, let aside unofficial ones.

ARM's and Google's takes on the situation:

But unfortunately, we haven't seen much news talking about such SBSA platforms since its inception except for some few servers, which indicates that SBSA is a failure to prevent fragmentation.

Worse, it is very unlikely to see some SBSA-like solution for mainstream platforms (phones, tablets, PCs, etc), as planned obsolescence is too profitable and that this has gone for too long so any hopes for OEMs willing to revert this back is close to none, especially on Android/iOS devices.

  • Google tried to takle the fragmentation issue due to ARM platforms with Project Treble and Project Mainline since they cannot force OEMs to have a standardized FSB sequence. The goals are to provide Android system updates independently from OEMs' ROMs that are stuck on a specific version because of planned obsolescence. However, this hasn't even changed things a bit, and it's also even harder for custom ROM developpers.

In fact, Google could certainly forces OEMs to have a standardized FSB sequence when they go through the Android certified devices program.

But remember that AOSP is open source and that OEMs may choose to go their own way should Google enforce anything. Which is something that already happenend with Huawei, Honor phones and more with "HarmonyOS": "Android exodus: more phone makers may turn to Huawei's HarmonyOS" - Techradar.

All in all, both attemps didn't even make a significant progress to circumvent ARM platforms fragmentation

ARM is really fragmented by design as a matter of fact.

One big thing that brings even more fragmentation is ARM's bad habits to use "rolling-release" development style for their "architectures":

This often brings brutal and sneaky feature removals without workarounds:


While x64 maintains compatibility from the very first 64 bit CPUs (AMD's Athlon 64) to the newest ones, ARM may not as they already did on 32 bit:

  • There was armel and armhf differences even on 32 bit ARM.
  • Which often
  • Companies can now even make adjustements on instructions sets through ARMs' CXC program.

Few things to remember and consider:

  • ARMv1 to ARMv7, A32 and AArch32 are 32 bit ARM, which means we can reasonably expect the same breakage level on 64 bit ARM.
  • On x64, very little features are dropped out of the blue, which means that 2021 CPUs still retain the whole 32 bit and even 16 bit compatibility (!). Should (rare) feature removal happens (e.g 3DNow!), there will mostly be a workaround to circumvent that.
  • ARM then cannot even boasts a 10 year backward compatibility and stability let aside the 25 years and counting from x64.
  • We still have perfectly working 2005 x64 CPUs that are still strong enough for nowadays web browsing.

Such backwards compatibility really prevents fragmentation.


PS: My post is indeed a heavy one. If someone can make it better to understand, I'm open to suggestions.

  • This post is very heavily anti ARM. But this is based on a few misconceptions. Firstly the division is not ARM vs non-ARM. It's the board having a BIOS with embedded firmware vs shipping the firmware with the OS or boot loader. Secondly ARM is a CPU architecture licences to manufacturers. The differences you describe have pretty much nothing to do with ARM itself. Thirdly if all the differences are wrapped up in early stage boot loader then why do they need an entire new OS distribution to ship one boot loader? May 9, 2021 at 0:24
  • You should also note that for the raspberry pi. as with other SBCs, the early stage boot loader is publicly available as a binary. The licence stipulates nothing about which OS you use, only that the binary may not be changed or used with other SBCs. May 9, 2021 at 0:28
  • 1
    It is not about having BIOS vs no BIOS since even UEFI equipped Microsoft Surface (RT) and Surface 2 still cannot be upgraded to Windows 10 for the very same reasons. While ARM is a CPU architecture licenced to manufacturers, it doesn't change a single thing about its ungodly fragmentation and planned obsolescence hence why it's mostly ARM vs non-ARM. About the 3rd point: The differences are not wrapped up in early stage bootloaders because they're all different, it's impossible to do that in ARM. This is why we need something like forcing SBSA for every ARM device.
    – X.LINK
    May 9, 2021 at 0:35
  • (cont'd): unix.stackexchange.com/questions/648838/… Other than that, I also find that strange that it tooks years for Raspberry Pi 3 to have decently working hardware acceleration on browsers. Any insights on that ?
    – X.LINK
    May 9, 2021 at 0:48
  • you've drawn the line in the wrong place for the wrong reasons. You don't find this in the x86 world because in the x86 world board manufacturers are required to ship a BIOS containing firmware which handles all this nonsense. In typical ARM SBCs there's no BIOS and all the firmware has to be supplied separately. That's not ARM vs non-ARM. It's BIOS vs no BIOS. The problem is with ARM SBCs is the lack of commercial pressure forcing them to ship a BIOS. May 9, 2021 at 0:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .