On Sat, Jun 23, 2018 at 04:32:21PM +0200, Mark Kettenis wrote: > 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? > >
ok mlarkin if you didn't get around to it already > [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; > } > - >
