4 ms·

This is a bit disingenuous. The problem is that every soc manufacturer wants custom data to pass to their driver. With ACPI, you need to standardize this data a

This is a bit disingenuous. The problem is that every soc manufacturer wants custom data to pass to their driver. With ACPI, you need to standardize this data and get it published in the yearly spec update. With device tree you just check in your new device tree bindings alongside your driver in the kernel repo. Device Tree blobs are only stable with respect to the kernel version they were built for. It also doesn't have to worry about being OS independent. SoC manufacturers are happy with this arrangement because it lets them iterate quickly. It is a much lower bar with much lower costs compared to ACPI. In recent years, ACPI has started adding support for encoding data which is non standard by allowing key value data, but using that sort of defeats the point. Those fields aren't usually documented and only the driver written for it understands how to interpret that data. Again, that forces ACPI blobs to be versioned alongside drivers. There is completely unlike how x86 works where everything really is standardized and you don't need specific drivers operate every peripheral on the board. Of course even on x86 you can have more specific drivers which are more optimized or expose additional functionality, but generic drivers can an do exist which get you decent support. Beyond device tree/ACPI this means adhering to standardized register layouts and things like that which is completely off the table with arm soc manufacturers.

my123 5y ago
Windows doesn't have that issue on Arm, you can just boot the newest Windows on Arm release on a random SoC from the past that (if it's the same arch of course, 32 bit or 64 bit have different drivers) as long as the work was initially done first. For ACPI, the vendors themselves tend to avoid changing bindings between generations for Windows there. Compounded with a stable driver ABI, things continued to work stably within all of Windows Phone (NT based, 8.0 to 10)'s lifetime, which had security update support until December 2019. Windows RT 8.1 still gets security updates today, and will continue to do so until January 2023. Linux not managing to standardize on a proper driver ABI _or_ stable bindings with the drivers in the kernel tree is just a Linux problem, and doesn't even affect other kernels on the platform, which mandate ACPI or something else. > There is completely unlike how x86 works where everything really is standardized and you don't need specific drivers operate every peripheral on the board Nope, on x86, the meaty bits like the GPU and such do not have a stable register interface or anything remotely near that between generations. :) On Arm systems, the interrupt controller (GICv2/3/4), timer (arch timer, since Cortex-A7/A15), IOMMUs (SMMU) and other standard devices were standardised since ages now (Apple is their own bubble and doesn't apply to this discussion). One of the remaining issues so far is PCIe hardware quirks/erratums, but that's getting solved. But Qualcomm isn't interested in making their Linux drivers work with their ACPI definitions, they are stable between generations on Windows though, and not changed needlessly over there. (which allowed us to work to bring AArch64 Windows on the Lumia 950/950 XL using drivers from other SoCs too)
- google234123 5y ago
  Linux hasnt managed to standardize a proper driver ABI for political reasons - not technical.
- surajrmal 5y ago
  While you cherry picked examples that work for your arguments, I would say that they arent entirely correct. On x86, you can use a bounded number of drivers and boot successfully on a large number of boards. This is because things like buses, storage and display are standardized. This is not true for ARM. Every manufacturer does its own thing. Yes there are bits which have been standardized and shared, but for the most part that's not the case. As a result you cannot really make a single image that boots on a large number of boards without also including a very large number of drivers. Windows phone only ran on a limited number of SOCs, primarily Qualcomm. Also for what it's worth, Qualcomm does update their ACPI definitions between SoC generations. They also fork their drivers to match. If there was a stable driver ABI they could probably do the same on Linux but that's not an option. On server, ARM vendors went the PC route and just adopted standard interfaces used servers (pcie, sata, etc). This is large departure from SoCs targeting phones, tablets, and iot.
  - my123 5y ago
    For QCOM the bindings for the base drivers are stable, and despite them forking drivers, the one for the others generally are - too The biggest concern there is the PEP power management mechanism instead of using what ACPI provides. > This is because things like buses, storage and display are standardized That's a rosy view of x86. Quite some laptops ship with Intel RST set up such as stock Windows wouldn't boot on them before adding that driver. Display (frame buffer) is standardised too as UEFI GOP, but that no longer applies when the GPU driver takes over of course. Storage controllers & USB bindings are standardised too. Doing a Qualcomm driverless boot on those platforms is very much possible, with storage and USB available, enough to install the OS and make it reach the desktop. (and on a side note, as far back as the Snapdragon 810, PCIe was very much used. The Lumia 950 (XL) had their Wi-Fi controller over a PCIe bus.)
