3 ms·

I'm actually more of an ARM person, simply because neither Intel nor AMD managed to get power efficiency under control, not even after Apple's M1 ripped the x86

I'm actually more of an ARM person, simply because neither Intel nor AMD managed to get power efficiency under control, not even after Apple's M1 ripped the x86 world to shreds. The problem is, the ARM world never got away from crappy BSPs or managed to get any kind of standardization. Anyone reasonably skilled can get at least a basic "hello world" running that uses BIOS routines to draw characters on a screen and it will work on any x86 compliant machine, no matter its age - there is no equivalent that will work on ARM devices. None at all. Every tiny device, from embedded gadgets to full blown phones, has to have its own kernel build. What a mess that is.

nasretdinov 2y ago
I think it's just never been a concern for embedded systems, which ARM has been used for mostly. Surely there is some standardisation coming, it'll just have to take a lot of time since there a lot of parties who need to come together.
- silon42 2y ago
  so... all existing ARM "PC" stuff is e-waste basically
- adastra22 2y ago
  There are UEFI standards for ARM boot initialization firmware. The problem is basically nobody uses them without significant customization.
nolist_policy 2y ago
Arm has UEFI and ACPI since a few years now.
- mschuster91 2y ago
  But who actually uses that? That's my point. Phones all run their custom bootloaders (if you're lucky they use something from the Android SDK as second stage), embedded stuff runs u-boot versions forked a decade ago (or longer), even the really popular stuff such as raspi and its various clones all run their own proprietary stuff.
  - bitsandboots 2y ago
    I suspect only the apple laptops. It was a pain for me to find an arm64 build of linux that'd run in normal vm software for example. Most were compiled for particular SBCs. Pretty much was left with only debian & opensuse. So I agree with this topic: arm ecosystem has to get its act together to further adoption.
    - vetinari 2y ago
      Apple laptops do not natively support UEFI either; the virtualization sw does. Booting via UEFI on arm is also supported by alma, fedora and ubuntu server.
  - mfuzzey 2y ago
    ACPI / UEFI is heavily used on ARM server systems. Embedded stuff mostly uses u-boot true. But u-boot itself is actually fine for this type of device. I recently did an evaluation of several system on modules. They all came with their own usually different version of u-boot. For the purspose of the evaluation I ddin't care I just pointed them at my kernel + DT and it booted. The "decades old" part really depends. At work I've just finished updating our u-boot 2020.10 to 2024.04. But embedded and PC / Server are fundementally different in terms of use case. On a PC / Server the user expects to install an OS of his choice. Embedded isn't like that, the definition of embedded it pretty much "single use case device" so being able to install a generic Linux distro and run libre office isn't a use case many care about, particularly if it would increase the hardware costs. Phones are a different case to embedded, here it *would* be useful to install a generic OS (though probably not the same distributions as on PCs). For that a standarised bootloader / OS interface would be useful but it deosn't have to be UEFI / ACPI, u-boot distroboot would be sufficient https://docs.u-boot.org/en/latest/develop/bootstd.html https://docs.u-boot.org/en/latest/develop/bootstd.html
mfuzzey 2y ago
You don't actually need a custom kernel build for every device these days (and haven't for years). Within the same ISA (ARM32 or ARM64) you can run the exact same binary kernel on multiple devices provided you have a suitable device tree for each. And that's not really much different in principle to APCI (which is really "DT on steroids"). The main difference is that with ACPI the device manufacturer ships the tables whereas with DT they have usually have to be provided by others. PCs haven't standardised everything at the hardware level for years. The original PC had standard IO addresses but this only covers a few things like keyboard, display, serial ports. Modern PCs, especially laptops, have all sorts of "non standard" chips hanging off I2C busses. There are 2 reasons it "just works" on PCs 1) ACPI tables descibe it (just like DT) 2) There are compatibility tests needed to get the Microsoft hardware certification to run Windows But it goes beyond the kernel to the full OS distribution. All PCs have pretty much the same use cases and similar UI capabilities. Sure some may be more powerful etc but they're all pretty much the same idea. So on a PC it makes snese to pop in a USB key with a "generic" Linux distribution an install it. It probably doesn't make as much sense to want to install the exact same distribution on your PC, phone, TV and router. This means that, given the OS is going to be customised anyway there just isn't as much demand for a fully plug and play system.

