redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

docs: arm64: convert docs to ReST and rename to .rst 

The documentation is in a format that is very close to ReST format.

The conversion is actually:
  - add blank lines in order to identify paragraphs;
  - fixing tables markups;
  - adding some lists markups;
  - marking literal blocks;
  - adjust some title markups.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
alistair/sunxi64-5.4-dsi
Mauro Carvalho Chehab 2019-06-12 14:52:38 -03:00 committed by Jonathan Corbet
parent 305a99eb98
commit b693d0b372
24 changed files with 703 additions and 479 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

288
Documentation/arm64/acpi_object_usage.txt → Documentation/arm64/acpi_object_usage.rst
View File

@ -1,5 +1,7 @@
===========
ACPI Tables ACPI Tables
----------- ===========
The expectations of individual ACPI tables are discussed in the list that The expectations of individual ACPI tables are discussed in the list that
follows. follows.
@ -11,54 +13,71 @@ outside of the UEFI Forum (see Section 5.2.6 of the specification).
For ACPI on arm64, tables also fall into the following categories: For ACPI on arm64, tables also fall into the following categories:
-- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT - Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
-- Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT - Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
-- Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IORT, - Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IORT,
MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO, MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO,
TCPA, TPM2, UEFI, XENV TCPA, TPM2, UEFI, XENV
-- Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT, - Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT,
MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
====== ========================================================================
Table Usage for ARMv8 Linux Table Usage for ARMv8 Linux
----- ---------------------------------------------------------------- ====== ========================================================================
BERT Section 18.3 (signature == "BERT") BERT Section 18.3 (signature == "BERT")
== Boot Error Record Table ==
**Boot Error Record Table**
Must be supplied if RAS support is provided by the platform. It Must be supplied if RAS support is provided by the platform. It
is recommended this table be supplied. is recommended this table be supplied.
BOOT Signature Reserved (signature == "BOOT") BOOT Signature Reserved (signature == "BOOT")
== simple BOOT flag table ==
**simple BOOT flag table**
Microsoft only table, will not be supported. Microsoft only table, will not be supported.
BGRT Section 5.2.22 (signature == "BGRT") BGRT Section 5.2.22 (signature == "BGRT")
== Boot Graphics Resource Table ==
**Boot Graphics Resource Table**
Optional, not currently supported, with no real use-case for an Optional, not currently supported, with no real use-case for an
ARM server. ARM server.
CPEP Section 5.2.18 (signature == "CPEP") CPEP Section 5.2.18 (signature == "CPEP")
== Corrected Platform Error Polling table ==
**Corrected Platform Error Polling table**
Optional, not currently supported, and not recommended until such Optional, not currently supported, and not recommended until such
time as ARM-compatible hardware is available, and the specification time as ARM-compatible hardware is available, and the specification
suitably modified. suitably modified.
CSRT Signature Reserved (signature == "CSRT") CSRT Signature Reserved (signature == "CSRT")
== Core System Resources Table ==
**Core System Resources Table**
Optional, not currently supported. Optional, not currently supported.
DBG2 Signature Reserved (signature == "DBG2") DBG2 Signature Reserved (signature == "DBG2")
== DeBuG port table 2 ==
**DeBuG port table 2**
License has changed and should be usable. Optional if used instead License has changed and should be usable. Optional if used instead
of earlycon=<device> on the command line. of earlycon=<device> on the command line.
DBGP Signature Reserved (signature == "DBGP") DBGP Signature Reserved (signature == "DBGP")
== DeBuG Port table ==
**DeBuG Port table**
Microsoft only table, will not be supported. Microsoft only table, will not be supported.
DSDT Section 5.2.11.1 (signature == "DSDT") DSDT Section 5.2.11.1 (signature == "DSDT")
== Differentiated System Description Table ==
**Differentiated System Description Table**
A DSDT is required; see also SSDT. A DSDT is required; see also SSDT.
ACPI tables contain only one DSDT but can contain one or more SSDTs, ACPI tables contain only one DSDT but can contain one or more SSDTs,
@ -66,22 +85,30 @@ DSDT Section 5.2.11.1 (signature == "DSDT")
but cannot modify or replace anything in the DSDT. but cannot modify or replace anything in the DSDT.
DMAR Signature Reserved (signature == "DMAR") DMAR Signature Reserved (signature == "DMAR")
== DMA Remapping table ==
**DMA Remapping table**
x86 only table, will not be supported. x86 only table, will not be supported.
DRTM Signature Reserved (signature == "DRTM") DRTM Signature Reserved (signature == "DRTM")
== Dynamic Root of Trust for Measurement table ==
**Dynamic Root of Trust for Measurement table**
Optional, not currently supported. Optional, not currently supported.
ECDT Section 5.2.16 (signature == "ECDT") ECDT Section 5.2.16 (signature == "ECDT")
== Embedded Controller Description Table ==
**Embedded Controller Description Table**
Optional, not currently supported, but could be used on ARM if and 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 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 there are no GPE blocks defined in hardware reduced mode. This would
need to be modified in the ACPI specification. need to be modified in the ACPI specification.
EINJ Section 18.6 (signature == "EINJ") EINJ Section 18.6 (signature == "EINJ")
== Error Injection table ==
**Error Injection table**
This table is very useful for testing platform response to error This table is very useful for testing platform response to error
conditions; it allows one to inject an error into the system as conditions; it allows one to inject an error into the system as
if it had actually occurred. However, this table should not be if it had actually occurred. However, this table should not be
@ -89,27 +116,35 @@ EINJ Section 18.6 (signature == "EINJ")
and executed with the ACPICA tools only during testing. and executed with the ACPICA tools only during testing.
ERST Section 18.5 (signature == "ERST") ERST Section 18.5 (signature == "ERST")
== Error Record Serialization Table ==
**Error Record Serialization Table**
On a platform supports RAS, this table must be supplied if it is not 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 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 table is not present, UEFI run time service will be utilized to save
and retrieve hardware error information to and from a persistent store. and retrieve hardware error information to and from a persistent store.
ETDT Signature Reserved (signature == "ETDT") ETDT Signature Reserved (signature == "ETDT")
== Event Timer Description Table ==
**Event Timer Description Table**
Obsolete table, will not be supported. Obsolete table, will not be supported.
FACS Section 5.2.10 (signature == "FACS") FACS Section 5.2.10 (signature == "FACS")
== Firmware ACPI Control Structure ==
**Firmware ACPI Control Structure**
It is unlikely that this table will be terribly useful. If it is 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 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 the hardware reduced profile, and only 64-bit address fields will
be considered valid. be considered valid.
FADT Section 5.2.9 (signature == "FACP") FADT Section 5.2.9 (signature == "FACP")
== Fixed ACPI Description Table ==
**Fixed ACPI Description Table**
Required for arm64. Required for arm64.
The HW_REDUCED_ACPI flag must be set. All of the fields that are 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 to be ignored when HW_REDUCED_ACPI is set are expected to be set to
zero. zero.
@ -118,22 +153,28 @@ FADT Section 5.2.9 (signature == "FACP")
used, not FIRMWARE_CTRL. used, not FIRMWARE_CTRL.
If PSCI is used (as is recommended), make sure that ARM_BOOT_ARCH is 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 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). 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, For the DSDT that is also required, the X_DSDT field is to be used,
not the DSDT field. not the DSDT field.
FPDT Section 5.2.23 (signature == "FPDT") FPDT Section 5.2.23 (signature == "FPDT")
== Firmware Performance Data Table ==
**Firmware Performance Data Table**
Optional, not currently supported. Optional, not currently supported.
GTDT Section 5.2.24 (signature == "GTDT") GTDT Section 5.2.24 (signature == "GTDT")
== Generic Timer Description Table ==
**Generic Timer Description Table**
Required for arm64. Required for arm64.
HEST Section 18.3.2 (signature == "HEST") HEST Section 18.3.2 (signature == "HEST")
== Hardware Error Source Table ==
**Hardware Error Source Table**
ARM-specific error sources have been defined; please use those or the 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 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 Bridge), or use type 9 (Generic Hardware Error Source). Firmware first
@ -144,122 +185,174 @@ HEST Section 18.3.2 (signature == "HEST")
is recommended this table be supplied. is recommended this table be supplied.
HPET Signature Reserved (signature == "HPET") HPET Signature Reserved (signature == "HPET")
== High Precision Event timer Table ==
**High Precision Event timer Table**
x86 only table, will not be supported. x86 only table, will not be supported.
IBFT Signature Reserved (signature == "IBFT") IBFT Signature Reserved (signature == "IBFT")
== iSCSI Boot Firmware Table ==
**iSCSI Boot Firmware Table**
Microsoft defined table, support TBD. Microsoft defined table, support TBD.
IORT Signature Reserved (signature == "IORT") IORT Signature Reserved (signature == "IORT")
== Input Output Remapping Table ==
**Input Output Remapping Table**
arm64 only table, required in order to describe IO topology, SMMUs, arm64 only table, required in order to describe IO topology, SMMUs,
and GIC ITSs, and how those various components are connected together, and GIC ITSs, and how those various components are connected together,
such as identifying which components are behind which SMMUs/ITSs. such as identifying which components are behind which SMMUs/ITSs.
This table will only be required on certain SBSA platforms (e.g., 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 when using GICv3-ITS and an SMMU); on SBSA Level 0 platforms, it
remains optional. remains optional.
IVRS Signature Reserved (signature == "IVRS") IVRS Signature Reserved (signature == "IVRS")
== I/O Virtualization Reporting Structure ==
**I/O Virtualization Reporting Structure**
x86_64 (AMD) only table, will not be supported. x86_64 (AMD) only table, will not be supported.
LPIT Signature Reserved (signature == "LPIT") LPIT Signature Reserved (signature == "LPIT")
== Low Power Idle Table ==
**Low Power Idle Table**
x86 only table as of ACPI 5.1; starting with ACPI 6.0, processor 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 descriptions and power states on ARM platforms should use the DSDT
and define processor container devices (_HID ACPI0010, Section 8.4, and define processor container devices (_HID ACPI0010, Section 8.4,
and more specifically 8.4.3 and and 8.4.4). and more specifically 8.4.3 and and 8.4.4).
MADT Section 5.2.12 (signature == "APIC") MADT Section 5.2.12 (signature == "APIC")
== Multiple APIC Description Table ==
**Multiple APIC Description Table**
Required for arm64. Only the GIC interrupt controller structures Required for arm64. Only the GIC interrupt controller structures
should be used (types 0xA - 0xF). should be used (types 0xA - 0xF).
MCFG Signature Reserved (signature == "MCFG") MCFG Signature Reserved (signature == "MCFG")
== Memory-mapped ConFiGuration space ==
**Memory-mapped ConFiGuration space**
If the platform supports PCI/PCIe, an MCFG table is required. If the platform supports PCI/PCIe, an MCFG table is required.
MCHI Signature Reserved (signature == "MCHI") MCHI Signature Reserved (signature == "MCHI")
== Management Controller Host Interface table ==
**Management Controller Host Interface table**
Optional, not currently supported. Optional, not currently supported.
MPST Section 5.2.21 (signature == "MPST") MPST Section 5.2.21 (signature == "MPST")
== Memory Power State Table ==
**Memory Power State Table**
Optional, not currently supported. Optional, not currently supported.
MSCT Section 5.2.19 (signature == "MSCT") MSCT Section 5.2.19 (signature == "MSCT")
== Maximum System Characteristic Table ==
**Maximum System Characteristic Table**
Optional, not currently supported. Optional, not currently supported.
MSDM Signature Reserved (signature == "MSDM") MSDM Signature Reserved (signature == "MSDM")
== Microsoft Data Management table ==
**Microsoft Data Management table**
Microsoft only table, will not be supported. Microsoft only table, will not be supported.
NFIT Section 5.2.25 (signature == "NFIT") NFIT Section 5.2.25 (signature == "NFIT")
== NVDIMM Firmware Interface Table ==
**NVDIMM Firmware Interface Table**
Optional, not currently supported. Optional, not currently supported.
OEMx Signature of "OEMx" only OEMx Signature of "OEMx" only
== OEM Specific Tables ==
**OEM Specific Tables**
All tables starting with a signature of "OEM" are reserved for OEM 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 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 to very specific end users, they are not recommended for use and are
not supported by the kernel for arm64. not supported by the kernel for arm64.
PCCT Section 14.1 (signature == "PCCT) PCCT Section 14.1 (signature == "PCCT)
== Platform Communications Channel Table ==
**Platform Communications Channel Table**
Recommend for use on arm64; use of PCC is recommended when using CPPC Recommend for use on arm64; use of PCC is recommended when using CPPC
to control performance and power for platform processors. to control performance and power for platform processors.
PMTT Section 5.2.21.12 (signature == "PMTT") PMTT Section 5.2.21.12 (signature == "PMTT")
== Platform Memory Topology Table ==
**Platform Memory Topology Table**
Optional, not currently supported. Optional, not currently supported.
PSDT Section 5.2.11.3 (signature == "PSDT") PSDT Section 5.2.11.3 (signature == "PSDT")
== Persistent System Description Table ==
**Persistent System Description Table**
Obsolete table, will not be supported. Obsolete table, will not be supported.
RASF Section 5.2.20 (signature == "RASF") RASF Section 5.2.20 (signature == "RASF")
== RAS Feature table ==
**RAS Feature table**
Optional, not currently supported. Optional, not currently supported.
RSDP Section 5.2.5 (signature == "RSD PTR") RSDP Section 5.2.5 (signature == "RSD PTR")
== Root System Description PoinTeR ==
**Root System Description PoinTeR**
Required for arm64. Required for arm64.
RSDT Section 5.2.7 (signature == "RSDT") RSDT Section 5.2.7 (signature == "RSDT")
== Root System Description Table ==
**Root System Description Table**
Since this table can only provide 32-bit addresses, it is deprecated 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. on arm64, and will not be used. If provided, it will be ignored.
SBST Section 5.2.14 (signature == "SBST") SBST Section 5.2.14 (signature == "SBST")
== Smart Battery Subsystem Table ==
**Smart Battery Subsystem Table**
Optional, not currently supported. Optional, not currently supported.
SLIC Signature Reserved (signature == "SLIC") SLIC Signature Reserved (signature == "SLIC")
== Software LIcensing table ==
**Software LIcensing table**
Microsoft only table, will not be supported. Microsoft only table, will not be supported.
SLIT Section 5.2.17 (signature == "SLIT") SLIT Section 5.2.17 (signature == "SLIT")
== System Locality distance Information Table ==
**System Locality distance Information Table**
Optional in general, but required for NUMA systems. Optional in general, but required for NUMA systems.
SPCR Signature Reserved (signature == "SPCR") SPCR Signature Reserved (signature == "SPCR")
== Serial Port Console Redirection table ==
**Serial Port Console Redirection table**
Required for arm64. Required for arm64.
SPMI Signature Reserved (signature == "SPMI") SPMI Signature Reserved (signature == "SPMI")
== Server Platform Management Interface table ==
**Server Platform Management Interface table**
Optional, not currently supported. Optional, not currently supported.
SRAT Section 5.2.16 (signature == "SRAT") SRAT Section 5.2.16 (signature == "SRAT")
== System Resource Affinity Table ==
**System Resource Affinity Table**
Optional, but if used, only the GICC Affinity structures are read. Optional, but if used, only the GICC Affinity structures are read.
To support arm64 NUMA, this table is required. To support arm64 NUMA, this table is required.
SSDT Section 5.2.11.2 (signature == "SSDT") SSDT Section 5.2.11.2 (signature == "SSDT")
== Secondary System Description Table ==
**Secondary System Description Table**
These tables are a continuation of the DSDT; these are recommended 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 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 also serve the purpose of dividing up device descriptions into more
@ -272,49 +365,69 @@ SSDT Section 5.2.11.2 (signature == "SSDT")
one DSDT but can contain many SSDTs. one DSDT but can contain many SSDTs.
STAO Signature Reserved (signature == "STAO") STAO Signature Reserved (signature == "STAO")
== _STA Override table ==
**_STA Override table**
Optional, but only necessary in virtualized environments in order to Optional, but only necessary in virtualized environments in order to
hide devices from guest OSs. hide devices from guest OSs.
TCPA Signature Reserved (signature == "TCPA") TCPA Signature Reserved (signature == "TCPA")
== Trusted Computing Platform Alliance table ==
**Trusted Computing Platform Alliance table**
Optional, not currently supported, and may need changes to fully Optional, not currently supported, and may need changes to fully
interoperate with arm64. interoperate with arm64.
TPM2 Signature Reserved (signature == "TPM2") TPM2 Signature Reserved (signature == "TPM2")
== Trusted Platform Module 2 table ==
**Trusted Platform Module 2 table**
Optional, not currently supported, and may need changes to fully Optional, not currently supported, and may need changes to fully
interoperate with arm64. interoperate with arm64.
UEFI Signature Reserved (signature == "UEFI") UEFI Signature Reserved (signature == "UEFI")
== UEFI ACPI data table ==
**UEFI ACPI data table**
Optional, not currently supported. No known use case for arm64, Optional, not currently supported. No known use case for arm64,
at present. at present.
WAET Signature Reserved (signature == "WAET") WAET Signature Reserved (signature == "WAET")
== Windows ACPI Emulated devices Table ==
**Windows ACPI Emulated devices Table**
Microsoft only table, will not be supported. Microsoft only table, will not be supported.
WDAT Signature Reserved (signature == "WDAT") WDAT Signature Reserved (signature == "WDAT")
== Watch Dog Action Table ==
**Watch Dog Action Table**
Microsoft only table, will not be supported. Microsoft only table, will not be supported.
WDRT Signature Reserved (signature == "WDRT") WDRT Signature Reserved (signature == "WDRT")
== Watch Dog Resource Table ==
**Watch Dog Resource Table**
Microsoft only table, will not be supported. Microsoft only table, will not be supported.
WPBT Signature Reserved (signature == "WPBT") WPBT Signature Reserved (signature == "WPBT")
== Windows Platform Binary Table ==
**Windows Platform Binary Table**
Microsoft only table, will not be supported. Microsoft only table, will not be supported.
XENV Signature Reserved (signature == "XENV") XENV Signature Reserved (signature == "XENV")
== Xen project table ==
**Xen project table**
Optional, used only by Xen at present. Optional, used only by Xen at present.
XSDT Section 5.2.8 (signature == "XSDT") XSDT Section 5.2.8 (signature == "XSDT")
== eXtended System Description Table ==
Required for arm64.
**eXtended System Description Table**
Required for arm64.
====== ========================================================================
ACPI Objects ACPI Objects
------------ ------------
@ -323,10 +436,11 @@ shown in the list that follows; any object not explicitly mentioned below
should be used as needed for a particular platform or particular subsystem, should be used as needed for a particular platform or particular subsystem,
such as power management or PCI. such as power management or PCI.
===== ================ ========================================================
Name Section Usage for ARMv8 Linux Name Section Usage for ARMv8 Linux
---- ------------ ------------------------------------------------- ===== ================ ========================================================
_CCA 6.2.17 This method must be defined for all bus masters _CCA 6.2.17 This method must be defined for all bus masters
on arm64 -- there are no assumptions made about on arm64 - there are no assumptions made about
whether such devices are cache coherent or not. whether such devices are cache coherent or not.
The _CCA value is inherited by all descendants of The _CCA value is inherited by all descendants of
these devices so it does not need to be repeated. these devices so it does not need to be repeated.
@ -422,8 +536,8 @@ _OSC 6.2.11 This method can be a global method in ACPI (i.e.,
by the kernel community, then register it with the by the kernel community, then register it with the
UEFI Forum. UEFI Forum.
\_OSI 5.7.2 Deprecated on ARM64. As far as ACPI firmware is \_OSI 5.7.2 Deprecated on ARM64. As far as ACPI firmware is
concerned, _OSI is not to be used to determine what concerned, _OSI is not to be used to determine what
sort of system is being used or what functionality sort of system is being used or what functionality
is provided. The _OSC method is to be used instead. is provided. The _OSC method is to be used instead.
@ -447,7 +561,7 @@ _PSx 7.3.2-5 Use as needed; power management specific. If _PS0 is
usage, change them in these methods. usage, change them in these methods.
_RDI 8.4.4.4 Recommended for use with processor definitions (_HID _RDI 8.4.4.4 Recommended for use with processor definitions (_HID
ACPI0010) on arm64. This should only be used in ACPI0010) on arm64. This should only be used in
conjunction with _LPI. conjunction with _LPI.
\_REV 5.7.4 Always returns the latest version of ACPI supported. \_REV 5.7.4 Always returns the latest version of ACPI supported.
@ -476,6 +590,7 @@ _SWS 7.4.3 Use as needed; power management specific; this may
_UID 6.1.12 Recommended for distinguishing devices of the same _UID 6.1.12 Recommended for distinguishing devices of the same
class; define it if at all possible. class; define it if at all possible.
===== ================ ========================================================
@ -488,7 +603,7 @@ platforms, ACPI events must be signaled differently.
There are two options: GPIO-signaled interrupts (Section 5.6.5), and There are two options: GPIO-signaled interrupts (Section 5.6.5), and
interrupt-signaled events (Section 5.6.9). Interrupt-signaled events are a 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 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 on a given platform, and which to use may be dependent of limitations in any
given SoC. If possible, interrupt-signaled events are recommended. given SoC. If possible, interrupt-signaled events are recommended.
@ -564,39 +679,40 @@ supported.
The following classes of objects are not supported: The following classes of objects are not supported:
-- Section 9.2: ambient light sensor devices - Section 9.2: ambient light sensor devices
-- Section 9.3: battery devices - Section 9.3: battery devices
-- Section 9.4: lids (e.g., laptop lids) - Section 9.4: lids (e.g., laptop lids)
-- Section 9.8.2: IDE controllers - Section 9.8.2: IDE controllers
-- Section 9.9: floppy controllers - Section 9.9: floppy controllers
-- Section 9.10: GPE block devices - Section 9.10: GPE block devices
-- Section 9.15: PC/AT RTC/CMOS devices - Section 9.15: PC/AT RTC/CMOS devices
-- Section 9.16: user presence detection devices - Section 9.16: user presence detection devices
-- Section 9.17: I/O APIC devices; all GICs must be enumerable via MADT - 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 9.18: time and alarm devices (see 9.15)
-- Section 10: power source and power meter devices - Section 10: power source and power meter devices
-- Section 11: thermal management - Section 11: thermal management
-- Section 12: embedded controllers interface - Section 12: embedded controllers interface
-- Section 13: SMBus interfaces - Section 13: SMBus interfaces
This also means that there is no support for the following objects: This also means that there is no support for the following objects:
==== =========================== ==== ==========
Name Section Name Section Name Section Name Section
---- ------------ ---- ------------ ==== =========================== ==== ==========
_ALC 9.3.4 _FDM 9.10.3 _ALC 9.3.4 _FDM 9.10.3
_ALI 9.3.2 _FIX 6.2.7 _ALI 9.3.2 _FIX 6.2.7
_ALP 9.3.6 _GAI 10.4.5 _ALP 9.3.6 _GAI 10.4.5
@ -619,4 +735,4 @@ _DCK 6.5.2 _UPD 9.16.1
_EC 12.12 _UPP 9.16.2 _EC 12.12 _UPP 9.16.2
_FDE 9.10.1 _WPC 10.5.2 _FDE 9.10.1 _WPC 10.5.2
_FDI 9.10.2 _WPP 10.5.3 _FDI 9.10.2 _WPP 10.5.3
==== =========================== ==== ==========

155
Documentation/arm64/arm-acpi.txt → Documentation/arm64/arm-acpi.rst
View File

@ -1,5 +1,7 @@
=====================
ACPI on ARMv8 Servers ACPI on ARMv8 Servers
--------------------- =====================
ACPI can be used for ARMv8 general purpose servers designed to follow ACPI can be used for ARMv8 general purpose servers designed to follow
the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server
Base Boot Requirements) [1] specifications. Please note that the SBBR Base Boot Requirements) [1] specifications. Please note that the SBBR
@ -34,28 +36,28 @@ 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, - ACPI’s byte code (AML) allows the platform to encode hardware behavior,
while DT explicitly does not support this. For hardware vendors, being while DT explicitly does not support this. For hardware vendors, being
able to encode behavior is a key tool used in supporting operating able to encode behavior is a key tool used in supporting operating
system releases on new hardware. system releases on new hardware.
-- ACPI’s OSPM defines a power management model that constrains what the - ACPI’s OSPM defines a power management model that constrains what the
platform is allowed to do into a specific model, while still providing platform is allowed to do into a specific model, while still providing
flexibility in hardware design. flexibility in hardware design.
-- In the enterprise server environment, ACPI has established bindings (such - In the enterprise server environment, ACPI has established bindings (such
as for RAS) which are currently used in production systems. DT does not. 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 x86 would end up using completely different code paths in both firmware
and the kernel. and the kernel.
-- Choosing a single interface to describe the abstraction between a platform - Choosing a single interface to describe the abstraction between a platform
and an OS is important. Hardware vendors would not be required to implement 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, 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 agreeing on a single interface instead of being fragmented into per OS
interfaces makes for better interoperability overall. interfaces makes for better interoperability overall.
-- The new ACPI governance process works well and Linux is now at the same - 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 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 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 Linux is in any way secondary to Microsoft in this arena. The move of
@ -169,31 +171,31 @@ 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 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.1 specification):
-- RSDP (Root System Description Pointer), section 5.2.5 - RSDP (Root System Description Pointer), section 5.2.5
-- XSDT (eXtended System Description Table), section 5.2.8 - XSDT (eXtended System Description Table), section 5.2.8
-- FADT (Fixed ACPI Description Table), section 5.2.9 - FADT (Fixed ACPI Description Table), section 5.2.9
-- DSDT (Differentiated System Description Table), section - DSDT (Differentiated System Description Table), section
5.2.11.1 5.2.11.1
-- MADT (Multiple APIC Description Table), section 5.2.12 - MADT (Multiple APIC Description Table), section 5.2.12
-- GTDT (Generic Timer Description Table), section 5.2.24 - GTDT (Generic Timer Description Table), section 5.2.24
-- If PCI is supported, the MCFG (Memory mapped ConFiGuration - 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-31.
-- If booting without a console=<device> kernel parameter is - If booting without a console=<device> kernel parameter is
supported, the SPCR (Serial Port Console Redirection table), supported, the SPCR (Serial Port Console Redirection table),
section 5.2.6, specifically Table 5-31. section 5.2.6, specifically Table 5-31.
-- If necessary to describe the I/O topology, SMMUs and GIC ITSs, - If necessary to describe the I/O topology, SMMUs and GIC ITSs,
the IORT (Input Output Remapping Table, section 5.2.6, specifically the IORT (Input Output Remapping Table, section 5.2.6, specifically
Table 5-31). Table 5-31).
-- If NUMA is supported, the SRAT (System Resource Affinity Table) - If NUMA is supported, the SRAT (System Resource Affinity Table)
and SLIT (System Locality distance Information Table), sections and SLIT (System Locality distance Information Table), sections
5.2.16 and 5.2.17, respectively. 5.2.16 and 5.2.17, respectively.
@ -269,9 +271,9 @@ describes how to define the structure of an object returned via _DSD, and
how specific data structures are defined by specific UUIDs. Linux should 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 [5]:
-- UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
-- http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf - http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
The UEFI Forum provides a mechanism for registering device properties [4] The UEFI Forum provides a mechanism for registering device properties [4]
so that they may be used across all operating systems supporting ACPI. so that they may be used across all operating systems supporting ACPI.
@ -327,10 +329,10 @@ turning a device full off.
There are two options for using those Power Resources. They can: There are two options for using those Power Resources. They can:
-- be managed in a _PSx method which gets called on entry to power - be managed in a _PSx method which gets called on entry to power
state Dx. state Dx.
-- be declared separately as power resources with their own _ON and _OFF - 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 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 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 while in Dx. Kernel then tracks number of devices using a power resource
@ -339,16 +341,16 @@ There are two options for using those Power Resources. They can:
The kernel ACPI code will also assume that the _PSx methods follow the normal The kernel ACPI code will also assume that the _PSx methods follow the normal
ACPI rules for such methods: ACPI rules for such methods:
-- If either _PS0 or _PS3 is implemented, then the other method must also - If either _PS0 or _PS3 is implemented, then the other method must also
be implemented. be implemented.
-- If a device requires usage or setup of a power resource when on, the ASL - 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. should organize that it is allocated/enabled using the _PS0 method.
-- Resources allocated or enabled in the _PS0 method should be disabled - Resources allocated or enabled in the _PS0 method should be disabled
or de-allocated in the _PS3 method. or de-allocated in the _PS3 method.
-- Firmware will leave the resources in a reasonable state before handing - Firmware will leave the resources in a reasonable state before handing
over control to the kernel. over control to the kernel.
Such code in _PSx methods will of course be very platform specific. But, Such code in _PSx methods will of course be very platform specific. But,
@ -394,52 +396,52 @@ 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 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 allow most divergence between ACPI and DT functionality to be kept local to
the probe function instead of being scattered throughout the driver. For the probe function instead of being scattered throughout the driver. For
example: example::
static int device_probe_dt(struct platform_device *pdev) static int device_probe_dt(struct platform_device *pdev)
{ {
/* DT specific functionality */ /* DT specific functionality */
... ...
} }
static int device_probe_acpi(struct platform_device *pdev) static int device_probe_acpi(struct platform_device *pdev)
{ {
/* ACPI specific functionality */ /* ACPI specific functionality */
... ...
} }
static int device_probe(struct platform_device *pdev) static int device_probe(struct platform_device *pdev)
{ {
... ...
struct device_node node = pdev->dev.of_node; struct device_node node = pdev->dev.of_node;
... ...
if (node) if (node)
ret = device_probe_dt(pdev); ret = device_probe_dt(pdev);
else if (ACPI_HANDLE(&pdev->dev)) else if (ACPI_HANDLE(&pdev->dev))
ret = device_probe_acpi(pdev); ret = device_probe_acpi(pdev);
else else
/* other initialization */ /* other initialization */
... ...
/* Continue with any generic probe operations */ /* Continue with any generic probe operations */
... ...
} }
DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it 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 clear the different names the driver is probed for, both from DT and from
ACPI: ACPI::
static struct of_device_id virtio_mmio_match[] = { static struct of_device_id virtio_mmio_match[] = {
{ .compatible = "virtio,mmio", }, { .compatible = "virtio,mmio", },
{ } { }
}; };
MODULE_DEVICE_TABLE(of, virtio_mmio_match); MODULE_DEVICE_TABLE(of, virtio_mmio_match);
static const struct acpi_device_id virtio_mmio_acpi_match[] = { static const struct acpi_device_id virtio_mmio_acpi_match[] = {
{ "LNRO0005", }, { "LNRO0005", },
{ } { }
}; };
MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match); MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
ASWG ASWG
@ -471,7 +473,8 @@ Linux Code
Individual items specific to Linux on ARM, contained in the the Linux Individual items specific to Linux on ARM, contained in the the Linux
source code, are in the list that follows: source code, are in the list that follows:
ACPI_OS_NAME This macro defines the string to be returned when 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 ARM64
systems, this macro will be "Linux" by default. systems, this macro will be "Linux" by default.
The command line parameter acpi_os=<string> The command line parameter acpi_os=<string>
@ -482,38 +485,44 @@ ACPI_OS_NAME This macro defines the string to be returned when
ACPI Objects ACPI Objects
------------ ------------
Detailed expectations for ACPI tables and object are listed in the file Detailed expectations for ACPI tables and object are listed in the file
Documentation/arm64/acpi_object_usage.txt. Documentation/arm64/acpi_object_usage.rst.
References References
---------- ----------
[0] http://silver.arm.com -- document ARM-DEN-0029, or newer [0] http://silver.arm.com
document ARM-DEN-0029, or newer:
"Server Base System Architecture", version 2.3, dated 27 Mar 2014 "Server Base System Architecture", version 2.3, dated 27 Mar 2014
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0044a/Server_Base_Boot_Requirements.pdf [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 Document ARM-DEN-0044A, or newer: "Server Base Boot Requirements, System
Software on ARM Platforms", dated 16 Aug 2014 Software on ARM Platforms", dated 16 Aug 2014
[2] http://www.secretlab.ca/archives/151, 10 Jan 2015, Copyright (c) 2015, [2] http://www.secretlab.ca/archives/151,
10 Jan 2015, Copyright (c) 2015,
Linaro Ltd., written by Grant Likely. Linaro Ltd., written by Grant Likely.
[3] AMD ACPI for Seattle platform documentation: [3] AMD ACPI for Seattle platform documentation
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_Guide.pdf 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
[4] http://www.uefi.org/acpi
please see the link for the "ACPI _DSD Device
Property Registry Instructions" Property Registry Instructions"
[5] http://www.uefi.org/acpi -- please see the link for the "_DSD (Device [5] http://www.uefi.org/acpi
please see the link for the "_DSD (Device
Specific Data) Implementation Guide" Specific Data) Implementation Guide"
[6] Kernel code for the unified device property interface can be found in [6] Kernel code for the unified device
property interface can be found in
include/linux/property.h and drivers/base/property.c. include/linux/property.h and drivers/base/property.c.
Authors Authors
------- -------
Al Stone <al.stone@linaro.org> - Al Stone <al.stone@linaro.org>
Graeme Gregory <graeme.gregory@linaro.org> - Graeme Gregory <graeme.gregory@linaro.org>
Hanjun Guo <hanjun.guo@linaro.org> - Hanjun Guo <hanjun.guo@linaro.org>
Grant Likely <grant.likely@linaro.org>, for the "Why ACPI on ARM?" section - Grant Likely <grant.likely@linaro.org>, for the "Why ACPI on ARM?" section

