summaryrefslogtreecommitdiff
path: root/ArmVirtPkg
AgeCommit message (Collapse)AuthorFilesLines
2019-10-16ArmVirtPkg/PlatformBootManagerLib: Don't update progress if Pcd is 0Pete Batard1-3/+11
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266 Similar to what we now do for OVMF, we need to consider the possibility that PlatformBootManagerWaitCallback () may be called with a PcdPlatformBootTimeOut that was set to zero, in which case the call should simply return. We also change the initial timeout variable name to make the code explicit. Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20191014150311.16740-3-pete@akeo.ie>
2019-09-13ArmVirtPkg: increase FD/FV size for NOOPT buildsArd Biesheuvel4-9/+68
After upgrading the CI system we use for building the ArmVirtPkg targets, we started seeing failures due to the NOOPT build running out of space when using the CLANG38 toolchain definition combined with clang 7. We really don't want to increase the FD/FV sizes in general to accommodate this, so parameterize the relevant quantities and increase them by 50% for NOOPT builds. Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-09-05ArmVirtPkg/PlatformBootManagerLib: unload image on EFI_SECURITY_VIOLATIONLaszlo Ersek1-1/+8
The LoadImage() boot service is a bit unusual in that it allocates resources in a particular failure case; namely, it produces a valid "ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to happen e.g. when Secure Boot verification fails for the image, but the platform policy for the particular image origin (such as "fixed media" or "removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code allows platform logic to selectively override the verification failure, and launch the image nonetheless. ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION for the kernel image loaded from fw_cfg -- any LoadImage() error is considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any other LoadImage() error, we leak the resources associated with "KernelImageHandle". From a resource usage perspective, EFI_SECURITY_VIOLATION must be considered "success", and rolled back. Implement this rollback, without breaking the proper "nesting" of error handling jumps and labels. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992 Fixes: 23d04b58e27b382bbd3f9b16ba9adb1cb203dad5 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-09-05ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linkingArd Biesheuvel1-1/+1
In some cases, the CLANG38 toolchain profile in LTO mode emits GOT based relocations in spite of our attempts to avoid this, by using hidden visibility, -Bsymbolic etc. On AARCH64, we managed to work around this by processing the GOT based relocations in GenFw. As it turns out, the same issue exists on 32-bit ARM, but unfortunately, we cannot use a similar trick to get rid of the GOT entry, and the relocation metadata is insufficient to locate the GOT entry in the binary. Note that in this particular case, we are interested in PIE linking only (i.e., producing a .rela section containing dynamic relocations that the startup code can process directly), and not in position independent code generation, and by passing the -pie option to the linker directly using -Wl,-pie (and dropping -shared), we can coerce the GOLD linker into doing only the former rather than both when it performs its LTO code generation. Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-08-21OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkgAnthony PERARD3-224/+1
Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg" Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-35-anthony.perard@citrix.com>
2019-06-28ArmVirtPkg: handle NETWORK_TLS_ENABLE in ArmVirtQemu*Laszlo Ersek3-8/+35
Port the [LibraryClasses], [PcdsFixedAtBuild] and [Components] settings that are related to NETWORK_TLS_ENABLE from OvmfPkg to ArmVirtPkg. ArmVirtXen is not modified because it doesn't include the edk2 network stack. (This change is now simpler than it would have been when TianoCore#1009 was originally filed, due to ArmVirtPkg consuming the NetworkPkg include fragments meanwhile, from TianoCore#1293 / commit 157a3b1aa50f.) The usage hints from "OvmfPkg/README", section "HTTPS Boot", apply. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Guillaume GARDET <guillaume.gardet@arm.com> Cc: Julien Grall <julien.grall@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1009 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Guillaume Gardet <guillaume.gardet@arm.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Gary Lin <glin@suse.com>
2019-06-14ArmVirtPkg/PlatformBootManagerLib: Use EDKII_SERIAL_PORT_LIB_VENDOR_GUIDAnthony PERARD1-6/+2
SERIAL_DXE_FILE_GUID is now defined in MdeModulePkg as EDKII_SERIAL_PORT_LIB_VENDOR_GUID, simply use it. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20190606131459.1464-3-anthony.perard@citrix.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [lersek@redhat.com: drop "from MdeModulePkg" from the subject] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2019-05-16ArmVirtPkg: Update DSC/FDF to use NetworkPkg's include fragment file.Fu Siyuan4-87/+52
This patch updates the platform DSC/FDF files to use the include fragment files provided by NetworkPkg. The feature enabling flags in [Defines] section have been updated to use the NetworkPkg's terms, and the value has been overridden with the original default value on this platform. v2:Add check for NETWORK_SNP_ENABLE and NETWORK_TLS_ENABLE. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Message-Id: <20190516081810.27840-4-shenglei.zhang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293 [lersek@redhat.com: add TianoCore Bugzilla reference] [lersek@redhat.com: undo spurious whitespace changes] [lersek@redhat.com: clarify SNP and TLS rejection messages] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2019-04-30ArmVirtPkg: build EnrollDefaultKeys.efiLaszlo Ersek3-0/+3
Having removed VALID_ARCHITECTURES from "OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf", it now makes sense to reflect the related platform DSC bits from OvmfPkg to ArmVirtPkg. Build "EnrollDefaultKeys.efi" as part of ArmVirtQemu and ArmVirtQemuKernel (which are the ArmVirtPkg platforms that include SecureBootConfigDxe too). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
2019-04-28ArmVirtPkg/ArmVirtPsciResetSystemLib: Add a new API ResetSystemZhichao Gao1-0/+44
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460 Add a new API ResetSystem to this ResetSystemLib instance. It only adds the basic functions from ResetSystemRuntimeDxe. Lacking of this interface may cause link error, if some drivers use this new API and link to this library instance. Notes: This library API only provide a basic function of reset. Full function should use the instance in the MdeModulePkg and make sure the depex driver is dispatched. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-10ArmVirtPkg: Update UefiDecompressLib instanceDandan Bi2-14/+0
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1683 V2: Use the common UefiDecompressLib resolution in [LibraryClasses.common] section and drop all the others. BaseUefiDecompressLib in MdePkg is the base UEFI decompress Library. BaseUefiTianoCustomDecompressLib in IntelFrameworkModulePkg implements the base UEFI decompress functionality and Tiano decompress functionality. 1. TIANOCOMPRESSED rule in ArmVirtRules.fdf.inc is not used, so remove it. 2. Platform doesn't use the TianoCompress, so do not have to use BaseUefiTianoCustomDecompressLib, can use the BaseUefiDecompressLib in MdePkg directly. 3. UefiDecompressLib common resolution now can apply to all module types. So keep the UefiDecompressLib resolution in [LibraryClasses.common] section and remove all others. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@arm.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-09ArmVirtPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney80-561/+80
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-02-25ArmVirtPkg/PlatformBootManagerLib: display boot option loading/startingLaszlo Ersek4-0/+6
Consume PlatformBmPrintScLib, added earlier in this series. When BdsDxe+UefiBootManagerLib report LoadImage() / StartImage() preparations and return statuses, print the reports to the UEFI console. This allows end-users better visibility into the boot process. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-25ArmVirtPkg/ArmVirtQemu*: enable minimal Status Code Routing in DXELaszlo Ersek3-0/+25
The EFI_RETURN_STATUS_EXTENDED_DATA feature from PI-1.7 (<https://mantis.uefi.org/mantis/view.php?id=1885>) enables platform code to learn about boot option failures (loading and launching) via status codes reported by the UEFI Boot Manager. In commit 59541d41633c, we removed all status code support from ArmVirtPkg. Reenable that support now, minimally, just to the extent so we can benefit from the PI-1.7 feature mentioned above: (1) Include the ReportStatusCodeRouterRuntimeDxe driver. This driver produces two protocols, EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. The former allows DXE phase modules and runtime modules to report (produce) status codes. The latter allows the same types of modules to register callbacks for status code handling (consumption). (Handler registration occurs only at boot time. Status codes are delivered to each handler at runtime as well, unless the handler is unregistered at ExitBootServices().) (2) Resolve ReportStatusCodeLib to a non-Null instance, for DXE_DRIVER modules only. This way DXE_DRIVER modules that use the REPORT_STATUS_CODE_EX() macro and friends will reach EFI_STATUS_CODE_PROTOCOL from point (1). (3) Set PcdReportStatusCodePropertyMask to 3 (the default value is 0). This causes the REPORT_STATUS_CODE_EX() macro and friends to let Progress Codes (bit#0) and Error Codes (bit#1) through to point (1). Debug Codes (bit#2) are filtered out. (4) Include no driver, for now, that registers any status code handler via EFI_RSC_HANDLER_PROTOCOL, from point (1). Status codes that reach ReportStatusCodeRouterRuntimeDxe will be thrown away. (5) Modify only the ArmVirtQemu* platforms. A status code handler will be added to "ArmVirtPkg/Library/PlatformBootManagerLib" in the next patch, and this library instance is not consumed by ArmVirtXen. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg/ArmVirtXen: don't set Pcd*ImageVerificationPolicyLaszlo Ersek3-7/+14
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-1} (6 builds in total), PcdOptionRomImageVerificationPolicy, PcdFixedMediaImageVerificationPolicy, and PcdRemovableMediaImageVerificationPolicy are not used in any of those builds. Restrict the settings to the ArmVirtQemu and ArmVirtQemuKernel platforms (preserving the -D SECURE_BOOT_ENABLE restriction in the process). ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg/ArmVirtXen: don't set PcdTurnOffUsbLegacySupportLaszlo Ersek3-2/+4
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (12 builds in total), the PCD is not used in any of those builds. Restrict the setting to the ArmVirtQemu and ArmVirtQemuKernel platforms. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg/ArmVirtXen: don't set PcdShellFileLaszlo Ersek1-1/+0
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (12 builds in total), the PCD is not used in any of those builds. Remove the setting. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg/ArmVirtXen: don't set PcdTerminalTypeGuidBufferLaszlo Ersek4-9/+6
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (12 builds in total), the PCD is not used in any of those builds. Restrict the setting to the ArmVirtQemu and ArmVirtQemuKernel platforms. Restrict the TTY_TERMINAL define similarly. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg/ArmVirtXen: don't set PcdPL031RtcBaseLaszlo Ersek1-3/+0
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (12 builds in total), the PCD is not used in any of those builds. Remove the setting. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg: don't set PcdDebugPrintErrorLevel in RELEASE buildsLaszlo Ersek1-0/+2
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Qemu,QemuKernel,Xen} x {RELEASE} x {feat-0,feat-1} (12 builds in total), the PCD is not used in any of those builds. Restrict the PCD setting to ($(TARGET) != RELEASE). ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg: don't set PcdDebugClearMemoryValueLaszlo Ersek1-1/+0
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Qemu,QemuKernel,Xen} x {RELEASE} x {feat-0,feat-1} (12 builds in total), the PCD is not used in any of those builds. Rather than just restrict the PCD setting to ($(TARGET) != RELEASE), remove the setting completely. The current value is identical to the 0xAF default in "MdePkg/MdePkg.dec", which recognizes Andrew Fish, and so it's unlikely to ever change. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg: don't set PcdCoreCountLaszlo Ersek3-4/+0
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Qemu,QemuKernel,Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (36 builds in total), the PCD is not used in any of those builds. Remove the setting. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg/PrePi: drop wrong PcdCoreCount dependencyLaszlo Ersek1-2/+0
The PcdCoreCount dependency in the "ArmVirtPrePiUniCoreRelocatable.inf" file is false; the module doesn't consume the PCD. Clean up the INF. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg: clean up PcdSetNxForStack setting (applies to ArmVirtQemu only)Laszlo Ersek2-5/+5
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {QemuKernel,Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (24 builds in total), the PCD is not used in any of those builds. Move the setting from "ArmVirt.dsc.inc" to "ArmVirtQemu.dsc", to reflect reality. We originally moved the PCD setting in the opposite direction in commit 8aab575c26e9 ("ArmVirtPkg: enable non-executable DXE stack for all platforms", 2017-03-07), generalizing it. However, as the comment itself states, and according to all 36 ArmVirt build reports: {AARCH64,ARM} x {Qemu,QemuKernel,Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} the PCD is only consumed by "MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf", and that module is only included in the ArmVirtQemu platform. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg: don't set PcdPostCodePropertyMaskLaszlo Ersek1-1/+0
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Qemu,QemuKernel,Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (36 builds in total), the PCD is not used in any of those builds. Remove the setting. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg/{ArmVirtQemu,ArmVirtQemuKernel}: don't set PcdTrustzoneSupportLaszlo Ersek2-6/+0
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Qemu,QemuKernel} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (24 builds in total), the PCD is not used in any of those builds. Remove the setting. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg: don't set PcdRelocateVectorTableLaszlo Ersek1-3/+0
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {Qemu,QemuKernel,Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (36 builds in total), the PCD is not used in any of those builds. Remove the setting. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-13ArmVirtPkg/ArmVirtQemuKernel: don't set PcdCPUCoresStackBaseLaszlo Ersek1-1/+0
According to the PCDs not used by modules or in conditional directives sections of all the build reports for {AARCH64,ARM} x {QemuKernel} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1} (12 builds in total), the PCD is not used in any of those builds. Remove the setting. ("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-07ArmVirtPkg: Fix various typosAntoine Coeur6-12/+12
Fix various typos in ArmVirtPkg. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Coeur <coeur@gmx.fr> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-01-24ArmVirtXen: Link VarCheckUefiLib NULL class library instanceStar Zeng1-1/+4
This patch is not related directly to REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 Merge EmuVariable and Real variable driver. It just makes ArmVirtXen be aligned with ArmVirtQemuXXX to link VarCheckUefiLib NULL class library instance. Suggested-by: Laszlo Ersek <lersek@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Julien Grall <julien.grall@arm.com> Acked-by: Julien Grall <julien.grall@arm.com>
2019-01-24ArmVirtXen: Use merged variable driver for emulated NV modeStar Zeng2-4/+9
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 Merge EmuVariable and Real variable driver. The real variable driver has been updated to support emulated variable NV mode and the EmuVariableRuntimeDxe will be removed later, so use merged variable driver for emulated NV mode. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Julien Grall <julien.grall@arm.com> Acked-by: Julien Grall <julien.grall@arm.com>
2019-01-16ArmVirtPkg: drop reference to ArmPkg/DefaultExceptionHandlerLibBaseArd Biesheuvel1-1/+0
Drop the reference to ArmPkg/DefaultExceptionHandlerLibBase, which is no longer used anywhere now that DebugAgentSymbolsBaseLib no longer incorporates a vector table and exception handling. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2018-12-20ArmVirtPkg/MemoryInitPeiLib: split memory HOB based on MAX_ALLOC_ADDRESSArd Biesheuvel1-4/+4
The current ArmVirtMemoryInitPeiLib code splits the memory region passed via PcdSystemMemoryBase/PcdSystemMemorySize in two if the region extends beyond the MAX_ADDRESS limit. This was introduced for 32-bit ARM, which may support more than 4 GB of physical address space, but cannot address all of it via a 1:1 mapping, and a single region that is not mappable in its entirety is unusable by the PEI core. AArch64 is in a similar situation now: platforms may support more than 256 TB of physical address space, but only 256 TB is addressable by the CPU, and so a memory region that extends from below this limit to above it should be split. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-12-18ArmVirtPkg: Remove redundant library instances in ArmVirtQemuKernel.dscFu Siyuan2-4/+1
Commit 9a67ba261fe9 ("ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF") incorrectly added the BaseCryptLib, OpensslLib and IntrinsicLib to "ArmVirtPkg/ArmVirtQemuKernel.dsc", it's redundant and the library instances from "ArmVirt.dsc.inc" is already sufficient. This patch also adjust the order of network drivers in "ArmVirtPkg/ ArmVirtQemuFvMain.fdf.inc" to make it same as the DSC file. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-12-14ArmVirtPkg/ArmVirt.dsc.inc: define TcpIoLib resolution unconditionallyArd Biesheuvel1-2/+0
Commit 9a67ba261fe9 ("ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF") failed to take into account that the now unconditionally included IScsiDxe.inf from NetworkPkg requires a resolution for TcpIoLib. Since specifying such a resolution is harmless for platforms that have no networking enabled, let's just fix things by dropping the conditionals around it. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-12-14ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.Fu Siyuan4-23/+12
This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively maintained and will be removed from edk2 master soon. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-12-13ArmVirtPkg/PrePi ARM CLANG35: drop incompatible command line optionArd Biesheuvel2-10/+0
Drop the -mno-movt command line option override, which is no longer needed, and actually incompatible with versions of Clang before 3.6. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2018-12-11ArmVirtPkg/PrePiUniCoreRelocatable CLANG38: work around build issuesArd Biesheuvel4-5/+49
The self-relocating PrePi module that is used by the ArmVirtQemuKernel and ArmVirtXen targets runs the linker in PIE mode so that it emits dynamic relocations into the final image in a way that permits the module to relocate itself into place before calling into the C code. When building these targets using the CLANG38 toolchain, we switch from the BFD to the GOLD linker, which behaves a bit differently when building PIE executables, and insists on emitting GOT indirected symbol references throughout, which means a) that we end up with absolute addresses (which need to be fixed up at load time) for no good reason, and b) we have to add support for handling GOT entries to GenFw if we want to convert them into PE/COFF. So instead, let's emit a shared library. Since the ELF image only serves as the input to GenFw, this does not lead to any loss of functionality, although it does require the -Bsymbolic linker option to be added to ensure that no symbol based dynamic relocations are emitted (which would, e.g., permit lazy binding for shared libraries). So for all other toolchains, the linker option changes are a no-op. Then, we have to convince CLANG38/GOLD that there is no need to refer to symbols via a GOT entry. This is done by forcing hidden visibility for all symbols in all components that make up the PrePi SEC module: this informs the linker that a symbol is never exported or preempted, making it safe to refer to it directly from anywhere in the code, rather than indirectly via a GOT entry. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com>
2018-12-11ArmVirtPkg/ArmVirtQemuKernel ARM: make some PCD settings apply to ARMArd Biesheuvel1-11/+9
Move some PCD settings outs of the [PcdsFixedAtBuild.AARCH64] block, so that they apply to 32-bit ARM as well. Without this change, the ARM build doesn't work. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-12-03ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mappingArd Biesheuvel3-9/+20
QEMU/mach-virt is rather unhelpful when it comes to tracking down NULL pointer dereferences that occur while running in UEFI: since we have NOR flash mapped at address 0x0, inadvertent reads go unnoticed, and even most writes are silently dropped, unless you're unlucky and the instruction in question is one that KVM cannot emulate, in which case you end up with a QEMU crash like this: error: kvm run failed Function not implemented PC=000000013f7ff804 X00=000000013f7ab108 X01=0000000000000064 X02=000000013f801988 X03=00000000800003c4 X04=0000000000000000 X05=0000000096000044 X06=fffffffffffd8270 X07=000000013f7ab4a0 X08=0000000000000001 X09=000000013f803b88 X10=000000013f7e88d0 X11=0000000000000009 X12=000000013f7ab554 X13=0000000000000008 X14=0000000000000002 X15=0000000000000000 X16=0000000000000000 X17=0000000000000000 X18=0000000000000000 X19=0000000000000000 X20=000000013f81c000 X21=000000013f7ab170 X22=000000013f81c000 X23=0000000009000018 X24=000000013f407020 X25=000000013f81c000 X26=000000013f803530 X27=000000013f802000 X28=000000013f7ab270 X29=000000013f7ab0d0 X30=000000013f7fee10 SP=000000013f7a6f30 PSTATE=800003c5 N--- EL1h and a warning in the host kernel log that load/store instruction decoding is not supported by KVM. Given that the first page of the flash device is not actually used anyway, let's reduce the mappings of the peripheral space and the flash device (both of which cover page #0) to only cover what is actually required: ArmVirtQemu.fdf: > 0x00001000|0x001ff000 > gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize ArmVirtQemuKernel.fdf: > 0x00008000|0x001f8000 > gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize For ArmVirtQemu, the resulting virtual mapping looks roughly like: - [0, 4K) : flash, unmapped - [4K, 2M) : flash, mapped as WB+X RAM - [2M, 64M) : flash, unmapped - [64M, 128M) : varstore flash, will be mapped by the NOR flash driver - [128M, 256M) : peripherals, mapped as device - [256M, 1GB) : 32-bit MMIO aperture, translated IO aperture, ECAM, will be mapped by the PCI host bridge driver - [1GB, ...) : RAM, mapped. After this change, any inadvertent read or write from/to the first physical page will trigger a translation fault inside the guest, regardless of the nature of the instruction, without crashing QEMU. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-12-03ArmVirtPkg/NorFlashQemuLib: disregard our primary FVArd Biesheuvel2-2/+16
The primary FV contains the firmware boot image, which is not runtime updatable in our case. So exposing it to the NOR flash driver is undesirable, since it may attempt to modify the NOR flash contents. It is also rather pointless, since we don't keep anything there that we care to expose. (the SEC and PEI phase modules are not executable from DXE context, and the contents of the embedded DXE phase FV are exposed by the DXE core directly via the FVB2 protocol) So let's disregard the NOR flash block that covers the primary FV. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-11-29ArmVirtPkg: drop PcdPrePiCpuMemorySize assignments from all platformsArd Biesheuvel3-11/+0
PcdPrePiCpuMemorySize is no longer used so drop the PCD overrides from all platform descriptions in ArmVirtPkg. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-11-29ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA rangeArd Biesheuvel2-2/+1
Derive the size of the GCD memory space map directly from the CPU's information registers rather than from the PcdPrePiCpuMemorySize PCD, which will be removed. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2018-11-29ArmVirtPkg/XenVirtMemInfoLib: refactor reading of the PA space sizeArd Biesheuvel4-75/+7
Use the new ArmLib helper to read the CPU's physical address limit so we can drop our own homecooked one. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-11-29ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA rangeArd Biesheuvel5-97/+5
Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the entire virtual address space is mapped with EFI_MEMORY_UC attributes, regardless of whether any devices actually reside there. Now that we are relaxing the address space limit to more than 40 bits, mapping all that address space actually takes up more space in page tables than we have so far made available as temporary RAM. So let's get rid of the mapping rather than increasing the available RAM, given that the mapping is not particularly useful anyway. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-11-29ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory mapArd Biesheuvel2-1/+46
Up until now, we have been getting away with not declaring the ECAM and translated I/O spaces at all in the GCD memory map, simply because we map the entire address space with device attributes in the early PEI code, and so the ECAM space will be mapped wherever it ends up. Now that we are about to make changes to how ArmVirtQemu reasons about the size of the address space, it would be better to get rid of this mapping of the entire address space, since it can get arbitrarily large without real benefit. So start by mapping the ECAM and translated I/O spaces explicitly, instead of relying on the early PEI mapping. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-11-26ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamicallyArd Biesheuvel2-21/+69
NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg that are not based on the device tree received from QEMU. For ArmVirtQemu, this does not really matter, given that the NOR flash banks are always the same: the PEI code is linked to execute in place from flash bank #0, and the fixed varstore PCDs refer to flash bank #1 directly. However, ArmVirtQemuKernel can execute at any offset, permitting it to be used as an intermediary loader when running QEMU with secure world emulation enabled, in which case NOR flash bank #0 is secure only and contains the secure world firmware. In this case, NorFlashQemuLib should not expose the first flash bank at all. To prevent introducing too much internal knowledge about which flash bank is accessible under which circumstances, let's switch to using the DTB to decide which flash banks to expose to the NOR flash driver. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-11-26ArmVirtPkg/FdtClientDxe: take DT node 'status' properties into accountArd Biesheuvel1-5/+33
DT has a [pseudo-]standardized 'status' property that can be set on any node, and which signifies that a node should be treated as absent unless it is set to 'ok' or 'okay'. So take this into account when iterating over nodes. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2018-11-19ArmVirtPkg/PrePi: clear frame pointer in startup codeArd Biesheuvel1-0/+3
When setting up the stack in the startup code and jumping into C code for the first time, ensure that the frame pointer register is cleared so that backtraces terminate correctly. Otherwise, output like the below is shown when encountering an exception on a DEBUG build: Synchronous Exception at 0x0000000078A14780 PC 0x000078A14780 (0x000078A00000+0x00014780) [ 0] ArmVeNorFlashDxe.dll PC 0x000078A10634 (0x000078A00000+0x00010634) [ 0] ArmVeNorFlashDxe.dll PC 0x000078A11CF0 (0x000078A00000+0x00011CF0) [ 0] ArmVeNorFlashDxe.dll PC 0x000078A11DD0 (0x000078A00000+0x00011DD0) [ 0] ArmVeNorFlashDxe.dll PC 0x00007BC9D87C (0x00007BC98000+0x0000587C) [ 1] PartitionDxe.dll PC 0x00007BC99B3C (0x00007BC98000+0x00001B3C) [ 1] PartitionDxe.dll PC 0x00007F362F50 (0x00007F359000+0x00009F50) [ 2] DxeCore.dll PC 0x00007BD63BB0 (0x00007BD5B000+0x00008BB0) [ 3] BdsDxe.dll PC 0x00007BD6EE00 (0x00007BD5B000+0x00013E00) [ 3] BdsDxe.dll PC 0x00007BD67C70 (0x00007BD5B000+0x0000CC70) [ 3] BdsDxe.dll PC 0x00007F3724F0 (0x00007F359000+0x000194F0) [ 4] DxeCore.dll PC 0x00004008FC30 PC 0x000040090130 PC 0x5800F6025800F5E1 Recursive exception occurred while dumping the CPU state which is rather unhelpful, given that this prevent the remaining debug output from being printed (register dump, stack dump, fault related system registers etc) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2018-07-27ArmVirtPkg/PlatformBDS: Implement PlatformBootManagerUnableToBootRuiyu Ni1-1/+61
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Julien Grall <julien.grall@linaro.org>
generated by cgit v1.1 at 2024-11-13 21:52:53 +0000