Move BaseCachingPciExpressLib library from ArmVirtPkg to under OvmfPkg.
RISC-V Virt platform can leverage the same library to access PCI Express
registers through PCI Express base address set in PcdPciExpressBaseAddress
and cached in a global variable.
Cc: Daniel Schaefer <daniel.schaefer@hpe.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Abner Chang <abner.chang@hpe.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
Check whenever an EDID blob is present. In case it is get the display
resolution from it. Unless PcdVideoResolutionSource indicates the
display resolution has been set already, update
PcdVideoHorizontalResolution and PcdVideoVerticalResolution accordingly.
Also add the resolution to the mode list.
This will make OVMF boot up with the display resolution configured by
QEMU, which is 1280x800 by default. The resolution can be set using the
xres and yres properties. Here is an example for FullHD:
struct QEMU_VIDEO_MODE_DATA has all the data needed to set the video
mode, there is no need to take the extra indirection and use
struct QEMU_VIDEO_BOCHS_MODES.
Gerd Hoffmann [Sat, 29 Jan 2022 16:26:14 +0000 (17:26 +0100)]
OvmfPkg: add PcdVideoResolutionSource
It's a UINT8 (enum) PCD telling where the PcdVideoHorizontalResolution
and PcdVideoVerticalResolution values are coming from. It can be:
0 (unset aka default from dsc file), or
1 (from PlatformConfig), or
2 (set by Video Driver).
It will be used by video drivers to avoid overriding PlatformConfig
values, or override each others values in case multiple display devices
are present.
The underlying problem this tries to solve is that the GOP protocol has
no way to indicate the preferred video mode. On physical hardware this
isn't much of a problem because using the highest resolution available
works just fine as that is typically the native display resolution
But in a virtual machine you don't want come up with a huge 4k window by
default just because the virtual vga is able to handle that. Cutting
down the video mode list isn't a great solution either as that would
also remove the modes from the platform configuration so the user
wouldn't be able to pick a resolution higher than the default any more.
So with patch drivers can use use PcdVideoHorizontalResolution and
PcdVideoVerticalResolution to indicate what the preferred display
resolution is, without overwriting the user preferences from
PlatformConfig if present.
A possible alternative approach would be to extend the GOP protocol, but
I'm not sure this is a good plan given this is mostly a problem for
virtual machines and using PCDs allows to keep this local to OvmfPkg.
Gerd Hoffmann [Fri, 21 Jan 2022 13:00:54 +0000 (14:00 +0100)]
ArmVirtPkg: change qemu default resolution to 1280x800
ovmf default display resolution is 800x600. This is rather small for
modern guests. qemu used 1024x768 as default for a long time and
switched the to 1280x800 recently[1] for the upcoming 7.0 release.
This patch brings ovmf in sync with the recent qemu update and likewise
switches the default to 1280x800.
Gerd Hoffmann [Fri, 21 Jan 2022 13:00:53 +0000 (14:00 +0100)]
OvmfPkg: change qemu default resolution to 1280x800
ovmf default display resolution is 800x600. This is rather small for
modern guests. qemu used 1024x768 as default for a long time and
switched the to 1280x800 recently[1] for the upcoming 7.0 release.
This patch brings ovmf in sync with the recent qemu update and likewise
switches the default to 1280x800.
Rebecca Cran [Wed, 19 Jan 2022 21:01:16 +0000 (05:01 +0800)]
MdeModulePkg/UefiBootManagerLib: Convert BmLoadOption to Variable Policy
Since the Variable Lock protocol is deprecated, convert locking of
PlatformRecovery#### in EfiBootManagerLoadOptionToVariable to use the
Variable Policy protocol.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Liu, Zhiguang [Wed, 19 Jan 2022 09:16:46 +0000 (17:16 +0800)]
UefiPayloadPkg: Use BaseCpuTimerLib for Universal Payload by default
Current, a macro CPU_TIMER_LIB_ENABLE is added to determine which timerlib
is used. BaseCpuTimerLib.inf is a better way and only fit for recent CPU.
Meanwhile, Universal Payload are only aimed to work with recent CPU.
Therefore, for Universal Payload, use the BaseCpuTimerLib by default
Cc: Guo Dong <guo.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
CompressedDataLength is declared as UINTN which is UINT64 in X64 arch.
But the second parameter of UefiDecompressGetInfo() is declared as
UINT32. So a build error is triggered. To declare CompressedDataLength
as UINT32 to fix the build error.
Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Abner Chang <abner.chang@hpe.com> Cc: Daniel Schaefer <daniel.schaefer@hpe.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
Current MM communicate routine from ArmPkg would conduct few checks prior
to proceeding with SMC calls. However, the inspection step is different
from PI specification.
This patch updated MM communicate input argument inspection routine to
assure that "if the `MessageLength` is zero, or too large for the MM
implementation to manage, the MM implementation must update the
`MessageLength` to reflect the size of the `Data` buffer that it can
tolerate", as described by `EFI_MM_COMMUNICATION_PROTOCOL.Communicate()`
section in PI specification.
Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Current MM communicate routine from ArmPkg would conduct few checks prior
to proceeding with SMC calls. However, the inspection step is different
from PI specification.
This patch updated MM communicate input argument inspection routine to
assure `CommSize` represents "the size of the data buffer being passed
in" instead of the size of the data being used from data buffer, as
described by section `EFI_MM_COMMUNICATION2_PROTOCOL.Communicate()` in PI
specification.
Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Current MM communicate routine from ArmPkg would conduct few checks prior
to proceeding with SMC calls. However, the inspection step is different
from PI specification.
This patch updated MM communicate input argument inspection routine to
assure that return code `EFI_INVALID_PARAMETER` represents "the
`CommBuffer**` parameters do not refer to the same location in memory",
as described by `EFI_MM_COMMUNICATION2_PROTOCOL.Communicate()` section
in PI specification.
Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Kun Qin [Tue, 25 Jan 2022 19:39:06 +0000 (03:39 +0800)]
ArmPkg: MmCommunicationDxe: MM communicate function argument attributes
Current MM communicate2 function from ArmPkg described input arguments
`CommBufferPhysical`, `CommBufferVirtual` and `CommSize` as input only,
which mismatches with the "input and output type" as in PI specification.
This change updated function descriptions of MM communite2 to match input
argument types.
Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Kun Qin [Tue, 25 Jan 2022 19:39:05 +0000 (03:39 +0800)]
MdePkg: MmCommunication2: Update MM communicate2 function description
Current MM communicate2 function definition described input arguments
`CommBufferPhysical`, `CommBufferVirtual` and `CommSize` as input only,
which mismatches with the "input and output type" as in PI specification.
This change updated function descriptions of MM communite2 definition to
match input argument types.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In EDKII implementation of variable policy, the DXE runtime agent would
communicate to MM to disable, register or query policies. However, these
operations populate the value of MessageLength that includes communicate
header to include MM communicate header, which mismatches with the
description of PI specification.
This fix will correct the MessageLength field calculation to exclude
the size of MM_COMMUNICATE_HEADER.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Sunny Wang [Tue, 11 Jan 2022 21:37:20 +0000 (05:37 +0800)]
MdeModulePkg/Variable: Make only EFI_VARIABLE_NON_VOLATILE invalid
Only EFI_VARIABLE_NON_VOLATILE attribute is an invalid combination
of attribute bits, so update the variable driver to return
EFI_INVALID_PARAMETER so that we can prevent the invalid variable
being created.
This change also fixes the SCT failure below:
- RT.QueryVariableInfo - With being an invalid combination -- FAILURE
For details, please check the threads below:
- https://edk2.groups.io/g/devel/topic/86486174
- https://edk2.groups.io/g/devel/message/82466
Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Cc: G Edhaya Chandran <edhaya.chandran@arm.com> Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com> Signed-off-by: Sunny Wang <sunny.wang@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Update the logic handling last attempt status codes from
FmpDeviceCheckImageWithStatus() implementations to account for
cases when the function return status code is EFI_SUCCESS
(since the image was checked successfully) but the ImageUpdatable
value is not valid.
In addition the following sentence is removed from the
LastAttemptStatus parameter definition for
FmpDeviceCheckImageWithStatus() since it can lead to confusion.
The expected status code value range is sufficient to implement
the library API.
"This value will only be checked when this
function returns an error."
Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Guomin Jiang <guomin.jiang@intel.com> Cc: Wei6 Xu <wei6.xu@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Guomin Jiang <guomin.jiang@intel.com>
Liu, Zhiguang [Fri, 14 Jan 2022 06:15:18 +0000 (23:15 -0700)]
UefiPayloadPkg: Not use BaseCpuTimerLib by default.
For recent X86 CPU, 0x15 CPUID instruction will return Time Stamp
Counter. This is recommended way to get the time, and also how
BaseCpuTimerLib works However, some CPU doesn't support this feature,
so disable it by default.
Cc: Guo Dong <guo.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Xie, Yuanhao [Mon, 17 Jan 2022 08:24:28 +0000 (01:24 -0700)]
UefiPayloadPkg: Change the user interface name of the Uiapp
Chanage the name "Uiapp" to "Enter Setup".
Cc: Guo Dong <guo.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Sebastien Boeuf [Tue, 11 Jan 2022 12:31:27 +0000 (20:31 +0800)]
OvmfPkg/CloudHv: Connect serial console
Cloud Hypervisor doesn't emulate any LPC bridge, therefore we simply
need to rely on the serial I/O port to be connected as a console.
It reuses the code from Xen since it's very generic.
Sebastien Boeuf [Tue, 11 Jan 2022 12:31:26 +0000 (20:31 +0800)]
OvmfPkg/CloudHv: Replace legacy 8254 PIT with local APIC timer
Cloud Hypervisor doesn't emulate the legacy 8254 PIT, which is why
instead of relying on it as the timer UEFI services, rely on the
XenTimerDxe implementation. This is not Xen specific, as it simply uses
the local APIC timer triggering interrupts on the vector 32.
Sebastien Boeuf [Tue, 11 Jan 2022 12:31:25 +0000 (20:31 +0800)]
OvmfPkg/CloudHv: Add new target for Cloud Hypervisor
Adding the new target CloudHvX64, copied directly from OvmfPkgX64. The
point is to create a target dedicated for Cloud Hypervisor rather than
trying to support both QEMU and Cloud Hypervisor on the same target.
Improvements and cleanups will be performed in follow up patches.
Chen, Lin Z [Tue, 11 Jan 2022 13:01:12 +0000 (21:01 +0800)]
BaseTools: Fix wrong variable header size
There are two type variable header and their size are different,
need to use matched size when calculating offset info, otherwise
it'll destroy other variables content when patching.
Signed-off-by: Chen, Lin Z <lin.z.chen@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Edwards, Craig [Wed, 5 Jan 2022 16:02:53 +0000 (00:02 +0800)]
MdeModulePkg/PartitionDxe: Add break to handle invalid LBA0 in MBR
Read Disk does a modification of ExtMbrStartingLba with the code MultU64x32
(ExtMbrStartingLba, BlockSize) Error detection to see if ExtMbrStartingLBA
has a value of 0. This is invalid as LBA 0 = MBR. After modification, the
next time ExtMbrStartingLba is in this function if ExtMbrStartingLba is set
to 0 in the MBR it never passes the while/do evaluation It is multiplied by
0 by read disk , set to 0 by an invalid MBR and goes back to evaluation
This condition will also cause Ws19 and WS22 to hang, however Microsoft has
developed a hotfix patch that will be released in 2022
Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Craig Edwards <craig.edwards@dell.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
UnitTestFrameworkPkg.dec contains cmockery folder from cmocka submodule.
However, the term "cmockery" is unrecognized by cspell tool.
This change grants spell check exception to "cmockery" to prevent
pipeline building failure.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Dov Murik [Tue, 4 Jan 2022 07:16:40 +0000 (15:16 +0800)]
OvmfPkg/AmdSev/SecretPei: Mark SEV launch secret area as reserved
Mark the SEV launch secret MEMFD area as reserved, which will allow the
guest OS to use it during the lifetime of the OS, without creating
copies of the sensitive content.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Tobin Feldman-Fitzthum <tobin@linux.ibm.com> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.Yao@intel.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Put off UFS HCS.DP (Device Attached) checking
until UfsDeviceDetection() to fix timing problem.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Ian Chiu <Ian.chiu@intel.com> Cc: Maggie Chu <maggie.chu@intel.com> Signed-off-by: VincentX Ke <vincentx.ke@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Refactoring UFS DME request function and retry up to 5 times.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Ian Chiu <Ian.chiu@intel.com> Cc: Maggie Chu <maggie.chu@intel.com> Signed-off-by: VincentX Ke <vincentx.ke@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Replace with UFS_UNIT_DESC to fix response timeout problem.
Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Ian Chiu <Ian.chiu@intel.com> Cc: Maggie Chu <maggie.chu@intel.com> Signed-off-by: VincentX Ke <vincentx.ke@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Ray Ni [Wed, 29 Dec 2021 13:21:09 +0000 (21:21 +0800)]
MdeModulePkg/PciBusDxe: Enumerator to check for RCiEP before looking for RP
Before trying to access parent root port to check ARI capabilities,
enumerator should see if Endpoint device is not Root Complex integrated
to avoid undefined parent register accesses.
Signed-off-by: Damian Bassa <damian.bassa@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
ExtendedImageRevision should be printed when Header revision >= 6.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
TCG specification says BIOS should extend measurement of microcode to TPM.
However, reference BIOS is not doing this. BIOS shall extend measurement of
microcode to TPM.
Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min M Xu <min.m.xu@intel.com> Cc: Qi Zhang <qi1.zhang@intel.com> Signed-off-by: Longlong Yang <longlong.yang@intel.com>
Gerd Hoffmann [Mon, 20 Dec 2021 14:32:38 +0000 (22:32 +0800)]
MdeModulePkg/UsbBusDxe: fix NOOPT build error
gcc-11 (fedora 35):
/home/kraxel/projects/edk2/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c: In function ?UsbIoBulkTransfer?:
/home/kraxel/projects/edk2/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c:277:12: error: ?UsbHcBulkTransfer? accessing 80 bytes in a region of size 8 [-Werror=stringop-overflow=]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Ashraf Ali S <ashraf.ali.s@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
S, Ashraf Ali [Thu, 16 Dec 2021 08:10:20 +0000 (16:10 +0800)]
IntelFsp2WrapperPkg : FSPM/S UPD data address based on Build Type
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3642
when the module is not building in IA32 mode which will lead to building
error. when a module built-in X64 function pointer will be the size of
64bit width which cannot be fit in 32bit address which will lead to
error. to overcome this issue introducing the 2 new PCD's for the 64bit
modules can consume it. based on the which pcd platform set, use that.
Cc: Chasel Chiu <chasel.chiu@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Kuo Ted <ted.kuo@intel.com> Cc: Duggapu Chinni B <chinni.b.duggapu@intel.com> Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com> Cc: Digant H Solanki <digant.h.solanki@intel.com> Cc: Sangeetha V <sangeetha.v@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Stefan Berger [Fri, 17 Dec 2021 02:37:22 +0000 (21:37 -0500)]
OvmfPkg: Call PlatformInitializeConsole for GPU passthrough case
For GPU passthrough support we have to initialize the console after
EfiBootManagerDispatchDeferredImages() has loaded ROMs, so call it after
this. This was the calling order before the TCG physical presence support
had to be moved and the console initialized earlier so user interaction
could be supported before processing TCG physical presence opcodes.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Shivanshu Goyal <shivanshu3@gmail.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
In V1: To follow the TCG CRB protocol specification, on every CRB TPM
command completion the TPM should return to Idle state, regardless of
the CRB Idle Bypass capability reported by the TPM device.
See: TCG PC Client Device Driver Design Principles for TPM 2.0,
Version 1.0, Rev 0.27
Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In V3: Cleaned up comments, debug prints and updated patch to use the
new debug ENUM definitions.
- Replaced EFI_D_INFO with DEBUG_INFO.
- Replaced EFI_D_VERBOSE with DEBUG_VERBOSE.
In V2: Add case to RegisterHashInterfaceLib logic
RegisterHashInterfaceLib needs to correctly handle registering the HashLib
instance supported algorithm bitmap when PcdTpm2HashMask is set to zero.
The current implementation of SyncPcrAllocationsAndPcrMask() triggers
PCR bank reallocation only based on the intersection between
TpmActivePcrBanks and PcdTpm2HashMask.
When the software HashLibBaseCryptoRouter solution is used, no PCR bank
reallocation is occurring based on the supported hashing algorithms
registered by the HashLib instances.
Need to have an additional check for the intersection between the
TpmActivePcrBanks and the PcdTcg2HashAlgorithmBitmap populated by the
HashLib instances present on the platform's BIOS.
Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In V1: Add debug functionality to examine TPM extend operations
performed by BIOS and inspect the PCR 00 value prior to
any BIOS measurements.
Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Nhi Pham [Thu, 16 Dec 2021 03:54:55 +0000 (10:54 +0700)]
ArmPkg/ProcessorSubClassDxe: Get serial and part number from OemMiscLib
Currently, the serial and part number of a processor are filled with
fixed PCDs. However, they may be updated dynamically according to the
information being passed from a the pre-UEFI firmware during booting.
So, this patch is to support updating these string fields from
OemMiscLib if the PCDs are empty.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Nhi Pham [Thu, 16 Dec 2021 03:54:54 +0000 (10:54 +0700)]
ArmPkg/SmbiosMiscDxe: Get full SMBIOS strings from OemMiscLib
Typically, the information of the SMBIOS type 1/2/3 is fetched from an
FRU device during UEFI booting intead of fixed PCDs. Therefore, this
patch is to add more HII string fields in the OemMiscLib and support
updating these SMBIOS types with the strings provided by the OemMiscLib
if the PCDs are empty.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Gerd Hoffmann [Wed, 15 Dec 2021 11:39:19 +0000 (12:39 +0100)]
OvmfPkg: create Tcg12ConfigPei.inf
Split Tcg2ConfigPei.inf into two variants: Tcg12ConfigPei.inf with
TPM 1.2 support included and Tcg2ConfigPei.inf supporting TPM 2.0 only.
This allows x86 builds to choose whenever TPM 1.2 support should be
included or not by picking the one or the other inf file.
Switch x86 builds to Tcg12ConfigPei.inf, so they continue to
have TPM 1.2 support.
No functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Gerd Hoffmann [Wed, 15 Dec 2021 11:39:17 +0000 (12:39 +0100)]
OvmfPkg: move tcg configuration to dsc and fdf include files
With this in place the tpm configuration is not duplicated for each of
our four ovmf config variants (ia32, ia32x64, x64, amdsev) and it is
easier to keep them all in sync when updating the tpm configuration.
No functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Current FvLib will hit parse issue when encountering LARGE file, then
ignore latter ffs/section, thus causing required drivers not being
dispatched. Therefore, need to add support for EFI_FFS_FILE_HEADER2
and EFI_COMMON_SECTION_HEADER2 in FvLib to fix this issue.
Pierre Gondois [Thu, 9 Dec 2021 09:32:51 +0000 (10:32 +0100)]
DynamicTablesPkg: Add DynamicPlatRepo library
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the inf file of the module and the main module
functionnalities and update the dsc file of the package.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the TokenMapper files, allowing to retrieve a CmObj
from a token/CmObjId couple.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:49 +0000 (10:32 +0100)]
DynamicTablesPkg: DynamicPlatRepo: Add TokenFixer
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the TokenFixer files, allowing to update the
self-token some CmObj have.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the TokenGenerator files.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:47 +0000 (10:32 +0100)]
DynamicTablesPkg: Definition for DynamicPlatRepoLib interface
The DynamicPlatRepoLib library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to
retrieve dynamic CmObjs among all CmObj (static CmObj for instance).
This patch defines the library interface of the DynamicPlatRepo.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:08 +0000 (10:32 +0100)]
DynamicTablesPkg: Handle 16550_WITH_GAS id
Handle the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_WITH_GAS
id when generating an AML description of a serial port. The same
_HID/_CID as the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550
are generated.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:07 +0000 (10:32 +0100)]
DynamicTablesPkg: Add FdtHwInfoParser library
Hardware information parser is an optional module defined
by the Dynamic Tables Framework. It can either parse an
XML, a Device Tree or a Json file containing the platform
hardware information to populate the platform information
repository.
FdtHwInfoParser library is an instance of a HwInfoParser
that parses a Device Tree and populates the Configuration
Manager Platform information repository.
FdtHwInfoParser library is aimed at providing a solution
for generating ACPI tables for Guest Partitions launched
by virtual machine managers (VMMs). One such use case is
Kvmtool where the Device Tree for the Guest is passed on
to the firmware by Kvmtool. The Configuration Manager for
Kvmtool firmware shall invoke the FdtHwInfoParser to parse
the Device Tree to populate the hardware information in
the Platform Info Repository. The Kvmtool Configuration
Manager can the process this information to generate the
required ACPI tables for the Guest VM.
This approach also scales well if the number of CPUs or
if the hardware configuration of the Guest partition is
varied.
FdtHwInfoParser thereby introduces 'Dynamic Tables for
Virtual Machines'.
Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=3741 Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
On platforms that implement PCIe, the PCIe configuration space
information must be described to a standards-based operating
system in the Memory mapped configuration space base address
Description (MCFG) table.
The PCIe information is described in the platform Device Tree,
the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/pci/
host-generic-pci.yaml
The FdtHwInfoParser implements a PCI configuration space Parser
that parses the platform Device Tree to create
CM_ARM_PCI_CONFIG_SPACE_INFO objects which are encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.
The platform Configuration Manager can then utilise this
information when generating the MCFG table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC Dispatcher is the top-level component that is responsible
for invoking the respective parsers for GICC, GICD, GIC MSI Frame,
GIC ITS and the GICR.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC Redistributor (GICR) structure is part of the Multiple
APIC Description Table (MADT) that enables the discovery of
GIC Redistributor base addresses by providing the Physical Base
Address of a page range containing the GIC Redistributors. More
than one GICR Structure may be presented in the MADT. The GICR
structures should only be used when describing GIC version 3 or
higher.
The GIC Redistributor information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC Redistributor Parser that
parses the platform Device Tree to create CM_ARM_GIC_REDIST_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:03 +0000 (10:32 +0100)]
DynamicTablesPkg: FdtHwInfoParser: Add ITS parser
Arm GIC v3/v4 optionally includes support for GIC Interrupt
Translation Service (ITS). The GIC ITS Structure is part of
the Multiple APIC Description Table (MADT) that describes
the GIC Interrupt Translation service to the OS.
The GIC Interrupt Translation Service information is described
in the platform Device Tree, the bindings for which can be
found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC ITS Parser that parses the
platform Device Tree to create CM_ARM_GIC_ITS_INFO objects which
are encapsulated in a Configuration Manager descriptor object and
added to the platform information repository.
The platform Configuration Manager can then utilise this information
when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Arm GIC version 2 systems that support Message Signalled Interrupts
implement GICv2m MSI frame(s). Each GICv2m MSI frame consists of a
4k page which includes registers to generate message signalled
interrupts to an associated GIC distributor. The frame also includes
registers to discover the set of distributor lines which may be
signalled by MSIs from that frame. A system may have multiple MSI
frames, and separate frames may be defined for secure and non-secure
access.
A MSI Frame structure is part of the Multiple APIC Description Table
(MADT) and must only be used to describe non-secure MSI frames.
The MSI Frame information is described in the platform Device Tree,
the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a MSI Frame Parser that parses
the platform Device Tree to create CM_ARM_GIC_MSI_FRAME_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
On ARM-based systems the Generic Interrupt Controller (GIC)
manages interrupts on the system. Each interrupt is identified
in the GIC by an interrupt identifier (INTID). ACPI GSIVs map
one to one to GIC INTIDs for peripheral interrupts, whether
shared (SPI) or private (PPI). The GIC distributor provides
the routing configuration for the interrupts.
The GIC Distributor (GICD) structure is part of the Multiple
APIC Description Table (MADT) that describes the GIC
distributor to the OS. The MADT table is a mandatory table
required for booting a standards-based operating system.
The GIC Distributor information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC Distributor Parser that
parses the platform Device Tree to create CM_ARM_GICD_INFO
object which is encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC CPU Interface (GICC) structure is part of the Multiple
APIC Description Table (MADT) that describes the interrupt model
for the platform. The MADT table is a mandatory table required
for booting a standards-based operating system.
Arm requires the GIC interrupt model, in which the logical
processors are required to have a Processor Device object in
the DSDT, and must convey each processor's GIC information to
the OS using the GICC structure.
The CPU and GIC information is described in the platform Device
Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/arm/cpus.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC CPU Interface Parser that
parses the platform Device Tree to create CM_ARM_GICC_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT and the SSDT CPU
information tables.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:31:59 +0000 (10:31 +0100)]
DynamicTablesPkg: FdtHwInfoParser: Add Serial port parser
The Microsoft Debug Port Table 2 (DBG2), the Serial Port Console
Redirector (SPCR) table are mandatory tables required for booting
a standards-based operating system. The DBG2 table is used by the
OS debugger while the SPCR table is used to configure the serial
terminal. Additionally, the serial ports available on a platform
for generic use also need to be described in DSDT/SSDT for an OS
to be able to use the serial ports.
The Arm Base System Architecture 1.0 specification a lists of
supported serial port hardware for Arm Platforms. This list
includes the following serial port UARTs:
- SBSA/Generic UART
- a fully 16550 compatible UART.
Along, with these the PL011 UART is the most commonly used serial
port hardware on Arm platforms.
The serial port hardware information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/serial/serial.yaml
- linux/Documentation/devicetree/bindings/serial/8250.txt
- linux/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
- linux/Documentation/devicetree/bindings/serial/pl011.yaml
The FdtHwInfoParser implements a Serial Port Parser that parses
the platform Device Tree to create CM_ARM_SERIAL_PORT_INFO objects
with the following IDs:
- EArmObjSerialConsolePortInfo (for use by SPCR)
- EArmObjSerialDebugPortInfo (for use by DBG2)
- EArmObjSerialPortInfo (for use as generic Serial Ports)
The Serial Port for use by SPCR is selected by parsing the Device
Tree for the '/chosen' node with the 'stdout-path' property. The
next Serial Port is selected for use as the Debug Serial Port and
the remaining serial ports are used as generic serial ports.
The CM_ARM_SERIAL_PORT_INFO objects are encapsulated in Configuration
Manager descriptor objects with the respective IDs and are added to
the platform information repository.
The platform Configuration Manager can then utilise this information
when generating the DBG2, SPCR and the SSDT serial port tables.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Generic Timer Description Table (GTDT) is a mandatory table
required for booting a standards-based operating system. It
provides an OSPM with information about a system's Generic Timer
configuration. The Generic Timer (GT) is a standard timer interface
implemented on ARM processor-based systems. The GTDT provides OSPM
with information about a system's GT interrupt configurations, for
both per-processor timers, and platform (memory-mapped) timers.
The Generic Timer information is described in the platform Device
Tree. The Device Tree bindings for the Generic timers can be found
at:
- linux/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
The FdtHwInfoParser implements a Generic Timer Parser that parses
the platform Device Tree to create a CM_ARM_GENERIC_TIMER_INFO
object. The CM_ARM_GENERIC_TIMER_INFO object is encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.
The platform Configuration Manager can then utilise this information
when generating the GTDT table.
Note: The Generic Timer Parser currently does not support parsing
of memory-mapped platform timers.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Fixed ACPI Description Table (FADT) is a mandatory table
required for booting a standards-based operating system. The
FADT table has an 'ARM Boot Architecture Flags' field that is
used by an OS at boot time to determine the code path during
boot. This field is used to specify if the platform complies
with the PSCI specification. It is also used to describe the
conduit (SMC/HVC) to be used for PSCI.
The PSCI compliance information for a platform is described
in the platform Device Tree, the bindings for which can be
found at:
- linux/Documentation/devicetree/bindings/arm/psci.yaml
The FdtHwInfoParser implements a Boot Arch Parser that parses
the platform Device Tree to create a CM_ARM_BOOT_ARCH_INFO
object. The CM_ARM_BOOT_ARCH_INFO object is encapsulated in
a Configuration Manager descriptor object and added to the
platform information repository.
The platform Configuration Manager can then utilise this
information when generating the FADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:31:55 +0000 (10:31 +0100)]
DynamicTablesPkg: FdtHwInfoParser: CM Object descriptor helper
FdtHwInfoParserLib is an instance of the HwInfoParser. The
FdtHwInfoParser parses a platform Device Tree and populates
the Platform Information repository with Configuration
Manager objects that describe the platform hardware.
These Configuration Manager objects are encapsulated in
Configuration Manager Object Descriptors.
Therefore, add helper functions to create and free the
Configuration Manager Object descriptors.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:31:54 +0000 (10:31 +0100)]
DynamicTablesPkg: Definition for HwInfoParser interface
Hardware information parser is an optional module defined
by the Dynamic Tables Framework. It can either parse an
XML, a Device Tree or a Json file containing the platform
hardware information to populate the platform information
repository.
The Configuration Manager can then utilise this information
to generate ACPI tables for the platform.
Therefore, define an interface for the HwInfoParser library
class.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Co-authored-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Rebecca Cran [Mon, 13 Dec 2021 18:30:56 +0000 (11:30 -0700)]
ArmPkg: Update SMC calls to use the new ArmCallSmc0/1/2/3 functions
New SMC helper functions have been added to reduce the amount of
template code. Update ArmSmcPsciResetSystemLib and
Smbios/ProcessorSubClassDxe to use them.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Rebecca Cran [Sun, 9 May 2021 19:26:47 +0000 (13:26 -0600)]
EmulatorPkg: Update lldbefi.py to work with current lldb which uses python3
The version of lldb shipping with macOS Big Sur is lldb-1205.0.27.3, and
it uses python3. Update lldbefi.py to work with it, including removing
the unused 'commands' import and fixing the print statements.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Andrew Fish <afish@apple.com>
Gerd Hoffmann [Wed, 8 Dec 2021 07:01:45 +0000 (08:01 +0100)]
OvmfPkg/PlatformPei: prefer etc/e820 for memory detection
Prefer the e820 map provided via qemu firmware config interface
for memory detection. Use rtc cmos only as fallback, which should
be rarely needed these days as qemu supports etc/e820 since 2013.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Add a bool parameter to ScanOrAdd64BitE820Ram to explicitly specify
whenever ScanOrAdd64BitE820Ram should add HOBs for high memory (above
4G) or scan only.
Also add a lowmem parameter so ScanOrAdd64BitE820Ram
can report the memory size below 4G.
This allows a more flexible usage of ScanOrAdd64BitE820Ram,
a followup patch will use it for all memory detection.
No functional change.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:05 +0000 (10:25 +0100)]
DynamicTablesPkg: Fix multiple objects parsing
When a CmObjDesc contains multiple objects, only the first one is
parsed as the buffer doesn't progress. Fix this.
Also check that the whole buffer has been parsed with an asset.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:04 +0000 (10:25 +0100)]
DynamicTablesPkg: SSDT Pci express generator
This generator allows to generate a SSDT table describing
a Pci express Bus. It uses the following CmObj:
- EArmObjCmRef
- EArmObjPciConfigSpaceInfo
- EArmObjPciAddressMapInfo
- EArmObjPciInterruptMapInfo
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:03 +0000 (10:25 +0100)]
DynamicTablesPkg: Add Pci related objects
Introduce the following CmObj in the ArmNameSpaceObjects:
- CM_ARM_PCI_ADDRESS_MAP_INFO
- CM_ARM_PCI_INTERRUPT_MAP_INFO
These objects allow to describe address range mapping
of Pci busses and interrupt mapping of Pci devices.
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:02 +0000 (10:25 +0100)]
DynamicTablesPkg: Add AmlAttachNode()
This function allows to add a node as the last node of a parent node
in an AML tree. For instance,
ASL code corresponding to NewNode:
Name (_UID, 0)
ASL code corresponding to ParentNode:
Device (PCI0) {
Name(_HID, EISAID("PNP0A08"))
}
"AmlAttachNode (ParentNode, NewNode)" will result in:
ASL code:
Device (PCI0) {
Name(_HID, EISAID("PNP0A08"))
Name (_UID, 0)
}
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:01 +0000 (10:25 +0100)]
DynamicTablesPkg: AML Code generation to add _PRT entries
_PRT entries can describe interrupt mapping for Pci devices. The
object is described in ACPI 6.4 s6.2.13 "_PRT (PCI Routing Table)".
Add AmlCodeGenPrtEntry() helper function to add _PRT entries
to an existing _PRT object.
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
projects / mirror_edk2.git / log