You must log in or register to comment.
Why is this LLM trying to teach me about acyclic graphs in the middle of an article about Linux platform support?
On regular x86 laptops, this mapping is already present in the UEFI firmware, described as ACPI tables. ACPI, which stands for Advanced Configuration and Power Interface, is an open standard that some firmware implementations use to advertise the devices that are part of the system to the operating system through a key-value data structure called “ACPI tables”. At boot, when the operating system detects ACPI tables, it reads them to enumerate the hardware devices and allow the various drivers and kernel modules to interact with all compatible discovered devices.
Why doesn’t Quallcomm have this? Seems like a major oversight. Kinda weird that they don’t have ACPI. It’s an open standard…
ETA: Sorry I was wrong. ACPI doesnt solve this*. Arm SystemReady SR/ES does and its why Ampere cpus can boot on linux on release without too much work.
Sadly its currently only used for iot/server stuff but hopefully it will eventually make its way to consumer tech. We need to raise awareness on this and pressure companies to commit to this standard.
*From what I read, WoA has full ACPI support but qcoms ACPI apis only work on Windows. [1 (ms link)][2]
Yeah its really unfortunate that most arm chips/devices use DTs instead of conforming to ACPI. However with ARM becoming more prominent on servers (and desktops), Im hoping this changes. There is now a push for ACPI on Arm since thats what companies running Arm on servers want. Ampere server cpus eg have ACPI support and arm now has docs on ACPI. I hope qualcomm is also forced to support ACPI. I think they will have to do it if they want to see their cpus being used in data centers and the like.I think x86 is basically the only platform that’s used ACPI, other hardware usually ships a fixed hardware list in firmware that the bootloader/kernel can read (Since it’s not like the motherboards are modular, e.g. the RTC is never going to randomly be connected to a different controller)
Historically ARM didn’t even do that, it was mostly used in tightly linked systems so you’d just build those assumptions into the software itself (e.g. a Gameboy always has a directional pad on specific pins, so you just read those pins directly) I remember the early days of the Raspberry Pi involved device dependent kernel images because they had to code the specific initialisation routines into the drivers, it took a while for them to gain “device tree” support so you could have a generic kernel.
I think x86 is basically the only platform that’s used ACPI
ARM and x86. From wikipedia:
Revision 5.0 of the ACPI specification was released in December 2011,[15] which added the ARM architecture support.
2011? That’s basically last week right?
Support for it (and UEFI ) came with their push into servers, they were forced to make the platform a lot less special and more general purpose like x86 traditionally has been.
End user facing hardware is a different matter though, like I know you can boot the Raspberry Pi via UEFI/ACPI (It builds the ACPI tables in the bootloader), but then Apple doesn’t use it at all for their ARM hardware and it uses something closer to a modern OpenFirmware.