91
Documentation/arm64/booting.txt → Documentation/arm64/booting.rst
View File

@ -1,7 +1,9 @@
Booting AArch64 Linux =====================
===================== Booting AArch64 Linux
=====================
Author: Will Deacon <will.deacon@arm.com> Author: Will Deacon <will.deacon@arm.com>
Date : 07 September 2012 Date : 07 September 2012
This document is based on the ARM booting document by Russell King and This document is based on the ARM booting document by Russell King and
@ -12,7 +14,7 @@ The AArch64 exception model is made up of a number of exception levels
counterpart. EL2 is the hypervisor level and exists only in non-secure counterpart. EL2 is the hypervisor level and exists only in non-secure
mode. EL3 is the highest priority level and exists only in secure mode. mode. EL3 is the highest priority level and exists only in secure mode.
For the purposes of this document, we will use the term `boot loader' 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 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 is passed to the Linux kernel. This may include secure monitor and
hypervisor code, or it may just be a handful of instructions for hypervisor code, or it may just be a handful of instructions for
@ -70,7 +72,7 @@ Image target is available instead.
Requirement: MANDATORY Requirement: MANDATORY
The decompressed kernel image contains a 64-byte header as follows: The decompressed kernel image contains a 64-byte header as follows::
u32 code0; /* Executable code */ u32 code0; /* Executable code */
u32 code1; /* Executable code */ u32 code1; /* Executable code */
@ -103,19 +105,26 @@ Header notes:
- The flags field (introduced in v3.17) is a little-endian 64-bit field - The flags field (introduced in v3.17) is a little-endian 64-bit field
composed as follows: composed as follows:
Bit 0: Kernel endianness. 1 if BE, 0 if LE.
Bit 1-2: Kernel Page size. ============= ===============================================================
0 - Unspecified. Bit 0 Kernel endianness. 1 if BE, 0 if LE.
1 - 4K Bit 1-2 Kernel Page size.
2 - 16K
3 - 64K * 0 - Unspecified.
Bit 3: Kernel physical placement * 1 - 4K
0 - 2MB aligned base should be as close as possible * 2 - 16K
to the base of DRAM, since memory below it is not * 3 - 64K
accessible via the linear mapping Bit 3 Kernel physical placement
1 - 2MB aligned base may be anywhere in physical
memory 0
Bits 4-63: Reserved. 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 may be anywhere in physical
memory
Bits 4-63 Reserved.
============= ===============================================================
- When image_size is zero, a bootloader should attempt to keep as much - 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 memory as possible free for use by the kernel immediately after the
@ -147,19 +156,22 @@ Before jumping into the kernel, the following conditions must be met:
corrupted by bogus network packets or disk data. This will save corrupted by bogus network packets or disk data. This will save
you many hours of debug. you many hours of debug.
- Primary CPU general-purpose register settings - Primary CPU general-purpose register settings:
x0 = physical address of device tree blob (dtb) in system RAM.
x1 = 0 (reserved for future use) - x0 = physical address of device tree blob (dtb) in system RAM.
x2 = 0 (reserved for future use) - x1 = 0 (reserved for future use)
x3 = 0 (reserved for future use) - x2 = 0 (reserved for future use)
- x3 = 0 (reserved for future use)
- CPU mode - CPU mode
All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
IRQ and FIQ). IRQ and FIQ).
The CPU must be in either EL2 (RECOMMENDED in order to have access to The CPU must be in either EL2 (RECOMMENDED in order to have access to
the virtualisation extensions) or non-secure EL1. the virtualisation extensions) or non-secure EL1.
- Caches, MMUs - Caches, MMUs
The MMU must be off. The MMU must be off.
Instruction cache may be on or off. Instruction cache may be on or off.
The address range corresponding to the loaded kernel image must be The address range corresponding to the loaded kernel image must be
@ -172,18 +184,21 @@ Before jumping into the kernel, the following conditions must be met:
operations (not recommended) must be configured and disabled. operations (not recommended) must be configured and disabled.
- Architected timers - Architected timers
CNTFRQ must be programmed with the timer frequency and CNTVOFF must CNTFRQ must be programmed with the timer frequency and CNTVOFF must
be programmed with a consistent value on all CPUs. If entering the be programmed with a consistent value on all CPUs. If entering the
kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where
available. available.
- Coherency - Coherency
All CPUs to be booted by the kernel must be part of the same 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 domain on entry to the kernel. This may require IMPLEMENTATION DEFINED
initialisation to enable the receiving of maintenance operations on initialisation to enable the receiving of maintenance operations on
each CPU. each CPU.
- System registers - System registers
All writable architected system registers at the exception level where All writable architected system registers at the exception level where
the kernel image will be entered must be initialised by software at a the kernel image will be entered must be initialised by software at a
higher exception level to prevent execution in an UNKNOWN state. higher exception level to prevent execution in an UNKNOWN state.
@ -195,28 +210,40 @@ Before jumping into the kernel, the following conditions must be met:
For systems with a GICv3 interrupt controller to be used in v3 mode: For systems with a GICv3 interrupt controller to be used in v3 mode:
- If EL3 is present: - If EL3 is present:
ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1. - ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
- ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
- If the kernel is entered at EL1: - 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. - 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. - The DT or ACPI tables must describe a GICv3 interrupt controller.
For systems with a GICv3 interrupt controller to be used in For systems with a GICv3 interrupt controller to be used in
compatibility (v2) mode: compatibility (v2) mode:
- If EL3 is present: - If EL3 is present:
ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0.
ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0.
- If the kernel is entered at EL1: - If the kernel is entered at EL1:
ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.
ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.
- The DT or ACPI tables must describe a GICv2 interrupt controller. - The DT or ACPI tables must describe a GICv2 interrupt controller.
For CPUs with pointer authentication functionality: For CPUs with pointer authentication functionality:
- If EL3 is present: - If EL3 is present:
SCR_EL3.APK (bit 16) must be initialised to 0b1
SCR_EL3.API (bit 17) must be initialised to 0b1 - 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: - 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 - HCR_EL2.APK (bit 40) must be initialised to 0b1
- HCR_EL2.API (bit 41) must be initialised to 0b1
The requirements described above for CPU mode, caches, MMUs, architected The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must timers, coherency and system registers apply to all CPUs. All CPUs must

204
Documentation/arm64/cpu-feature-registers.txt → Documentation/arm64/cpu-feature-registers.rst
View File

@ -1,5 +1,6 @@
ARM64 CPU Feature Registers ===========================
=========================== ARM64 CPU Feature Registers
===========================
Author: Suzuki K Poulose <suzuki.poulose@arm.com> Author: Suzuki K Poulose <suzuki.poulose@arm.com>
@ -9,7 +10,7 @@ registers to userspace. The availability of this ABI is advertised
via the HWCAP_CPUID in HWCAPs. via the HWCAP_CPUID in HWCAPs.
1. Motivation 1. Motivation
--------------- -------------
The ARM architecture defines a set of feature registers, which describe The ARM architecture defines a set of feature registers, which describe
the capabilities of the CPU/system. Access to these system registers is the capabilities of the CPU/system. Access to these system registers is
@ -33,9 +34,10 @@ there are some issues with their usage.
2. Requirements 2. Requirements
----------------- ---------------
a) Safety:
a) Safety :
Applications should be able to use the information provided by the Applications should be able to use the information provided by the
infrastructure to run safely across the system. This has greater infrastructure to run safely across the system. This has greater
implications on a system with heterogeneous CPUs. implications on a system with heterogeneous CPUs.
@ -47,7 +49,8 @@ there are some issues with their usage.
Otherwise an application could crash when scheduled on the CPU Otherwise an application could crash when scheduled on the CPU
which doesn't support CRC32. which doesn't support CRC32.
b) Security : b) Security:
Applications should only be able to receive information that is Applications should only be able to receive information that is
relevant to the normal operation in userspace. Hence, some of the 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 fields are masked out(i.e, made invisible) and their values are set to
@ -58,10 +61,12 @@ there are some issues with their usage.
(even when the CPU provides it). (even when the CPU provides it).
c) Implementation Defined Features c) Implementation Defined Features
The infrastructure doesn't expose any register which is The infrastructure doesn't expose any register which is
IMPLEMENTATION DEFINED as per ARMv8-A Architecture. IMPLEMENTATION DEFINED as per ARMv8-A Architecture.
d) CPU Identification : d) CPU Identification:
MIDR_EL1 is exposed to help identify the processor. On a MIDR_EL1 is exposed to help identify the processor. On a
heterogeneous system, this could be racy (just like getcpu()). The heterogeneous system, this could be racy (just like getcpu()). The
process could be migrated to another CPU by the time it uses the process could be migrated to another CPU by the time it uses the
@ -70,7 +75,7 @@ there are some issues with their usage.
currently executing on. The REVIDR is not exposed due to this currently executing on. The REVIDR is not exposed due to this
constraint, as REVIDR makes sense only in conjunction with the constraint, as REVIDR makes sense only in conjunction with the
MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
at: at::
/sys/devices/system/cpu/cpu$ID/regs/identification/ /sys/devices/system/cpu/cpu$ID/regs/identification/
\- midr \- midr
@ -85,7 +90,8 @@ exception and ends up in SIGILL being delivered to the process.
The infrastructure hooks into the exception handler and emulates the The infrastructure hooks into the exception handler and emulates the
operation if the source belongs to the supported system register space. operation if the source belongs to the supported system register space.
The infrastructure emulates only the following system register space: The infrastructure emulates only the following system register space::
Op0=3, Op1=0, CRn=0, CRm=0,4,5,6,7 Op0=3, Op1=0, CRn=0, CRm=0,4,5,6,7
(See Table C5-6 'System instruction encodings for non-Debug System (See Table C5-6 'System instruction encodings for non-Debug System
@ -107,73 +113,76 @@ infrastructure:
------------------------------------------- -------------------------------------------
1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0 1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0
x--------------------------------------------------x
+------------------------------+---------+---------+
| Name | bits | visible | | Name | bits | visible |
|--------------------------------------------------| +------------------------------+---------+---------+
| TS | [55-52] | y | | TS | [55-52] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| FHM | [51-48] | y | | FHM | [51-48] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| DP | [47-44] | y | | DP | [47-44] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| SM4 | [43-40] | y | | SM4 | [43-40] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| SM3 | [39-36] | y | | SM3 | [39-36] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| SHA3 | [35-32] | y | | SHA3 | [35-32] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| RDM | [31-28] | y | | RDM | [31-28] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| ATOMICS | [23-20] | y | | ATOMICS | [23-20] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| CRC32 | [19-16] | y | | CRC32 | [19-16] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| SHA2 | [15-12] | y | | SHA2 | [15-12] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| SHA1 | [11-8] | y | | SHA1 | [11-8] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| AES | [7-4] | y | | AES | [7-4] | y |
x--------------------------------------------------x +------------------------------+---------+---------+
2) ID_AA64PFR0_EL1 - Processor Feature Register 0 2) ID_AA64PFR0_EL1 - Processor Feature Register 0
x--------------------------------------------------x
+------------------------------+---------+---------+
| Name | bits | visible | | Name | bits | visible |
|--------------------------------------------------| +------------------------------+---------+---------+
| DIT | [51-48] | y | | DIT | [51-48] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| SVE | [35-32] | y | | SVE | [35-32] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| GIC | [27-24] | n | | GIC | [27-24] | n |
|--------------------------------------------------| +------------------------------+---------+---------+
| AdvSIMD | [23-20] | y | | AdvSIMD | [23-20] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| FP | [19-16] | y | | FP | [19-16] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| EL3 | [15-12] | n | | EL3 | [15-12] | n |
|--------------------------------------------------| +------------------------------+---------+---------+
| EL2 | [11-8] | n | | EL2 | [11-8] | n |
|--------------------------------------------------| +------------------------------+---------+---------+
| EL1 | [7-4] | n | | EL1 | [7-4] | n |
|--------------------------------------------------| +------------------------------+---------+---------+
| EL0 | [3-0] | n | | EL0 | [3-0] | n |
x--------------------------------------------------x +------------------------------+---------+---------+
3) MIDR_EL1 - Main ID Register 3) MIDR_EL1 - Main ID Register
x--------------------------------------------------x
+------------------------------+---------+---------+
| Name | bits | visible | | Name | bits | visible |
|--------------------------------------------------| +------------------------------+---------+---------+
| Implementer | [31-24] | y | | Implementer | [31-24] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| Variant | [23-20] | y | | Variant | [23-20] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| Architecture | [19-16] | y | | Architecture | [19-16] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| PartNum | [15-4] | y | | PartNum | [15-4] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| Revision | [3-0] | y | | Revision | [3-0] | y |
x--------------------------------------------------x +------------------------------+---------+---------+
NOTE: The 'visible' fields of MIDR_EL1 will contain the value 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 as available on the CPU where it is fetched and is not a system
@ -181,90 +190,92 @@ infrastructure:
4) ID_AA64ISAR1_EL1 - Instruction set attribute register 1 4) ID_AA64ISAR1_EL1 - Instruction set attribute register 1
x--------------------------------------------------x +------------------------------+---------+---------+
| Name | bits | visible | | Name | bits | visible |
|--------------------------------------------------| +------------------------------+---------+---------+
| GPI | [31-28] | y | | GPI | [31-28] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| GPA | [27-24] | y | | GPA | [27-24] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| LRCPC | [23-20] | y | | LRCPC | [23-20] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| FCMA | [19-16] | y | | FCMA | [19-16] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| JSCVT | [15-12] | y | | JSCVT | [15-12] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| API | [11-8] | y | | API | [11-8] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| APA | [7-4] | y | | APA | [7-4] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| DPB | [3-0] | y | | DPB | [3-0] | y |
x--------------------------------------------------x +------------------------------+---------+---------+
5) ID_AA64MMFR2_EL1 - Memory model feature register 2 5) ID_AA64MMFR2_EL1 - Memory model feature register 2
x--------------------------------------------------x +------------------------------+---------+---------+
| Name | bits | visible | | Name | bits | visible |
|--------------------------------------------------| +------------------------------+---------+---------+
| AT | [35-32] | y | | AT | [35-32] | y |
x--------------------------------------------------x +------------------------------+---------+---------+
6) ID_AA64ZFR0_EL1 - SVE feature ID register 0 6) ID_AA64ZFR0_EL1 - SVE feature ID register 0
x--------------------------------------------------x +------------------------------+---------+---------+
| Name | bits | visible | | Name | bits | visible |
|--------------------------------------------------| +------------------------------+---------+---------+
| SM4 | [43-40] | y | | SM4 | [43-40] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| SHA3 | [35-32] | y | | SHA3 | [35-32] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| BitPerm | [19-16] | y | | BitPerm | [19-16] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| AES | [7-4] | y | | AES | [7-4] | y |
|--------------------------------------------------| +------------------------------+---------+---------+
| SVEVer | [3-0] | y | | SVEVer | [3-0] | y |
x--------------------------------------------------x +------------------------------+---------+---------+
Appendix I: Example 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> * Sample program to demonstrate the MRS emulation ABI.
#include <sys/auxv.h> *
* 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.
*/
#define get_cpu_ftr(id) ({ \ #include <asm/hwcap.h>
#include <stdio.h>
#include <sys/auxv.h>
#define get_cpu_ftr(id) ({ \
unsigned long __val; \ unsigned long __val; \
asm("mrs %0, "#id : "=r" (__val)); \ asm("mrs %0, "#id : "=r" (__val)); \
printf("%-20s: 0x%016lx\n", #id, __val); \ printf("%-20s: 0x%016lx\n", #id, __val); \
}) })
int main(void) int main(void)
{ {
if (!(getauxval(AT_HWCAP) & HWCAP_CPUID)) { if (!(getauxval(AT_HWCAP) & HWCAP_CPUID)) {
fputs("CPUID registers unavailable\n", stderr); fputs("CPUID registers unavailable\n", stderr);
@ -284,13 +295,10 @@ int main(void)
get_cpu_ftr(MPIDR_EL1); get_cpu_ftr(MPIDR_EL1);
get_cpu_ftr(REVIDR_EL1); get_cpu_ftr(REVIDR_EL1);
#if 0 #if 0
/* Unexposed register access causes SIGILL */ /* Unexposed register access causes SIGILL */
get_cpu_ftr(ID_MMFR0_EL1); get_cpu_ftr(ID_MMFR0_EL1);
#endif #endif
return 0; return 0;
} }

56
Documentation/arm64/elf_hwcaps.txt → Documentation/arm64/elf_hwcaps.rst
View File

@ -1,3 +1,4 @@
================
ARM64 ELF hwcaps ARM64 ELF hwcaps
================ ================
@ -15,16 +16,16 @@ of flags called hwcaps, exposed in the auxilliary vector.
Userspace software can test for features by acquiring the AT_HWCAP or Userspace software can test for features by acquiring the AT_HWCAP or
AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
flags are set, e.g. flags are set, e.g.::
bool floating_point_is_present(void) bool floating_point_is_present(void)
{ {
unsigned long hwcaps = getauxval(AT_HWCAP); unsigned long hwcaps = getauxval(AT_HWCAP);
if (hwcaps & HWCAP_FP) if (hwcaps & HWCAP_FP)
return true; return true;
return false; return false;
} }
Where software relies on a feature described by a hwcap, it should check 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 the relevant hwcap flag to verify that the feature is present before
@ -45,7 +46,7 @@ userspace code at EL0. These hwcaps are defined in terms of ID register
fields, and should be interpreted with reference to the definition of fields, and should be interpreted with reference to the definition of
these fields in the ARM Architecture Reference Manual (ARM ARM). these fields in the ARM Architecture Reference Manual (ARM ARM).
Such hwcaps are described below in the form: Such hwcaps are described below in the form::
Functionality implied by idreg.field == val. Functionality implied by idreg.field == val.
@ -64,75 +65,58 @@ reference to ID registers, and may refer to other documentation.
--------------------------------- ---------------------------------
HWCAP_FP HWCAP_FP
Functionality implied by ID_AA64PFR0_EL1.FP == 0b0000. Functionality implied by ID_AA64PFR0_EL1.FP == 0b0000.
HWCAP_ASIMD HWCAP_ASIMD
Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0000. Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0000.
HWCAP_EVTSTRM HWCAP_EVTSTRM
The generic timer is configured to generate events at a frequency of The generic timer is configured to generate events at a frequency of
approximately 100KHz. approximately 100KHz.
HWCAP_AES HWCAP_AES
Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001.
HWCAP_PMULL HWCAP_PMULL
Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0010. Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0010.
HWCAP_SHA1 HWCAP_SHA1
Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001.
HWCAP_SHA2 HWCAP_SHA2
Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001.
HWCAP_CRC32 HWCAP_CRC32
Functionality implied by ID_AA64ISAR0_EL1.CRC32 == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.CRC32 == 0b0001.
HWCAP_ATOMICS HWCAP_ATOMICS
Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0010. Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0010.
HWCAP_FPHP HWCAP_FPHP
Functionality implied by ID_AA64PFR0_EL1.FP == 0b0001. Functionality implied by ID_AA64PFR0_EL1.FP == 0b0001.
HWCAP_ASIMDHP HWCAP_ASIMDHP
Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0001. Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0001.
HWCAP_CPUID HWCAP_CPUID
EL0 access to certain ID registers is available, to the extent EL0 access to certain ID registers is available, to the extent
described by Documentation/arm64/cpu-feature-registers.txt. described by Documentation/arm64/cpu-feature-registers.rst.
These ID registers may imply the availability of features. These ID registers may imply the availability of features.
HWCAP_ASIMDRDM HWCAP_ASIMDRDM
Functionality implied by ID_AA64ISAR0_EL1.RDM == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.RDM == 0b0001.
HWCAP_JSCVT HWCAP_JSCVT
Functionality implied by ID_AA64ISAR1_EL1.JSCVT == 0b0001. Functionality implied by ID_AA64ISAR1_EL1.JSCVT == 0b0001.
HWCAP_FCMA HWCAP_FCMA
Functionality implied by ID_AA64ISAR1_EL1.FCMA == 0b0001. Functionality implied by ID_AA64ISAR1_EL1.FCMA == 0b0001.
HWCAP_LRCPC HWCAP_LRCPC
Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0001. Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0001.
HWCAP_DCPOP HWCAP_DCPOP
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001. Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001.
HWCAP2_DCPODP HWCAP2_DCPODP
@ -140,27 +124,21 @@ HWCAP2_DCPODP
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010. Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
HWCAP_SHA3 HWCAP_SHA3
Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
HWCAP_SM3 HWCAP_SM3
Functionality implied by ID_AA64ISAR0_EL1.SM3 == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.SM3 == 0b0001.
HWCAP_SM4 HWCAP_SM4
Functionality implied by ID_AA64ISAR0_EL1.SM4 == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.SM4 == 0b0001.
HWCAP_ASIMDDP HWCAP_ASIMDDP
Functionality implied by ID_AA64ISAR0_EL1.DP == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.DP == 0b0001.
HWCAP_SHA512 HWCAP_SHA512
Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010. Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010.
HWCAP_SVE HWCAP_SVE
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001. Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
HWCAP2_SVE2 HWCAP2_SVE2
@ -188,40 +166,32 @@ HWCAP2_SVESM4
Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001. Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
HWCAP_ASIMDFHM HWCAP_ASIMDFHM
Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
HWCAP_DIT HWCAP_DIT
Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001. Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001.
HWCAP_USCAT HWCAP_USCAT
Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001. Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001.
HWCAP_ILRCPC HWCAP_ILRCPC
Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0010. Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0010.
HWCAP_FLAGM HWCAP_FLAGM
Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001. Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001.
HWCAP_SSBS HWCAP_SSBS
Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010. Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010.
HWCAP_PACA HWCAP_PACA
Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or
ID_AA64ISAR1_EL1.API == 0b0001, as described by ID_AA64ISAR1_EL1.API == 0b0001, as described by
Documentation/arm64/pointer-authentication.txt. Documentation/arm64/pointer-authentication.rst.
HWCAP_PACG HWCAP_PACG
Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
ID_AA64ISAR1_EL1.GPI == 0b0001, as described by ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
Documentation/arm64/pointer-authentication.txt. Documentation/arm64/pointer-authentication.rst.
4. Unused AT_HWCAP bits 4. Unused AT_HWCAP bits

7
Documentation/arm64/hugetlbpage.txt → Documentation/arm64/hugetlbpage.rst
View File

@ -1,3 +1,4 @@
====================
HugeTLBpage on ARM64 HugeTLBpage on ARM64
==================== ====================
@ -31,8 +32,10 @@ and level of the page table.
The following hugepage sizes are supported - The following hugepage sizes are supported -
CONT PTE PMD CONT PMD PUD ====== ======== ==== ======== ===
-------- --- -------- --- - CONT PTE PMD CONT PMD PUD
====== ======== ==== ======== ===
4K: 64K 2M 32M 1G 4K: 64K 2M 32M 1G
16K: 2M 32M 1G 16K: 2M 32M 1G
64K: 2M 512M 16G 64K: 2M 512M 16G
====== ======== ==== ======== ===

28
Documentation/arm64/index.rst 100644
View File

@ -0,0 +1,28 @@
:orphan:
==================
ARM64 Architecture
==================
.. toctree::
:maxdepth: 1
acpi_object_usage
arm-acpi
booting
cpu-feature-registers
elf_hwcaps
hugetlbpage
legacy_instructions
memory
pointer-authentication
silicon-errata
sve
tagged-pointers
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

43
Documentation/arm64/legacy_instructions.txt → Documentation/arm64/legacy_instructions.rst
View File

@ -1,3 +1,7 @@
===================
Legacy instructions
===================
The arm64 port of the Linux kernel provides infrastructure to support The arm64 port of the Linux kernel provides infrastructure to support
emulation of instructions which have been deprecated, or obsoleted in emulation of instructions which have been deprecated, or obsoleted in
the architecture. The infrastructure code uses undefined instruction the architecture. The infrastructure code uses undefined instruction
@ -9,19 +13,22 @@ The emulation mode can be controlled by writing to sysctl nodes
behaviours and the corresponding values of the sysctl nodes - behaviours and the corresponding values of the sysctl nodes -
* Undef * Undef
Value: 0 Value: 0
Generates undefined instruction abort. Default for instructions that Generates undefined instruction abort. Default for instructions that
have been obsoleted in the architecture, e.g., SWP have been obsoleted in the architecture, e.g., SWP
* Emulate * Emulate
Value: 1 Value: 1
Uses software emulation. To aid migration of software, in this mode Uses software emulation. To aid migration of software, in this mode
usage of emulated instruction is traced as well as rate limited usage of emulated instruction is traced as well as rate limited
warnings are issued. This is the default for deprecated warnings are issued. This is the default for deprecated
instructions, .e.g., CP15 barriers instructions, .e.g., CP15 barriers
* Hardware Execution * Hardware Execution
Value: 2 Value: 2
Although marked as deprecated, some implementations may support the Although marked as deprecated, some implementations may support the
enabling/disabling of hardware support for the execution of these enabling/disabling of hardware support for the execution of these
instructions. Using hardware execution generally provides better instructions. Using hardware execution generally provides better
@ -38,20 +45,24 @@ individual instruction notes for further information.
Supported legacy instructions Supported legacy instructions
----------------------------- -----------------------------
* SWP{B} * SWP{B}
Node: /proc/sys/abi/swp
Status: Obsolete :Node: /proc/sys/abi/swp
Default: Undef (0) :Status: Obsolete
:Default: Undef (0)
* CP15 Barriers * CP15 Barriers
Node: /proc/sys/abi/cp15_barrier
Status: Deprecated :Node: /proc/sys/abi/cp15_barrier
Default: Emulate (1) :Status: Deprecated
:Default: Emulate (1)
* SETEND * SETEND
Node: /proc/sys/abi/setend
Status: Deprecated :Node: /proc/sys/abi/setend
Default: Emulate (1)* :Status: Deprecated
Note: All the cpus on the system must have mixed endian support at EL0 :Default: Emulate (1)*
for this feature to be enabled. If a new CPU - which doesn't support mixed
endian - is hotplugged in after this feature has been enabled, there could Note: All the cpus on the system must have mixed endian support at EL0
be unexpected results in the application. for this feature to be enabled. If a new CPU - which doesn't support mixed
endian - is hotplugged in after this feature has been enabled, there could
be unexpected results in the application.

98
Documentation/arm64/memory.rst 100644
View File

@ -0,0 +1,98 @@
==============================
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.
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 + 3 levels::
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000007fffffffff 512GB user
ffffff8000000000 ffffffffffffffff 512GB kernel
AArch64 Linux memory layout with 4KB pages + 4 levels::
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffffffffffffffff 256TB kernel
AArch64 Linux memory layout with 64KB pages + 2 levels::
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 000003ffffffffff 4TB user
fffffc0000000000 ffffffffffffffff 4TB kernel
AArch64 Linux memory layout with 64KB pages + 3 levels::
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffffffffffffffff 256TB kernel
For details of the virtual kernel memory layout please see the kernel
booting log.
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
+-------------------------------------------------> [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_HARDEN_EL2_VECTORS is selected for particular CPUs.
When using KVM with the Virtualization Host Extensions, no additional
mappings are created, since the host kernel runs directly in EL2.

97
Documentation/arm64/memory.txt
View File

@ -1,97 +0,0 @@
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.
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 + 3 levels:
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000007fffffffff 512GB user
ffffff8000000000 ffffffffffffffff 512GB kernel
AArch64 Linux memory layout with 4KB pages + 4 levels:
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffffffffffffffff 256TB kernel
AArch64 Linux memory layout with 64KB pages + 2 levels:
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 000003ffffffffff 4TB user
fffffc0000000000 ffffffffffffffff 4TB kernel
AArch64 Linux memory layout with 64KB pages + 3 levels:
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffffffffffffffff 256TB kernel
For details of the virtual kernel memory layout please see the kernel
booting log.
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
+-------------------------------------------------> [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_HARDEN_EL2_VECTORS is selected for particular CPUs.
When using KVM with the Virtualization Host Extensions, no additional
mappings are created, since the host kernel runs directly in EL2.

2
Documentation/arm64/pointer-authentication.txt → Documentation/arm64/pointer-authentication.rst
View File

@ -1,7 +1,9 @@
=======================================
Pointer authentication in AArch64 Linux Pointer authentication in AArch64 Linux
======================================= =======================================
Author: Mark Rutland <mark.rutland@arm.com> Author: Mark Rutland <mark.rutland@arm.com>
Date: 2017-07-19 Date: 2017-07-19
This document briefly describes the provision of pointer authentication This document briefly describes the provision of pointer authentication

65
Documentation/arm64/silicon-errata.txt → Documentation/arm64/silicon-errata.rst
View File

@ -1,7 +1,9 @@
Silicon Errata and Software Workarounds =======================================
======================================= Silicon Errata and Software Workarounds
=======================================
Author: Will Deacon <will.deacon@arm.com> Author: Will Deacon <will.deacon@arm.com>
Date : 27 November 2015 Date : 27 November 2015
It is an unfortunate fact of life that hardware is often produced with It is an unfortunate fact of life that hardware is often produced with
@ -9,11 +11,13 @@ so-called "errata", which can cause it to deviate from the architecture
under specific circumstances. For hardware produced by ARM, these under specific circumstances. For hardware produced by ARM, these
errata are broadly classified into the following categories: 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 Category A A critical error without a viable workaround.
Category B A significant or critical error with an acceptable
workaround. workaround.
Category C: A minor error that is not expected to occur under normal Category C A minor error that is not expected to occur under normal
operation. operation.
========== ========================================================
For more information, consult one of the "Software Developers Errata For more information, consult one of the "Software Developers Errata
Notice" documents available on infocenter.arm.com (registration Notice" documents available on infocenter.arm.com (registration
@ -42,47 +46,86 @@ file acts as a registry of software workarounds in the Linux Kernel and
will be updated when new workarounds are committed and backported to will be updated when new workarounds are committed and backported to
stable kernels. stable kernels.
| Implementor | Component | Erratum ID | Kconfig |
+----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+
| Implementor | Component | Erratum ID | Kconfig |
+================+=================+=================+=============================+
| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 | | Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
| | | | | +----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | | ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 | | ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 | | ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | | ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | | ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A57 | #852523 | N/A | | ARM | Cortex-A57 | #852523 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | | ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A72 | #853709 | N/A | | ARM | Cortex-A72 | #853709 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 | | ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 | | ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 | | ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 | | ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 | | ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 | | ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 | | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-500 | #841119,826419 | N/A | | ARM | MMU-500 | #841119,826419 | N/A |
| | | | | +----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 | | Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 | | Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | | Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 | | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 | | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX SMMUv2 | #27704 | N/A | | Cavium | ThunderX SMMUv2 | #27704 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX2 SMMUv3| #74 | N/A | | Cavium | ThunderX2 SMMUv3| #74 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX2 SMMUv3| #126 | N/A | | Cavium | ThunderX2 SMMUv3| #126 | N/A |
| | | | | +----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
| | | | | +----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 | | Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip0{6,7} | #161010701 | N/A | | Hisilicon | Hip0{6,7} | #161010701 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 | | Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A | | Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
| | | | | +----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 | | Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 | | Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 | | Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 | | Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 | | Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
+----------------+-----------------+-----------------+-----------------------------+

12
Documentation/arm64/sve.txt → Documentation/arm64/sve.rst
View File

@ -1,7 +1,9 @@
Scalable Vector Extension support for AArch64 Linux ===================================================
=================================================== Scalable Vector Extension support for AArch64 Linux
===================================================
Author: Dave Martin <Dave.Martin@arm.com> Author: Dave Martin <Dave.Martin@arm.com>
Date: 4 August 2017 Date: 4 August 2017
This document outlines briefly the interface provided to userspace by Linux in This document outlines briefly the interface provided to userspace by Linux in
@ -426,7 +428,7 @@ In A64 state, SVE adds the following:
* FPSR and FPCR are retained from ARMv8-A, and interact with SVE floating-point * FPSR and FPCR are retained from ARMv8-A, and interact with SVE floating-point
operations in a similar way to the way in which they interact with ARMv8 operations in a similar way to the way in which they interact with ARMv8
floating-point operations. floating-point operations::
8VL-1 128 0 bit index 8VL-1 128 0 bit index
+---- //// -----------------+ +---- //// -----------------+
@ -483,6 +485,8 @@ ARMv8-A defines the following floating-point / SIMD register state:
* 32 128-bit vector registers V0..V31 * 32 128-bit vector registers V0..V31
* 2 32-bit status/control registers FPSR, FPCR * 2 32-bit status/control registers FPSR, FPCR
::
127 0 bit index 127 0 bit index
+---------------+ +---------------+
V0 | | V0 | |
@ -517,7 +521,7 @@ References
[2] arch/arm64/include/uapi/asm/ptrace.h [2] arch/arm64/include/uapi/asm/ptrace.h
AArch64 Linux ptrace ABI definitions AArch64 Linux ptrace ABI definitions
[3] Documentation/arm64/cpu-feature-registers.txt [3] Documentation/arm64/cpu-feature-registers.rst
[4] ARM IHI0055C [4] ARM IHI0055C
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf

6
Documentation/arm64/tagged-pointers.txt → Documentation/arm64/tagged-pointers.rst
View File

@ -1,7 +1,9 @@
Tagged virtual addresses in AArch64 Linux =========================================
========================================= Tagged virtual addresses in AArch64 Linux
=========================================
Author: Will Deacon <will.deacon@arm.com> Author: Will Deacon <will.deacon@arm.com>
Date : 12 June 2013 Date : 12 June 2013
This document briefly describes the provision of tagged virtual This document briefly describes the provision of tagged virtual

4
Documentation/translations/zh_CN/arm64/booting.txt
View File

@ -1,4 +1,4 @@
Chinese translated version of Documentation/arm64/booting.txt Chinese translated version of Documentation/arm64/booting.rst
If you have any comment or update to the content, please contact the If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem original document maintainer directly. However, if you have a problem
@ -10,7 +10,7 @@ M: Will Deacon <will.deacon@arm.com>
zh_CN: Fu Wei <wefu@redhat.com> zh_CN: Fu Wei <wefu@redhat.com>
C: 55f058e7574c3615dea4615573a19bdb258696c6 C: 55f058e7574c3615dea4615573a19bdb258696c6
--------------------------------------------------------------------- ---------------------------------------------------------------------
Documentation/arm64/booting.txt 的中文翻译 Documentation/arm64/booting.rst 的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻

4
Documentation/translations/zh_CN/arm64/legacy_instructions.txt
View File

@ -1,4 +1,4 @@
Chinese translated version of Documentation/arm64/legacy_instructions.txt Chinese translated version of Documentation/arm64/legacy_instructions.rst
If you have any comment or update to the content, please contact the If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem original document maintainer directly. However, if you have a problem
@ -10,7 +10,7 @@ Maintainer: Punit Agrawal <punit.agrawal@arm.com>
Suzuki K. Poulose <suzuki.poulose@arm.com> Suzuki K. Poulose <suzuki.poulose@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com> Chinese maintainer: Fu Wei <wefu@redhat.com>
--------------------------------------------------------------------- ---------------------------------------------------------------------
Documentation/arm64/legacy_instructions.txt 的中文翻译 Documentation/arm64/legacy_instructions.rst 的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻

4
Documentation/translations/zh_CN/arm64/memory.txt
View File

@ -1,4 +1,4 @@
Chinese translated version of Documentation/arm64/memory.txt Chinese translated version of Documentation/arm64/memory.rst
If you have any comment or update to the content, please contact the If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem original document maintainer directly. However, if you have a problem
@ -9,7 +9,7 @@ or if there is a problem with the translation.
Maintainer: Catalin Marinas <catalin.marinas@arm.com> Maintainer: Catalin Marinas <catalin.marinas@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com> Chinese maintainer: Fu Wei <wefu@redhat.com>
--------------------------------------------------------------------- ---------------------------------------------------------------------
Documentation/arm64/memory.txt 的中文翻译 Documentation/arm64/memory.rst 的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻

4
Documentation/translations/zh_CN/arm64/silicon-errata.txt
View File

@ -1,4 +1,4 @@
Chinese translated version of Documentation/arm64/silicon-errata.txt Chinese translated version of Documentation/arm64/silicon-errata.rst
If you have any comment or update to the content, please contact the If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem original document maintainer directly. However, if you have a problem
@ -10,7 +10,7 @@ M: Will Deacon <will.deacon@arm.com>
zh_CN: Fu Wei <wefu@redhat.com> zh_CN: Fu Wei <wefu@redhat.com>
C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
--------------------------------------------------------------------- ---------------------------------------------------------------------
Documentation/arm64/silicon-errata.txt 的中文翻译 Documentation/arm64/silicon-errata.rst 的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻

4
Documentation/translations/zh_CN/arm64/tagged-pointers.txt
View File

@ -1,4 +1,4 @@
Chinese translated version of Documentation/arm64/tagged-pointers.txt Chinese translated version of Documentation/arm64/tagged-pointers.rst
If you have any comment or update to the content, please contact the If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem original document maintainer directly. However, if you have a problem
@ -9,7 +9,7 @@ or if there is a problem with the translation.
Maintainer: Will Deacon <will.deacon@arm.com> Maintainer: Will Deacon <will.deacon@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com> Chinese maintainer: Fu Wei <wefu@redhat.com>
--------------------------------------------------------------------- ---------------------------------------------------------------------
Documentation/arm64/tagged-pointers.txt 的中文翻译 Documentation/arm64/tagged-pointers.rst 的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻

2
Documentation/virtual/kvm/api.txt
View File

@ -2205,7 +2205,7 @@ max_vq. This is the maximum vector length available to the guest on
this vcpu, and determines which register slices are visible through this vcpu, and determines which register slices are visible through
this ioctl interface. this ioctl interface.
(See Documentation/arm64/sve.txt for an explanation of the "vq" (See Documentation/arm64/sve.rst for an explanation of the "vq"
nomenclature.) nomenclature.)
KVM_REG_ARM64_SVE_VLS is only accessible after KVM_ARM_VCPU_INIT. KVM_REG_ARM64_SVE_VLS is only accessible after KVM_ARM_VCPU_INIT.

2
arch/arm64/include/asm/efi.h
View File

@ -83,7 +83,7 @@ static inline unsigned long efi_get_max_fdt_addr(unsigned long dram_base)
* guaranteed to cover the kernel Image. * guaranteed to cover the kernel Image.
* *
* Since the EFI stub is part of the kernel Image, we can relax the * Since the EFI stub is part of the kernel Image, we can relax the
* usual requirements in Documentation/arm64/booting.txt, which still * usual requirements in Documentation/arm64/booting.rst, which still
* apply to other bootloaders, and are required for some kernel * apply to other bootloaders, and are required for some kernel
* configurations. * configurations.
*/ */

2
arch/arm64/include/asm/image.h
View File

@ -27,7 +27,7 @@
/* /*
* struct arm64_image_header - arm64 kernel image header * struct arm64_image_header - arm64 kernel image header
* See Documentation/arm64/booting.txt for details * See Documentation/arm64/booting.rst for details
* *
* @code0: Executable code, or * @code0: Executable code, or
* @mz_header alternatively used for part of MZ header * @mz_header alternatively used for part of MZ header

2
arch/arm64/include/uapi/asm/sigcontext.h
View File

@ -137,7 +137,7 @@ struct sve_context {
* vector length beyond its initial architectural limit of 2048 bits * vector length beyond its initial architectural limit of 2048 bits
* (16 quadwords). * (16 quadwords).
* *
* See linux/Documentation/arm64/sve.txt for a description of the VL/VQ * See linux/Documentation/arm64/sve.rst for a description of the VL/VQ
* terminology. * terminology.
*/ */
#define SVE_VQ_BYTES __SVE_VQ_BYTES /* bytes per quadword */ #define SVE_VQ_BYTES __SVE_VQ_BYTES /* bytes per quadword */

2
arch/arm64/kernel/kexec_image.c
View File

@ -53,7 +53,7 @@ static void *image_load(struct kimage *image,
/* /*
* We require a kernel with an unambiguous Image header. Per * We require a kernel with an unambiguous Image header. Per
* Documentation/arm64/booting.txt, this is the case when image_size * Documentation/arm64/booting.rst, this is the case when image_size
* is non-zero (practically speaking, since v3.17). * is non-zero (practically speaking, since v3.17).
*/ */
h = (struct arm64_image_header *)kernel; h = (struct arm64_image_header *)kernel;