--- /dev/null
- - Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IBFT,
- IORT, MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT,
- STAO, TCPA, TPM2, UEFI, XENV
+ ===========
+ 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, PCCT, SSDT
+
- - Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT, MSDM, OEMx,
- PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
++ - Optional: AGDI, BGRT, CEDT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT,
++ HMAT, IBFT, IORT, MCHI, MPAM, MPST, MSCT, NFIT, PMTT, PPTT, RASF, SBST,
++ SDEI, SLIT, SPMI, SRAT, STAO, TCPA, TPM2, UEFI, XENV
+
++ - Not supported: AEST, APMT, BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT,
++ MSDM, OEMx, PDTT, PSDT, RAS2, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
+
+ ====== ========================================================================
+ Table Usage for ARMv8 Linux
+ ====== ========================================================================
++AEST Signature Reserved (signature == "AEST")
++
++ **Arm Error Source Table**
++
++ This table informs the OS of any error nodes in the system that are
++ compliant with the Arm RAS architecture.
++
++AGDI Signature Reserved (signature == "AGDI")
++
++ **Arm Generic diagnostic Dump and Reset Device Interface Table**
++
++ This table describes a non-maskable event, that is used by the platform
++ firmware, to request the OS to generate a diagnostic dump and reset the device.
++
++APMT Signature Reserved (signature == "APMT")
++
++ **Arm Performance Monitoring Table**
++
++ This table describes the properties of PMU support implmented by
++ components in the system.
++
+ 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.
+
++CEDT Signature Reserved (signature == "CEDT")
++
++ **CXL Early Discovery Table**
++
++ This table allows the OS to discover any CXL Host Bridges and the Host
++ Bridge registers.
++
+ 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**
+
+ License has changed and should be usable. Optional if used instead
+ of earlycon=<device> on the command line.
+
+ 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, useful for boot performance profiling.
+
+ 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**
+
+ ARM-specific error sources have been defined; please use those or the
+ PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER
+ Bridge), or use type 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.
+
++HMAT Section 5.2.28 (signature == "HMAT")
++
++ **Heterogeneous Memory Attribute Table**
++
++ This table describes the memory attributes, such as memory side cache
++ attributes and bandwidth and latency details, related to Memory Proximity
++ Domains. The OS uses this information to optimize the system memory
++ configuration.
++
+ 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.
+
+ IORT Signature Reserved (signature == "IORT")
+
+ **Input Output Remapping Table**
+
+ arm64 only table, required in order to describe IO topology, SMMUs,
+ and GIC ITSs, and how those various components are connected together,
+ such as identifying which components are behind which SMMUs/ITSs.
+ This table will only be required on certain SBSA platforms (e.g.,
+ when using GICv3-ITS and an SMMU); on SBSA Level 0 platforms, it
+ remains optional.
+
+ 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; starting with ACPI 6.0, processor
+ descriptions and power states on ARM platforms should use the DSDT
+ and define processor container devices (_HID ACPI0010, Section 8.4,
+ and more specifically 8.4.3 and 8.4.4).
+
+ 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 - 0xF).
+
+ 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.
+
++MPAM Signature Reserved (signature == "MPAM")
++
++ **Memory Partitioning And Monitoring table**
++
++ This table allows the OS to discover the MPAM controls implemented by
++ the subsystems.
++
+ MPST Section 5.2.21 (signature == "MPST")
+
+ **Memory Power State Table**
+
+ Optional, not currently supported.
+
+ MSCT Section 5.2.19 (signature == "MSCT")
+
+ **Maximum System Characteristic Table**
+
+ Optional, not currently supported.
+
+ MSDM Signature Reserved (signature == "MSDM")
+
+ **Microsoft Data Management table**
+
+ Microsoft only table, will not be supported.
+
+ NFIT Section 5.2.25 (signature == "NFIT")
+
+ **NVDIMM Firmware Interface Table**
+
+ Optional, not currently supported.
+
+ OEMx Signature of "OEMx" only
+
+ **OEM Specific Tables**
+
+ All tables starting with a signature of "OEM" are reserved for OEM
+ use. Since these are not meant to be of general use but are limited
+ to very specific end users, they are not recommended for use and are
+ not supported by the kernel for arm64.
+
+ PCCT Section 14.1 (signature == "PCCT)
+
+ **Platform Communications Channel Table**
+
+ Recommend for use on arm64; use of PCC is recommended when using CPPC
+ to control performance and power for platform processors.
+
++PDTT Section 5.2.29 (signature == "PDTT")
++
++ **Platform Debug Trigger Table**
++
++ This table describes PCC channels used to gather debug logs of
++ non-architectural features.
++
++
+ PMTT Section 5.2.21.12 (signature == "PMTT")
+
+ **Platform Memory Topology Table**
+
+ Optional, not currently supported.
+
++PPTT Section 5.2.30 (signature == "PPTT")
++
++ **Processor Properties Topology Table**
++
++ This table provides the processor and cache topology.
++
+ PSDT Section 5.2.11.3 (signature == "PSDT")
+
+ **Persistent System Description Table**
+
+ Obsolete table, will not be supported.
+
++RAS2 Section 5.2.21 (signature == "RAS2")
++
++ **RAS Features 2 table**
++
++ This table provides interfaces for the RAS capabilities implemented in
++ the platform.
++
+ 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. If provided, it will be ignored.
+
+ SBST Section 5.2.14 (signature == "SBST")
+
+ **Smart Battery Subsystem Table**
+
+ Optional, not currently supported.
+
++SDEI Signature Reserved (signature == "SDEI")
++
++ **Software Delegated Exception Interface table**
++
++ This table advertises the presence of the SDEI interface.
++
+ 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 arm64 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.
+
+ STAO Signature Reserved (signature == "STAO")
+
+ **_STA Override table**
+
+ Optional, but only necessary in virtualized environments in order to
+ hide devices from guest OSs.
+
+ 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.
+
+ XENV Signature Reserved (signature == "XENV")
+
+ **Xen project table**
+
+ Optional, used only by Xen at present.
+
+ XSDT Section 5.2.8 (signature == "XSDT")
+
+ **eXtended System Description Table**
+
+ Required for arm64.
+ ====== ========================================================================
+
+ ACPI Objects
+ ------------
+ The expectations on individual ACPI objects that are likely to be used are
+ shown in the list that follows; any object not explicitly mentioned below
+ should be used as needed for a particular platform or particular subsystem,
+ such as power management or PCI.
+
+ ===== ================ ========================================================
+ Name Section Usage for ARMv8 Linux
+ ===== ================ ========================================================
+ _CCA 6.2.17 This method must be defined for all bus masters
+ on arm64 - there are no assumptions made about
+ whether such devices are cache coherent or not.
+ The _CCA value is inherited by all descendants of
+ these devices so it does not need to be repeated.
+ Without _CCA on arm64, the kernel does not know what
+ to do about setting up DMA for the device.
+
+ NB: this method provides default cache coherency
+ attributes; the presence of an SMMU can be used to
+ modify that, however. For example, a master could
+ default to non-coherent, but be made coherent with
+ the appropriate SMMU configuration (see Table 17 of
+ the IORT specification, ARM Document DEN 0049B).
+
+ _CID 6.1.2 Use as needed, see also _HID.
+
+ _CLS 6.1.3 Use as needed, see also _HID.
+
+ _CPC 8.4.7.1 Use as needed, power management specific. CPPC is
+ recommended on arm64.
+
+ _CRS 6.2.2 Required on arm64.
+
+ _CSD 8.4.2.2 Use as needed, used only in conjunction with _CST.
+
+ _CST 8.4.2.1 Low power idle states (8.4.4) are recommended instead
+ of C-states.
+
+ _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.
+
+ _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 9.1.1 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.
+
+ \_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.
+
+ _HID 6.1.5 This is the primary object to use in device probing,
+ though _CID and _CLS may also be used.
+
+ _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.
+
+ _LPI 8.4.4.3 Recommended for use with processor definitions (_HID
+ ACPI0010) on arm64. See also _RDI.
+
+ _MLS 6.1.7 Highly recommended for use in internationalization.
+
+ _OFF 7.2.2 It is recommended to define this method for any device
+ that can be turned on or off.
+
+ _ON 7.2.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. As far as ACPI firmware is
+ concerned, _OSI is not to be used to determine what
+ sort of system is being used or what functionality
+ is provided. The _OSC method is to be used instead.
+
+ _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.
+
+ \_PR 5.3.1 This namespace is for x86 use only on legacy systems.
+ Do not use it on arm64.
+
+ _PRT 6.2.13 Required as part of the definition of all PCI root
+ devices.
+
+ _PRx 7.3.8-11 Use as needed; power management specific. If _PR0 is
+ defined, _PR3 must also be defined.
+
+ _PSx 7.3.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.
+
+ _RDI 8.4.4.4 Recommended for use with processor definitions (_HID
+ ACPI0010) on arm64. This should only be used in
+ conjunction with _LPI.
+
+ \_REV 5.7.4 Always returns the latest version of ACPI supported.
+
+ \_SB 5.3.1 Required on arm64; all devices must be defined in this
+ namespace.
+
+ _SLI 6.2.15 Use is recommended when SLIT table is in use.
+
+ _STA 6.3.7, It is recommended to define this method for any device
+ 7.2.4 that can be turned on or off. See also the STAO table
+ that provides overrides to hide devices in virtualized
+ environments.
+
+ _SRS 6.2.16 Use as needed; 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 Use as needed, but recommended.
+
+ _SWS 7.4.3 Use as needed; power management specific; this may
+ require specification changes for use on arm64.
+
+ _UID 6.1.12 Recommended for distinguishing devices of the same
+ class; define it if at all possible.
+ ===== ================ ========================================================
+
+
+
+
+ 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, ACPI events must be signaled differently.
+
+ There are two options: GPIO-signaled interrupts (Section 5.6.5), and
+ interrupt-signaled events (Section 5.6.9). Interrupt-signaled events are a
+ new feature in the ACPI 6.1 specification. Either - or both - can be used
+ on a given platform, and which to use may be dependent of limitations in any
+ given SoC. If possible, interrupt-signaled events are recommended.
+
+
+ ACPI Processor Control
+ ----------------------
+ Section 8 of the ACPI specification changed significantly in version 6.0.
+ Processors should now be defined as Device objects with _HID ACPI0007; do
+ not use the deprecated Processor statement in ASL. All multiprocessor systems
+ should also define a hierarchy of processors, done with Processor Container
+ Devices (see Section 8.4.3.1, _HID ACPI0010); do not use processor aggregator
+ devices (Section 8.5) to describe processor topology. Section 8.4 of the
+ specification describes the semantics of these object definitions and how
+ they interrelate.
+
+ Most importantly, the processor hierarchy defined also defines the low power
+ idle states that are available to the platform, along with the rules for
+ determining which processors can be turned on or off and the circumstances
+ that control that. Without this information, the processors will run in
+ whatever power state they were left in by UEFI.
+
+ Note too, that the processor Device objects defined and the entries in the
+ MADT for GICs are expected to be in synchronization. The _UID of the Device
+ object must correspond to processor IDs used in the MADT.
+
+ It is recommended that CPPC (8.4.5) be used as the primary model for processor
+ performance control on arm64. C-states and P-states may become available at
+ some point in the future, but most 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. Booting of secondary CPUs using the ACPI
+ parking protocol is possible, but discouraged, since only PSCI is supported
+ for ARM servers.
+
+
+ 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 high priority interrupt;
+ given that these are corrected (or correctable) errors being reported, this
+ is sufficient. The NMI is emulated as the highest priority 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.
+ Some of these objects have x86 equivalents, and may actually make sense in ARM
+ servers. However, there is either no hardware available at present, or there
+ may not even be a non-ARM implementation yet. Hence, they are not currently
+ supported.
+
+ The following classes of objects 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)
+
+ - Section 10: power source and power meter devices
+
+ - Section 11: thermal management
+
+ - Section 12: embedded controllers interface
+
+ - Section 13: SMBus interfaces
+
+
+ This also means that there is no support for the following objects:
+
+ ==== =========================== ==== ==========
+ Name Section Name Section
+ ==== =========================== ==== ==========
+ _ALC 9.3.4 _FDM 9.10.3
+ _ALI 9.3.2 _FIX 6.2.7
+ _ALP 9.3.6 _GAI 10.4.5
+ _ALR 9.3.5 _GHL 10.4.7
+ _ALT 9.3.3 _GTM 9.9.2.1.1
+ _BCT 10.2.2.10 _LID 9.5.1
+ _BDN 6.5.3 _PAI 10.4.4
+ _BIF 10.2.2.1 _PCL 10.3.2
+ _BIX 10.2.2.1 _PIF 10.3.3
+ _BLT 9.2.3 _PMC 10.4.1
+ _BMA 10.2.2.4 _PMD 10.4.8
+ _BMC 10.2.2.12 _PMM 10.4.3
+ _BMD 10.2.2.11 _PRL 10.3.4
+ _BMS 10.2.2.5 _PSR 10.3.1
+ _BST 10.2.2.6 _PTP 10.4.2
+ _BTH 10.2.2.7 _SBS 10.1.3
+ _BTM 10.2.2.9 _SHL 10.4.6
+ _BTP 10.2.2.8 _STM 9.9.2.1.1
+ _DCK 6.5.2 _UPD 9.16.1
+ _EC 12.12 _UPP 9.16.2
+ _FDE 9.10.1 _WPC 10.5.2
+ _FDI 9.10.2 _WPP 10.5.3
+ ==== =========================== ==== ==========
--- /dev/null
-=====================
-ACPI on ARMv8 Servers
-=====================
-
-ACPI can be used for ARMv8 general purpose servers designed to follow
-the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server
-Base Boot Requirements) [1] specifications. Please note that the SBBR
-can be retrieved simply by visiting [1], but the SBSA is currently only
-available to those with an ARM login due to ARM IP licensing concerns.
-
-The ARMv8 kernel implements the reduced hardware model of ACPI version
++===================
++ACPI on Arm systems
++===================
++
++ACPI can be used for Armv8 and Armv9 systems designed to follow
++the BSA (Arm Base System Architecture) [0] and BBR (Arm
++Base Boot Requirements) [1] specifications. Both BSA and BBR are publicly
++accessible documents.
++Arm Servers, in addition to being BSA compliant, comply with a set
++of rules defined in SBSA (Server Base System Architecture) [2].
++
++The Arm kernel implements the reduced hardware model of ACPI version
+ 5.1 or later. Links to the specification and all external documents
+ it refers to are managed by the UEFI Forum. The specification is
+ available at http://www.uefi.org/specifications and documents referenced
+ by the specification can be found via http://www.uefi.org/acpi.
+
-If an ARMv8 system does not meet the requirements of the SBSA and SBBR,
++If an Arm system does not meet the requirements of the BSA and BBR,
+ or cannot be described using the mechanisms defined in the required ACPI
+ specifications, then ACPI may not be a good fit for the hardware.
+
+ While the documents mentioned above set out the requirements for building
-industry-standard ARMv8 servers, they also apply to more than one operating
++industry-standard Arm systems, they also apply to more than one operating
+ system. The purpose of this document is to describe the interaction between
-ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of
++ACPI and Linux only, on an Arm system -- that is, what Linux expects of
+ ACPI and what ACPI can expect of Linux.
+
+
-Why ACPI on ARM?
++Why ACPI on Arm?
+ ----------------
+ Before examining the details of the interface between ACPI and Linux, it is
+ useful to understand why ACPI is being used. Several technologies already
+ exist in Linux for describing non-enumerable hardware, after all. In this
-section we summarize a blog post [2] from Grant Likely that outlines the
-reasoning behind ACPI on ARMv8 servers. Actually, we snitch a good portion
++section we summarize a blog post [3] from Grant Likely that outlines the
++reasoning behind ACPI on Arm systems. Actually, we snitch a good portion
+ of the summary text almost directly, to be honest.
+
-The short form of the rationale for ACPI on ARM is:
++The short form of the rationale for ACPI on Arm is:
+
+ - ACPI’s byte code (AML) allows the platform to encode hardware behavior,
+ while DT explicitly does not support this. For hardware vendors, being
+ able to encode behavior is a key tool used in supporting operating
+ system releases on new hardware.
+
+ - ACPI’s OSPM defines a power management model that constrains what the
+ platform is allowed to do into a specific model, while still providing
+ flexibility in hardware design.
+
+ - In the enterprise server environment, ACPI has established bindings (such
+ as for RAS) which are currently used in production systems. DT does not.
- Such bindings could be defined in DT at some point, but doing so means ARM
++ Such bindings could be defined in DT at some point, but doing so means Arm
+ and x86 would end up using completely different code paths in both firmware
+ and the kernel.
+
+ - Choosing a single interface to describe the abstraction between a platform
+ and an OS is important. Hardware vendors would not be required to implement
+ both DT and ACPI if they want to support multiple operating systems. And,
+ agreeing on a single interface instead of being fragmented into per OS
+ interfaces makes for better interoperability overall.
+
+ - The new ACPI governance process works well and Linux is now at the same
+ table as hardware vendors and other OS vendors. In fact, there is no
+ longer any reason to feel that ACPI only belongs to Windows or that
+ Linux is in any way secondary to Microsoft in this arena. The move of
+ ACPI governance into the UEFI forum has significantly opened up the
+ specification development process, and currently, a large portion of the
+ changes being made to ACPI are being driven by Linux.
+
+ Key to the use of ACPI is the support model. For servers in general, the
+ responsibility for hardware behaviour cannot solely be the domain of the
+ kernel, but rather must be split between the platform and the kernel, in
+ order to allow for orderly change over time. ACPI frees the OS from needing
+ to understand all the minute details of the hardware so that the OS doesn’t
+ need to be ported to each and every device individually. It allows the
+ hardware vendors to take responsibility for power management behaviour without
+ depending on an OS release cycle which is not under their control.
+
+ ACPI is also important because hardware and OS vendors have already worked
+ out the mechanisms for supporting a general purpose computing ecosystem. The
+ infrastructure is in place, the bindings are in place, and the processes are
+ in place. DT does exactly what Linux needs it to when working with vertically
+ integrated devices, but there are no good processes for supporting what the
+ server vendors need. Linux could potentially get there with DT, but doing so
+ really just duplicates something that already works. ACPI already does what
+ the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
+ vendors would still end up providing two completely separate firmware
+ interfaces -- one for Linux and one for Windows.
+
+
+ Kernel Compatibility
+ --------------------
+ One of the primary motivations for ACPI is standardization, and using that
+ to provide backward compatibility for Linux kernels. In the server market,
+ software and hardware are often used for long periods. ACPI allows the
+ kernel and firmware to agree on a consistent abstraction that can be
+ maintained over time, even as hardware or software change. As long as the
+ abstraction is supported, systems can be updated without necessarily having
+ to replace the kernel.
+
+ When a Linux driver or subsystem is first implemented using ACPI, it by
+ definition ends up requiring a specific version of the ACPI specification
+ -- it's baseline. ACPI firmware must continue to work, even though it may
+ not be optimal, with the earliest kernel version that first provides support
+ for that baseline version of ACPI. There may be a need for additional drivers,
+ but adding new functionality (e.g., CPU power management) should not break
+ older kernel versions. Further, ACPI firmware must also work with the most
+ recent version of the kernel.
+
+
+ Relationship with Device Tree
+ -----------------------------
-ACPI support in drivers and subsystems for ARMv8 should never be mutually
++ACPI support in drivers and subsystems for Arm should never be mutually
+ exclusive with DT support at compile time.
+
+ At boot time the kernel will only use one description method depending on
+ parameters passed from the boot loader (including kernel bootargs).
+
+ Regardless of whether DT or ACPI is used, the kernel must always be capable
+ of booting with either scheme (in kernels with both schemes enabled at compile
+ time).
+
+
+ Booting using ACPI tables
+ -------------------------
-The only defined method for passing ACPI tables to the kernel on ARMv8
++The only defined method for passing ACPI tables to the kernel on Arm
+ is via the UEFI system configuration table. Just so it is explicit, this
+ means that ACPI is only supported on platforms that boot via UEFI.
+
-When an ARMv8 system boots, it can either have DT information, ACPI tables,
++When an Arm system boots, it can either have DT information, ACPI tables,
+ or in some very unusual cases, both. If no command line parameters are used,
+ the kernel will try to use DT for device enumeration; if there is no DT
+ present, the kernel will try to use ACPI tables, but only if they are present.
+ In neither is available, the kernel will not boot. If acpi=force is used
+ on the command line, the kernel will attempt to use ACPI tables first, but
+ fall back to DT if there are no ACPI tables present. The basic idea is that
+ the kernel will not fail to boot unless it absolutely has no other choice.
+
+ Processing of ACPI tables may be disabled by passing acpi=off on the kernel
+ command line; this is the default behavior.
+
+ In order for the kernel to load and use ACPI tables, the UEFI implementation
+ MUST set the ACPI_20_TABLE_GUID to point to the RSDP table (the table with
+ the ACPI signature "RSD PTR "). If this pointer is incorrect and acpi=force
+ is used, the kernel will disable ACPI and try to use DT to boot instead; the
+ kernel has, in effect, determined that ACPI tables are not present at that
+ point.
+
+ If the pointer to the RSDP table is correct, the table will be mapped into
+ the kernel by the ACPI core, using the address provided by UEFI.
+
+ The ACPI core will then locate and map in all other ACPI tables provided by
+ using the addresses in the RSDP table to find the XSDT (eXtended System
+ Description Table). The XSDT in turn provides the addresses to all other
+ ACPI tables provided by the system firmware; the ACPI core will then traverse
+ this table and map in the tables listed.
+
+ The ACPI core will ignore any provided RSDT (Root System Description Table).
+ RSDTs have been deprecated and are ignored on arm64 since they only allow
+ for 32-bit addresses.
+
+ Further, the ACPI core will only use the 64-bit address fields in the FADT
+ (Fixed ACPI Description Table). Any 32-bit address fields in the FADT will
+ be ignored on arm64.
+
+ Hardware reduced mode (see Section 4.1 of the ACPI 6.1 specification) will
+ be enforced by the ACPI core on arm64. Doing so allows the ACPI core to
+ run less complex code since it no longer has to provide support for legacy
+ hardware from other architectures. Any fields that are not to be used for
+ hardware reduced mode must be set to zero.
+
+ For the ACPI core to operate properly, and in turn provide the information
+ the kernel needs to configure devices, it expects to find the following
-tables (all section numbers refer to the ACPI 6.1 specification):
++tables (all section numbers refer to the ACPI 6.5 specification):
+
+ - RSDP (Root System Description Pointer), section 5.2.5
+
+ - XSDT (eXtended System Description Table), section 5.2.8
+
+ - FADT (Fixed ACPI Description Table), section 5.2.9
+
+ - DSDT (Differentiated System Description Table), section
+ 5.2.11.1
+
+ - MADT (Multiple APIC Description Table), section 5.2.12
+
+ - GTDT (Generic Timer Description Table), section 5.2.24
+
++ - PPTT (Processor Properties Topology Table), section 5.2.30
++
++ - DBG2 (DeBuG port table 2), section 5.2.6, specifically Table 5-6.
++
++ - APMT (Arm Performance Monitoring unit Table), section 5.2.6, specifically Table 5-6.
++
++ - AGDI (Arm Generic diagnostic Dump and Reset Device Interface Table), section 5.2.6, specifically Table 5-6.
++
+ - If PCI is supported, the MCFG (Memory mapped ConFiGuration
- Table), section 5.2.6, specifically Table 5-31.
++ Table), section 5.2.6, specifically Table 5-6.
+
+ - If booting without a console=<device> kernel parameter is
+ supported, the SPCR (Serial Port Console Redirection table),
- section 5.2.6, specifically Table 5-31.
++ section 5.2.6, specifically Table 5-6.
+
+ - If necessary to describe the I/O topology, SMMUs and GIC ITSs,
+ the IORT (Input Output Remapping Table, section 5.2.6, specifically
- Table 5-31).
++ Table 5-6).
++
++ - If NUMA is supported, the following tables are required:
++
++ - SRAT (System Resource Affinity Table), section 5.2.16
++
++ - SLIT (System Locality distance Information Table), section 5.2.17
++
++ - If NUMA is supported, and the system contains heterogeneous memory,
++ the HMAT (Heterogeneous Memory Attribute Table), section 5.2.28.
++
++ - If the ACPI Platform Error Interfaces are required, the following
++ tables are conditionally required:
++
++ - BERT (Boot Error Record Table, section 18.3.1)
++
++ - EINJ (Error INJection table, section 18.6.1)
++
++ - ERST (Error Record Serialization Table, section 18.5)
++
++ - HEST (Hardware Error Source Table, section 18.3.2)
++
++ - SDEI (Software Delegated Exception Interface table, section 5.2.6,
++ specifically Table 5-6)
++
++ - AEST (Arm Error Source Table, section 5.2.6,
++ specifically Table 5-6)
++
++ - RAS2 (ACPI RAS2 feature table, section 5.2.21)
++
++ - If the system contains controllers using PCC channel, the
++ PCCT (Platform Communications Channel Table), section 14.1
++
++ - If the system contains a controller to capture board-level system state,
++ and communicates with the host via PCC, the PDTT (Platform Debug Trigger
++ Table), section 5.2.29.
++
++ - If NVDIMM is supported, the NFIT (NVDIMM Firmware Interface Table), section 5.2.26
++
++ - If video framebuffer is present, the BGRT (Boot Graphics Resource Table), section 5.2.23
++
++ - If IPMI is implemented, the SPMI (Server Platform Management Interface),
++ section 5.2.6, specifically Table 5-6.
++
++ - If the system contains a CXL Host Bridge, the CEDT (CXL Early Discovery
++ Table), section 5.2.6, specifically Table 5-6.
++
++ - If the system supports MPAM, the MPAM (Memory Partitioning And Monitoring table), section 5.2.6,
++ specifically Table 5-6.
++
++ - If the system lacks persistent storage, the IBFT (ISCSI Boot Firmware
++ Table), section 5.2.6, specifically Table 5-6.
+
- - If NUMA is supported, the SRAT (System Resource Affinity Table)
- and SLIT (System Locality distance Information Table), sections
- 5.2.16 and 5.2.17, respectively.
+
+ If the above tables are not all present, the kernel may or may not be
+ able to boot properly since it may not be able to configure all of the
+ devices available. This list of tables is not meant to be all inclusive;
+ in some environments other tables may be needed (e.g., any of the APEI
+ tables from section 18) to support specific functionality.
+
+
+ ACPI Detection
+ --------------
+ Drivers should determine their probe() type by checking for a null
+ value for ACPI_HANDLE, or checking .of_node, or other information in
+ the device structure. This is detailed further in the "Driver
+ Recommendations" section.
+
+ In non-driver code, if the presence of ACPI needs to be detected at
+ run time, then check the value of acpi_disabled. If CONFIG_ACPI is not
+ set, acpi_disabled will always be 1.
+
+
+ Device Enumeration
+ ------------------
+ Device descriptions in ACPI should use standard recognized ACPI interfaces.
+ These may contain less information than is typically provided via a Device
+ Tree description for the same device. This is also one of the reasons that
+ ACPI can be useful -- the driver takes into account that it may have less
+ detailed information about the device and uses sensible defaults instead.
+ If done properly in the driver, the hardware can change and improve over
+ time without the driver having to change at all.
+
+ Clocks provide an excellent example. In DT, clocks need to be specified
+ and the drivers need to take them into account. In ACPI, the assumption
+ is that UEFI will leave the device in a reasonable default state, including
+ any clock settings. If for some reason the driver needs to change a clock
+ value, this can be done in an ACPI method; all the driver needs to do is
+ invoke the method and not concern itself with what the method needs to do
+ to change the clock. Changing the hardware can then take place over time
+ by changing what the ACPI method does, and not the driver.
+
+ In DT, the parameters needed by the driver to set up clocks as in the example
+ above are known as "bindings"; in ACPI, these are known as "Device Properties"
+ and provided to a driver via the _DSD object.
+
+ ACPI tables are described with a formal language called ASL, the ACPI
+ Source Language (section 19 of the specification). This means that there
+ are always multiple ways to describe the same thing -- including device
+ properties. For example, device properties could use an ASL construct
+ that looks like this: Name(KEY0, "value0"). An ACPI device driver would
+ then retrieve the value of the property by evaluating the KEY0 object.
+ However, using Name() this way has multiple problems: (1) ACPI limits
+ names ("KEY0") to four characters unlike DT; (2) there is no industry
+ wide registry that maintains a list of names, minimizing re-use; (3)
+ there is also no registry for the definition of property values ("value0"),
+ again making re-use difficult; and (4) how does one maintain backward
+ compatibility as new hardware comes out? The _DSD method was created
+ to solve precisely these sorts of problems; Linux drivers should ALWAYS
+ use the _DSD method for device properties and nothing else.
+
+ The _DSM object (ACPI Section 9.14.1) could also be used for conveying
+ device properties to a driver. Linux drivers should only expect it to
+ be used if _DSD cannot represent the data required, and there is no way
+ to create a new UUID for the _DSD object. Note that there is even less
+ regulation of the use of _DSM than there is of _DSD. Drivers that depend
+ on the contents of _DSM objects will be more difficult to maintain over
+ time because of this; as of this writing, the use of _DSM is the cause
+ of quite a few firmware problems and is not recommended.
+
+ Drivers should look for device properties in the _DSD object ONLY; the _DSD
+ object is described in the ACPI specification section 6.2.5, but this only
+ describes how to define the structure of an object returned via _DSD, and
+ how specific data structures are defined by specific UUIDs. Linux should
-only use the _DSD Device Properties UUID [5]:
++only use the _DSD Device Properties UUID [4]:
+
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
+
- - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
-
-The UEFI Forum provides a mechanism for registering device properties [4]
-so that they may be used across all operating systems supporting ACPI.
-Device properties that have not been registered with the UEFI Forum should
-not be used.
++Common device properties can be registered by creating a pull request to [4] so
++that they may be used across all operating systems supporting ACPI.
++Device properties that have not been registered with the UEFI Forum can be used
++but not as "uefi-" common properties.
+
+ Before creating new device properties, check to be sure that they have not
+ been defined before and either registered in the Linux kernel documentation
+ as DT bindings, or the UEFI Forum as device properties. While we do not want
+ to simply move all DT bindings into ACPI device properties, we can learn from
+ what has been previously defined.
+
+ If it is necessary to define a new device property, or if it makes sense to
+ synthesize the definition of a binding so it can be used in any firmware,
+ both DT bindings and ACPI device properties for device drivers have review
+ processes. Use them both. When the driver itself is submitted for review
+ to the Linux mailing lists, the device property definitions needed must be
+ submitted at the same time. A driver that supports ACPI and uses device
+ properties will not be considered complete without their definitions. Once
+ the device property has been accepted by the Linux community, it must be
+ registered with the UEFI Forum [4], which will review it again for consistency
+ within the registry. This may require iteration. The UEFI Forum, though,
+ will always be the canonical site for device property definitions.
+
+ It may make sense to provide notice to the UEFI Forum that there is the
+ intent to register a previously unused device property name as a means of
+ reserving the name for later use. Other operating system vendors will
+ also be submitting registration requests and this may help smooth the
+ process.
+
+ Once registration and review have been completed, the kernel provides an
+ interface for looking up device properties in a manner independent of
-whether DT or ACPI is being used. This API should be used [6]; it can
++whether DT or ACPI is being used. This API should be used [5]; it can
+ eliminate some duplication of code paths in driver probing functions and
+ discourage divergence between DT bindings and ACPI device properties.
+
+
+ Programmable Power Control Resources
+ ------------------------------------
+ Programmable power control resources include such resources as voltage/current
+ providers (regulators) and clock sources.
+
+ With ACPI, the kernel clock and regulator framework is not expected to be used
+ at all.
+
+ The kernel assumes that power control of these resources is represented with
+ Power Resource Objects (ACPI section 7.1). The ACPI core will then handle
+ correctly enabling and disabling resources as they are needed. In order to
+ get that to work, ACPI assumes each device has defined D-states and that these
+ can be controlled through the optional ACPI methods _PS0, _PS1, _PS2, and _PS3;
+ in ACPI, _PS0 is the method to invoke to turn a device full on, and _PS3 is for
+ turning a device full off.
+
+ There are two options for using those Power Resources. They can:
+
+ - be managed in a _PSx method which gets called on entry to power
+ state Dx.
+
+ - be declared separately as power resources with their own _ON and _OFF
+ methods. They are then tied back to D-states for a particular device
+ via _PRx which specifies which power resources a device needs to be on
+ while in Dx. Kernel then tracks number of devices using a power resource
+ and calls _ON/_OFF as needed.
+
+ The kernel ACPI code will also assume that the _PSx methods follow the normal
+ ACPI rules for such methods:
+
+ - If either _PS0 or _PS3 is implemented, then the other method must also
+ be implemented.
+
+ - If a device requires usage or setup of a power resource when on, the ASL
+ should organize that it is allocated/enabled using the _PS0 method.
+
+ - Resources allocated or enabled in the _PS0 method should be disabled
+ or de-allocated in the _PS3 method.
+
+ - Firmware will leave the resources in a reasonable state before handing
+ over control to the kernel.
+
+ Such code in _PSx methods will of course be very platform specific. But,
+ this allows the driver to abstract out the interface for operating the device
+ and avoid having to read special non-standard values from ACPI tables. Further,
+ abstracting the use of these resources allows the hardware to change over time
+ without requiring updates to the driver.
+
+
+ Clocks
+ ------
+ ACPI makes the assumption that clocks are initialized by the firmware --
+ UEFI, in this case -- to some working value before control is handed over
+ to the kernel. This has implications for devices such as UARTs, or SoC-driven
+ LCD displays, for example.
+
+ When the kernel boots, the clocks are assumed to be set to reasonable
+ working values. If for some reason the frequency needs to change -- e.g.,
+ throttling for power management -- the device driver should expect that
+ process to be abstracted out into some ACPI method that can be invoked
+ (please see the ACPI specification for further recommendations on standard
+ methods to be expected). The only exceptions to this are CPU clocks where
+ CPPC provides a much richer interface than ACPI methods. If the clocks
+ are not set, there is no direct way for Linux to control them.
+
+ If an SoC vendor wants to provide fine-grained control of the system clocks,
+ they could do so by providing ACPI methods that could be invoked by Linux
+ drivers. However, this is NOT recommended and Linux drivers should NOT use
+ such methods, even if they are provided. Such methods are not currently
+ standardized in the ACPI specification, and using them could tie a kernel
+ to a very specific SoC, or tie an SoC to a very specific version of the
+ kernel, both of which we are trying to avoid.
+
+
+ Driver Recommendations
+ ----------------------
+ DO NOT remove any DT handling when adding ACPI support for a driver. The
+ same device may be used on many different systems.
+
+ DO try to structure the driver so that it is data-driven. That is, set up
+ a struct containing internal per-device state based on defaults and whatever
+ else must be discovered by the driver probe function. Then, have the rest
+ of the driver operate off of the contents of that struct. Doing so should
+ allow most divergence between ACPI and DT functionality to be kept local to
+ the probe function instead of being scattered throughout the driver. For
+ example::
+
+ static int device_probe_dt(struct platform_device *pdev)
+ {
+ /* DT specific functionality */
+ ...
+ }
+
+ static int device_probe_acpi(struct platform_device *pdev)
+ {
+ /* ACPI specific functionality */
+ ...
+ }
+
+ static int device_probe(struct platform_device *pdev)
+ {
+ ...
+ struct device_node node = pdev->dev.of_node;
+ ...
+
+ if (node)
+ ret = device_probe_dt(pdev);
+ else if (ACPI_HANDLE(&pdev->dev))
+ ret = device_probe_acpi(pdev);
+ else
+ /* other initialization */
+ ...
+ /* Continue with any generic probe operations */
+ ...
+ }
+
+ DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it
+ clear the different names the driver is probed for, both from DT and from
+ ACPI::
+
+ static struct of_device_id virtio_mmio_match[] = {
+ { .compatible = "virtio,mmio", },
+ { }
+ };
+ MODULE_DEVICE_TABLE(of, virtio_mmio_match);
+
+ static const struct acpi_device_id virtio_mmio_acpi_match[] = {
+ { "LNRO0005", },
+ { }
+ };
+ MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
+
+
+ ASWG
+ ----
+ The ACPI specification changes regularly. During the year 2014, for instance,
+ version 5.1 was released and version 6.0 substantially completed, with most of
-the changes being driven by ARM-specific requirements. Proposed changes are
++the changes being driven by Arm-specific requirements. Proposed changes are
+ presented and discussed in the ASWG (ACPI Specification Working Group) which
+ is a part of the UEFI Forum. The current version of the ACPI specification
-is 6.1 release in January 2016.
++is 6.5 release in August 2022.
+
+ Participation in this group is open to all UEFI members. Please see
+ http://www.uefi.org/workinggroup for details on group membership.
+
-It is the intent of the ARMv8 ACPI kernel code to follow the ACPI specification
++It is the intent of the Arm ACPI kernel code to follow the ACPI specification
+ as closely as possible, and to only implement functionality that complies with
+ the released standards from UEFI ASWG. As a practical matter, there will be
+ vendors that provide bad ACPI tables or violate the standards in some way.
+ If this is because of errors, quirks and fix-ups may be necessary, but will
+ be avoided if possible. If there are features missing from ACPI that preclude
+ it from being used on a platform, ECRs (Engineering Change Requests) should be
+ submitted to ASWG and go through the normal approval process; for those that
+ are not UEFI members, many other members of the Linux community are and would
+ likely be willing to assist in submitting ECRs.
+
+
+ Linux Code
+ ----------
-Individual items specific to Linux on ARM, contained in the Linux
++Individual items specific to Linux on Arm, contained in the Linux
+ source code, are in the list that follows:
+
+ ACPI_OS_NAME
+ This macro defines the string to be returned when
- an ACPI method invokes the _OS method. On ARM64
++ an ACPI method invokes the _OS method. On Arm
+ systems, this macro will be "Linux" by default.
+ The command line parameter acpi_os=<string>
+ can be used to set it to some other value. The
+ default value for other architectures is "Microsoft
+ Windows NT", for example.
+
+ ACPI Objects
+ ------------
+ Detailed expectations for ACPI tables and object are listed in the file
+ Documentation/arch/arm64/acpi_object_usage.rst.
+
+
+ References
+ ----------
-[0] http://silver.arm.com
- document ARM-DEN-0029, or newer:
- "Server Base System Architecture", version 2.3, dated 27 Mar 2014
++[0] https://developer.arm.com/documentation/den0094/latest
++ document Arm-DEN-0094: "Arm Base System Architecture", version 1.0C, dated 6 Oct 2022
++
++[1] https://developer.arm.com/documentation/den0044/latest
++ Document Arm-DEN-0044: "Arm Base Boot Requirements", version 2.0G, dated 15 Apr 2022
+
-[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0044a/Server_Base_Boot_Requirements.pdf
- Document ARM-DEN-0044A, or newer: "Server Base Boot Requirements, System
- Software on ARM Platforms", dated 16 Aug 2014
++[2] https://developer.arm.com/documentation/den0029/latest
++ Document Arm-DEN-0029: "Arm Server Base System Architecture", version 7.1, dated 06 Oct 2022
+
-[2] http://www.secretlab.ca/archives/151,
++[3] http://www.secretlab.ca/archives/151,
+ 10 Jan 2015, Copyright (c) 2015,
+ Linaro Ltd., written by Grant Likely.
+
-[3] AMD ACPI for Seattle platform documentation
- http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_Guide.pdf
-
-
-[4] http://www.uefi.org/acpi
- please see the link for the "ACPI _DSD Device
- Property Registry Instructions"
-
-[5] http://www.uefi.org/acpi
- please see the link for the "_DSD (Device
- Specific Data) Implementation Guide"
++[4] _DSD (Device Specific Data) Implementation Guide
++ https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf
+
-[6] Kernel code for the unified device
++[5] Kernel code for the unified device
+ property interface can be found in
+ include/linux/property.h and drivers/base/property.c.
+
+
+ Authors
+ -------
+ - Al Stone <al.stone@linaro.org>
+ - Graeme Gregory <graeme.gregory@linaro.org>
+ - Hanjun Guo <hanjun.guo@linaro.org>
+
+ - Grant Likely <grant.likely@linaro.org>, for the "Why ACPI on ARM?" section
--- /dev/null
+ =====================
+ Booting AArch64 Linux
+ =====================
+
+ Author: Will Deacon <will.deacon@arm.com>
+
+ Date : 07 September 2012
+
+ This document is based on the ARM booting document by Russell King and
+ is relevant to all public releases of the AArch64 Linux kernel.
+
+ The AArch64 exception model is made up of a number of exception levels
+ (EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure
+ counterpart. EL2 is the hypervisor level, EL3 is the highest priority
+ level and exists only in secure mode. Both are architecturally optional.
+
+ For the purposes of this document, we will use the term `boot loader`
+ simply to define all software that executes on the CPU(s) before control
+ is passed to the Linux kernel. This may include secure monitor and
+ hypervisor code, or it may just be a handful of instructions for
+ preparing a minimal boot environment.
+
+ Essentially, the boot loader should provide (as a minimum) the
+ following:
+
+ 1. Setup and initialise the RAM
+ 2. Setup the device tree
+ 3. Decompress the kernel image
+ 4. Call the kernel image
+
+
+ 1. Setup and initialise RAM
+ ---------------------------
+
+ Requirement: MANDATORY
+
+ The boot loader is expected to find and initialise all RAM that the
+ kernel will use for volatile data storage in the system. It performs
+ this in a machine dependent manner. (It may use internal algorithms
+ to automatically locate and size all RAM, or it may use knowledge of
+ the RAM in the machine, or any other method the boot loader designer
+ sees fit.)
+
+
+ 2. Setup the device tree
+ -------------------------
+
+ Requirement: MANDATORY
+
+ The device tree blob (dtb) must be placed on an 8-byte boundary and must
+ not exceed 2 megabytes in size. Since the dtb will be mapped cacheable
+ using blocks of up to 2 megabytes in size, it must not be placed within
+ any 2M region which must be mapped with any specific attributes.
+
+ NOTE: versions prior to v4.2 also require that the DTB be placed within
+ the 512 MB region starting at text_offset bytes below the kernel Image.
+
+ 3. Decompress the kernel image
+ ------------------------------
+
+ Requirement: OPTIONAL
+
+ The AArch64 kernel does not currently provide a decompressor and
+ therefore requires decompression (gzip etc.) to be performed by the boot
+ loader if a compressed Image target (e.g. Image.gz) is used. For
+ bootloaders that do not implement this requirement, the uncompressed
+ Image target is available instead.
+
+
+ 4. Call the kernel image
+ ------------------------
+
+ Requirement: MANDATORY
+
+ The decompressed kernel image contains a 64-byte header as follows::
+
+ u32 code0; /* Executable code */
+ u32 code1; /* Executable code */
+ u64 text_offset; /* Image load offset, little endian */
+ u64 image_size; /* Effective Image size, little endian */
+ u64 flags; /* kernel flags, little endian */
+ u64 res2 = 0; /* reserved */
+ u64 res3 = 0; /* reserved */
+ u64 res4 = 0; /* reserved */
+ u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
+ u32 res5; /* reserved (used for PE COFF offset) */
+
+
+ Header notes:
+
+ - As of v3.17, all fields are little endian unless stated otherwise.
+
+ - code0/code1 are responsible for branching to stext.
+
+ - when booting through EFI, code0/code1 are initially skipped.
+ res5 is an offset to the PE header and the PE header has the EFI
+ entry point (efi_stub_entry). When the stub has done its work, it
+ jumps to code0 to resume the normal boot process.
+
+ - Prior to v3.17, the endianness of text_offset was not specified. In
+ these cases image_size is zero and text_offset is 0x80000 in the
+ endianness of the kernel. Where image_size is non-zero image_size is
+ little-endian and must be respected. Where image_size is zero,
+ text_offset can be assumed to be 0x80000.
+
+ - The flags field (introduced in v3.17) is a little-endian 64-bit field
+ composed as follows:
+
+ ============= ===============================================================
+ Bit 0 Kernel endianness. 1 if BE, 0 if LE.
+ Bit 1-2 Kernel Page size.
+
+ * 0 - Unspecified.
+ * 1 - 4K
+ * 2 - 16K
+ * 3 - 64K
+ Bit 3 Kernel physical placement
+
+ 0
+ 2MB aligned base should be as close as possible
+ to the base of DRAM, since memory below it is not
+ accessible via the linear mapping
+ 1
+ 2MB aligned base such that all image_size bytes
+ counted from the start of the image are within
+ the 48-bit addressable range of physical memory
+ Bits 4-63 Reserved.
+ ============= ===============================================================
+
+ - When image_size is zero, a bootloader should attempt to keep as much
+ memory as possible free for use by the kernel immediately after the
+ end of the kernel image. The amount of space required will vary
+ depending on selected features, and is effectively unbound.
+
+ The Image must be placed text_offset bytes from a 2MB aligned base
+ address anywhere in usable system RAM and called there. The region
+ between the 2 MB aligned base address and the start of the image has no
+ special significance to the kernel, and may be used for other purposes.
+ At least image_size bytes from the start of the image must be free for
+ use by the kernel.
+ NOTE: versions prior to v4.6 cannot make use of memory below the
+ physical offset of the Image so it is recommended that the Image be
+ placed as close as possible to the start of system RAM.
+
+ If an initrd/initramfs is passed to the kernel at boot, it must reside
+ entirely within a 1 GB aligned physical memory window of up to 32 GB in
+ size that fully covers the kernel Image as well.
+
+ Any memory described to the kernel (even that below the start of the
+ image) which is not marked as reserved from the kernel (e.g., with a
+ memreserve region in the device tree) will be considered as available to
+ the kernel.
+
+ Before jumping into the kernel, the following conditions must be met:
+
+ - Quiesce all DMA capable devices so that memory does not get
+ corrupted by bogus network packets or disk data. This will save
+ you many hours of debug.
+
+ - Primary CPU general-purpose register settings:
+
+ - x0 = physical address of device tree blob (dtb) in system RAM.
+ - x1 = 0 (reserved for future use)
+ - x2 = 0 (reserved for future use)
+ - x3 = 0 (reserved for future use)
+
+ - CPU mode
+
+ All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
+ IRQ and FIQ).
+ The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order
+ to have access to the virtualisation extensions), or in EL1.
+
+ - Caches, MMUs
+
+ The MMU must be off.
+
+ The instruction cache may be on or off, and must not hold any stale
+ entries corresponding to the loaded kernel image.
+
+ The address range corresponding to the loaded kernel image must be
+ cleaned to the PoC. In the presence of a system cache or other
+ coherent masters with caches enabled, this will typically require
+ cache maintenance by VA rather than set/way operations.
+ System caches which respect the architected cache maintenance by VA
+ operations must be configured and may be enabled.
+ System caches which do not respect architected cache maintenance by VA
+ operations (not recommended) must be configured and disabled.
+
+ - Architected timers
+
+ CNTFRQ must be programmed with the timer frequency and CNTVOFF must
+ be programmed with a consistent value on all CPUs. If entering the
+ kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where
+ available.
+
+ - Coherency
+
+ All CPUs to be booted by the kernel must be part of the same coherency
+ domain on entry to the kernel. This may require IMPLEMENTATION DEFINED
+ initialisation to enable the receiving of maintenance operations on
+ each CPU.
+
+ - System registers
+
+ All writable architected system registers at or below the exception
+ level where the kernel image will be entered must be initialised by
+ software at a higher exception level to prevent execution in an UNKNOWN
+ state.
+
+ For all systems:
+ - If EL3 is present:
+
+ - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
+ executing on.
+ - The value of SCR_EL3.FIQ must be the same as the one present at boot
+ time whenever the kernel is executing.
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.HCE (bit 8) must be initialised to 0b1.
+
+ For systems with a GICv3 interrupt controller to be used in v3 mode:
+ - If EL3 is present:
+
+ - ICC_SRE_EL3.Enable (bit 3) must be initialised to 0b1.
+ - ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
+ - ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across
+ all CPUs the kernel is executing on, and must stay constant
+ for the lifetime of the kernel.
+
+ - If the kernel is entered at EL1:
+
+ - ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
+ - ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
+
+ - The DT or ACPI tables must describe a GICv3 interrupt controller.
+
+ For systems with a GICv3 interrupt controller to be used in
+ compatibility (v2) mode:
+
+ - If EL3 is present:
+
+ ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0.
+
+ - If the kernel is entered at EL1:
+
+ ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.
+
+ - The DT or ACPI tables must describe a GICv2 interrupt controller.
+
+ For CPUs with pointer authentication functionality:
+
+ - If EL3 is present:
+
+ - SCR_EL3.APK (bit 16) must be initialised to 0b1
+ - SCR_EL3.API (bit 17) must be initialised to 0b1
+
+ - If the kernel is entered at EL1:
+
+ - HCR_EL2.APK (bit 40) must be initialised to 0b1
+ - HCR_EL2.API (bit 41) must be initialised to 0b1
+
+ For CPUs with Activity Monitors Unit v1 (AMUv1) extension present:
+
+ - If EL3 is present:
+
+ - CPTR_EL3.TAM (bit 30) must be initialised to 0b0
+ - CPTR_EL2.TAM (bit 30) must be initialised to 0b0
+ - AMCNTENSET0_EL0 must be initialised to 0b1111
+ - AMCNTENSET1_EL0 must be initialised to a platform specific value
+ having 0b1 set for the corresponding bit for each of the auxiliary
+ counters present.
+
+ - If the kernel is entered at EL1:
+
+ - AMCNTENSET0_EL0 must be initialised to 0b1111
+ - AMCNTENSET1_EL0 must be initialised to a platform specific value
+ having 0b1 set for the corresponding bit for each of the auxiliary
+ counters present.
+
+ For CPUs with the Fine Grained Traps (FEAT_FGT) extension present:
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
+
+ For CPUs with support for HCRX_EL2 (FEAT_HCX) present:
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.HXEn (bit 38) must be initialised to 0b1.
+
+ For CPUs with Advanced SIMD and floating point support:
+
+ - If EL3 is present:
+
+ - CPTR_EL3.TFP (bit 10) must be initialised to 0b0.
+
+ - If EL2 is present and the kernel is entered at EL1:
+
+ - CPTR_EL2.TFP (bit 10) must be initialised to 0b0.
+
+ For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
+
+ - if EL3 is present:
+
+ - CPTR_EL3.EZ (bit 8) must be initialised to 0b1.
+
+ - ZCR_EL3.LEN must be initialised to the same value for all CPUs the
+ kernel is executed on.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - CPTR_EL2.TZ (bit 8) must be initialised to 0b0.
+
+ - CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11.
+
+ - ZCR_EL2.LEN must be initialised to the same value for all CPUs the
+ kernel will execute on.
+
+ For CPUs with the Scalable Matrix Extension (FEAT_SME):
+
+ - If EL3 is present:
+
+ - CPTR_EL3.ESM (bit 12) must be initialised to 0b1.
+
+ - SCR_EL3.EnTP2 (bit 41) must be initialised to 0b1.
+
+ - SMCR_EL3.LEN must be initialised to the same value for all CPUs the
+ kernel will execute on.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - CPTR_EL2.TSM (bit 12) must be initialised to 0b0.
+
+ - CPTR_EL2.SMEN (bits 25:24) must be initialised to 0b11.
+
+ - SCTLR_EL2.EnTP2 (bit 60) must be initialised to 0b1.
+
+ - SMCR_EL2.LEN must be initialised to the same value for all CPUs the
+ kernel will execute on.
+
+ - HWFGRTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
+
+ - HWFGWTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
+
+ - HWFGRTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
+
+ - HWFGWTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
+
+ For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64):
+
+ - If EL3 is present:
+
+ - SMCR_EL3.FA64 (bit 31) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - SMCR_EL2.FA64 (bit 31) must be initialised to 0b1.
+
+ For CPUs with the Memory Tagging Extension feature (FEAT_MTE2):
+
+ - If EL3 is present:
+
+ - SCR_EL3.ATA (bit 26) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
+
+ For CPUs with the Scalable Matrix Extension version 2 (FEAT_SME2):
+
+ - If EL3 is present:
+
+ - SMCR_EL3.EZT0 (bit 30) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1.
+
++ For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS):
++
++ - If the kernel is entered at EL1 and EL2 is present:
++
++ - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1.
++
++ For CPUs with the Extended Translation Control Register feature (FEAT_TCR2):
++
++ - If EL3 is present:
++
++ - SCR_EL3.TCR2En (bit 43) must be initialised to 0b1.
++
++ - If the kernel is entered at EL1 and EL2 is present:
++
++ - HCRX_EL2.TCR2En (bit 14) must be initialised to 0b1.
++
++ For CPUs with the Stage 1 Permission Indirection Extension feature (FEAT_S1PIE):
++
++ - If EL3 is present:
++
++ - SCR_EL3.PIEn (bit 45) must be initialised to 0b1.
++
++ - If the kernel is entered at EL1 and EL2 is present:
++
++ - HFGRTR_EL2.nPIR_EL1 (bit 58) must be initialised to 0b1.
++
++ - HFGWTR_EL2.nPIR_EL1 (bit 58) must be initialised to 0b1.
++
++ - HFGRTR_EL2.nPIRE0_EL1 (bit 57) must be initialised to 0b1.
++
++ - HFGRWR_EL2.nPIRE0_EL1 (bit 57) must be initialised to 0b1.
++
+ The requirements described above for CPU mode, caches, MMUs, architected
+ timers, coherency and system registers apply to all CPUs. All CPUs must
+ enter the kernel in the same exception level. Where the values documented
+ disable traps it is permissible for these traps to be enabled so long as
+ those traps are handled transparently by higher exception levels as though
+ the values documented were set.
+
+ The boot loader is expected to enter the kernel on each CPU in the
+ following manner:
+
+ - The primary CPU must jump directly to the first instruction of the
+ kernel image. The device tree blob passed by this CPU must contain
+ an 'enable-method' property for each cpu node. The supported
+ enable-methods are described below.
+
+ It is expected that the bootloader will generate these device tree
+ properties and insert them into the blob prior to kernel entry.
+
+ - CPUs with a "spin-table" enable-method must have a 'cpu-release-addr'
+ property in their cpu node. This property identifies a
+ naturally-aligned 64-bit zero-initalised memory location.
+
+ These CPUs should spin outside of the kernel in a reserved area of
+ memory (communicated to the kernel by a /memreserve/ region in the
+ device tree) polling their cpu-release-addr location, which must be
+ contained in the reserved region. A wfe instruction may be inserted
+ to reduce the overhead of the busy-loop and a sev will be issued by
+ the primary CPU. When a read of the location pointed to by the
+ cpu-release-addr returns a non-zero value, the CPU must jump to this
+ value. The value will be written as a single 64-bit little-endian
+ value, so CPUs must convert the read value to their native endianness
+ before jumping to it.
+
+ - CPUs with a "psci" enable method should remain outside of
+ the kernel (i.e. outside of the regions of memory described to the
+ kernel in the memory node, or in a reserved area of memory described
+ to the kernel by a /memreserve/ region in the device tree). The
+ kernel will issue CPU_ON calls as described in ARM document number ARM
+ DEN 0022A ("Power State Coordination Interface System Software on ARM
+ processors") to bring CPUs into the kernel.
+
+ The device tree should contain a 'psci' node, as described in
+ Documentation/devicetree/bindings/arm/psci.yaml.
+
+ - Secondary CPU general-purpose register settings
+
+ - x0 = 0 (reserved for future use)
+ - x1 = 0 (reserved for future use)
+ - x2 = 0 (reserved for future use)
+ - x3 = 0 (reserved for future use)
--- /dev/null
+ ===========================
+ ARM64 CPU Feature Registers
+ ===========================
+
+ Author: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+
+ This file describes the ABI for exporting the AArch64 CPU ID/feature
+ registers to userspace. The availability of this ABI is advertised
+ via the HWCAP_CPUID in HWCAPs.
+
+ 1. Motivation
+ -------------
+
+ The ARM architecture defines a set of feature registers, which describe
+ the capabilities of the CPU/system. Access to these system registers is
+ restricted from EL0 and there is no reliable way for an application to
+ extract this information to make better decisions at runtime. There is
+ limited information available to the application via HWCAPs, however
+ there are some issues with their usage.
+
+ a) Any change to the HWCAPs requires an update to userspace (e.g libc)
+ to detect the new changes, which can take a long time to appear in
+ distributions. Exposing the registers allows applications to get the
+ information without requiring updates to the toolchains.
+
+ b) Access to HWCAPs is sometimes limited (e.g prior to libc, or
+ when ld is initialised at startup time).
+
+ c) HWCAPs cannot represent non-boolean information effectively. The
+ architecture defines a canonical format for representing features
+ in the ID registers; this is well defined and is capable of
+ representing all valid architecture variations.
+
+
+ 2. Requirements
+ ---------------
+
+ a) Safety:
+
+ Applications should be able to use the information provided by the
+ infrastructure to run safely across the system. This has greater
+ implications on a system with heterogeneous CPUs.
+ The infrastructure exports a value that is safe across all the
+ available CPU on the system.
+
+ e.g, If at least one CPU doesn't implement CRC32 instructions, while
+ others do, we should report that the CRC32 is not implemented.
+ Otherwise an application could crash when scheduled on the CPU
+ which doesn't support CRC32.
+
+ b) Security:
+
+ Applications should only be able to receive information that is
+ relevant to the normal operation in userspace. Hence, some of the
+ fields are masked out(i.e, made invisible) and their values are set to
+ indicate the feature is 'not supported'. See Section 4 for the list
+ of visible features. Also, the kernel may manipulate the fields
+ based on what it supports. e.g, If FP is not supported by the
+ kernel, the values could indicate that the FP is not available
+ (even when the CPU provides it).
+
+ c) Implementation Defined Features
+
+ The infrastructure doesn't expose any register which is
+ IMPLEMENTATION DEFINED as per ARMv8-A Architecture.
+
+ d) CPU Identification:
+
+ MIDR_EL1 is exposed to help identify the processor. On a
+ heterogeneous system, this could be racy (just like getcpu()). The
+ process could be migrated to another CPU by the time it uses the
+ register value, unless the CPU affinity is set. Hence, there is no
+ guarantee that the value reflects the processor that it is
+ currently executing on. The REVIDR is not exposed due to this
+ constraint, as REVIDR makes sense only in conjunction with the
+ MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
+ at::
+
+ /sys/devices/system/cpu/cpu$ID/regs/identification/
+ \- midr
+ \- revidr
+
+ 3. Implementation
+ --------------------
+
+ The infrastructure is built on the emulation of the 'MRS' instruction.
+ Accessing a restricted system register from an application generates an
+ exception and ends up in SIGILL being delivered to the process.
+ The infrastructure hooks into the exception handler and emulates the
+ operation if the source belongs to the supported system register space.
+
+ The infrastructure emulates only the following system register space::
+
+ Op0=3, Op1=0, CRn=0, CRm=0,2,3,4,5,6,7
+
+ (See Table C5-6 'System instruction encodings for non-Debug System
+ register accesses' in ARMv8 ARM DDI 0487A.h, for the list of
+ registers).
+
+ The following rules are applied to the value returned by the
+ infrastructure:
+
+ a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0.
+ b) The value of a reserved field is populated with the reserved
+ value as defined by the architecture.
+ c) The value of a 'visible' field holds the system wide safe value
+ for the particular feature (except for MIDR_EL1, see section 4).
+ d) All other fields (i.e, invisible fields) are set to indicate
+ the feature is missing (as defined by the architecture).
+
+ 4. List of registers with visible features
+ -------------------------------------------
+
+ 1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | RNDR | [63-60] | y |
+ +------------------------------+---------+---------+
+ | TS | [55-52] | y |
+ +------------------------------+---------+---------+
+ | FHM | [51-48] | y |
+ +------------------------------+---------+---------+
+ | DP | [47-44] | y |
+ +------------------------------+---------+---------+
+ | SM4 | [43-40] | y |
+ +------------------------------+---------+---------+
+ | SM3 | [39-36] | y |
+ +------------------------------+---------+---------+
+ | SHA3 | [35-32] | y |
+ +------------------------------+---------+---------+
+ | RDM | [31-28] | y |
+ +------------------------------+---------+---------+
+ | ATOMICS | [23-20] | y |
+ +------------------------------+---------+---------+
+ | CRC32 | [19-16] | y |
+ +------------------------------+---------+---------+
+ | SHA2 | [15-12] | y |
+ +------------------------------+---------+---------+
+ | SHA1 | [11-8] | y |
+ +------------------------------+---------+---------+
+ | AES | [7-4] | y |
+ +------------------------------+---------+---------+
+
+
+ 2) ID_AA64PFR0_EL1 - Processor Feature Register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | DIT | [51-48] | y |
+ +------------------------------+---------+---------+
+ | SVE | [35-32] | y |
+ +------------------------------+---------+---------+
+ | GIC | [27-24] | n |
+ +------------------------------+---------+---------+
+ | AdvSIMD | [23-20] | y |
+ +------------------------------+---------+---------+
+ | FP | [19-16] | y |
+ +------------------------------+---------+---------+
+ | EL3 | [15-12] | n |
+ +------------------------------+---------+---------+
+ | EL2 | [11-8] | n |
+ +------------------------------+---------+---------+
+ | EL1 | [7-4] | n |
+ +------------------------------+---------+---------+
+ | EL0 | [3-0] | n |
+ +------------------------------+---------+---------+
+
+
+ 3) ID_AA64PFR1_EL1 - Processor Feature Register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | MTE | [11-8] | y |
+ +------------------------------+---------+---------+
+ | SSBS | [7-4] | y |
+ +------------------------------+---------+---------+
+ | BT | [3-0] | y |
+ +------------------------------+---------+---------+
+
+
+ 4) MIDR_EL1 - Main ID Register
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | Implementer | [31-24] | y |
+ +------------------------------+---------+---------+
+ | Variant | [23-20] | y |
+ +------------------------------+---------+---------+
+ | Architecture | [19-16] | y |
+ +------------------------------+---------+---------+
+ | PartNum | [15-4] | y |
+ +------------------------------+---------+---------+
+ | Revision | [3-0] | y |
+ +------------------------------+---------+---------+
+
+ NOTE: The 'visible' fields of MIDR_EL1 will contain the value
+ as available on the CPU where it is fetched and is not a system
+ wide safe value.
+
+ 5) ID_AA64ISAR1_EL1 - Instruction set attribute register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | I8MM | [55-52] | y |
+ +------------------------------+---------+---------+
+ | DGH | [51-48] | y |
+ +------------------------------+---------+---------+
+ | BF16 | [47-44] | y |
+ +------------------------------+---------+---------+
+ | SB | [39-36] | y |
+ +------------------------------+---------+---------+
+ | FRINTTS | [35-32] | y |
+ +------------------------------+---------+---------+
+ | GPI | [31-28] | y |
+ +------------------------------+---------+---------+
+ | GPA | [27-24] | y |
+ +------------------------------+---------+---------+
+ | LRCPC | [23-20] | y |
+ +------------------------------+---------+---------+
+ | FCMA | [19-16] | y |
+ +------------------------------+---------+---------+
+ | JSCVT | [15-12] | y |
+ +------------------------------+---------+---------+
+ | API | [11-8] | y |
+ +------------------------------+---------+---------+
+ | APA | [7-4] | y |
+ +------------------------------+---------+---------+
+ | DPB | [3-0] | y |
+ +------------------------------+---------+---------+
+
+ 6) ID_AA64MMFR0_EL1 - Memory model feature register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | ECV | [63-60] | y |
+ +------------------------------+---------+---------+
+
+ 7) ID_AA64MMFR2_EL1 - Memory model feature register 2
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | AT | [35-32] | y |
+ +------------------------------+---------+---------+
+
+ 8) ID_AA64ZFR0_EL1 - SVE feature ID register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | F64MM | [59-56] | y |
+ +------------------------------+---------+---------+
+ | F32MM | [55-52] | y |
+ +------------------------------+---------+---------+
+ | I8MM | [47-44] | y |
+ +------------------------------+---------+---------+
+ | SM4 | [43-40] | y |
+ +------------------------------+---------+---------+
+ | SHA3 | [35-32] | y |
+ +------------------------------+---------+---------+
+ | BF16 | [23-20] | y |
+ +------------------------------+---------+---------+
+ | BitPerm | [19-16] | y |
+ +------------------------------+---------+---------+
+ | AES | [7-4] | y |
+ +------------------------------+---------+---------+
+ | SVEVer | [3-0] | y |
+ +------------------------------+---------+---------+
+
+ 8) ID_AA64MMFR1_EL1 - Memory model feature register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | AFP | [47-44] | y |
+ +------------------------------+---------+---------+
+
+ 9) ID_AA64ISAR2_EL1 - Instruction set attribute register 2
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
++ | MOPS | [19-16] | y |
++ +------------------------------+---------+---------+
+ | RPRES | [7-4] | y |
+ +------------------------------+---------+---------+
+ | WFXT | [3-0] | y |
+ +------------------------------+---------+---------+
+
+ 10) MVFR0_EL1 - AArch32 Media and VFP Feature Register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | FPDP | [11-8] | y |
+ +------------------------------+---------+---------+
+
+ 11) MVFR1_EL1 - AArch32 Media and VFP Feature Register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | SIMDFMAC | [31-28] | y |
+ +------------------------------+---------+---------+
+ | SIMDSP | [19-16] | y |
+ +------------------------------+---------+---------+
+ | SIMDInt | [15-12] | y |
+ +------------------------------+---------+---------+
+ | SIMDLS | [11-8] | y |
+ +------------------------------+---------+---------+
+
+ 12) ID_ISAR5_EL1 - AArch32 Instruction Set Attribute Register 5
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | CRC32 | [19-16] | y |
+ +------------------------------+---------+---------+
+ | SHA2 | [15-12] | y |
+ +------------------------------+---------+---------+
+ | SHA1 | [11-8] | y |
+ +------------------------------+---------+---------+
+ | AES | [7-4] | y |
+ +------------------------------+---------+---------+
+
+
+ Appendix I: Example
+ -------------------
+
+ ::
+
+ /*
+ * Sample program to demonstrate the MRS emulation ABI.
+ *
+ * Copyright (C) 2015-2016, ARM Ltd
+ *
+ * Author: Suzuki K Poulose <suzuki.poulose@arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+ #include <asm/hwcap.h>
+ #include <stdio.h>
+ #include <sys/auxv.h>
+
+ #define get_cpu_ftr(id) ({ \
+ unsigned long __val; \
+ asm("mrs %0, "#id : "=r" (__val)); \
+ printf("%-20s: 0x%016lx\n", #id, __val); \
+ })
+
+ int main(void)
+ {
+
+ if (!(getauxval(AT_HWCAP) & HWCAP_CPUID)) {
+ fputs("CPUID registers unavailable\n", stderr);
+ return 1;
+ }
+
+ get_cpu_ftr(ID_AA64ISAR0_EL1);
+ get_cpu_ftr(ID_AA64ISAR1_EL1);
+ get_cpu_ftr(ID_AA64MMFR0_EL1);
+ get_cpu_ftr(ID_AA64MMFR1_EL1);
+ get_cpu_ftr(ID_AA64PFR0_EL1);
+ get_cpu_ftr(ID_AA64PFR1_EL1);
+ get_cpu_ftr(ID_AA64DFR0_EL1);
+ get_cpu_ftr(ID_AA64DFR1_EL1);
+
+ get_cpu_ftr(MIDR_EL1);
+ get_cpu_ftr(MPIDR_EL1);
+ get_cpu_ftr(REVIDR_EL1);
+
+ #if 0
+ /* Unexposed register access causes SIGILL */
+ get_cpu_ftr(ID_MMFR0_EL1);
+ #endif
+
+ return 0;
+ }
--- /dev/null
+ .. _elf_hwcaps_index:
+
+ ================
+ ARM64 ELF hwcaps
+ ================
+
+ This document describes the usage and semantics of the arm64 ELF hwcaps.
+
+
+ 1. Introduction
+ ---------------
+
+ Some hardware or software features are only available on some CPU
+ implementations, and/or with certain kernel configurations, but have no
+ architected discovery mechanism available to userspace code at EL0. The
+ kernel exposes the presence of these features to userspace through a set
+ of flags called hwcaps, exposed in the auxiliary vector.
+
+ Userspace software can test for features by acquiring the AT_HWCAP or
+ AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
+ flags are set, e.g.::
+
+ bool floating_point_is_present(void)
+ {
+ unsigned long hwcaps = getauxval(AT_HWCAP);
+ if (hwcaps & HWCAP_FP)
+ return true;
+
+ return false;
+ }
+
+ Where software relies on a feature described by a hwcap, it should check
+ the relevant hwcap flag to verify that the feature is present before
+ attempting to make use of the feature.
+
+ Features cannot be probed reliably through other means. When a feature
+ is not available, attempting to use it may result in unpredictable
+ behaviour, and is not guaranteed to result in any reliable indication
+ that the feature is unavailable, such as a SIGILL.
+
+
+ 2. Interpretation of hwcaps
+ ---------------------------
+
+ The majority of hwcaps are intended to indicate the presence of features
+ which are described by architected ID registers inaccessible to
+ userspace code at EL0. These hwcaps are defined in terms of ID register
+ fields, and should be interpreted with reference to the definition of
+ these fields in the ARM Architecture Reference Manual (ARM ARM).
+
+ Such hwcaps are described below in the form::
+
+ Functionality implied by idreg.field == val.
+
+ Such hwcaps indicate the availability of functionality that the ARM ARM
+ defines as being present when idreg.field has value val, but do not
+ indicate that idreg.field is precisely equal to val, nor do they
+ indicate the absence of functionality implied by other values of
+ idreg.field.
+
+ Other hwcaps may indicate the presence of features which cannot be
+ described by ID registers alone. These may be described without
+ reference to ID registers, and may refer to other documentation.
+
+
+ 3. The hwcaps exposed in AT_HWCAP
+ ---------------------------------
+
+ HWCAP_FP
+ Functionality implied by ID_AA64PFR0_EL1.FP == 0b0000.
+
+ HWCAP_ASIMD
+ Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0000.
+
+ HWCAP_EVTSTRM
+ The generic timer is configured to generate events at a frequency of
+ approximately 10KHz.
+
+ HWCAP_AES
+ Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001.
+
+ HWCAP_PMULL
+ Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0010.
+
+ HWCAP_SHA1
+ Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001.
+
+ HWCAP_SHA2
+ Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001.
+
+ HWCAP_CRC32
+ Functionality implied by ID_AA64ISAR0_EL1.CRC32 == 0b0001.
+
+ HWCAP_ATOMICS
+ Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0010.
+
+ HWCAP_FPHP
+ Functionality implied by ID_AA64PFR0_EL1.FP == 0b0001.
+
+ HWCAP_ASIMDHP
+ Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0001.
+
+ HWCAP_CPUID
+ EL0 access to certain ID registers is available, to the extent
+ described by Documentation/arch/arm64/cpu-feature-registers.rst.
+
+ These ID registers may imply the availability of features.
+
+ HWCAP_ASIMDRDM
+ Functionality implied by ID_AA64ISAR0_EL1.RDM == 0b0001.
+
+ HWCAP_JSCVT
+ Functionality implied by ID_AA64ISAR1_EL1.JSCVT == 0b0001.
+
+ HWCAP_FCMA
+ Functionality implied by ID_AA64ISAR1_EL1.FCMA == 0b0001.
+
+ HWCAP_LRCPC
+ Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0001.
+
+ HWCAP_DCPOP
+ Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001.
+
+ HWCAP_SHA3
+ Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
+
+ HWCAP_SM3
+ Functionality implied by ID_AA64ISAR0_EL1.SM3 == 0b0001.
+
+ HWCAP_SM4
+ Functionality implied by ID_AA64ISAR0_EL1.SM4 == 0b0001.
+
+ HWCAP_ASIMDDP
+ Functionality implied by ID_AA64ISAR0_EL1.DP == 0b0001.
+
+ HWCAP_SHA512
+ Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010.
+
+ HWCAP_SVE
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
+
+ HWCAP_ASIMDFHM
+ Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
+
+ HWCAP_DIT
+ Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001.
+
+ HWCAP_USCAT
+ Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001.
+
+ HWCAP_ILRCPC
+ Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0010.
+
+ HWCAP_FLAGM
+ Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001.
+
+ HWCAP_SSBS
+ Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010.
+
+ HWCAP_SB
+ Functionality implied by ID_AA64ISAR1_EL1.SB == 0b0001.
+
+ HWCAP_PACA
+ Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or
+ ID_AA64ISAR1_EL1.API == 0b0001, as described by
+ Documentation/arch/arm64/pointer-authentication.rst.
+
+ HWCAP_PACG
+ Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
+ ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
+ Documentation/arch/arm64/pointer-authentication.rst.
+
+ HWCAP2_DCPODP
+ Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
+
+ HWCAP2_SVE2
+ Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
+
+ HWCAP2_SVEAES
+ Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
+
+ HWCAP2_SVEPMULL
+ Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010.
+
+ HWCAP2_SVEBITPERM
+ Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001.
+
+ HWCAP2_SVESHA3
+ Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001.
+
+ HWCAP2_SVESM4
+ Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
+
+ HWCAP2_FLAGM2
+ Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
+
+ HWCAP2_FRINT
+ Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
+
+ HWCAP2_SVEI8MM
+ Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001.
+
+ HWCAP2_SVEF32MM
+ Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001.
+
+ HWCAP2_SVEF64MM
+ Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001.
+
+ HWCAP2_SVEBF16
+ Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001.
+
+ HWCAP2_I8MM
+ Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
+
+ HWCAP2_BF16
+ Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0001.
+
+ HWCAP2_DGH
+ Functionality implied by ID_AA64ISAR1_EL1.DGH == 0b0001.
+
+ HWCAP2_RNG
+ Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
+
+ HWCAP2_BTI
+ Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
+
+ HWCAP2_MTE
+ Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
+ by Documentation/arch/arm64/memory-tagging-extension.rst.
+
+ HWCAP2_ECV
+ Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
+
+ HWCAP2_AFP
+ Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
+
+ HWCAP2_RPRES
+ Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
+
+ HWCAP2_MTE3
+ Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
+ by Documentation/arch/arm64/memory-tagging-extension.rst.
+
+ HWCAP2_SME
+ Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described
+ by Documentation/arch/arm64/sme.rst.
+
+ HWCAP2_SME_I16I64
+ Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111.
+
+ HWCAP2_SME_F64F64
+ Functionality implied by ID_AA64SMFR0_EL1.F64F64 == 0b1.
+
+ HWCAP2_SME_I8I32
+ Functionality implied by ID_AA64SMFR0_EL1.I8I32 == 0b1111.
+
+ HWCAP2_SME_F16F32
+ Functionality implied by ID_AA64SMFR0_EL1.F16F32 == 0b1.
+
+ HWCAP2_SME_B16F32
+ Functionality implied by ID_AA64SMFR0_EL1.B16F32 == 0b1.
+
+ HWCAP2_SME_F32F32
+ Functionality implied by ID_AA64SMFR0_EL1.F32F32 == 0b1.
+
+ HWCAP2_SME_FA64
+ Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1.
+
+ HWCAP2_WFXT
+ Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
+
+ HWCAP2_EBF16
+ Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
+
+ HWCAP2_SVE_EBF16
+ Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0010.
+
+ HWCAP2_CSSC
+ Functionality implied by ID_AA64ISAR2_EL1.CSSC == 0b0001.
+
+ HWCAP2_RPRFM
+ Functionality implied by ID_AA64ISAR2_EL1.RPRFM == 0b0001.
+
+ HWCAP2_SVE2P1
+ Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0010.
+
+ HWCAP2_SME2
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0001.
+
+ HWCAP2_SME2P1
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0010.
+
+ HWCAP2_SMEI16I32
+ Functionality implied by ID_AA64SMFR0_EL1.I16I32 == 0b0101
+
+ HWCAP2_SMEBI32I32
+ Functionality implied by ID_AA64SMFR0_EL1.BI32I32 == 0b1
+
+ HWCAP2_SMEB16B16
+ Functionality implied by ID_AA64SMFR0_EL1.B16B16 == 0b1
+
+ HWCAP2_SMEF16F16
+ Functionality implied by ID_AA64SMFR0_EL1.F16F16 == 0b1
+
++HWCAP2_MOPS
++ Functionality implied by ID_AA64ISAR2_EL1.MOPS == 0b0001.
++
+ 4. Unused AT_HWCAP bits
+ -----------------------
+
+ For interoperation with userspace, the kernel guarantees that bits 62
+ and 63 of AT_HWCAP will always be returned as 0.
--- /dev/null
+ .. _arm64_index:
+
+ ==================
+ ARM64 Architecture
+ ==================
+
+ .. toctree::
+ :maxdepth: 1
+
+ acpi_object_usage
+ amu
+ arm-acpi
+ asymmetric-32bit
+ booting
+ cpu-feature-registers
+ elf_hwcaps
+ hugetlbpage
++ kdump
+ legacy_instructions
+ memory
+ memory-tagging-extension
+ perf
+ pointer-authentication
++ ptdump
+ silicon-errata
+ sme
+ sve
+ tagged-address-abi
+ tagged-pointers
+
+ features
+
+ .. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
--- /dev/null
--- /dev/null
++=======================================
++crashkernel memory reservation on arm64
++=======================================
++
++Author: Baoquan He <bhe@redhat.com>
++
++Kdump mechanism is used to capture a corrupted kernel vmcore so that
++it can be subsequently analyzed. In order to do this, a preliminarily
++reserved memory is needed to pre-load the kdump kernel and boot such
++kernel if corruption happens.
++
++That reserved memory for kdump is adapted to be able to minimally
++accommodate the kdump kernel and the user space programs needed for the
++vmcore collection.
++
++Kernel parameter
++================
++
++Through the kernel parameters below, memory can be reserved accordingly
++during the early stage of the first kernel booting so that a continuous
++large chunk of memomy can be found. The low memory reservation needs to
++be considered if the crashkernel is reserved from the high memory area.
++
++- crashkernel=size@offset
++- crashkernel=size
++- crashkernel=size,high crashkernel=size,low
++
++Low memory and high memory
++==========================
++
++For kdump reservations, low memory is the memory area under a specific
++limit, usually decided by the accessible address bits of the DMA-capable
++devices needed by the kdump kernel to run. Those devices not related to
++vmcore dumping can be ignored. On arm64, the low memory upper bound is
++not fixed: it is 1G on the RPi4 platform but 4G on most other systems.
++On special kernels built with CONFIG_ZONE_(DMA|DMA32) disabled, the
++whole system RAM is low memory. Outside of the low memory described
++above, the rest of system RAM is considered high memory.
++
++Implementation
++==============
++
++1) crashkernel=size@offset
++--------------------------
++
++The crashkernel memory must be reserved at the user-specified region or
++fail if already occupied.
++
++
++2) crashkernel=size
++-------------------
++
++The crashkernel memory region will be reserved in any available position
++according to the search order:
++
++Firstly, the kernel searches the low memory area for an available region
++with the specified size.
++
++If searching for low memory fails, the kernel falls back to searching
++the high memory area for an available region of the specified size. If
++the reservation in high memory succeeds, a default size reservation in
++the low memory will be done. Currently the default size is 128M,
++sufficient for the low memory needs of the kdump kernel.
++
++Note: crashkernel=size is the recommended option for crashkernel kernel
++reservations. The user would not need to know the system memory layout
++for a specific platform.
++
++3) crashkernel=size,high crashkernel=size,low
++---------------------------------------------
++
++crashkernel=size,(high|low) are an important supplement to
++crashkernel=size. They allows the user to specify how much memory needs
++to be allocated from the high memory and low memory respectively. On
++many systems the low memory is precious and crashkernel reservations
++from this area should be kept to a minimum.
++
++To reserve memory for crashkernel=size,high, searching is first
++attempted from the high memory region. If the reservation succeeds, the
++low memory reservation will be done subsequently.
++
++If reservation from the high memory failed, the kernel falls back to
++searching the low memory with the specified size in crashkernel=,high.
++If it succeeds, no further reservation for low memory is needed.
++
++Notes:
++
++- If crashkernel=,low is not specified, the default low memory
++ reservation will be done automatically.
++
++- if crashkernel=0,low is specified, it means that the low memory
++ reservation is omitted intentionally.
--- /dev/null
- ffff800000000000 ffff800007ffffff 128MB modules
- ffff800008000000 fffffbffefffffff 124TB vmalloc
+ ==============================
+ Memory Layout on AArch64 Linux
+ ==============================
+
+ Author: Catalin Marinas <catalin.marinas@arm.com>
+
+ This document describes the virtual memory layout used by the AArch64
+ Linux kernel. The architecture allows up to 4 levels of translation
+ tables with a 4KB page size and up to 3 levels with a 64KB page size.
+
+ AArch64 Linux uses either 3 levels or 4 levels of translation tables
+ with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
+ (256TB) virtual addresses, respectively, for both user and kernel. With
+ 64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
+ virtual address, are used but the memory layout is the same.
+
+ ARMv8.2 adds optional support for Large Virtual Address space. This is
+ only available when running with a 64KB page size and expands the
+ number of descriptors in the first level of translation.
+
+ User addresses have bits 63:48 set to 0 while the kernel addresses have
+ the same bits set to 1. TTBRx selection is given by bit 63 of the
+ virtual address. The swapper_pg_dir contains only kernel (global)
+ mappings while the user pgd contains only user (non-global) mappings.
+ The swapper_pg_dir address is written to TTBR1 and never written to
+ TTBR0.
+
+
+ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
+
+ Start End Size Use
+ -----------------------------------------------------------------------
+ 0000000000000000 0000ffffffffffff 256TB user
+ ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
+ [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region]
- ffff800000000000 ffff800007ffffff 128MB modules
- ffff800008000000 fffffbffefffffff 124TB vmalloc
++ ffff800000000000 ffff80007fffffff 2GB modules
++ ffff800080000000 fffffbffefffffff 124TB vmalloc
+ fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
+ fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
+ fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
+ fffffbffff800000 fffffbffffffffff 8MB [guard region]
+ fffffc0000000000 fffffdffffffffff 2TB vmemmap
+ fffffe0000000000 ffffffffffffffff 2TB [guard region]
+
+
+ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
+
+ Start End Size Use
+ -----------------------------------------------------------------------
+ 0000000000000000 000fffffffffffff 4PB user
+ fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map
+ [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region]
++ ffff800000000000 ffff80007fffffff 2GB modules
++ ffff800080000000 fffffbffefffffff 124TB vmalloc
+ fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
+ fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
+ fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
+ fffffbffff800000 fffffbffffffffff 8MB [guard region]
+ fffffc0000000000 ffffffdfffffffff ~4TB vmemmap
+ ffffffe000000000 ffffffffffffffff 128GB [guard region]
+
+
+ Translation table lookup with 4KB pages::
+
+ +--------+--------+--------+--------+--------+--------+--------+--------+
+ |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
+ +--------+--------+--------+--------+--------+--------+--------+--------+
+ | | | | | |
+ | | | | | v
+ | | | | | [11:0] in-page offset
+ | | | | +-> [20:12] L3 index
+ | | | +-----------> [29:21] L2 index
+ | | +---------------------> [38:30] L1 index
+ | +-------------------------------> [47:39] L0 index
+ +-------------------------------------------------> [63] TTBR0/1
+
+
+ Translation table lookup with 64KB pages::
+
+ +--------+--------+--------+--------+--------+--------+--------+--------+
+ |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
+ +--------+--------+--------+--------+--------+--------+--------+--------+
+ | | | | |
+ | | | | v
+ | | | | [15:0] in-page offset
+ | | | +----------> [28:16] L3 index
+ | | +--------------------------> [41:29] L2 index
+ | +-------------------------------> [47:42] L1 index (48-bit)
+ | [51:42] L1 index (52-bit)
+ +-------------------------------------------------> [63] TTBR0/1
+
+
+ When using KVM without the Virtualization Host Extensions, the
+ hypervisor maps kernel pages in EL2 at a fixed (and potentially
+ random) offset from the linear mapping. See the kern_hyp_va macro and
+ kvm_update_va_mask function for more details. MMIO devices such as
+ GICv2 gets mapped next to the HYP idmap page, as do vectors when
+ ARM64_SPECTRE_V3A is enabled for particular CPUs.
+
+ When using KVM with the Virtualization Host Extensions, no additional
+ mappings are created, since the host kernel runs directly in EL2.
+
+ 52-bit VA support in the kernel
+ -------------------------------
+ If the ARMv8.2-LVA optional feature is present, and we are running
+ with a 64KB page size; then it is possible to use 52-bits of address
+ space for both userspace and kernel addresses. However, any kernel
+ binary that supports 52-bit must also be able to fall back to 48-bit
+ at early boot time if the hardware feature is not present.
+
+ This fallback mechanism necessitates the kernel .text to be in the
+ higher addresses such that they are invariant to 48/52-bit VAs. Due
+ to the kasan shadow being a fraction of the entire kernel VA space,
+ the end of the kasan shadow must also be in the higher half of the
+ kernel VA space for both 48/52-bit. (Switching from 48-bit to 52-bit,
+ the end of the kasan shadow is invariant and dependent on ~0UL,
+ whilst the start address will "grow" towards the lower addresses).
+
+ In order to optimise phys_to_virt and virt_to_phys, the PAGE_OFFSET
+ is kept constant at 0xFFF0000000000000 (corresponding to 52-bit),
+ this obviates the need for an extra variable read. The physvirt
+ offset and vmemmap offsets are computed at early boot to enable
+ this logic.
+
+ As a single binary will need to support both 48-bit and 52-bit VA
+ spaces, the VMEMMAP must be sized large enough for 52-bit VAs and
+ also must be sized large enough to accommodate a fixed PAGE_OFFSET.
+
+ Most code in the kernel should not need to consider the VA_BITS, for
+ code that does need to know the VA size the variables are
+ defined as follows:
+
+ VA_BITS constant the *maximum* VA space size
+
+ VA_BITS_MIN constant the *minimum* VA space size
+
+ vabits_actual variable the *actual* VA space size
+
+
+ Maximum and minimum sizes can be useful to ensure that buffers are
+ sized large enough or that addresses are positioned close enough for
+ the "worst" case.
+
+ 52-bit userspace VAs
+ --------------------
+ To maintain compatibility with software that relies on the ARMv8.0
+ VA space maximum size of 48-bits, the kernel will, by default,
+ return virtual addresses to userspace from a 48-bit range.
+
+ Software can "opt-in" to receiving VAs from a 52-bit space by
+ specifying an mmap hint parameter that is larger than 48-bit.
+
+ For example:
+
+ .. code-block:: c
+
+ maybe_high_address = mmap(~0UL, size, prot, flags,...);
+
+ It is also possible to build a debug kernel that returns addresses
+ from a 52-bit space by enabling the following kernel config options:
+
+ .. code-block:: sh
+
+ CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y
+
+ Note that this option is only intended for debugging applications
+ and should not be used in production.
--- /dev/null
--- /dev/null
++======================
++Kernel page table dump
++======================
++
++ptdump is a debugfs interface that provides a detailed dump of the
++kernel page tables. It offers a comprehensive overview of the kernel
++virtual memory layout as well as the attributes associated with the
++various regions in a human-readable format. It is useful to dump the
++kernel page tables to verify permissions and memory types. Examining the
++page table entries and permissions helps identify potential security
++vulnerabilities such as mappings with overly permissive access rights or
++improper memory protections.
++
++Memory hotplug allows dynamic expansion or contraction of available
++memory without requiring a system reboot. To maintain the consistency
++and integrity of the memory management data structures, arm64 makes use
++of the ``mem_hotplug_lock`` semaphore in write mode. Additionally, in
++read mode, ``mem_hotplug_lock`` supports an efficient implementation of
++``get_online_mems()`` and ``put_online_mems()``. These protect the
++offlining of memory being accessed by the ptdump code.
++
++In order to dump the kernel page tables, enable the following
++configurations and mount debugfs::
++
++ CONFIG_GENERIC_PTDUMP=y
++ CONFIG_PTDUMP_CORE=y
++ CONFIG_PTDUMP_DEBUGFS=y
++
++ mount -t debugfs nodev /sys/kernel/debug
++ cat /sys/kernel/debug/kernel_page_tables
++
++On analysing the output of ``cat /sys/kernel/debug/kernel_page_tables``
++one can derive information about the virtual address range of the entry,
++followed by size of the memory region covered by this entry, the
++hierarchical structure of the page tables and finally the attributes
++associated with each page. The page attributes provide information about
++access permissions, execution capability, type of mapping such as leaf
++level PTE or block level PGD, PMD and PUD, and access status of a page
++within the kernel memory. Assessing these attributes can assist in
++understanding the memory layout, access patterns and security
++characteristics of the kernel pages.
++
++Kernel virtual memory layout example::
++
++ start address end address size attributes
++ +---------------------------------------------------------------------------------------+
++ | ---[ Linear Mapping start ]---------------------------------------------------------- |
++ | .................. |
++ | 0xfff0000000000000-0xfff0000000210000 2112K PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED |
++ | 0xfff0000000210000-0xfff0000001c00000 26560K PTE ro NX SHD AF UXN MEM/NORMAL |
++ | .................. |
++ | ---[ Linear Mapping end ]------------------------------------------------------------ |
++ +---------------------------------------------------------------------------------------+
++ | ---[ Modules start ]----------------------------------------------------------------- |
++ | .................. |
++ | 0xffff800000000000-0xffff800008000000 128M PTE |
++ | .................. |
++ | ---[ Modules end ]------------------------------------------------------------------- |
++ +---------------------------------------------------------------------------------------+
++ | ---[ vmalloc() area ]---------------------------------------------------------------- |
++ | .................. |
++ | 0xffff800008010000-0xffff800008200000 1984K PTE ro x SHD AF UXN MEM/NORMAL |
++ | 0xffff800008200000-0xffff800008e00000 12M PTE ro x SHD AF CON UXN MEM/NORMAL |
++ | .................. |
++ | ---[ vmalloc() end ]----------------------------------------------------------------- |
++ +---------------------------------------------------------------------------------------+
++ | ---[ Fixmap start ]------------------------------------------------------------------ |
++ | .................. |
++ | 0xfffffbfffdb80000-0xfffffbfffdb90000 64K PTE ro x SHD AF UXN MEM/NORMAL |
++ | 0xfffffbfffdb90000-0xfffffbfffdba0000 64K PTE ro NX SHD AF UXN MEM/NORMAL |
++ | .................. |
++ | ---[ Fixmap end ]-------------------------------------------------------------------- |
++ +---------------------------------------------------------------------------------------+
++ | ---[ PCI I/O start ]----------------------------------------------------------------- |
++ | .................. |
++ | 0xfffffbfffe800000-0xfffffbffff800000 16M PTE |
++ | .................. |
++ | ---[ PCI I/O end ]------------------------------------------------------------------- |
++ +---------------------------------------------------------------------------------------+
++ | ---[ vmemmap start ]----------------------------------------------------------------- |
++ | .................. |
++ | 0xfffffc0002000000-0xfffffc0002200000 2M PTE RW NX SHD AF UXN MEM/NORMAL |
++ | 0xfffffc0002200000-0xfffffc0020000000 478M PTE |
++ | .................. |
++ | ---[ vmemmap end ]------------------------------------------------------------------- |
++ +---------------------------------------------------------------------------------------+
++
++``cat /sys/kernel/debug/kernel_page_tables`` output::
++
++ 0xfff0000001c00000-0xfff0000080000000 2020M PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED
++ 0xfff0000080000000-0xfff0000800000000 30G PMD
++ 0xfff0000800000000-0xfff0000800700000 7M PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED
++ 0xfff0000800700000-0xfff0000800710000 64K PTE ro NX SHD AF UXN MEM/NORMAL-TAGGED
++ 0xfff0000800710000-0xfff0000880000000 2089920K PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED
++ 0xfff0000880000000-0xfff0040000000000 4062G PMD
++ 0xfff0040000000000-0xffff800000000000 3964T PGD
--- /dev/null
+ =======================================
+ Silicon Errata and Software Workarounds
+ =======================================
+
+ Author: Will Deacon <will.deacon@arm.com>
+
+ Date : 27 November 2015
+
+ It is an unfortunate fact of life that hardware is often produced with
+ so-called "errata", which can cause it to deviate from the architecture
+ under specific circumstances. For hardware produced by ARM, these
+ errata are broadly classified into the following categories:
+
+ ========== ========================================================
+ Category A A critical error without a viable workaround.
+ Category B A significant or critical error with an acceptable
+ workaround.
+ Category C A minor error that is not expected to occur under normal
+ operation.
+ ========== ========================================================
+
+ For more information, consult one of the "Software Developers Errata
+ Notice" documents available on infocenter.arm.com (registration
+ required).
+
+ As far as Linux is concerned, Category B errata may require some special
+ treatment in the operating system. For example, avoiding a particular
+ sequence of code, or configuring the processor in a particular way. A
+ less common situation may require similar actions in order to declassify
+ a Category A erratum into a Category C erratum. These are collectively
+ known as "software workarounds" and are only required in the minority of
+ cases (e.g. those cases that both require a non-secure workaround *and*
+ can be triggered by Linux).
+
+ For software workarounds that may adversely impact systems unaffected by
+ the erratum in question, a Kconfig entry is added under "Kernel
+ Features" -> "ARM errata workarounds via the alternatives framework".
+ These are enabled by default and patched in at runtime when an affected
+ CPU is detected. For less-intrusive workarounds, a Kconfig option is not
+ available and the code is structured (preferably with a comment) in such
+ a way that the erratum will not be hit.
+
+ This approach can make it slightly onerous to determine exactly which
+ errata are worked around in an arbitrary kernel source tree, so this
+ file acts as a registry of software workarounds in the Linux Kernel and
+ will be updated when new workarounds are committed and backported to
+ stable kernels.
+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Implementor | Component | Erratum ID | Kconfig |
+ +================+=================+=================+=============================+
+ | Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A55 | #1530923 | ARM64_ERRATUM_1530923 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A55 | #2441007 | ARM64_ERRATUM_2441007 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A57 | #852523 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A57 | #1319537 | ARM64_ERRATUM_1319367 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A57 | #1742098 | ARM64_ERRATUM_1742098 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A72 | #853709 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A72 | #1319367 | ARM64_ERRATUM_1319367 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A72 | #1655431 | ARM64_ERRATUM_1742098 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Neoverse-N1 | #1349291 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | ARM | MMU-500 | #841119,826419 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX GICv3 | #38539 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX SMMUv2 | #27704 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX2 SMMUv3| #74 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX2 SMMUv3| #126 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Marvell | ARM-MMU-500 | #582743 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Hisilicon | Hip0{6,7} | #161010701 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Hisilicon | Hip0{6,7} | #161010803 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
+ +----------------+-----------------+-----------------+-----------------------------+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Qualcomm Tech. | Kryo/Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1463225 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1418040 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1530923 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1024718 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
+ +----------------+-----------------+-----------------+-----------------------------+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 |
+ +----------------+-----------------+-----------------+-----------------------------+
+
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
+ +----------------+-----------------+-----------------+-----------------------------+
++
+++----------------+-----------------+-----------------+-----------------------------+
++| ASR | ASR8601 | #8601001 | N/A |
+++----------------+-----------------+-----------------+-----------------------------+
projects / platform / kernel / linux-rpi.git / commitdiff