One of the real downsides of ARM is, it seems, the relative lack of standardization. An x64 kernel? It’ll run on most anything from the last ten years at least. And as for boot process, it’s probably one of two options (and in many cases one computer can boot either legacy or EFI).
ARM, on the other hand…my raspberry pi collection does one thing, my Orange Pi does something else, and God help you if you want to try swapping the Orange kernel for the Raspberry (or vice versa)!
If the system is SystemReady then the EFI boot chain is fairly straightforward now. My current workstation just booted off the Debian usb installer like any other pc.
A standard called SystemReady exists. For the systems that actually follow its standards, you can have a single ARM OS installation image that you copy to a USB drive and can then boot through UEFI and run with no problems on an Ampere server, an NXP device, an Nvidia Jetson system, and more.
Unfortunately it’s a pretty new standard, only since 2020, and Qualcomm in particular is a major holdout who hasn’t been using it.
Just like x86, you still need the OS to have drivers for the particular device you’re installing on, but this standard at least lets you have a unified image, and many ARM vendors have been getting better about upstreaming open-source drivers in the Linux kernel.
I’m hoping RISC-V will start showing up in consumer products soon. Hopefully the first ones will be Linux laptops. Windows doesn’t have RISC-V support yet, does it? This might be the opportunity for Linux to become the default for RISC-V.
a potential reason might be the very fragmentary nature of the RISC-V ISA, which makes a standard RISC-V kernel very complicated if you want to support more than a (barebones) profile. This is also supported by a RISC-V mailing list thread, where ‘expensive maintenance’ is mentioned for why Google doesn’t want to support RISC-V.
That might change. It wouldn’t be surprising if Google jumped back onto the train once RISC-V became popular again. But that might take a while.
I think a lot of the problem is how proprietary some of the hardware is. For instance, the Raspberry pi only runs the raspberry pi kernel which has a lot of proprietary blobs.
Meanwhile boards from Pine64 don’t need proprietary software to boot. The achieve this by being selective with the hardware and hardware vendors.
I don’t think this is as much of a problem, proprietary hardware is a thing on x86 too. The two big problems are a lack of boot standardization, and vendors not upstreaming their device drivers. A lack of standardization means it is difficult or impossible to use a single image to boot across different devices, and the lack of upstream drivers means even if you solved the boot process, you won’t be able to interface with peripherals without using a very custom kernel.
True, one of the issues of Android is also cost and development time. Manufacturers want to develop a product as cheap and fast as possible to keep up with demand.
That’s true for all commercial development. No company wants to invest more than they have to. Upstreaming does save time in the long run, but not in the short term.
Technically Google could of made upstreaming easier or even the default but they instead modified the kernel a bunch and then encouraged bad practices in development.
There are of course trade offs to everything though. For instance, Qualcomm could do better.
That is only sort of true. You don’t need proprietary software on a live USB to boot x86. That’s not the case with the Raspberry Pi as it boots from its GPU
“So far, Qualcomm has most of the critical functions working inside Linux, specifically version Linux 6.9 that was released not too long ago. These critical functions include UEFI-based boot support along with all the standard bootloaders like Grub and system-d.”
One of the real downsides of ARM is, it seems, the relative lack of standardization. An x64 kernel? It’ll run on most anything from the last ten years at least. And as for boot process, it’s probably one of two options (and in many cases one computer can boot either legacy or EFI).
ARM, on the other hand…my raspberry pi collection does one thing, my Orange Pi does something else, and God help you if you want to try swapping the Orange kernel for the Raspberry (or vice versa)!
Arm:
Somehow, the kernel has been loaded and we have transferred control into it.
But we still need a hundred blobs and if the kernel needs to do something it has to make a call to the firmware.
This is what we get when you use Broadcom
If the system is SystemReady then the EFI boot chain is fairly straightforward now. My current workstation just booted off the Debian usb installer like any other pc.
Faith in standards temporarily restored
Somehow, the kernel returned. -Poe dameron
A standard called SystemReady exists. For the systems that actually follow its standards, you can have a single ARM OS installation image that you copy to a USB drive and can then boot through UEFI and run with no problems on an Ampere server, an NXP device, an Nvidia Jetson system, and more.
Unfortunately it’s a pretty new standard, only since 2020, and Qualcomm in particular is a major holdout who hasn’t been using it.
Just like x86, you still need the OS to have drivers for the particular device you’re installing on, but this standard at least lets you have a unified image, and many ARM vendors have been getting better about upstreaming open-source drivers in the Linux kernel.
I’m hoping RISC-V will start showing up in consumer products soon. Hopefully the first ones will be Linux laptops. Windows doesn’t have RISC-V support yet, does it? This might be the opportunity for Linux to become the default for RISC-V.
Anti Commercial-AI license
Sad android already dropped RISC-V support
Woah. Got a source for that?
Anti Commercial-AI license
https://hackaday.com/2024/05/03/google-removes-risc-v-support-from-android/
Thanks for the link.
That might change. It wouldn’t be surprising if Google jumped back onto the train once RISC-V became popular again. But that might take a while.
Anti Commercial-AI license
https://www.theregister.com/2024/05/01/riscv_support_android_pulled/?td=rt-3a
wouldn’t risk-v be worse in terms of standardisation? At least for advanced functionality
Pine64 has a few Risc-V boards
I think a lot of the problem is how proprietary some of the hardware is. For instance, the Raspberry pi only runs the raspberry pi kernel which has a lot of proprietary blobs.
Meanwhile boards from Pine64 don’t need proprietary software to boot. The achieve this by being selective with the hardware and hardware vendors.
I don’t think this is as much of a problem, proprietary hardware is a thing on x86 too. The two big problems are a lack of boot standardization, and vendors not upstreaming their device drivers. A lack of standardization means it is difficult or impossible to use a single image to boot across different devices, and the lack of upstream drivers means even if you solved the boot process, you won’t be able to interface with peripherals without using a very custom kernel.
True, one of the issues of Android is also cost and development time. Manufacturers want to develop a product as cheap and fast as possible to keep up with demand.
That’s true for all commercial development. No company wants to invest more than they have to. Upstreaming does save time in the long run, but not in the short term.
Technically Google could of made upstreaming easier or even the default but they instead modified the kernel a bunch and then encouraged bad practices in development.
There are of course trade offs to everything though. For instance, Qualcomm could do better.
I mean, you can get the Pi to use EFI and just boot generic images.
It needs proprietary software to boot
Most x86 EFIs are, so the comparison is not really fair.
That is only sort of true. You don’t need proprietary software on a live USB to boot x86. That’s not the case with the Raspberry Pi as it boots from its GPU
deleted by creator
“So far, Qualcomm has most of the critical functions working inside Linux, specifically version Linux 6.9 that was released not too long ago. These critical functions include UEFI-based boot support along with all the standard bootloaders like Grub and system-d.”
It’s not x86 vs ARM problem. But rather vendor problem, how AMD/Intel upstream their Linux support while other do not.
The actual downside is, that you can’t have generalized drivers.