The lates generation of 64-bit ARM server hardware seems to be ACPI-only. This obviously fills me with a tremendous amount of joy. ACPi is clearly superior to device trees. So much more superior that they you have to embed snippets of device tree properties into your AML to make it do anything useful on stuff that isn't 100% bog-standard hardware [1].
Well, enough sarcasm. Maybe this is even a good thing since it encourages ARM server vendors from being too creative and simply stick everything of interest behind a PCIe host bridge. I have some ideas on how to support ACPI on OpenBSD/arm64. As a first stap, I'd like to make acpidump(4) work. The diff below adds a little bit of kernel code to stick the address where the ACPI tables can be found into a global variable. ok? [1] https://lwn.net/Articles/612062/ Index: dev/acpi/efi.h =================================================================== RCS file: /cvs/src/sys/dev/acpi/efi.h,v retrieving revision 1.2 diff -u -p -r1.2 efi.h --- dev/acpi/efi.h 4 Jan 2018 14:30:08 -0000 1.2 +++ dev/acpi/efi.h 23 Jun 2018 14:13:57 -0000 @@ -13,7 +13,6 @@ typedef uint64_t UINT64; typedef u_long UINTN; typedef uint16_t CHAR16; typedef void VOID; -typedef uint32_t EFI_GUID[4]; typedef uint64_t EFI_PHYSICAL_ADDRESS; typedef uint64_t EFI_VIRTUAL_ADDRESS; typedef UINTN EFI_STATUS; @@ -23,6 +22,17 @@ typedef VOID *EFI_SIMPLE_TEXT_INPUT_PRO typedef VOID *EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL; typedef VOID *EFI_BOOT_SERVICES; +typedef struct { + UINT32 Data1; + UINT16 Data2; + UINT16 Data3; + UINT8 Data4[8]; +} EFI_GUID; + +#define EFI_ACPI_20_TABLE_GUID \ + { 0x8868e871, 0xe4f1, 0x11d3, \ + { 0xbc, 0x22, 0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81} } + typedef enum { EfiReservedMemoryType, EfiLoaderCode, @@ -130,4 +140,6 @@ typedef struct { #define EFI_SUCCESS 0 -#endif /* _MACHINE_EFI_H_ */ +#define efi_guidcmp(_a, _b) memcmp((_a), (_b), sizeof(EFI_GUID)) + +#endif /* _DEV_ACPI_EFI_H_ */ Index: arch/arm64/dev/efi.c =================================================================== RCS file: /cvs/src/sys/arch/arm64/dev/efi.c,v retrieving revision 1.4 diff -u -p -r1.4 efi.c --- arch/arm64/dev/efi.c 6 Apr 2018 19:09:05 -0000 1.4 +++ arch/arm64/dev/efi.c 23 Jun 2018 14:13:57 -0000 @@ -41,6 +41,8 @@ extern uint32_t mmap_desc_ver; extern EFI_MEMORY_DESCRIPTOR *mmap; +uint64_t efi_acpi_table; + struct efi_softc { struct device sc_dev; struct pmap *sc_pm; @@ -168,18 +170,25 @@ efi_attach(struct device *parent, struct } /* - * The FirmwareVendor field has been converted from a physical - * pointer to a virtual pointer, so we have to activate our - * pmap to access it. + * The FirmwareVendor and ConfigurationTable fields have been + * converted from a physical pointer to a virtual pointer, so + * we have to activate our pmap to access them. */ + efi_enter(sc); if (st->FirmwareVendor) { printf("%s: ", sc->sc_dev.dv_xname); - efi_enter(sc); for (i = 0; st->FirmwareVendor[i]; i++) printf("%c", st->FirmwareVendor[i]); - efi_leave(sc); printf(" rev 0x%x\n", st->FirmwareRevision); } + for (i = 0; i < st->NumberOfTableEntries; i++) { + EFI_CONFIGURATION_TABLE *ct = &st->ConfigurationTable[i]; + static EFI_GUID acpi_guid = EFI_ACPI_20_TABLE_GUID; + + if (efi_guidcmp(&acpi_guid, &ct->VendorGuid) == 0) + efi_acpi_table = (uint64_t)ct->VendorTable; + } + efi_leave(sc); if (rs == NULL) return; @@ -278,4 +287,3 @@ efi_settime(struct todr_chip_handle *han return EIO; return 0; } -
