8 ms·

Having worked with devicetrees and hated it, I don't like this idea. I don't like the modern world of ARM and embedded where you have hardcoded firmware images

Having worked with devicetrees and hated it, I don't like this idea. I don't like the modern world of ARM and embedded where you have hardcoded firmware images for every single device. I like the x86 model, where you have a one size fits all boot disk which just loads different drivers. You don't port your OS to a new computer, you just write drivers for the new hardware parts. And your hardware describes itself to the OS. Granted, UEFI is grotesquely complicated. Probably you could replace most of it with a EEPROM that has a mapping of device ID to memory address, and some instructions how to speak to the embedded controller (basically, ACPI). Unfortunately, UEFI/ACPI or simliar seems to be going nowhere in the ARM world, so it doesn't seem installing Windows/Linux is going to be as easy on ARM as on x86 anytime soon.

mlindner 4y ago
You realize that you're just moving the ball around on who provides what, right? Someone has to write that software that "describes itself to the OS" and rather than having the hardware describe itself to the OS, why can't the OS itself determine what hardware it has? That "describes itself to the OS" part is actually often being done by a complete OS as well. > Unfortunately, UEFI/ACPI or simliar seems to be going nowhere in the ARM world, so it doesn't seem installing Windows/Linux is going to be as easy on ARM as on x86 anytime soon. That's a really good thing. Bryan rants about ARM trying to go that way and thinks it's a terrible idea. I'm glad it's failing, assuming that's actually the case.
- gjsman-1000 4y ago
  > Bryan rants about ARM trying to go that way and thinks it's a terrible idea. I'm glad it's failing, assuming that's actually the case. I'd be curious why because the PC model seems to be way more user-friendly, competition-friendly, and long-term-reliable than the current ARM model. I wish I could just download an ISO of Android 13 and install it on almost any Android phone like I could Windows.
  - mlindner 4y ago
    Well it's in the talk, he spends considerable time on the subject in fact. I suggest taking a watch.
  - eschaton 4y ago
    The PC model worked because a lot of people put a lot of blood sweat and tears into making it work and then embraced the sunk cost fallacy to a degree only previously seen in politics and religion. Open Firmware—between the device tree system and the bytecode driver system—plus ELF provide a truly universal boot protocol for 32-bit and larger systems. And not only that, major and tractable implementations are now Open Source too, including things like the bytecode compilers. It’s practically unconscionable that modern ARM and RISC-V don’t simply require Open Firmware boot support.
    - snvzz 4y ago
      In RISC-V, the boot model is standarized. There's SBI (from years ago, where the open implementation opensbi is used by most boards) and UEFI (implemented not in any random way, but after SBI runs, and as per the spec published earlier this year). All the pieces are in place for RISC-V to effectively dodge boot chaos. Way before the server/workstation RISC-V hardware hit the market. In ARM, it's a mess. Because ARM took way too long to do way too little re: boot standardization.
      - raxxorraxor 4y ago
        You also have to look at ARMs largest customers. This influences development and the most prominent aren't necessarily interested in ARM becoming a more open platform. Which it fundamentally isn't just as x86.
- THENATHE 4y ago
  It is wildly easier to get a mouse to tell the operating system first off that it is a mouse, than it is for the operating system to analyze the mouse and make that determination for itself. Imagine scaling that up to GPUs! The device needs to describe itself because IT is unique.
  - mlindner 4y ago
    In fact the mouse doesn't tell the operating system that it's a mouse. The operating system reads that off as part of the hardware USB handshake what the device is. USB is an example of a system done largely correctly as compared to all the other processors embedded into a SoC.
    - stefan_ 4y ago
      Based on USB descriptors filled out by the mouse vendor and sent by the mouse. Thanks for playing.
    - 95014_refugee 4y ago
      This is perhaps the first time I've heard "USB" and "correctly" in a clause without a negative. I encourage you to spend more time with it. Meet your hero. Get to know it. Understanding will surely follow. 8)
