tyler.durden
/
audk
mirror of https://github.com/acidanthera/audk.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
audk/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf

45 lines
1.1 KiB
INI
Raw Normal View History

ArmVirtPkg: add PlatformHasAcpiDtDxe This driver produces the EDKII Platform Has ACPI and Platform Has Device Tree protocols, exactly matching the current ACPI / DT exposure on QEMU, according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 15:12:28 +01:00
## @file
# Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
# hardware description to the operating system.
#
# Copyright (c) 2017, Red Hat, Inc.
#
ArmVirtPkg: Replace BSD License with BSD+Patent License https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 01:03:23 +02:00
# SPDX-License-Identifier: BSD-2-Clause-Patent
ArmVirtPkg: add PlatformHasAcpiDtDxe This driver produces the EDKII Platform Has ACPI and Platform Has Device Tree protocols, exactly matching the current ACPI / DT exposure on QEMU, according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 15:12:28 +01:00
##
[Defines]
INF_VERSION = 1.25
BASE_NAME = PlatformHasAcpiDtDxe
FILE_GUID = 9d1dd27f-6d7f-427b-aec4-b62f6279c2f1
MODULE_TYPE = DXE_DRIVER
VERSION_STRING = 1.0
ENTRY_POINT = PlatformHasAcpiDt
[Sources]
PlatformHasAcpiDtDxe.c
[Packages]
ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override In general, we should not present two separate (and inevitably different) hardware descriptions to the OS, in the form of ACPI tables and a device tree blob. For this reason, we recently added the logic to ArmVirtQemu to only expose the ACPI 2.0 entry point if no DT binary is being passed, and vice versa. However, this is arguably a regression for those who relied on DT descriptions being available, even if the former behavior can be restored by passing the -no-acpi switch to QEMU. So allow a secret handshake with the UEFI Shell, to set a variable that will result in ACPI to be disabled on subsequent boots even if -no-acpi was not passed on the QEMU command line. setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi =01 To delete the variable and revert to the old situation, simply omit the value after the = setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi = Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
2017-03-29 19:50:39 +02:00
ArmVirtPkg/ArmVirtPkg.dec
ArmVirtPkg: add PlatformHasAcpiDtDxe This driver produces the EDKII Platform Has ACPI and Platform Has Device Tree protocols, exactly matching the current ACPI / DT exposure on QEMU, according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 15:12:28 +01:00
EmbeddedPkg/EmbeddedPkg.dec
MdeModulePkg: move PlatformHasAcpiGuid from EmbeddedPkg Given the agreement on the edk2-devel regarding the fact that the notion whether or not a 'platform has ACPI' is a universal one, move the PlatformHasAcpi GUID to MdeModulePkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: "Zeng, Star" <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2017-04-05 11:35:06 +02:00
MdeModulePkg/MdeModulePkg.dec
ArmVirtPkg: add PlatformHasAcpiDtDxe This driver produces the EDKII Platform Has ACPI and Platform Has Device Tree protocols, exactly matching the current ACPI / DT exposure on QEMU, according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 15:12:28 +01:00
MdePkg/MdePkg.dec
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to the guest. Showing both is never needed (it is actually detrimental to the adoption of standards, such as SBSA / SBBR). * Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe) > Found FwCfg @ 0x9020008/0x9020000 > Found FwCfg DMA @ 0x9020010 > InstallProtocolInterface: [EdkiiPlatformHasAcpi] 0 plus the usual messages. Later the guest kernel logs > [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000 > MEMATTR=0x13a675018 before it lists the ACPI tables one by one. In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern matches no files, while the "/sys/firmware/acpi/tables/*" pattern matches the ACPI tables. * With "-no-acpi", the firmware logs: > PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000 > PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010 > PlatformHasAcpiDtDxe | InstallProtocolInterface: > PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTree] 0 > FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @ > FdtClientDxe | 0x13FFBF000 to OS > ... > DXE_CORE | Driver [AcpiTableDxe] was discovered but not > DXE_CORE | loaded!! > DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but > DXE_CORE | not loaded!! > ... > RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI > RamDiskDxe | Table Protocol, unable to publish RAM disks to > RamDiskDxe | NFIT. (BootGraphicsResourceTableDxe's ReadyToBoot callback -- InstallBootGraphicsResourceTable() -- handles the lack of EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs > [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 MEMATTR=0x138caa018 In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern matches the directory "/sys/firmware/devicetree/base", which contains a large number of DT nodes, while the "/sys/firmware/acpi/tables/*" pattern matches no files. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 17:50:24 +01:00
OvmfPkg/OvmfPkg.dec
ArmVirtPkg: add PlatformHasAcpiDtDxe This driver produces the EDKII Platform Has ACPI and Platform Has Device Tree protocols, exactly matching the current ACPI / DT exposure on QEMU, according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 15:12:28 +01:00
[LibraryClasses]
BaseLib
DebugLib
ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override In general, we should not present two separate (and inevitably different) hardware descriptions to the OS, in the form of ACPI tables and a device tree blob. For this reason, we recently added the logic to ArmVirtQemu to only expose the ACPI 2.0 entry point if no DT binary is being passed, and vice versa. However, this is arguably a regression for those who relied on DT descriptions being available, even if the former behavior can be restored by passing the -no-acpi switch to QEMU. So allow a secret handshake with the UEFI Shell, to set a variable that will result in ACPI to be disabled on subsequent boots even if -no-acpi was not passed on the QEMU command line. setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi =01 To delete the variable and revert to the old situation, simply omit the value after the = setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi = Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
2017-03-29 19:50:39 +02:00
PcdLib
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to the guest. Showing both is never needed (it is actually detrimental to the adoption of standards, such as SBSA / SBBR). * Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe) > Found FwCfg @ 0x9020008/0x9020000 > Found FwCfg DMA @ 0x9020010 > InstallProtocolInterface: [EdkiiPlatformHasAcpi] 0 plus the usual messages. Later the guest kernel logs > [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000 > MEMATTR=0x13a675018 before it lists the ACPI tables one by one. In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern matches no files, while the "/sys/firmware/acpi/tables/*" pattern matches the ACPI tables. * With "-no-acpi", the firmware logs: > PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000 > PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010 > PlatformHasAcpiDtDxe | InstallProtocolInterface: > PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTree] 0 > FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @ > FdtClientDxe | 0x13FFBF000 to OS > ... > DXE_CORE | Driver [AcpiTableDxe] was discovered but not > DXE_CORE | loaded!! > DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but > DXE_CORE | not loaded!! > ... > RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI > RamDiskDxe | Table Protocol, unable to publish RAM disks to > RamDiskDxe | NFIT. (BootGraphicsResourceTableDxe's ReadyToBoot callback -- InstallBootGraphicsResourceTable() -- handles the lack of EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs > [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 MEMATTR=0x138caa018 In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern matches the directory "/sys/firmware/devicetree/base", which contains a large number of DT nodes, while the "/sys/firmware/acpi/tables/*" pattern matches no files. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 17:50:24 +01:00
QemuFwCfgLib
ArmVirtPkg: add PlatformHasAcpiDtDxe This driver produces the EDKII Platform Has ACPI and Platform Has Device Tree protocols, exactly matching the current ACPI / DT exposure on QEMU, according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 15:12:28 +01:00
UefiBootServicesTableLib
UefiDriverEntryPoint
[Guids]
gEdkiiPlatformHasAcpiGuid ## SOMETIMES_PRODUCES ## PROTOCOL
gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL
ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override In general, we should not present two separate (and inevitably different) hardware descriptions to the OS, in the form of ACPI tables and a device tree blob. For this reason, we recently added the logic to ArmVirtQemu to only expose the ACPI 2.0 entry point if no DT binary is being passed, and vice versa. However, this is arguably a regression for those who relied on DT descriptions being available, even if the former behavior can be restored by passing the -no-acpi switch to QEMU. So allow a secret handshake with the UEFI Shell, to set a variable that will result in ACPI to be disabled on subsequent boots even if -no-acpi was not passed on the QEMU command line. setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi =01 To delete the variable and revert to the old situation, simply omit the value after the = setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi = Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
2017-03-29 19:50:39 +02:00
[Pcd]
gArmVirtTokenSpaceGuid.PcdForceNoAcpi
ArmVirtPkg: add PlatformHasAcpiDtDxe This driver produces the EDKII Platform Has ACPI and Platform Has Device Tree protocols, exactly matching the current ACPI / DT exposure on QEMU, according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-03-17 15:12:28 +01:00
[Depex]
ArmVirtPkg/PlatformHasAcpiDtDxe: depend on gEfiVariableArchProtocolGuid PlatformHasAcpiDtDxe consumes the DynamicHii PCD called "gArmVirtTokenSpaceGuid.PcdForceNoAcpi". The PcdGetBool() library call terminates in gRT->GetVariable(), in the MdeModulePkg/Universal/PCD/Dxe driver. Put "gEfiVariableArchProtocolGuid" on PlatformHasAcpiDtDxe's DEPEX so that we not attempt the call before the PCD driver can successfully read non-volatile variables. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Steve Capper <steve.capper@linaro.org> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@arm.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2018-04-12 01:37:21 +02:00
gEfiVariableArchProtocolGuid