nasretdinov 2y ago

I think it's just never been a concern for embedded systems, which ARM has been used for mostly. Surely there is some standardisation coming, it'll just have to take a lot of time since there a lot of parties who need to come together.

silon42 2y ago
so... all existing ARM "PC" stuff is e-waste basically
adastra22 2y ago
There are UEFI standards for ARM boot initialization firmware. The problem is basically nobody uses them without significant customization.

nolist_policy 2y ago

Arm has UEFI and ACPI since a few years now.

mschuster91 2y ago
But who actually uses that? That's my point. Phones all run their custom bootloaders (if you're lucky they use something from the Android SDK as second stage), embedded stuff runs u-boot versions forked a decade ago (or longer), even the really popular stuff such as raspi and its various clones all run their own proprietary stuff.
- bitsandboots 2y ago
  I suspect only the apple laptops. It was a pain for me to find an arm64 build of linux that'd run in normal vm software for example. Most were compiled for particular SBCs. Pretty much was left with only debian & opensuse. So I agree with this topic: arm ecosystem has to get its act together to further adoption.
  - vetinari 2y ago
    Apple laptops do not natively support UEFI either; the virtualization sw does. Booting via UEFI on arm is also supported by alma, fedora and ubuntu server.
- mfuzzey 2y ago
  ACPI / UEFI is heavily used on ARM server systems. Embedded stuff mostly uses u-boot true. But u-boot itself is actually fine for this type of device. I recently did an evaluation of several system on modules. They all came with their own usually different version of u-boot. For the purspose of the evaluation I ddin't care I just pointed them at my kernel + DT and it booted. The "decades old" part really depends. At work I've just finished updating our u-boot 2020.10 to 2024.04. But embedded and PC / Server are fundementally different in terms of use case. On a PC / Server the user expects to install an OS of his choice. Embedded isn't like that, the definition of embedded it pretty much "single use case device" so being able to install a generic Linux distro and run libre office isn't a use case many care about, particularly if it would increase the hardware costs. Phones are a different case to embedded, here it *would* be useful to install a generic OS (though probably not the same distributions as on PCs). For that a standarised bootloader / OS interface would be useful but it deosn't have to be UEFI / ACPI, u-boot distroboot would be sufficient https://docs.u-boot.org/en/latest/develop/bootstd.html https://docs.u-boot.org/en/latest/develop/bootstd.html

mfuzzey 2y ago

You don't actually need a custom kernel build for every device these days (and haven't for years). Within the same ISA (ARM32 or ARM64) you can run the exact same binary kernel on multiple devices provided you have a suitable device tree for each. And that's not really much different in principle to APCI (which is really "DT on steroids"). The main difference is that with ACPI the device manufacturer ships the tables whereas with DT they have usually have to be provided by others. PCs haven't standardised everything at the hardware level for years. The original PC had standard IO addresses but this only covers a few things like keyboard, display, serial ports. Modern PCs, especially laptops, have all sorts of "non standard" chips hanging off I2C busses. There are 2 reasons it "just works" on PCs 1) ACPI tables descibe it (just like DT) 2) There are compatibility tests needed to get the Microsoft hardware certification to run Windows But it goes beyond the kernel to the full OS distribution. All PCs have pretty much the same use cases and similar UI capabilities. Sure some may be more powerful etc but they're all pretty much the same idea. So on a PC it makes snese to pop in a USB key with a "generic" Linux distribution an install it. It probably doesn't make as much sense to want to install the exact same distribution on your PC, phone, TV and router. This means that, given the OS is going to be customised anyway there just isn't as much demand for a fully plug and play system.