catiopatio 4y ago
Historically, OpenFirmware provided exactly what you were asking for — self-describing devices, device driver methods hanging off the device nodes, and portable, architecture-independent bytecode-based option ROM drivers on expansion cards. Devicetree is a paired down version of OF; they retained the tree containing key/value device metadata, and dropped all the good bits.
- tremon 4y ago
  How are architecture-independent bytecode-based option ROM drivers the good bits in the context of open source systems?
  - catiopatio 4y ago
    You could ship bootable PCI cards that worked on any OF-capable architecture. Open source doesn’t mean not shipping binaries.
  - vetinari 4y ago
    It was Forth bytecode; the disassembly was pretty readable, without any fancy tools, straight from the OF console (at least on PPC Macs).
    - anthk 4y ago
      I wonder if anyone could implement an OF binary for the Z-Machine. Can OF read files? I mean, not just booting them into memory at $ADDRESS, but read/parse them. I know a Tetris it's doable.
  - eschaton 4y ago
    How are they NOT the BEST bits? With Open Firmware you can build Open Source systems that boot on hardware that you’ve not only never seen but never will see. Open Firmware + ELF can still be our future if we embrace it.
    - calvin_ 4y ago
userbinator 4y ago
so it doesn't seem installing Windows/Linux is going to be as easy on ARM as on x86 anytime soon. From firsthand experience, I can say that at least installing Linux on a UEFI ARM system of the type that QEMU emulates was surprisingly straightforward, and even the ARM version of Windows seemed to detect the virtual hardware just fine. ...and I say this as someone who has worked on the PC platform for over 3 decades, and am a fan of the original BIOS. UEFI is a bloated mess, but it's better than nothing.
- mort96 4y ago
  But most ARM hardware aren't "UEFI ARM system[s] of the type that QEMU emulates", which is the problem.
  - mappu 4y ago
    Most ARM hardware is cellphones, raspberry pi and the Mac M1, which certainly aren't that type. But a lot of ARM hardware is that type. The keywords are SBSA / SBBR / SystemReady. If your hardware is SBBR compatible then Fedora and Ubuntu's ARM64 iso, and Windows ARM64, downloaded from their website, will at least boot fine (drivers are a different question as always). There's a good list of supported hardware in the lower half of https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-systemready-reach-50 https://community.arm.com/arm-community-blogs/b/architecture... . Many systems from Avantek, Gigabyte, NXP, Marvell, Solidrun etc are standardizing on this way of booting. DeviceTree is low-level enough that you can implement UEFI on top of it. There's a UEFI port for the Raspberry Pi 4 at https://rpi4-uefi.dev/ https://rpi4-uefi.dev/ that produces an SBBR layer, allowing it to boot any off-the-shelf ARM64 SBBR distro.
    - deleted 4y ago
      [deleted]
- bcantrill 4y ago
  I think it can be fairly said that the thesis of the talk is that UEFI is not, in fact, better than nothing -- and that in a literal sense, having nothing (along with a well-documented part!) is vastly preferable to UEFI.
Roark66 4y ago
>Having worked with devicetrees and hated it, I don't like this idea. I don't like the modern world of ARM and embedded where you have hardcoded firmware images for every single device. I like the x86 model, where you have a one size fits all boot disk which just loads different drivers. You don't port your OS to a new computer, you just write drivers for the new hardware parts. And your hardware describes itself to the OS. Having worked with ARM too I have to disagree. I found device trees really flexible and easy to get going. However, I worked with Rockchip hardware so I had pretty good documentation, lots of examples, and source code for everything(for an old linux kernel, but still). This basically ensured I could do everything I wanted. Of course, when a vendor doesn't provide documentation and example driver source this may not be so easy.
- xani_ 4y ago
  > Having worked with ARM too I have to disagree. I found device trees really flexible and easy to get going. ... as opposed to not having to "get it going at all"?
  - Roark66 4y ago
    Well, As opposed to having to plug register addresses directly into C code. That's the alternative, isn't it?
