5 ms·

> Every single person I've seen express interest in this device, wants it for Linux (dev or to try as a daily driver). Does Linux still require specific images

> Every single person I've seen express interest in this device, wants it for Linux (dev or to try as a daily driver). Does Linux still require specific images with patches to be built for every SBC/device?

jsheard 2y ago
Technically no if you get a machine with ARM SystemReady certification, but effectively yes in practice because zero affordable SBCs meet that criteria. I think the Ampere Altras are the only ones you can easily buy, and those start at $1400 for a bare motherboard and CPU combo with no RAM included. https://www.newegg.com/asrock-rack-altrad8ud-1l2t-q64-22-ampere-altra-max-ampere-altra-processors/p/N82E16813140134 https://www.newegg.com/asrock-rack-altrad8ud-1l2t-q64-22-amp...
aidenn0 2y ago
It depends on what you mean by "every SBC/device" and "specific images" If your SBC requires things not in mainline linux (which is common for new ARM SoCs), then you will need a custom kernel. Otherwise it can use a stock kernel, but might need a custom version of uboot, and will definitely need a board-specific device-tree.
- Y_Y 2y ago
  Fuck device trees so much. Is there some fundamental impediment to having the same "plug 'n play" experience that we've have on x86 IBM-clone descendants for thirty years?
  - ComputerGuru 2y ago
    Yes. Lack of BIOS or EFI. And ACPI. And. and. and.
    - Y_Y 2y ago
      You're right, in the sense that the standards that enable this magic are not present on Arm SBCs, but I wouldn't consider that "fundamental". Arm is at least theoretically on board with UEFI, for example, and there are implementors making boards that support it. What I'm really asking is if a sufficiently determined person couldn't have avoided all these headaches by building and/or standardizing equivalent technologies. (And if it's possible why hasn't it happened yet?)
      - Joel_Mckay 2y ago
        Most of these ARM boards use the u-boot method for staged bring up of the system. =3
      - murderfs 2y ago
        > What I'm really asking is if a sufficiently determined person couldn't have avoided all these headaches by building and/or standardizing equivalent technologies. https://xkcd.com/927/ https://xkcd.com/927/ The reason that this worked out in x86-land is that the entire industry spawned from cloning and making extensions for a single product, the IBM PC.
      - ComputerGuru 2y ago
        Basically because of the way the tech evolved. x86 was made to be “generic” from very early on, in large because of the decoupling between CPU vendors and PC vendors. ARM doesn’t make chips you can buy and plug into devices (they don’t make chips at all). You get the IP for the core and you then typically integrate it into your SoC. There is/was so much custom development that there was no benefit in adding an abstraction for the sake of adding an abstraction when the only ARM SoC a device would ever see is the one that shipped from the factory with it, and the tight coupling between firmware and hardware developers for phones and tablets meant you would just hardcode the values and behaviors and peripherals you expected to find. There is a level of abstraction at the code level with svd files that let you more easily code new firmware against new chips reusing existing logic, but it’s like the equivalent of a some mediocre api compatibility without abi compatibility - you still need new blobs for the end user. The era of PCs and laptops using ARM running generic operating systems came ages into the existence and growth of the ARM ecosystem. Compromises such as device trees were found, but it’s nothing like BIOS and ACPI. (Now we’ll get the typical replies stating “yes but no one does BIOS and ACPI correctly so I’d rather have to wait for actually correct device trees blobs from the manufacturer than a buggy ACPI implementation” to offer the alternative viewpoint.)
  - murderfs 2y ago
    Yes, the impediment is that there isn't a single IBM machine that everyone's cloning.
  - AlotOfReading 2y ago
    That standard exists, it's called SystemReady. Vendors choose not to implement it. However, device trees are far better than ACPI. The only reason anyone likes it is that there's a lot of generous people dedicating their time to patching over broken ACPI tables so that users don't have to see how utterly terrible it is. Device trees make that pain into very clear and obvious errors instead of giving you a subtly broken system.
  - rcxdude 2y ago
    IBM PCs use ACPI tables, which are basically the same thing as device trees. It's just that ACPI tables are burnt into the UEFI bootloader on the motherboard, while most SBCs put the bootloader on the same media as the OS. (generally I think this is an area which just hasn't become mainstream enough for this standardisation to be useful: when most of your users are hacking around with the SBC and are happy to just download the vendor's SD card image, there's very little impetus to make something plug-and-play)
    - throwup238 2y ago
      > (generally I think this is an area which just hasn't become mainstream enough for this standardisation to be useful: when most of your users are hacking around with the SBC and are happy to just download the vendor's SD card image, there's very little impetus to make something plug-and-play) I think it's a more subtle problem of embedded software engineering culture being a decade or more behind the rest of software development, especially at any IC company that aren't NVIDIA/Intel/AMD. IME most SBC users are commercial, not users hacking with it (I don't know about this specific dev kit though), and every professional EE I know hates dealing with poorly supported non-mainline linux SBCs. If your company/clients don't commit to a single platform like iMX for years at a time, managing embedded linux is a pain in the ass. That's why RPi was so successful with its compute modules, the community handled a lot of that pain instead of depending on the vendor.
      - aidenn0 2y ago
        > embedded software engineering culture being a decade or more behind the rest of software development I'm not sure, because putting the bootloader in EPROM or NOR has been done on embedded boards for years; it's just rare on mass-manufactured general-use SBCs. I don't know if that's because of BOM, convenience for commercial SBC customers, or just to make it harder to brick the board.
      - rcxdude 2y ago
        There is that general (much bigger) issue with fragmentation as well. But that's mostly seperate from 'I also need to stick a devicetree on my boot media'. (I do know the pain of non-mainline linux SBCs, and I make some effort to avoid it now: even if it means using old chips, I'll very strongly prefer one with mainline support, note that raspberry pi is also pretty behind on getting their support upstream, even the pi 4 is still lagging, and the pi 5 isn't even usable. They just have some vaguely decent support for their fork)
  - Joel_Mckay 2y ago
    Have a look at the kernel >5.x.y organization. Overlays were a necessary result of every manufacture spinning their own board variant with standard cores and generic drivers. i.e. to bring up the hardware a generic monolith kernel would need to balloon in complexity, and could still mishandle ambiguous module setup etc. It is a kludge for sure, but a necessary one in the current ecosystem. =3
