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)?
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.
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
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
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.