- koprulusector 4y ago
  I’ve been struggling with Rockchip! Do you have any links to the docs you’ve used? The ones I have found for the rock pi n10 on radxa’s site are very incomplete.
  - Roark66 4y ago
    Yes, but all my docs are for rk3566, pine's Quartz64-A and soquartz boards. Radxa uses the same chip in few places, but I'm not sure if the board schematics will be of any use to you. If this is the chip you need info for let me know by replying to this message and I'll do a pastebin listing the docs I have. Everything I have came from 3 sources. There is a Linux BSP SDK file (36GB or so) and an Android SDK (75gb or so). Both have docs folders with lots of docs documenting various sdks (for the gpu, npu, camera etc). Those files also contain drivers source for old linux kernels that can be adapted to newer ones with a bit of work. Both are linked on pine's wiki under soquartz. Just Google soquartz pine wiki. The third resource is just two parts of rk3568 TRM(same as rk3566) . They are here: https://github.com/heitbaum/rk3568/tree/main/doc https://github.com/heitbaum/rk3568/tree/main/doc
koprulusector 4y ago
100% agree. It’s soooo painful messing with device trees and building a boot image. I’ve got a rock pi n10 for which I’ve been struggling to compile a newer kernel image that works (the device vendor has only published Linux ISOs up to buster). The whole process is so weird and rough, working with u-boot and ARM Trusted firmware, device trees, etc. it’s like a 20 step process to go through. Installing Gentoo for the first time is 10x easier, in my opinion.
- csande17 4y ago
  I too have found installing Gentoo to be way easier than building a working image for an ARM development board. I think a lot of that is due to Gentoo having better documentation and tools, though. Then again, part of the reason Gentoo can write good documentation is because every x86_64 computer works pretty much the same way!
garaetjjte 4y ago
>where you have a one size fits all boot disk which just loads different drivers But that's exactly the point of device trees. You should be able to use generic ARM kernel build, and it loads appropriate drivers based on dtb provided by system firmware.
- tadfisher 4y ago
  Then why does every permutation of every supported ARM-based product have a dtb checked in to the kernel source?
  - mappu 4y ago
    They're usually also in U-boot in ROM. The trees in the kernel override the platform's one because the kernel is newer and knows better. ACPI on x86 works the same way - it's in ROM but the OS doesn't necessarily use it blindly, it has plenty of quirks to interpret it with.
cryptonector 4y ago
A happy medium might involve something like a BIOS that's just a vendor-provided library in an EEPROM but which somehow is guaranteed not to run anything in hidden cores, BMCs, or via interrupts that the OS does not set up. Even then, it would be even better if that library were open source that the OS could carry its own artifacts of. Not because open source is great, but so the OS can truly be in control. The point u/bcantrill makes about the OS not getting DRAM error information gives me cold sweats! If the library is open source, then, yes, each boot loader and kernel will have to be built for the hardware it will boot on, at least until it gets far enough to get additional firmware/drivers from a boot image RAM disk or whatever.
95014_refugee 4y ago
> I like the x86 model, where you have a one size fits all boot disk which just loads different drivers. This is not "the x86 model". This is the "Microsoft refuses to support anything" model. It is dead, and good f*ing riddance.
- ignaloidas 4y ago
  > This is the "Microsoft refuses to support anything" model. It's rather "Everyone wants to boot Windows, and Microsoft can't be bothered to deal with everyone" model.
occamrazor 4y ago
I may be completely wrong, but I remember reading that Apple M1/M2 computers use a similar approach, with a minimal firmware in the boot image and the rest loaded with the OS.
- ignaloidas 4y ago
  Not really. The list of firmware is lengthy, and most of it is loaded by the bootloader. Though some is indeed loaded by the OS. https://github.com/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon#firmware-overview https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
