[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
ARM64 ACPI status report 1
First some background on this project:
ARM has a standard called Server Base System Architecture (SBSA) that
defines a basic set of hardware required for compliant systems. In
addition, a companion spec called Server Base Boot Requirements (SBBR)
defines ARM64 firmware interfaces necessary for booting an OS with basic
functionality. UEFI, ACPI (in something called "hardware-reduced mode"),
and SMBIOS are the firmware interfaces defined by SBBR.
Some highlights of the changes I've made since starting this project:
- ACPI MD code has been implemented and ACPICA has been hooked into the
- The ARM64 UEFI bootloader (bootaa64.efi) has been made ACPI and SMBIOS
- A lot of work has been done in evbarm to support FDT and runtime
configuration. For booting in ACPI mode, I'm taking advantage of this
by having the bootloader generate a devicetree at runtime that
describes a "NetBSD ARM ACPI platform". Generic ACPI platform support
code is added to spin up CPUs, discover the serial console, etc.
An "acpi at fdt" driver ties in the ACPI subsystem and all other device
drivers attach here.
- It took two tries to get CPU attachment right. First attempt was to
attach a CPU to each CPU device in the DSDT ("ACPI0007"). To spin up a
secondary processor, you need to make a firmware call using the Power
State and Control Interface (PSCI), passing a processor ID derived from
the MPIDR register and a physical address that contains the startup
code. The CPU device node in the DSDT does not include the MPIDR, so to
get this you need to read the _UID method and find a MADT
Generic Interrupt (GICC) subtable containing the same value. This
subtable has another field that defines the processor's MPIDR. Problem
is that on my dev board (SoftIron Overdrive 1000) the firmware messed
this up, and the processor _UIDs do not always match the GICC UIDs. I
changed the code to ignore the CPU devices in the DSDT completely, and
instead use GICC subtables to attach CPUs directly.
- PCIe support via ACPI MCFG tables. On x86, we don't attach pci to acpi,
so the strategy here was a bit different (and I had to fix a few
existing assumptions along the way).
- Userland tools for ACPI (acpidump, amldb, iasl) were added to the ARM64
build. acpidump only works with options INSECURE as it uses /dev/mem,
and this is not defined in GENERIC64.
- The ACPI subsystem was unconditionally attaching a PM timer
timecounter, and both ACPI-Fast and ACPI-Safe timers match higher than
the ARM Generic Timer. It turns out that we shouldn't have been
attaching the PM timer in this case, because the PM_TMR_LEN field in
the Fixed ACPI Description Table (FADT) was 0. Fixed.
- Added support for building the ACPI subsystem with the ACPICA
ACPI_REDUCED_HARDWARE option. This disables some code that we will not
need for SBSA.
- On hardware-reduced platforms, interrupts and/or GPIOs are used to
signal ACPI events. ACPI glue for the existing PL061 GPIO driver (this
is the GPIO controller defined by SBSA) was written and extended to
support these events. In addition, an ACPI Generic Event Device driver
was written to support interrupt-based ACPI events (not yet tested).
- An SBSA-compliant watchdog driver was implemented.
- Added ACPI attachment glue for the ARM Generic Timer, GICv2, GICv3,
PL011 UART, DesignWare I2C, and AHCI SATA drivers.
- Support for the PCI MSI/MSI-X kernel API was added to the ARM port,
along with an implementation of MSI for GICv2m. MSI-X support for
GICv2m has not yet been written.
- sysutils/dmidecode in pkgsrc was patched to support finding the SMBIOS
table on ARM64 systems.
- SoftIron Overdrive 1000 and QEMU in ACPI mode are working well now:
- Overdrive 1000: https://dmesgd.nycbug.org/index.cgi?do=view&id=4526
- QEMU: https://youtu.be/GXYmfQ-7ZaE
- Some testing on ThunderX but we are not yet multiuser there.
- Some testing on a Raspberry Pi 3 running Tianocore EDK2. Does not work
because it is not SBSA compliant (no Generic Interrupt Controller).
Out of scope, but I may make this work at some point in the future just
What's next, in no particular order:
- Bring in support for EFI runtime services to the kernel. This is needed
to access the RTC.
- Adding GPT support (currently only supports MBR) and NFS booting to the
- GICv2m MSI-X support
- GICv3 ITS (MSI/MSI-X) support
- Add ACPI glue for ehci and xhci at acpi
Main Index |
Thread Index |