audk/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf

51 lines
1.4 KiB
INI
Raw Normal View History

## @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.
#
# This program and the accompanying materials are licensed and made available
# under the terms and conditions of the BSD License which accompanies this
# distribution. The full text of the license may be found at
# http://opensource.org/licenses/bsd-license.php
#
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
##
[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/ArmVirtPkg.dec
EmbeddedPkg/EmbeddedPkg.dec
MdeModulePkg/MdeModulePkg.dec
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
[LibraryClasses]
BaseLib
DebugLib
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
UefiBootServicesTableLib
UefiDriverEntryPoint
[Guids]
gEdkiiPlatformHasAcpiGuid ## SOMETIMES_PRODUCES ## PROTOCOL
gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL
[Pcd]
gArmVirtTokenSpaceGuid.PcdForceNoAcpi
[Depex]
TRUE