ARM64 ACPI status report 1

[Jared McNeill <jmcneill%invisible.ca@localhost>]

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
   ARM64 build.

 - The ARM64 UEFI bootloader (bootaa64.efi) has been made ACPI and SMBIOS
   aware.

 - 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
   for fun.

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
   UEFI bootloader.

 - GICv2m MSI-X support

 - GICv3 ITS (MSI/MSI-X) support

 - Add ACPI glue for ehci and xhci at acpi

Cheers,
Jared