mise_en_place 2y ago
Yes but that isn't a Linux-specific thing. You will always need a BSP (Board Support Package) for any embedded custom hardware, whether it's an SBC or any SoC for that matter.

jsheard 2y ago

Technically no if you get a machine with ARM SystemReady certification, but effectively yes in practice because zero affordable SBCs meet that criteria. I think the Ampere Altras are the only ones you can easily buy, and those start at $1400 for a bare motherboard and CPU combo with no RAM included. https://www.newegg.com/asrock-rack-altrad8ud-1l2t-q64-22-ampere-altra-max-ampere-altra-processors/p/N82E16813140134 https://www.newegg.com/asrock-rack-altrad8ud-1l2t-q64-22-amp...

aidenn0 2y ago

It depends on what you mean by "every SBC/device" and "specific images" If your SBC requires things not in mainline linux (which is common for new ARM SoCs), then you will need a custom kernel. Otherwise it can use a stock kernel, but might need a custom version of uboot, and will definitely need a board-specific device-tree.

Y_Y 2y ago
Fuck device trees so much. Is there some fundamental impediment to having the same "plug 'n play" experience that we've have on x86 IBM-clone descendants for thirty years?
- ComputerGuru 2y ago
  Yes. Lack of BIOS or EFI. And ACPI. And. and. and.
  - Y_Y 2y ago
    You're right, in the sense that the standards that enable this magic are not present on Arm SBCs, but I wouldn't consider that "fundamental". Arm is at least theoretically on board with UEFI, for example, and there are implementors making boards that support it. What I'm really asking is if a sufficiently determined person couldn't have avoided all these headaches by building and/or standardizing equivalent technologies. (And if it's possible why hasn't it happened yet?)
    - Joel_Mckay 2y ago
      Most of these ARM boards use the u-boot method for staged bring up of the system. =3
    - murderfs 2y ago
      > What I'm really asking is if a sufficiently determined person couldn't have avoided all these headaches by building and/or standardizing equivalent technologies. https://xkcd.com/927/ https://xkcd.com/927/ The reason that this worked out in x86-land is that the entire industry spawned from cloning and making extensions for a single product, the IBM PC.
    - ComputerGuru 2y ago
      Basically because of the way the tech evolved. x86 was made to be “generic” from very early on, in large because of the decoupling between CPU vendors and PC vendors. ARM doesn’t make chips you can buy and plug into devices (they don’t make chips at all). You get the IP for the core and you then typically integrate it into your SoC. There is/was so much custom development that there was no benefit in adding an abstraction for the sake of adding an abstraction when the only ARM SoC a device would ever see is the one that shipped from the factory with it, and the tight coupling between firmware and hardware developers for phones and tablets meant you would just hardcode the values and behaviors and peripherals you expected to find. There is a level of abstraction at the code level with svd files that let you more easily code new firmware against new chips reusing existing logic, but it’s like the equivalent of a some mediocre api compatibility without abi compatibility - you still need new blobs for the end user. The era of PCs and laptops using ARM running generic operating systems came ages into the existence and growth of the ARM ecosystem. Compromises such as device trees were found, but it’s nothing like BIOS and ACPI. (Now we’ll get the typical replies stating “yes but no one does BIOS and ACPI correctly so I’d rather have to wait for actually correct device trees blobs from the manufacturer than a buggy ACPI implementation” to offer the alternative viewpoint.)
