I’ve seen people talking about it and experienced it myself with a server, but why does Linux run so well on ARM (especially compared to Windows)?
I’ve seen people talking about it and experienced it myself with a server, but why does Linux run so well on ARM (especially compared to Windows)?
Having tried a Surface X back in the day, I don’t know what you mean. Windows runs on ARM just fine. In fact, Windows 8 was an excellent OS for tablets that only sucked because Microsoft had to push the tabllet UI to deskrops without touch screen. The only reason it doesn’t run on all boards is the exclusivity deal they signed with Qualcom and Microsoft’s lack of interest. The bargain bin devices that do run Windows on ARM have terrible hardware that would probably run slowly if you installed ChromeOS or Linux too.
In fact, Microsoft actually has the sway necessary to force manufacturers to cut their stupid uBoot crap. Running Linux on an ARM board absolutely sucks ass. Many drivers are lacking, kernels need to be built specifically for your hardware as if you’re running Gentoo in 2005, or you’ll need the custom kernel the manufacturer made five years ago and never updated. Some manufacturers (Raspberry etc.) publish their own kernels, but those are rarely up to date with upstream.
Windows doesn’t have generic ARM drivers to run om anything and getting Linux to work on ARM sucks. Unlike x64, ARM doesn’t have a standard boot method (it has uefi but only on Windows devices really) so running anything custom is a terrible experience.
The only thing making Linux remotely usable on ARM is the Android kernel that can be used as a reference to write decent drivers for upstreaming (see: postmarketos). Android devices are usually stuck with whatever major+minor (LTS) version they shipped with, only receiving security updates (occasionally) unless volunteers toil at porting the alterations to something upstreamable. I suppose there are more people writing Linux drivers in their free time than there are people writing Windows drivers for free, but that’s got little to do with the technical design of either kernel.
Microsoft has launched an ARM devkit and I haven’t seen any major complaints other than that Apple’s CPUs are much faster in comparison. That thing would probably run Linux just as fine.
Raspberry pi works fine with linux, cutiePi also. my iomega nas is an arm board running debian…i don’t see the issue
The Raspberry Pi is an exception. It has taken until 2021-2022 for things like video acceleration to work using the normal Linux kernel (not the Raspberry Pi customised one with patches that only that kernel uses). For at least half a decade, you needed a custom kernel with device specific patches or the darn thing just wouldn’t work.
Now it mostly works, though the RPi people do keep a separate kernel around with a few patches that they consider better than the ones the Linux kernel has merged.
If you take any other device with a similar board (like RPi clones with an m.2 slot) you’ll have to mess with special drivers yet again.
Pi-like devices also use a special configuration setup (a fat32 partition with some hardcoded file paths) that normal ARM boards don’t use. That’s because you need the closed source Raspberry Pi bootloader to actually get the device to boot.
Imagine having to install grub-msi-gaming-laptops-2021 instead of grub in your desktop. Yes, it works, ut It’s all custom with special code and tricks. This is also why you can just insert a USB drive and install Linux on PC but need to deal with special images you flash to the SD card for Pi-likes.
The issue with Arm is they aren’t all one board/chip, you have ARM based design licenced from them and they are built to meet the criteria of what the customer requires. i.e. for my iomega NAS there isn’t firmware boot, you just have to generate an empty section of 00s on the first 32bytes of the drive so the board knows that is the drive to load the kernel from (no grub no uboot) and the board is set to do the rest from the next partition.
It’s not like x64 is all the exact same board with different performance levels either. There are a few conventions, but between AMD, Intel, and Zhaoxin, there are a lot of differences. Different boards also have different buses (SPI, I²C, etc.) that all have their own hardware discovery aside from standard PCIe.
It helps that there are effectively two BIOS writing companies that build firmware for almost every manufacturer, but alternatives like Coreboot still load software the same way.
There’s very little preventing ARM boards from implementing a basic UEFI implementation that works like any normal computer. The UEFI platform itself has an open source reference implementation ready to be patched for board specifics and flashed onto a 512MB chip. Manufacturers just don’t do it, because their customers don’t care enough to make the lack of normal bootloaders a problem.
Booting isn’t the only problem with ARM. Instead of saving information about builtin devices on the board and exposing it via ACPI, board manufacturers create a devicetree and ship it with the kernel. This means that if you want to run your own kernel you need to build your own devicetree
But all x86 instructions are the same right, thus why it doesnt matter what era your chip is from or what manufacturer, arm can be very different
x64 has all kinds of vendor exclusive instructions sets (AVX-512 and SEV-SNP for example). The solution for most programs and compilers is to either be conservative (only including the most common instruction sets) or to compile code to multiple different paths depending on what extensions are available (resulting in larger binaries that can use more modern features).
For a while, I rented a dedicated server for cheap that was running a first generation i7. Performance was fine for web server stuff, but the lack of AES acceleration was definitely annoying and several times I’ve run into attempts to run SSE instructions that the processor simply couldn’t run. I’ve also run into instruction set annoyances when trying to run pre-compiled machine learning tools that assumed functional AVX instructions that my desktop doesn’t understand.
Most ARM devices run Armv8-A or these days Armv9-A, with possibly some extensions. There’s also the special ARM Thumb (which is a requirement for some platform code) but that’s supported by most ARM chips as well. Like on x64, there are a few optional extensions (like Neon for SIMD, or Apple’s additions to make Rosetta2 work as well as it does).
The instruction sets match enough that distros like Debian and Alpine have most of their packages available for ARM (aarch64). Once you get a kernel loaded and the system up and running, you can grab generic binaries from standard distros and run a normal Linux system without ever having to recompile your userland code.
The biggest problem on ARM remains getting a working kernel and getting it to boot.
Thanks for the info, I appreciate the reply
Theese devices support linux out of the box. Try installing a proper linux distro on your phone and good luck finding a graphics driver that is not sotware rendering
As did microsofts arm device support windows, which is the point zi was replying to with skullgiver. of course windows works if the arm version was built for the hardware it runs on.