als0 4y ago
> Unfortunately, UEFI/ACPI or simliar seems to be going nowhere in the ARM world What do you mean by that? Every ARM server has UEFI/ACPI, and it's now looking like every new PC using ARM will include it out of the box. The Google Pixel smartphones use UEFI. There are even UEFI images for Raspberry Pi 4. Sure, the embedded space is probably going to be holding out for a while longer, but seems disingenuous to say UEFI is going nowhere in the ARM world.
- captainmuon 4y ago
  True, but most of todays SBCs and phones don't support UEFI. If you look at SBSA, it has server in the name. You should be able to put vanilla Ubuntu on a SD card and pop it into a computer and get at least the basic features working. Instead, now you have the choice between opaque firmware images from the vendor (with an ancient kernel, and random additions to userspace), or building your own images with a lot of tinkering.
  - als0 4y ago
    > If you look at SBSA, it has server in the name. There is now a generic BSA https://developer.arm.com/documentation/den0094/latest https://developer.arm.com/documentation/den0094/latest (not server specific)
mfuzzey 4y ago
The problem isn't with device trees. And actually, ACPI is just like DT really (but more complicated because it has "methods" in addition to just properties). The difference is that you don't see it so much because the PC vendor has already written the ACPI tables. The major difference on X86 is that it is (for historical reasons) much more standardised at the hardware level than on ARM (at least on embedded ARM, there is more standardisation in the ARM server space). It also makes more use of discoverable busses like USB and PCI so the parts that need to be described in ACPI are smaller than the parts that have to be described in DT on ARM (as much is either "implicitly standardised" or on a discoverable bus). And that is because all PCs are basically the same whereas there is a huge variety in ARM SoC hardware and boards, mostly for understandable reasons (there are a huge variety of use cases and price points in embedded systems). If you were to build an embedded X86 system not using a PC architecture (North bridge, South bridege etc) but using the processor and your own design you would have exactly the same problem. That said you don't have to have "hardcoded firmware images for every single device" in the embedded ARM world. I build an in house BSP for a product family of ~15 devices based on 3 different SoCs and we have a single kernel and userspace (Debian based) for all of them. All the DTs are on the boot partition and the bootloader selects the right one based on hardware information (typically a small EEPROM). The only part that has to be different is the bootloader itself (and then not different for every device but for each SoC) - so we have 3 bootloaders all supplied as part of the BSP and when building the install media we say which one to write. Even that, in theory, could be avoided, at least on SoCs with the same ISA by improving u-boot a bit to make stuff like clocks configurable from data (the u-boot device tree) like the kernel already does. This may one day be possible once u-boot completely adopts the driver model.

mlindner 4y ago

You realize that you're just moving the ball around on who provides what, right? Someone has to write that software that "describes itself to the OS" and rather than having the hardware describe itself to the OS, why can't the OS itself determine what hardware it has? That "describes itself to the OS" part is actually often being done by a complete OS as well. > Unfortunately, UEFI/ACPI or simliar seems to be going nowhere in the ARM world, so it doesn't seem installing Windows/Linux is going to be as easy on ARM as on x86 anytime soon. That's a really good thing. Bryan rants about ARM trying to go that way and thinks it's a terrible idea. I'm glad it's failing, assuming that's actually the case.

gjsman-1000 4y ago
> Bryan rants about ARM trying to go that way and thinks it's a terrible idea. I'm glad it's failing, assuming that's actually the case. I'd be curious why because the PC model seems to be way more user-friendly, competition-friendly, and long-term-reliable than the current ARM model. I wish I could just download an ISO of Android 13 and install it on almost any Android phone like I could Windows.
- mlindner 4y ago
  Well it's in the talk, he spends considerable time on the subject in fact. I suggest taking a watch.
