6 ms·

At some point SBCs that require a custom linux image will become unacceptable, right? Right?

by zzzoom 6mo ago

jagged-chisel 6mo ago
“Custom”? No. Proprietary and closed? One can hope.
- Gigachad 6mo ago
  I think even custom is unacceptable. It’s too much of a pain being limited in your distro choice because you are limited to specific builds. On x86 you can run anything.
joshuaissac 6mo ago
There are some projects to port UEFI to boards like Orange Pi and Raspberry Pi. You can install a normal OS once you have flashed that. https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4 https://github.com/tianocore/edk2-platforms/tree/master/Plat... https://github.com/edk2-porting/edk2-rk3588 https://github.com/edk2-porting/edk2-rk3588
- ajb 6mo ago
  There also seems to be a plan to add uefi support to u-boot[1]. Many of these kinds of boards have u-boot implementations, so could then boot uefi kernel. However many of these ARM chips have their own sub-architecture in the Linux source tree, I'm not sure that it's possible today to build a single image with them all built in and choose the subarchitecture at runtime. Theoretically it could be done, of course, but who has the incentive to do that work? (I seem to remember Linus complaining about this situation to the Arm maintainer, maybe 10-20 years ago) [1] https://docs.u-boot.org/en/v2021.04/uefi/uefi.html https://docs.u-boot.org/en/v2021.04/uefi/uefi.html
- ekianjo 6mo ago
  The orange pi 6 plus supports UEFI from the get go.
- aidenn0 6mo ago
  Per TFA, the Orange Pi 6 Plus ships with UEFI, but the SoC requires a vendor specific kernel.
jubilanti 6mo ago
[dead]
Aurornis 6mo ago
Using vendor kernels is standard in embedded development. Upstreaming takes a long time so even among well-supported boards you either have to wait many years for everything to get upstreamed or find a board where the upstreamed kernel supports enough peripherals that you're not missing anything you need. I think it's a good thing that people are realizing that these SBCs are better used as development tools for people who understand embedded dev instead of as general purpose PCs. For years now you can find comments under every Raspberry Pi or other SBC thread informing everyone that a mini PC is a better idea for general purpose compute unless you really need something an SBC offers, like specific interfaces or low power.
- apatheticonion 6mo ago
  I have always found it perplexing. Why is that required? Is it the lack of drivers in upstream? Is it something to do with how ARM devices seemingly can't install Linux the same way x86 machines can (something something device tree)?
  - girvo 6mo ago
    Yeah lack of peripheral drivers upstream for all the little things on the board, plus (AIUI) ARM doesn't have the same self-describing hardware discovery mechanisms that x86 computers have. Basically, standardisation. They're closer to MCUs in that way, is how I found it (though my knowledge is way out of date now, been years since I was doing embedded)
    - apatheticonion 6mo ago
      I've just been doing some reading. The driver situation in Linux is a bit dire. On the one hand there is no stable driver ABI because that would restrict the ability for Linux to optimize. On the other hand vendors (like Orange Pi, Samsung, Qualcomm, etc etc) end up maintaining long running and often outdated custom forks of Linux in an effort to hide their driver sources. Seems..... broken
- mort96 6mo ago
parl_match 6mo ago
> At some point SBCs that require a custom linux image will become unacceptable, right? The flash images contain information used by the bios to configure and bring up the device. It's more than just a filesystem. Just because it's not the standard consoomer "bios menu" you're used to doesn't mean it's wrong. It's just different. These boards are based off of solutions not generally made available to the public. As a result, they require a small amount of technical knowledge beyond what operating a consumer PC might require. So, packaging a standard arm linux install into a "custom" image is perfectly fine, to be honest.
- zzzoom 6mo ago
  If the image contains information required to bring up the device, why isn't that data shipped in firmware?
  - orangeboats 6mo ago
    In some cases the built-in firmware is very barebones, just enough to get U-boot to load up and do the rest of the job.
  - parl_match 6mo ago
    > If the image contains information required to bring up the device, why isn't that data shipped in firmware? the firmware is usually an extremely minimal set of boot routines loaded on the SOC package itself. to save space and cost, their goal is to jump to an external program. so, many reasons - firmware is less modular, meaning you cant ship hardware variants without also shipping firmware updates (the boot blob contains the device tree). also raises cost (see next) - requires flash, which adds to BOM. intended designs of these ultra low cost SOCs would simply ship a single emmc (which the SD card replaces) - no guaranteed input device for interactive setup. they'd have to make ui variants, including for weird embedded devices (such as a transit kiosk). and who is that for? a technician who would just reimage the device anyways? - firmware updates in the field add more complexity. these are often low service or automatic service devices anyways if you're shipping a highly margin sensitive, mass market device (such as a set top box, which a lot of these chipsets were designed for), the product is not only the SOC but the board reference design. when you buy a pi-style product, you're usually missing out on a huge amount of normally-included ecosystem. that means that you can get a SBC for cheap using mass produced merchant silicon, but the consumer experience is sub-par. after all, this wasn't designed for your use case :)

