5 ms·

> no ARM equivalent to ACPI The ARM equivalent to ACPI is ACPI. ACPI is not "between the board and CPU", it's "between the OS and the computer". Which is actu

> no ARM equivalent to ACPI The ARM equivalent to ACPI is ACPI. ACPI is not "between the board and CPU", it's "between the OS and the computer". Which is actually much more important. Writing drivers for bespoke PCIe, USB and SATA controllers is not fun. ACPI standardizes configuration of these things.

zozbot234 7y ago
> The ARM equivalent to ACPI is ACPI. But most ARM devices aren't using it - their closest equivalent is the device tree.
- glommer 7y ago
  That is one of the things that Nuvia is promising to change.
- morning_gelato 7y ago
  That's certainly true for ARM devices taken as a whole, but I believe most ARM servers are SBBR and SBSA compliant, which means they do support ACPI.
derefr 7y ago
> ACPI is not "between the board and CPU", it's "between the OS and the computer". Eh, kinda-sorta. ACPI (through the availability of a DSDT in BIOS flash) provides whatever's running on application processors (like CPUs, but also independent coprocessors like mobile baseband processors and server baseboard management controllers) the ability to 1. query "the board" for what's effectively a listing of the available busses, and the devices on those busses; and 2. to initialize those devices with wired address-space regions on those busses, such that nothing conflicts. Now, certainly, ARM boards that have standardized "network-like" peripheral busses like PCIe, USB, or (maybe) SATA, have an ACPI controller on the SoC, to schedule those devices' address-space regions onto those busses. But not all ARM devices have those busses. Some are entirely embedded, with the ARM core serving more of the function of a microcontroller than a true application processor. (There are ARM cores in keyboards and mice!) And some—especially cheap—consumer ARM "platforms" only have busses like SPI and I²C. (You know, like an Arduino!) Even older fully-featured ARM "computers", like smartphones and portable game consoles, didn't support ACPI until very recently, either (which is much of why devices like the 3DS and PSVita didn't support Bluetooth or USB OTG HNP.) In either case, these devices more-often-than-not don't have ACPI controllers, instead "hard-wiring" each peripheral device on the board to a certain address-space range on a certain bus available to the CPU, just like PCs used to do before there were even IRQ jumpers. (One clear example: every Nintendo portable since the GBA was an ARM SoC, but none of them until the Switch have had ACPI. They just had a static IO memory map, that you could program against.) And even those ARM devices that do have an ACPI controller on-board, almost universally don't use it the way that x86 does, where even chipset-specific devices like Platform Controller Hubs get probed and configured by ACPI rather than just sitting statically on a special bus.
- floatboth 7y ago
  We're not talking about embedded devices in a server thread :) I'm not sure what you're calling "an ACPI controller". (You seem to be thinking of MMUs and PICs??) ACPI is a software interface. The tables are the ACPI. It's possible to implement ACPI on a system that originally shipped with U-Boot and Flattened Device Trees. Say, for the Raspberry Pi: https://github.com/tianocore/edk2-platforms/tree/8b72f720d53ee2df22e5d4e2479c6f0d0a870af0/Platform/RaspberryPi/RPi3/AcpiTables https://github.com/tianocore/edk2-platforms/tree/8b72f720d53...

zozbot234 7y ago

> The ARM equivalent to ACPI is ACPI. But most ARM devices aren't using it - their closest equivalent is the device tree.

glommer 7y ago
That is one of the things that Nuvia is promising to change.
morning_gelato 7y ago
That's certainly true for ARM devices taken as a whole, but I believe most ARM servers are SBBR and SBSA compliant, which means they do support ACPI.

derefr 7y ago

> ACPI is not "between the board and CPU", it's "between the OS and the computer". Eh, kinda-sorta. ACPI (through the availability of a DSDT in BIOS flash) provides whatever's running on application processors (like CPUs, but also independent coprocessors like mobile baseband processors and server baseboard management controllers) the ability to 1. query "the board" for what's effectively a listing of the available busses, and the devices on those busses; and 2. to initialize those devices with wired address-space regions on those busses, such that nothing conflicts. Now, certainly, ARM boards that have standardized "network-like" peripheral busses like PCIe, USB, or (maybe) SATA, have an ACPI controller on the SoC, to schedule those devices' address-space regions onto those busses. But not all ARM devices have those busses. Some are entirely embedded, with the ARM core serving more of the function of a microcontroller than a true application processor. (There are ARM cores in keyboards and mice!) And some—especially cheap—consumer ARM "platforms" only have busses like SPI and I²C. (You know, like an Arduino!) Even older fully-featured ARM "computers", like smartphones and portable game consoles, didn't support ACPI until very recently, either (which is much of why devices like the 3DS and PSVita didn't support Bluetooth or USB OTG HNP.) In either case, these devices more-often-than-not don't have ACPI controllers, instead "hard-wiring" each peripheral device on the board to a certain address-space range on a certain bus available to the CPU, just like PCs used to do before there were even IRQ jumpers. (One clear example: every Nintendo portable since the GBA was an ARM SoC, but none of them until the Switch have had ACPI. They just had a static IO memory map, that you could program against.) And even those ARM devices that do have an ACPI controller on-board, almost universally don't use it the way that x86 does, where even chipset-specific devices like Platform Controller Hubs get probed and configured by ACPI rather than just sitting statically on a special bus.

floatboth 7y ago
We're not talking about embedded devices in a server thread :) I'm not sure what you're calling "an ACPI controller". (You seem to be thinking of MMUs and PICs??) ACPI is a software interface. The tables are the ACPI. It's possible to implement ACPI on a system that originally shipped with U-Boot and Flattened Device Trees. Say, for the Raspberry Pi: https://github.com/tianocore/edk2-platforms/tree/8b72f720d53ee2df22e5d4e2479c6f0d0a870af0/Platform/RaspberryPi/RPi3/AcpiTables https://github.com/tianocore/edk2-platforms/tree/8b72f720d53...