- eschaton 4y ago
  The PC model worked because a lot of people put a lot of blood sweat and tears into making it work and then embraced the sunk cost fallacy to a degree only previously seen in politics and religion. Open Firmware—between the device tree system and the bytecode driver system—plus ELF provide a truly universal boot protocol for 32-bit and larger systems. And not only that, major and tractable implementations are now Open Source too, including things like the bytecode compilers. It’s practically unconscionable that modern ARM and RISC-V don’t simply require Open Firmware boot support.
  - snvzz 4y ago
    In RISC-V, the boot model is standarized. There's SBI (from years ago, where the open implementation opensbi is used by most boards) and UEFI (implemented not in any random way, but after SBI runs, and as per the spec published earlier this year). All the pieces are in place for RISC-V to effectively dodge boot chaos. Way before the server/workstation RISC-V hardware hit the market. In ARM, it's a mess. Because ARM took way too long to do way too little re: boot standardization.
    - raxxorraxor 4y ago
      You also have to look at ARMs largest customers. This influences development and the most prominent aren't necessarily interested in ARM becoming a more open platform. Which it fundamentally isn't just as x86.
THENATHE 4y ago
It is wildly easier to get a mouse to tell the operating system first off that it is a mouse, than it is for the operating system to analyze the mouse and make that determination for itself. Imagine scaling that up to GPUs! The device needs to describe itself because IT is unique.
- mlindner 4y ago
  In fact the mouse doesn't tell the operating system that it's a mouse. The operating system reads that off as part of the hardware USB handshake what the device is. USB is an example of a system done largely correctly as compared to all the other processors embedded into a SoC.
  - stefan_ 4y ago
    Based on USB descriptors filled out by the mouse vendor and sent by the mouse. Thanks for playing.
  - 95014_refugee 4y ago
    This is perhaps the first time I've heard "USB" and "correctly" in a clause without a negative. I encourage you to spend more time with it. Meet your hero. Get to know it. Understanding will surely follow. 8)

catiopatio 4y ago

Historically, OpenFirmware provided exactly what you were asking for — self-describing devices, device driver methods hanging off the device nodes, and portable, architecture-independent bytecode-based option ROM drivers on expansion cards. Devicetree is a paired down version of OF; they retained the tree containing key/value device metadata, and dropped all the good bits.

tremon 4y ago
How are architecture-independent bytecode-based option ROM drivers the good bits in the context of open source systems?
- catiopatio 4y ago
  You could ship bootable PCI cards that worked on any OF-capable architecture. Open source doesn’t mean not shipping binaries.
- vetinari 4y ago
  It was Forth bytecode; the disassembly was pretty readable, without any fancy tools, straight from the OF console (at least on PPC Macs).
  - anthk 4y ago
    I wonder if anyone could implement an OF binary for the Z-Machine. Can OF read files? I mean, not just booting them into memory at $ADDRESS, but read/parse them. I know a Tetris it's doable.
- eschaton 4y ago
  How are they NOT the BEST bits? With Open Firmware you can build Open Source systems that boot on hardware that you’ve not only never seen but never will see. Open Firmware + ELF can still be our future if we embrace it.
  - calvin_ 4y ago

userbinator 4y ago

so it doesn't seem installing Windows/Linux is going to be as easy on ARM as on x86 anytime soon. From firsthand experience, I can say that at least installing Linux on a UEFI ARM system of the type that QEMU emulates was surprisingly straightforward, and even the ARM version of Windows seemed to detect the virtual hardware just fine. ...and I say this as someone who has worked on the PC platform for over 3 decades, and am a fan of the original BIOS. UEFI is a bloated mess, but it's better than nothing.

mort96 4y ago
But most ARM hardware aren't "UEFI ARM system[s] of the type that QEMU emulates", which is the problem.
- mappu 4y ago
  Most ARM hardware is cellphones, raspberry pi and the Mac M1, which certainly aren't that type. But a lot of ARM hardware is that type. The keywords are SBSA / SBBR / SystemReady. If your hardware is SBBR compatible then Fedora and Ubuntu's ARM64 iso, and Windows ARM64, downloaded from their website, will at least boot fine (drivers are a different question as always). There's a good list of supported hardware in the lower half of https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-systemready-reach-50 https://community.arm.com/arm-community-blogs/b/architecture... . Many systems from Avantek, Gigabyte, NXP, Marvell, Solidrun etc are standardizing on this way of booting. DeviceTree is low-level enough that you can implement UEFI on top of it. There's a UEFI port for the Raspberry Pi 4 at https://rpi4-uefi.dev/ https://rpi4-uefi.dev/ that produces an SBBR layer, allowing it to boot any off-the-shelf ARM64 SBBR distro.
  - deleted 4y ago
    [deleted]