908B64B197 5y ago
> SoC manufacturers are happy with this arrangement because it lets them iterate quickly. It is a much lower bar with much lower costs compared to ACPI. You can also get away with ugly hacks and sub par devs. Doesn't matter anyways, you got all the money from selling the SoC, software is an afterthought.

my123 5y ago

Windows doesn't have that issue on Arm, you can just boot the newest Windows on Arm release on a random SoC from the past that (if it's the same arch of course, 32 bit or 64 bit have different drivers) as long as the work was initially done first. For ACPI, the vendors themselves tend to avoid changing bindings between generations for Windows there. Compounded with a stable driver ABI, things continued to work stably within all of Windows Phone (NT based, 8.0 to 10)'s lifetime, which had security update support until December 2019. Windows RT 8.1 still gets security updates today, and will continue to do so until January 2023. Linux not managing to standardize on a proper driver ABI _or_ stable bindings with the drivers in the kernel tree is just a Linux problem, and doesn't even affect other kernels on the platform, which mandate ACPI or something else. > There is completely unlike how x86 works where everything really is standardized and you don't need specific drivers operate every peripheral on the board Nope, on x86, the meaty bits like the GPU and such do not have a stable register interface or anything remotely near that between generations. :) On Arm systems, the interrupt controller (GICv2/3/4), timer (arch timer, since Cortex-A7/A15), IOMMUs (SMMU) and other standard devices were standardised since ages now (Apple is their own bubble and doesn't apply to this discussion). One of the remaining issues so far is PCIe hardware quirks/erratums, but that's getting solved. But Qualcomm isn't interested in making their Linux drivers work with their ACPI definitions, they are stable between generations on Windows though, and not changed needlessly over there. (which allowed us to work to bring AArch64 Windows on the Lumia 950/950 XL using drivers from other SoCs too)

google234123 5y ago
Linux hasnt managed to standardize a proper driver ABI for political reasons - not technical.
surajrmal 5y ago
While you cherry picked examples that work for your arguments, I would say that they arent entirely correct. On x86, you can use a bounded number of drivers and boot successfully on a large number of boards. This is because things like buses, storage and display are standardized. This is not true for ARM. Every manufacturer does its own thing. Yes there are bits which have been standardized and shared, but for the most part that's not the case. As a result you cannot really make a single image that boots on a large number of boards without also including a very large number of drivers. Windows phone only ran on a limited number of SOCs, primarily Qualcomm. Also for what it's worth, Qualcomm does update their ACPI definitions between SoC generations. They also fork their drivers to match. If there was a stable driver ABI they could probably do the same on Linux but that's not an option. On server, ARM vendors went the PC route and just adopted standard interfaces used servers (pcie, sata, etc). This is large departure from SoCs targeting phones, tablets, and iot.
- my123 5y ago
  For QCOM the bindings for the base drivers are stable, and despite them forking drivers, the one for the others generally are - too The biggest concern there is the PEP power management mechanism instead of using what ACPI provides. > This is because things like buses, storage and display are standardized That's a rosy view of x86. Quite some laptops ship with Intel RST set up such as stock Windows wouldn't boot on them before adding that driver. Display (frame buffer) is standardised too as UEFI GOP, but that no longer applies when the GPU driver takes over of course. Storage controllers & USB bindings are standardised too. Doing a Qualcomm driverless boot on those platforms is very much possible, with storage and USB available, enough to install the OS and make it reach the desktop. (and on a side note, as far back as the Snapdragon 810, PCIe was very much used. The Lumia 950 (XL) had their Wi-Fi controller over a PCIe bus.)

908B64B197 5y ago

> SoC manufacturers are happy with this arrangement because it lets them iterate quickly. It is a much lower bar with much lower costs compared to ACPI. You can also get away with ugly hacks and sub par devs. Doesn't matter anyways, you got all the money from selling the SoC, software is an afterthought.