My uninformed normie view of the ecosystem suggests that it's the support for almost every particular board, and that's exactly the issue. For some reason, ARM devices always have some custom OS or Android and can't run off-the-shelf Linux. Meanwhile you can just buy an x86/amd64 device and assume it will just work. I presume there is some fundamental reason why ARM devices are so bad about this? Like they're just missing standardization and every device requires some custom firmware to be loaded by the OS that's inevitably always packaged in a hacky way?

▲

Muromec a day ago | parent | next [-]

Its the kernel drivers, not firmware. There is no bios or acpi, so the kernel itself has to support a specifc board. In practice it means there is a dtb file that configures it and the actual drivers in the kernel.

Manufacturers hack it together, flash to device and publish the sources, but dont bother with upstreaming and move on.

Same story as android devices not having updates two years after release.

▲

ndriscoll a day ago | parent [-]

But "no BOIS or ACPI" and requiring the kernel to support each individual board sounds exactly like the problem is the ARM architecture in general. Until that's sorted it makes sense to be wary of ARM.

▲

heavyset_go 14 hours ago | parent | next [-]

It's not a problem with ARM servers or vendors that care about building well designed ARM workstations.

It's a problem that's inherit to mobile computing and will likely never change unless with regulation or an open standards device line somehow hitting it out of the park and setting new expectations a la PCs.

The problem is zero expectation of ever running anything other than the vendor supplied support package/image and how fast/cheap it is to just wire shit together instead of worrying about standards and interoperability with 3rd party integrators.

▲

MarsIronPI 14 hours ago | parent [-]

How so? The Steam Deck is an x86 mobile PC with all the implications of everything (well, all the generic hardware e.g. WiFi, GPU IIRC) work out of the box.

	▲	heavyset_go 13 hours ago \| parent [-]
		When I say mobile, I mean ARM SoCs in the phone, embedded and IoT lineage, not so much full featured PCs in mobile form factor.

▲

mappu 18 hours ago | parent | prev | next [-]

What is ACPI other than a DTB baked into the firmware/bootloader?

Any SBC could buy an extra flash chip and burn an outdated U-Boot with the manufacturer's DTB baked in. Then U-Boot would boot Linux, just like UEFI does, and Linux would read the firmware's fixed DTB, just like it reads x86 firmware's fixed ACPI tables.

But - cui bono?

You need drivers in your main OS either way. On x86 you are not generally relying on your EFI's drivers for storage, video or networking.

It's actually nice that you can go without, and have one less layer.

▲

Muromec a day ago | parent | prev | next [-]

It is more or less like wifi problem on laptops, but multiplied by the number of chips. In a way it's more of a lunux problem than arm problem.

At some point the "good" boards get enough support and the situation slowly improves.

We reached the state where you dont need to spec-check the laptop if you want to run linux on it, the same will happen to arm sbc I hope.

▲

f1shy 21 hours ago | parent | prev [-]

Is a decision of linux about how to handle HW in the ARM world. So is a little like in the middle.

▲

bri3d 17 hours ago | parent | prev | next [-]

It's the shape of the delivered artifact that's driven the way things are implemented in the ecosystem, not a really fundamental architecture difference.

The shape of historically delivered ARM artifacts has been embedded devices. Embedded devices usually work once in one specific configuration. The shape of historically delivered ARM Linux products is a Thing that boots and runs. This only requires a kernel that works on one single device in one single configuration.

The shape of historically delivered x86 artifacts is socketed processors that plug into a variety of motherboards with a variety of downstream hardware, and the shape of historically delivered x86 operating systems is floppies, CDs, or install media that is expected to work on any x86 machine.

As ARM moves out of this historical system, things improve; I believe that for example you could run the same aarch64 Linux kernel on Pi 2B 1.2+, 3, and 4, with either UEFI/ACPI or just different DTBs for each device, because the drivers for these devices are mainline-quality and capable of discovering the environment in which they are running at runtime.

People commonly point to ACPI+UEFI vs DeviceTree as causes for these differences, but I think this is wrong; these are symptoms, not causes, and are broadly Not The Problem. With properly constructed drivers you could load a different DTB for each device and achieve similar results as ACPI; it's just different formats (and different levels of complexity + dynamic behavior). In some ways ACPI is "superior" since it enables runtime dynamism (ie - power events or even keystrokes can trigger behavior changes) without driver knowledge, but in some ways it's worse since it's a complex bytecode system and usually full of weird bugs and edge cases, versus DTB where what you see is what you get.

▲

joebe89 an hour ago | parent | prev | next [-]

Maybe this was the case a few years ago, but I would argue the landscape has changed a lot since then - with many more distro options for Arm64 devices.

▲

Youden a day ago | parent | prev [-]

This has often been the case in the past but the situation is much improved now.

For example I have an Orange Pi 5 Plus running the totally generic aarch64 image of Home Assistant OS [0]. Zero customization was needed, it just works with mainline everything.

There's even UEFI [1].

Granted this isn't the case for all boards but Rockchip at least seems to have great upstream support.

[0]: https://github.com/home-assistant/operating-system/releases

[1]: https://github.com/edk2-porting/edk2-rk3588

	▲	shadowpho 17 hours ago \| parent [-]
		Yeah but you can get a n100 on sale for about the same price, and it comes with a case, nvme storage (way better then sd card), power supply, proper cooling solution, and less maintanance…