bcantrill 4y ago
I think it can be fairly said that the thesis of the talk is that UEFI is not, in fact, better than nothing -- and that in a literal sense, having nothing (along with a well-documented part!) is vastly preferable to UEFI.

Roark66 4y ago

>Having worked with devicetrees and hated it, I don't like this idea. I don't like the modern world of ARM and embedded where you have hardcoded firmware images for every single device. I like the x86 model, where you have a one size fits all boot disk which just loads different drivers. You don't port your OS to a new computer, you just write drivers for the new hardware parts. And your hardware describes itself to the OS. Having worked with ARM too I have to disagree. I found device trees really flexible and easy to get going. However, I worked with Rockchip hardware so I had pretty good documentation, lots of examples, and source code for everything(for an old linux kernel, but still). This basically ensured I could do everything I wanted. Of course, when a vendor doesn't provide documentation and example driver source this may not be so easy.

xani_ 4y ago
> Having worked with ARM too I have to disagree. I found device trees really flexible and easy to get going. ... as opposed to not having to "get it going at all"?
- Roark66 4y ago
  Well, As opposed to having to plug register addresses directly into C code. That's the alternative, isn't it?
koprulusector 4y ago
I’ve been struggling with Rockchip! Do you have any links to the docs you’ve used? The ones I have found for the rock pi n10 on radxa’s site are very incomplete.
- Roark66 4y ago
  Yes, but all my docs are for rk3566, pine's Quartz64-A and soquartz boards. Radxa uses the same chip in few places, but I'm not sure if the board schematics will be of any use to you. If this is the chip you need info for let me know by replying to this message and I'll do a pastebin listing the docs I have. Everything I have came from 3 sources. There is a Linux BSP SDK file (36GB or so) and an Android SDK (75gb or so). Both have docs folders with lots of docs documenting various sdks (for the gpu, npu, camera etc). Those files also contain drivers source for old linux kernels that can be adapted to newer ones with a bit of work. Both are linked on pine's wiki under soquartz. Just Google soquartz pine wiki. The third resource is just two parts of rk3568 TRM(same as rk3566) . They are here: https://github.com/heitbaum/rk3568/tree/main/doc https://github.com/heitbaum/rk3568/tree/main/doc

koprulusector 4y ago

100% agree. It’s soooo painful messing with device trees and building a boot image. I’ve got a rock pi n10 for which I’ve been struggling to compile a newer kernel image that works (the device vendor has only published Linux ISOs up to buster). The whole process is so weird and rough, working with u-boot and ARM Trusted firmware, device trees, etc. it’s like a 20 step process to go through. Installing Gentoo for the first time is 10x easier, in my opinion.

csande17 4y ago
I too have found installing Gentoo to be way easier than building a working image for an ARM development board. I think a lot of that is due to Gentoo having better documentation and tools, though. Then again, part of the reason Gentoo can write good documentation is because every x86_64 computer works pretty much the same way!

garaetjjte 4y ago

>where you have a one size fits all boot disk which just loads different drivers But that's exactly the point of device trees. You should be able to use generic ARM kernel build, and it loads appropriate drivers based on dtb provided by system firmware.

tadfisher 4y ago
Then why does every permutation of every supported ARM-based product have a dtb checked in to the kernel source?
- mappu 4y ago
  They're usually also in U-boot in ROM. The trees in the kernel override the platform's one because the kernel is newer and knows better. ACPI on x86 works the same way - it's in ROM but the OS doesn't necessarily use it blindly, it has plenty of quirks to interpret it with.

cryptonector 4y ago

