123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593 |
- ACPI Tables
- -----------
- The expectations of individual ACPI tables are discussed in the list that
- follows.
- If a section number is used, it refers to a section number in the ACPI
- specification where the object is defined. If "Signature Reserved" is used,
- the table signature (the first four bytes of the table) is the only portion
- of the table recognized by the specification, and the actual table is defined
- outside of the UEFI Forum (see Section 5.2.6 of the specification).
- For ACPI on arm64, tables also fall into the following categories:
- -- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
- -- Recommended: BERT, EINJ, ERST, HEST, SSDT
- -- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST,
- MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI
- -- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS,
- LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
- Table Usage for ARMv8 Linux
- ----- ----------------------------------------------------------------
- BERT Section 18.3 (signature == "BERT")
- == Boot Error Record Table ==
- Must be supplied if RAS support is provided by the platform. It
- is recommended this table be supplied.
- BOOT Signature Reserved (signature == "BOOT")
- == simple BOOT flag table ==
- Microsoft only table, will not be supported.
- BGRT Section 5.2.22 (signature == "BGRT")
- == Boot Graphics Resource Table ==
- Optional, not currently supported, with no real use-case for an
- ARM server.
- CPEP Section 5.2.18 (signature == "CPEP")
- == Corrected Platform Error Polling table ==
- Optional, not currently supported, and not recommended until such
- time as ARM-compatible hardware is available, and the specification
- suitably modified.
- CSRT Signature Reserved (signature == "CSRT")
- == Core System Resources Table ==
- Optional, not currently supported.
- DBG2 Signature Reserved (signature == "DBG2")
- == DeBuG port table 2 ==
- Microsoft only table, will not be supported.
- DBGP Signature Reserved (signature == "DBGP")
- == DeBuG Port table ==
- Microsoft only table, will not be supported.
- DSDT Section 5.2.11.1 (signature == "DSDT")
- == Differentiated System Description Table ==
- A DSDT is required; see also SSDT.
- ACPI tables contain only one DSDT but can contain one or more SSDTs,
- which are optional. Each SSDT can only add to the ACPI namespace,
- but cannot modify or replace anything in the DSDT.
- DMAR Signature Reserved (signature == "DMAR")
- == DMA Remapping table ==
- x86 only table, will not be supported.
- DRTM Signature Reserved (signature == "DRTM")
- == Dynamic Root of Trust for Measurement table ==
- Optional, not currently supported.
- ECDT Section 5.2.16 (signature == "ECDT")
- == Embedded Controller Description Table ==
- Optional, not currently supported, but could be used on ARM if and
- only if one uses the GPE_BIT field to represent an IRQ number, since
- there are no GPE blocks defined in hardware reduced mode. This would
- need to be modified in the ACPI specification.
- EINJ Section 18.6 (signature == "EINJ")
- == Error Injection table ==
- This table is very useful for testing platform response to error
- conditions; it allows one to inject an error into the system as
- if it had actually occurred. However, this table should not be
- shipped with a production system; it should be dynamically loaded
- and executed with the ACPICA tools only during testing.
- ERST Section 18.5 (signature == "ERST")
- == Error Record Serialization Table ==
- On a platform supports RAS, this table must be supplied if it is not
- UEFI-based; if it is UEFI-based, this table may be supplied. When this
- table is not present, UEFI run time service will be utilized to save
- and retrieve hardware error information to and from a persistent store.
- ETDT Signature Reserved (signature == "ETDT")
- == Event Timer Description Table ==
- Obsolete table, will not be supported.
- FACS Section 5.2.10 (signature == "FACS")
- == Firmware ACPI Control Structure ==
- It is unlikely that this table will be terribly useful. If it is
- provided, the Global Lock will NOT be used since it is not part of
- the hardware reduced profile, and only 64-bit address fields will
- be considered valid.
- FADT Section 5.2.9 (signature == "FACP")
- == Fixed ACPI Description Table ==
- Required for arm64.
- The HW_REDUCED_ACPI flag must be set. All of the fields that are
- to be ignored when HW_REDUCED_ACPI is set are expected to be set to
- zero.
- If an FACS table is provided, the X_FIRMWARE_CTRL field is to be
- used, not FIRMWARE_CTRL.
- If PSCI is used (as is recommended), make sure that ARM_BOOT_ARCH is
- filled in properly -- that the PSCI_COMPLIANT flag is set and that
- PSCI_USE_HVC is set or unset as needed (see table 5-37).
- For the DSDT that is also required, the X_DSDT field is to be used,
- not the DSDT field.
- FPDT Section 5.2.23 (signature == "FPDT")
- == Firmware Performance Data Table ==
- Optional, not currently supported.
- GTDT Section 5.2.24 (signature == "GTDT")
- == Generic Timer Description Table ==
- Required for arm64.
- HEST Section 18.3.2 (signature == "HEST")
- == Hardware Error Source Table ==
- Until further error source types are defined, use only types 6 (AER
- Root Port), 7 (AER Endpoint), 8 (AER Bridge), or 9 (Generic Hardware
- Error Source). Firmware first error handling is possible if and only
- if Trusted Firmware is being used on arm64.
- Must be supplied if RAS support is provided by the platform. It
- is recommended this table be supplied.
- HPET Signature Reserved (signature == "HPET")
- == High Precision Event timer Table ==
- x86 only table, will not be supported.
- IBFT Signature Reserved (signature == "IBFT")
- == iSCSI Boot Firmware Table ==
- Microsoft defined table, support TBD.
- IVRS Signature Reserved (signature == "IVRS")
- == I/O Virtualization Reporting Structure ==
- x86_64 (AMD) only table, will not be supported.
- LPIT Signature Reserved (signature == "LPIT")
- == Low Power Idle Table ==
- x86 only table as of ACPI 5.1; future versions have been adapted for
- use with ARM and will be recommended in order to support ACPI power
- management.
- MADT Section 5.2.12 (signature == "APIC")
- == Multiple APIC Description Table ==
- Required for arm64. Only the GIC interrupt controller structures
- should be used (types 0xA - 0xE).
- MCFG Signature Reserved (signature == "MCFG")
- == Memory-mapped ConFiGuration space ==
- If the platform supports PCI/PCIe, an MCFG table is required.
- MCHI Signature Reserved (signature == "MCHI")
- == Management Controller Host Interface table ==
- Optional, not currently supported.
- MPST Section 5.2.21 (signature == "MPST")
- == Memory Power State Table ==
- Optional, not currently supported.
- MSDM Signature Reserved (signature == "MSDM")
- == Microsoft Data Management table ==
- Microsoft only table, will not be supported.
- MSCT Section 5.2.19 (signature == "MSCT")
- == Maximum System Characteristic Table ==
- Optional, not currently supported.
- RASF Section 5.2.20 (signature == "RASF")
- == RAS Feature table ==
- Optional, not currently supported.
- RSDP Section 5.2.5 (signature == "RSD PTR")
- == Root System Description PoinTeR ==
- Required for arm64.
- RSDT Section 5.2.7 (signature == "RSDT")
- == Root System Description Table ==
- Since this table can only provide 32-bit addresses, it is deprecated
- on arm64, and will not be used.
- SBST Section 5.2.14 (signature == "SBST")
- == Smart Battery Subsystem Table ==
- Optional, not currently supported.
- SLIC Signature Reserved (signature == "SLIC")
- == Software LIcensing table ==
- Microsoft only table, will not be supported.
- SLIT Section 5.2.17 (signature == "SLIT")
- == System Locality distance Information Table ==
- Optional in general, but required for NUMA systems.
- SPCR Signature Reserved (signature == "SPCR")
- == Serial Port Console Redirection table ==
- Required for arm64.
- SPMI Signature Reserved (signature == "SPMI")
- == Server Platform Management Interface table ==
- Optional, not currently supported.
- SRAT Section 5.2.16 (signature == "SRAT")
- == System Resource Affinity Table ==
- Optional, but if used, only the GICC Affinity structures are read.
- To support NUMA, this table is required.
- SSDT Section 5.2.11.2 (signature == "SSDT")
- == Secondary System Description Table ==
- These tables are a continuation of the DSDT; these are recommended
- for use with devices that can be added to a running system, but can
- also serve the purpose of dividing up device descriptions into more
- manageable pieces.
- An SSDT can only ADD to the ACPI namespace. It cannot modify or
- replace existing device descriptions already in the namespace.
- These tables are optional, however. ACPI tables should contain only
- one DSDT but can contain many SSDTs.
- TCPA Signature Reserved (signature == "TCPA")
- == Trusted Computing Platform Alliance table ==
- Optional, not currently supported, and may need changes to fully
- interoperate with arm64.
- TPM2 Signature Reserved (signature == "TPM2")
- == Trusted Platform Module 2 table ==
- Optional, not currently supported, and may need changes to fully
- interoperate with arm64.
- UEFI Signature Reserved (signature == "UEFI")
- == UEFI ACPI data table ==
- Optional, not currently supported. No known use case for arm64,
- at present.
- WAET Signature Reserved (signature == "WAET")
- == Windows ACPI Emulated devices Table ==
- Microsoft only table, will not be supported.
- WDAT Signature Reserved (signature == "WDAT")
- == Watch Dog Action Table ==
- Microsoft only table, will not be supported.
- WDRT Signature Reserved (signature == "WDRT")
- == Watch Dog Resource Table ==
- Microsoft only table, will not be supported.
- WPBT Signature Reserved (signature == "WPBT")
- == Windows Platform Binary Table ==
- Microsoft only table, will not be supported.
- XSDT Section 5.2.8 (signature == "XSDT")
- == eXtended System Description Table ==
- Required for arm64.
- ACPI Objects
- ------------
- The expectations on individual ACPI objects are discussed in the list that
- follows:
- Name Section Usage for ARMv8 Linux
- ---- ------------ -------------------------------------------------
- _ADR 6.1.1 Use as needed.
- _BBN 6.5.5 Use as needed; PCI-specific.
- _BDN 6.5.3 Optional; not likely to be used on arm64.
- _CCA 6.2.17 This method should be defined for all bus masters
- on arm64. While cache coherency is assumed, making
- it explicit ensures the kernel will set up DMA as
- it should.
- _CDM 6.2.1 Optional, to be used only for processor devices.
- _CID 6.1.2 Use as needed.
- _CLS 6.1.3 Use as needed.
- _CRS 6.2.2 Required on arm64.
- _DCK 6.5.2 Optional; not likely to be used on arm64.
- _DDN 6.1.4 This field can be used for a device name. However,
- it is meant for DOS device names (e.g., COM1), so be
- careful of its use across OSes.
- _DEP 6.5.8 Use as needed.
- _DIS 6.2.3 Optional, for power management use.
- _DLM 5.7.5 Optional.
- _DMA 6.2.4 Optional.
- _DSD 6.2.5 To be used with caution. If this object is used, try
- to use it within the constraints already defined by the
- Device Properties UUID. Only in rare circumstances
- should it be necessary to create a new _DSD UUID.
- In either case, submit the _DSD definition along with
- any driver patches for discussion, especially when
- device properties are used. A driver will not be
- considered complete without a corresponding _DSD
- description. Once approved by kernel maintainers,
- the UUID or device properties must then be registered
- with the UEFI Forum; this may cause some iteration as
- more than one OS will be registering entries.
- _DSM Do not use this method. It is not standardized, the
- return values are not well documented, and it is
- currently a frequent source of error.
- _DSW 7.2.1 Use as needed; power management specific.
- _EDL 6.3.1 Optional.
- _EJD 6.3.2 Optional.
- _EJx 6.3.3 Optional.
- _FIX 6.2.7 x86 specific, not used on arm64.
- \_GL 5.7.1 This object is not to be used in hardware reduced
- mode, and therefore should not be used on arm64.
- _GLK 6.5.7 This object requires a global lock be defined; there
- is no global lock on arm64 since it runs in hardware
- reduced mode. Hence, do not use this object on arm64.
- \_GPE 5.3.1 This namespace is for x86 use only. Do not use it
- on arm64.
- _GSB 6.2.7 Optional.
- _HID 6.1.5 Use as needed. This is the primary object to use in
- device probing, though _CID and _CLS may also be used.
- _HPP 6.2.8 Optional, PCI specific.
- _HPX 6.2.9 Optional, PCI specific.
- _HRV 6.1.6 Optional, use as needed to clarify device behavior; in
- some cases, this may be easier to use than _DSD.
- _INI 6.5.1 Not required, but can be useful in setting up devices
- when UEFI leaves them in a state that may not be what
- the driver expects before it starts probing.
- _IRC 7.2.15 Use as needed; power management specific.
- _LCK 6.3.4 Optional.
- _MAT 6.2.10 Optional; see also the MADT.
- _MLS 6.1.7 Optional, but highly recommended for use in
- internationalization.
- _OFF 7.1.2 It is recommended to define this method for any device
- that can be turned on or off.
- _ON 7.1.3 It is recommended to define this method for any device
- that can be turned on or off.
- \_OS 5.7.3 This method will return "Linux" by default (this is
- the value of the macro ACPI_OS_NAME on Linux). The
- command line parameter acpi_os=<string> can be used
- to set it to some other value.
- _OSC 6.2.11 This method can be a global method in ACPI (i.e.,
- \_SB._OSC), or it may be associated with a specific
- device (e.g., \_SB.DEV0._OSC), or both. When used
- as a global method, only capabilities published in
- the ACPI specification are allowed. When used as
- a device-specific method, the process described for
- using _DSD MUST be used to create an _OSC definition;
- out-of-process use of _OSC is not allowed. That is,
- submit the device-specific _OSC usage description as
- part of the kernel driver submission, get it approved
- by the kernel community, then register it with the
- UEFI Forum.
- \_OSI 5.7.2 Deprecated on ARM64. Any invocation of this method
- will print a warning on the console and return false.
- That is, as far as ACPI firmware is concerned, _OSI
- cannot be used to determine what sort of system is
- being used or what functionality is provided. The
- _OSC method is to be used instead.
- _OST 6.3.5 Optional.
- _PDC 8.4.1 Deprecated, do not use on arm64.
- \_PIC 5.8.1 The method should not be used. On arm64, the only
- interrupt model available is GIC.
- _PLD 6.1.8 Optional.
- \_PR 5.3.1 This namespace is for x86 use only on legacy systems.
- Do not use it on arm64.
- _PRS 6.2.12 Optional.
- _PRT 6.2.13 Required as part of the definition of all PCI root
- devices.
- _PRW 7.2.13 Use as needed; power management specific.
- _PRx 7.2.8-11 Use as needed; power management specific. If _PR0 is
- defined, _PR3 must also be defined.
- _PSC 7.2.6 Use as needed; power management specific.
- _PSE 7.2.7 Use as needed; power management specific.
- _PSW 7.2.14 Use as needed; power management specific.
- _PSx 7.2.2-5 Use as needed; power management specific. If _PS0 is
- defined, _PS3 must also be defined. If clocks or
- regulators need adjusting to be consistent with power
- usage, change them in these methods.
- \_PTS 7.3.1 Use as needed; power management specific.
- _PXM 6.2.14 Optional.
- _REG 6.5.4 Use as needed.
- \_REV 5.7.4 Always returns the latest version of ACPI supported.
- _RMV 6.3.6 Optional.
- \_SB 5.3.1 Required on arm64; all devices must be defined in this
- namespace.
- _SEG 6.5.6 Use as needed; PCI-specific.
- \_SI 5.3.1, Optional.
- 9.1
- _SLI 6.2.15 Optional; recommended when SLIT table is in use.
- _STA 6.3.7, It is recommended to define this method for any device
- 7.1.4 that can be turned on or off.
- _SRS 6.2.16 Optional; see also _PRS.
- _STR 6.1.10 Recommended for conveying device names to end users;
- this is preferred over using _DDN.
- _SUB 6.1.9 Use as needed; _HID or _CID are preferred.
- _SUN 6.1.11 Optional.
- \_Sx 7.3.2 Use as needed; power management specific.
- _SxD 7.2.16-19 Use as needed; power management specific.
- _SxW 7.2.20-24 Use as needed; power management specific.
- _SWS 7.3.3 Use as needed; power management specific; this may
- require specification changes for use on arm64.
- \_TTS 7.3.4 Use as needed; power management specific.
- \_TZ 5.3.1 Optional.
- _UID 6.1.12 Recommended for distinguishing devices of the same
- class; define it if at all possible.
- \_WAK 7.3.5 Use as needed; power management specific.
- ACPI Event Model
- ----------------
- Do not use GPE block devices; these are not supported in the hardware reduced
- profile used by arm64. Since there are no GPE blocks defined for use on ARM
- platforms, GPIO-signaled interrupts should be used for creating system events.
- ACPI Processor Control
- ----------------------
- Section 8 of the ACPI specification is currently undergoing change that
- should be completed in the 6.0 version of the specification. Processor
- performance control will be handled differently for arm64 at that point
- in time. Processor aggregator devices (section 8.5) will not be used,
- for example, but another similar mechanism instead.
- While UEFI constrains what we can say until the release of 6.0, it is
- recommended that CPPC (8.4.5) be used as the primary model. This will
- still be useful into the future. C-states and P-states will still be
- provided, but most of the current design work appears to favor CPPC.
- Further, it is essential that the ARMv8 SoC provide a fully functional
- implementation of PSCI; this will be the only mechanism supported by ACPI
- to control CPU power state (including secondary CPU booting).
- More details will be provided on the release of the ACPI 6.0 specification.
- ACPI System Address Map Interfaces
- ----------------------------------
- In Section 15 of the ACPI specification, several methods are mentioned as
- possible mechanisms for conveying memory resource information to the kernel.
- For arm64, we will only support UEFI for booting with ACPI, hence the UEFI
- GetMemoryMap() boot service is the only mechanism that will be used.
- ACPI Platform Error Interfaces (APEI)
- -------------------------------------
- The APEI tables supported are described above.
- APEI requires the equivalent of an SCI and an NMI on ARMv8. The SCI is used
- to notify the OSPM of errors that have occurred but can be corrected and the
- system can continue correct operation, even if possibly degraded. The NMI is
- used to indicate fatal errors that cannot be corrected, and require immediate
- attention.
- Since there is no direct equivalent of the x86 SCI or NMI, arm64 handles
- these slightly differently. The SCI is handled as a normal GPIO-signaled
- interrupt; given that these are corrected (or correctable) errors being
- reported, this is sufficient. The NMI is emulated as the highest priority
- GPIO-signaled interrupt possible. This implies some caution must be used
- since there could be interrupts at higher privilege levels or even interrupts
- at the same priority as the emulated NMI. In Linux, this should not be the
- case but one should be aware it could happen.
- ACPI Objects Not Supported on ARM64
- -----------------------------------
- While this may change in the future, there are several classes of objects
- that can be defined, but are not currently of general interest to ARM servers.
- These are not supported:
- -- Section 9.2: ambient light sensor devices
- -- Section 9.3: battery devices
- -- Section 9.4: lids (e.g., laptop lids)
- -- Section 9.8.2: IDE controllers
- -- Section 9.9: floppy controllers
- -- Section 9.10: GPE block devices
- -- Section 9.15: PC/AT RTC/CMOS devices
- -- Section 9.16: user presence detection devices
- -- Section 9.17: I/O APIC devices; all GICs must be enumerable via MADT
- -- Section 9.18: time and alarm devices (see 9.15)
- ACPI Objects Not Yet Implemented
- --------------------------------
- While these objects have x86 equivalents, and they do make some sense in ARM
- servers, there is either no hardware available at present, or in some cases
- there may not yet be a non-ARM implementation. Hence, they are currently not
- implemented though that may change in the future.
- Not yet implemented are:
- -- Section 10: power source and power meter devices
- -- Section 11: thermal management
- -- Section 12: embedded controllers interface
- -- Section 13: SMBus interfaces
- -- Section 17: NUMA support (prototypes have been submitted for
- review)
|