At some point SBCs that require a custom linux image will become unacceptable, right? Right?

by zzzoom 6mo ago

At some point SBCs that require a custom linux image will become unacceptable, right? Right?

jagged-chisel 6mo ago

“Custom”? No. Proprietary and closed? One can hope.

Gigachad 6mo ago
I think even custom is unacceptable. It’s too much of a pain being limited in your distro choice because you are limited to specific builds. On x86 you can run anything.

joshuaissac 6mo ago

There are some projects to port UEFI to boards like Orange Pi and Raspberry Pi. You can install a normal OS once you have flashed that. https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4 https://github.com/tianocore/edk2-platforms/tree/master/Plat... https://github.com/edk2-porting/edk2-rk3588 https://github.com/edk2-porting/edk2-rk3588

ajb 6mo ago
There also seems to be a plan to add uefi support to u-boot[1]. Many of these kinds of boards have u-boot implementations, so could then boot uefi kernel. However many of these ARM chips have their own sub-architecture in the Linux source tree, I'm not sure that it's possible today to build a single image with them all built in and choose the subarchitecture at runtime. Theoretically it could be done, of course, but who has the incentive to do that work? (I seem to remember Linus complaining about this situation to the Arm maintainer, maybe 10-20 years ago) [1] https://docs.u-boot.org/en/v2021.04/uefi/uefi.html https://docs.u-boot.org/en/v2021.04/uefi/uefi.html
ekianjo 6mo ago
The orange pi 6 plus supports UEFI from the get go.
aidenn0 6mo ago
Per TFA, the Orange Pi 6 Plus ships with UEFI, but the SoC requires a vendor specific kernel.

jubilanti 6mo ago

[dead]

Aurornis 6mo ago

Using vendor kernels is standard in embedded development. Upstreaming takes a long time so even among well-supported boards you either have to wait many years for everything to get upstreamed or find a board where the upstreamed kernel supports enough peripherals that you're not missing anything you need. I think it's a good thing that people are realizing that these SBCs are better used as development tools for people who understand embedded dev instead of as general purpose PCs. For years now you can find comments under every Raspberry Pi or other SBC thread informing everyone that a mini PC is a better idea for general purpose compute unless you really need something an SBC offers, like specific interfaces or low power.

apatheticonion 6mo ago
I have always found it perplexing. Why is that required? Is it the lack of drivers in upstream? Is it something to do with how ARM devices seemingly can't install Linux the same way x86 machines can (something something device tree)?
- girvo 6mo ago
  Yeah lack of peripheral drivers upstream for all the little things on the board, plus (AIUI) ARM doesn't have the same self-describing hardware discovery mechanisms that x86 computers have. Basically, standardisation. They're closer to MCUs in that way, is how I found it (though my knowledge is way out of date now, been years since I was doing embedded)
  - apatheticonion 6mo ago
    I've just been doing some reading. The driver situation in Linux is a bit dire. On the one hand there is no stable driver ABI because that would restrict the ability for Linux to optimize. On the other hand vendors (like Orange Pi, Samsung, Qualcomm, etc etc) end up maintaining long running and often outdated custom forks of Linux in an effort to hide their driver sources. Seems..... broken
mort96 6mo ago

parl_match 6mo ago

> At some point SBCs that require a custom linux image will become unacceptable, right? The flash images contain information used by the bios to configure and bring up the device. It's more than just a filesystem. Just because it's not the standard consoomer "bios menu" you're used to doesn't mean it's wrong. It's just different. These boards are based off of solutions not generally made available to the public. As a result, they require a small amount of technical knowledge beyond what operating a consumer PC might require. So, packaging a standard arm linux install into a "custom" image is perfectly fine, to be honest.

zzzoom 6mo ago
If the image contains information required to bring up the device, why isn't that data shipped in firmware?
- orangeboats 6mo ago
  In some cases the built-in firmware is very barebones, just enough to get U-boot to load up and do the rest of the job.
- parl_match 6mo ago
  > If the image contains information required to bring up the device, why isn't that data shipped in firmware? the firmware is usually an extremely minimal set of boot routines loaded on the SOC package itself. to save space and cost, their goal is to jump to an external program. so, many reasons - firmware is less modular, meaning you cant ship hardware variants without also shipping firmware updates (the boot blob contains the device tree). also raises cost (see next) - requires flash, which adds to BOM. intended designs of these ultra low cost SOCs would simply ship a single emmc (which the SD card replaces) - no guaranteed input device for interactive setup. they'd have to make ui variants, including for weird embedded devices (such as a transit kiosk). and who is that for? a technician who would just reimage the device anyways? - firmware updates in the field add more complexity. these are often low service or automatic service devices anyways if you're shipping a highly margin sensitive, mass market device (such as a set top box, which a lot of these chipsets were designed for), the product is not only the SOC but the board reference design. when you buy a pi-style product, you're usually missing out on a huge amount of normally-included ecosystem. that means that you can get a SBC for cheap using mass produced merchant silicon, but the consumer experience is sub-par. after all, this wasn't designed for your use case :)