- murderfs 2y ago
  Yes, the impediment is that there isn't a single IBM machine that everyone's cloning.
- AlotOfReading 2y ago
  That standard exists, it's called SystemReady. Vendors choose not to implement it. However, device trees are far better than ACPI. The only reason anyone likes it is that there's a lot of generous people dedicating their time to patching over broken ACPI tables so that users don't have to see how utterly terrible it is. Device trees make that pain into very clear and obvious errors instead of giving you a subtly broken system.
- rcxdude 2y ago
  IBM PCs use ACPI tables, which are basically the same thing as device trees. It's just that ACPI tables are burnt into the UEFI bootloader on the motherboard, while most SBCs put the bootloader on the same media as the OS. (generally I think this is an area which just hasn't become mainstream enough for this standardisation to be useful: when most of your users are hacking around with the SBC and are happy to just download the vendor's SD card image, there's very little impetus to make something plug-and-play)
  - throwup238 2y ago
    > (generally I think this is an area which just hasn't become mainstream enough for this standardisation to be useful: when most of your users are hacking around with the SBC and are happy to just download the vendor's SD card image, there's very little impetus to make something plug-and-play) I think it's a more subtle problem of embedded software engineering culture being a decade or more behind the rest of software development, especially at any IC company that aren't NVIDIA/Intel/AMD. IME most SBC users are commercial, not users hacking with it (I don't know about this specific dev kit though), and every professional EE I know hates dealing with poorly supported non-mainline linux SBCs. If your company/clients don't commit to a single platform like iMX for years at a time, managing embedded linux is a pain in the ass. That's why RPi was so successful with its compute modules, the community handled a lot of that pain instead of depending on the vendor.
    - aidenn0 2y ago
      > embedded software engineering culture being a decade or more behind the rest of software development I'm not sure, because putting the bootloader in EPROM or NOR has been done on embedded boards for years; it's just rare on mass-manufactured general-use SBCs. I don't know if that's because of BOM, convenience for commercial SBC customers, or just to make it harder to brick the board.
    - rcxdude 2y ago
      There is that general (much bigger) issue with fragmentation as well. But that's mostly seperate from 'I also need to stick a devicetree on my boot media'. (I do know the pain of non-mainline linux SBCs, and I make some effort to avoid it now: even if it means using old chips, I'll very strongly prefer one with mainline support, note that raspberry pi is also pretty behind on getting their support upstream, even the pi 4 is still lagging, and the pi 5 isn't even usable. They just have some vaguely decent support for their fork)
- Joel_Mckay 2y ago
  Have a look at the kernel >5.x.y organization. Overlays were a necessary result of every manufacture spinning their own board variant with standard cores and generic drivers. i.e. to bring up the hardware a generic monolith kernel would need to balloon in complexity, and could still mishandle ambiguous module setup etc. It is a kludge for sure, but a necessary one in the current ecosystem. =3

mise_en_place 2y ago

Yes but that isn't a Linux-specific thing. You will always need a BSP (Board Support Package) for any embedded custom hardware, whether it's an SBC or any SoC for that matter.