6 ms·

In the end none of that really matters, as evidenced by the PFTF* bringing it into compliance with the relevant standards. The UEFI/ACPI stack is sufficiently a

In the end none of that really matters, as evidenced by the PFTF* bringing it into compliance with the relevant standards. The UEFI/ACPI stack is sufficiently abstract that it has allowed x86 to evolve and scale from little embedded devices like the atomic pi, to HP superdomes using the same basic OS for a couple decades. So the low level boot mechanisms on Arm SBC's don't really matter because they are just used to boot a SBC specific UEFI image. The UEFI image then provides a standard mechanism for booting your OS of choice. The fact its taken 15+ years for the arm ecosystem to notice this, might be an interesting thing to study. * https://github.com/pftf https://github.com/pftf (SBBR-compliant (UEFI+ACPI) AArch64 firmware for the Raspberry Pi)

monocasa 6y ago
It's more complex than that. One of the major reasons why there isn't a universal ARM standard of booting is that once you've gained control of execution, now you just have a bunch more per SoC work that needs to happen in the kernel compared to x86. ARM is simply far far far more heterogeneous on much deeper levels than x86-pc. "Well, ARM just should be more standardized on it's hardware interface then", is a common refrain I hear then, but that's just nerfing a major benefit of ARM in the first place. It's a strategic advantage that it didn't have it's own set of legacy cruft or an extremely heavyweight interface to everything like PCI is.
- StillBored 6y ago
  Well neither did x86 back in the < 486 days, but ACPI, PCI and USB were developed in response to exploding complexity of systems that needed to have their machines described in config.sys and autoexec.bat files with matching user set PIO/MMIO/DMA/IRQ jumpers set. So, at this point arm machines have shown that everyone doing their own thing just creates giant piles of DT cruft and the associated mess in the kernel as each SoC designer thinks they have the one true way to do interrupts, or whatever other portion of the SoC one chooses to look at. Hence the standards dictate the use of arm compatible GIC's and the like. Its also a large part of why many IoT like devices get updates for a year or two, then get dropped as the maintenance burden of all these custom devices/etc gets too great. Also, much of the work (like pinmuxing/clock mgmt/etc) is completely redundant if the firmware configures it. That is is part of the abstraction. edit: At this point, time to market is a more important metric than saving a few thousand transistors failing to provide standard machine autodetection/etc logic.
  - monocasa 6y ago
    Right, but that solution ('make the hardware more complex, because who cares when it's all to support literally the fastest CPU cores you can buy') comes with a different cost tradeoff. Other than servers, ARM isn't really in the same niche that can handle that additional gate/licensing cost to paper over the differences. And quite frankly, ARM's standards that you've given the example of "just buy more ARM IP blocks" feel more like a cash grab on ARM's part than a real attempt at a standard. "Just pay us for a GIC, and implementing a GIC interface yourself or buying from someone else will probably have our lawyers calling you" is not a real solution in the cost conscious space like SBCs. Response to edit: ACPI doesn't make time to market any better, and they'll just phone it in there too. I think the ACPI tables of the PS4 would crash Linux if you try to boot without going in and manually editing them because they cared about time to market and only booting their OS on their hardware.
  - qbasic_forever 6y ago
    Everything has changed though, no longer do you have your beige-box 486 connected to a totally different brand mouse over a serial connection. You have your ARM SOC on a phone or tablet talking to the touchscreen physically glued to the front of said-device. The device manufacturers know exactly what hardware is on and connected to the SOC, and can optimize accordingly. There is very little physical device-interop anymore, and anything still left is talking over higher-level busses (USB) or wireless (BLE). Nothing an end-user has is directly driving interrupt pins to a CPU anymore.
    - StillBored 6y ago
      Has it? What is the difference from the perspective of a generic OS whether the disk controller is provided by BrokenHWCo and plugged into an ISA slot, or its provided by SoCInc and glued to a AXI bus in the SoC? In both cases an engineer has to get involved to describe the address/interrupt/configuration mechanism to the OS, and likely provide a driver or set of tweaks for every single OS in existence that might ever run on the platform. The point of the standardization is that SoCInc adds a device that behaves like one of the standard device in the ecosystem (say NVMe, AHCI or SDHCI for a disk) does the low level platform specific configuration in the firmware and hands the OS something that looks to be a standard PCI, ACPI, USB, or whatever device. Then it can boot one of the dozen OS's or hypervisors the end customer might be interested in using the drivers they already have built in. The onboard mgmt processor then does all the realtime power/perf monitoring in response to course grained OS/ACPI requests and custom code which is aware of SoC specific load/bus utilization/thermal/etc values. So, all this ends up being an engineering tradeoff, is it worth while to attempt to cram ones application into a ESP8266 (its after-all quite capable and has excellent wifi/web style interfaces built in) or run a full blown linux kernel/etc. By the time your running linux, your already talking about a pretty massive system just to get to the capabilities of that ESP8266, so the overhead of these standards is quite trivial. They were after all invented for machines with performance and resource requirements closer to that ESP8266 than anything in the entire Cortex-A line. The choice to dedicate engineers at SocInc to duplicate the efforts of those at Microsoft, or Canonical to shave frontend engineering costs off is likely a very poor choice. As I mentioned above, its probably a large reason why so many IoT and Android devices don't get updates after a year or two. Those engineers are off writing new autoexec.bat files for the latest SoC's. Dedicating them to fixing security holes and bugs in the Os for the next 20 years for every SoC shipped costs a lot of money. There is very nearly 0 value add to hiring an engineer to design an interrupt controller, another to write a driver for every OS in existence for it, and another for 20 years to maintain the result. For what? Lower interrupt latency? To save a thousand transistors or a license fee? If your customer doesn't have some very specific use case for that interrupt controller the value is likely negative.

monocasa 6y ago

It's more complex than that. One of the major reasons why there isn't a universal ARM standard of booting is that once you've gained control of execution, now you just have a bunch more per SoC work that needs to happen in the kernel compared to x86. ARM is simply far far far more heterogeneous on much deeper levels than x86-pc. "Well, ARM just should be more standardized on it's hardware interface then", is a common refrain I hear then, but that's just nerfing a major benefit of ARM in the first place. It's a strategic advantage that it didn't have it's own set of legacy cruft or an extremely heavyweight interface to everything like PCI is.

StillBored 6y ago
Well neither did x86 back in the < 486 days, but ACPI, PCI and USB were developed in response to exploding complexity of systems that needed to have their machines described in config.sys and autoexec.bat files with matching user set PIO/MMIO/DMA/IRQ jumpers set. So, at this point arm machines have shown that everyone doing their own thing just creates giant piles of DT cruft and the associated mess in the kernel as each SoC designer thinks they have the one true way to do interrupts, or whatever other portion of the SoC one chooses to look at. Hence the standards dictate the use of arm compatible GIC's and the like. Its also a large part of why many IoT like devices get updates for a year or two, then get dropped as the maintenance burden of all these custom devices/etc gets too great. Also, much of the work (like pinmuxing/clock mgmt/etc) is completely redundant if the firmware configures it. That is is part of the abstraction. edit: At this point, time to market is a more important metric than saving a few thousand transistors failing to provide standard machine autodetection/etc logic.
- monocasa 6y ago
  Right, but that solution ('make the hardware more complex, because who cares when it's all to support literally the fastest CPU cores you can buy') comes with a different cost tradeoff. Other than servers, ARM isn't really in the same niche that can handle that additional gate/licensing cost to paper over the differences. And quite frankly, ARM's standards that you've given the example of "just buy more ARM IP blocks" feel more like a cash grab on ARM's part than a real attempt at a standard. "Just pay us for a GIC, and implementing a GIC interface yourself or buying from someone else will probably have our lawyers calling you" is not a real solution in the cost conscious space like SBCs. Response to edit: ACPI doesn't make time to market any better, and they'll just phone it in there too. I think the ACPI tables of the PS4 would crash Linux if you try to boot without going in and manually editing them because they cared about time to market and only booting their OS on their hardware.
- qbasic_forever 6y ago
  Everything has changed though, no longer do you have your beige-box 486 connected to a totally different brand mouse over a serial connection. You have your ARM SOC on a phone or tablet talking to the touchscreen physically glued to the front of said-device. The device manufacturers know exactly what hardware is on and connected to the SOC, and can optimize accordingly. There is very little physical device-interop anymore, and anything still left is talking over higher-level busses (USB) or wireless (BLE). Nothing an end-user has is directly driving interrupt pins to a CPU anymore.
  - StillBored 6y ago
    Has it? What is the difference from the perspective of a generic OS whether the disk controller is provided by BrokenHWCo and plugged into an ISA slot, or its provided by SoCInc and glued to a AXI bus in the SoC? In both cases an engineer has to get involved to describe the address/interrupt/configuration mechanism to the OS, and likely provide a driver or set of tweaks for every single OS in existence that might ever run on the platform. The point of the standardization is that SoCInc adds a device that behaves like one of the standard device in the ecosystem (say NVMe, AHCI or SDHCI for a disk) does the low level platform specific configuration in the firmware and hands the OS something that looks to be a standard PCI, ACPI, USB, or whatever device. Then it can boot one of the dozen OS's or hypervisors the end customer might be interested in using the drivers they already have built in. The onboard mgmt processor then does all the realtime power/perf monitoring in response to course grained OS/ACPI requests and custom code which is aware of SoC specific load/bus utilization/thermal/etc values. So, all this ends up being an engineering tradeoff, is it worth while to attempt to cram ones application into a ESP8266 (its after-all quite capable and has excellent wifi/web style interfaces built in) or run a full blown linux kernel/etc. By the time your running linux, your already talking about a pretty massive system just to get to the capabilities of that ESP8266, so the overhead of these standards is quite trivial. They were after all invented for machines with performance and resource requirements closer to that ESP8266 than anything in the entire Cortex-A line. The choice to dedicate engineers at SocInc to duplicate the efforts of those at Microsoft, or Canonical to shave frontend engineering costs off is likely a very poor choice. As I mentioned above, its probably a large reason why so many IoT and Android devices don't get updates after a year or two. Those engineers are off writing new autoexec.bat files for the latest SoC's. Dedicating them to fixing security holes and bugs in the Os for the next 20 years for every SoC shipped costs a lot of money. There is very nearly 0 value add to hiring an engineer to design an interrupt controller, another to write a driver for every OS in existence for it, and another for 20 years to maintain the result. For what? Lower interrupt latency? To save a thousand transistors or a license fee? If your customer doesn't have some very specific use case for that interrupt controller the value is likely negative.