A happy medium might involve something like a BIOS that's just a vendor-provided library in an EEPROM but which somehow is guaranteed not to run anything in hidden cores, BMCs, or via interrupts that the OS does not set up. Even then, it would be even better if that library were open source that the OS could carry its own artifacts of. Not because open source is great, but so the OS can truly be in control. The point u/bcantrill makes about the OS not getting DRAM error information gives me cold sweats! If the library is open source, then, yes, each boot loader and kernel will have to be built for the hardware it will boot on, at least until it gets far enough to get additional firmware/drivers from a boot image RAM disk or whatever.

95014_refugee 4y ago

> I like the x86 model, where you have a one size fits all boot disk which just loads different drivers. This is not "the x86 model". This is the "Microsoft refuses to support anything" model. It is dead, and good f*ing riddance.

ignaloidas 4y ago
> This is the "Microsoft refuses to support anything" model. It's rather "Everyone wants to boot Windows, and Microsoft can't be bothered to deal with everyone" model.

occamrazor 4y ago

I may be completely wrong, but I remember reading that Apple M1/M2 computers use a similar approach, with a minimal firmware in the boot image and the rest loaded with the OS.

ignaloidas 4y ago
Not really. The list of firmware is lengthy, and most of it is loaded by the bootloader. Though some is indeed loaded by the OS. https://github.com/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon#firmware-overview https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...

als0 4y ago

> Unfortunately, UEFI/ACPI or simliar seems to be going nowhere in the ARM world What do you mean by that? Every ARM server has UEFI/ACPI, and it's now looking like every new PC using ARM will include it out of the box. The Google Pixel smartphones use UEFI. There are even UEFI images for Raspberry Pi 4. Sure, the embedded space is probably going to be holding out for a while longer, but seems disingenuous to say UEFI is going nowhere in the ARM world.

captainmuon 4y ago
True, but most of todays SBCs and phones don't support UEFI. If you look at SBSA, it has server in the name. You should be able to put vanilla Ubuntu on a SD card and pop it into a computer and get at least the basic features working. Instead, now you have the choice between opaque firmware images from the vendor (with an ancient kernel, and random additions to userspace), or building your own images with a lot of tinkering.
- als0 4y ago
  > If you look at SBSA, it has server in the name. There is now a generic BSA https://developer.arm.com/documentation/den0094/latest https://developer.arm.com/documentation/den0094/latest (not server specific)

mfuzzey 4y ago

The problem isn't with device trees. And actually, ACPI is just like DT really (but more complicated because it has "methods" in addition to just properties). The difference is that you don't see it so much because the PC vendor has already written the ACPI tables. The major difference on X86 is that it is (for historical reasons) much more standardised at the hardware level than on ARM (at least on embedded ARM, there is more standardisation in the ARM server space). It also makes more use of discoverable busses like USB and PCI so the parts that need to be described in ACPI are smaller than the parts that have to be described in DT on ARM (as much is either "implicitly standardised" or on a discoverable bus). And that is because all PCs are basically the same whereas there is a huge variety in ARM SoC hardware and boards, mostly for understandable reasons (there are a huge variety of use cases and price points in embedded systems). If you were to build an embedded X86 system not using a PC architecture (North bridge, South bridege etc) but using the processor and your own design you would have exactly the same problem. That said you don't have to have "hardcoded firmware images for every single device" in the embedded ARM world. I build an in house BSP for a product family of ~15 devices based on 3 different SoCs and we have a single kernel and userspace (Debian based) for all of them. All the DTs are on the boot partition and the bootloader selects the right one based on hardware information (typically a small EEPROM). The only part that has to be different is the bootloader itself (and then not different for every device but for each SoC) - so we have 3 bootloaders all supplied as part of the BSP and when building the install media we say which one to write. Even that, in theory, could be avoided, at least on SoCs with the same ISA by improving u-boot a bit to make stuff like clocks configurable from data (the u-boot device tree) like the kernel already does. This may one day be possible once u-boot completely adopts the driver model.