The PowerManagementProfileInfo Object has been moved from the
Arm Namespace to the Arch Common namespace.
Therefore, update the Kvmtool Guest firmware configuration
manager to reflect this change.
Cc: Pierre Gondois <Pierre.Gondois@arm.com>
Cc: Yeo Reum Yun <YeoReum.Yun@arm.com>
Cc: AbdulLateef Attar <AbdulLateef.Attar@amd.com>
Cc: Jeshua Smith <jeshuas@nvidia.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Girish Mahadevan <gmahadevan@nvidia.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Retire the special ResetSystemLib implementation for the PEI phase on
virtual platforms, which has been superseded by the generic version
combined with a PEI-compatible implementation of ArmMonitorLib.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The TPM2 related PEIMs depend on ResetSystemLib too, and so in order to
be able to switch to the generic ArmPkg implementation which relies on
ArmMonitorLib, the latter library class requires a PEIM-compatible
implementation too.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Switch to the new, generic ArmPsciResetSystemLib implementation that
obtains the conduit using ArmMonitorLib, of which a version already
exists that determines the conduit by looking up the PSCI DT node.
This permits the removal of the ArmVirtPkg specific implementation of
ResetSystemLib, which essentially does the exact same thing, but in a
single library.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Feature PCDs and fixed-at-build PCDs are identical in concept, but the
latter are accessible from assembler, whereas the former are not. So
convert the SMCCC conduit selection PCD to fixed-at-build so we can make
use of this in a subsequent patch.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
When setting memory attributes on its MMIO region,
KvmtoolRtcFdtClientLib will clear EFI_MEMORY_XP from
the region if a platform has it set. This MMIO region is
not intended to be executed from, so fix this by explicitly
setting EFI_MEMORY_XP on this region in the lib.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Platforms today may use this PCD as a dynamic PCD as that is an
allowed type in its PCD declaration. From `ArmPkg.dec`:
[PcdsFixedAtBuild.common, PcdsDynamic.common, PcdsPatchableInModule.common]
gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x0000002A
This library causes a build error if it used as a dynamic PCD since
it places the PCD in a `[FixedPcd]` section in the INF.
Other libraries do set the PCD and depend on the dynamic PCD behavior.
Since this library accesses the PCD with `PcdGet64 ()` which is
compatible with FixedAtBuild PCDs, this change moves the PCD out an
explicit `[FixedPcd]` section to resolve the following build error:
```
INFO - : error 3000: Building modules from source INFs, following
PCD use Dynamic and FixedAtBuild access method.
It must be corrected to use only one access
method.
INFO - gArmTokenSpaceGuid.PcdSystemMemorySize
```
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
PcdArmArchTimerFreqInHz lets platforms override the architectural timer
frequency, but this really isn't supported in hardware by anything lower
than EL3. Setting it to 0 skips the override - but that is also the
default. So drop the explicit setting in ArmVirtPkg platforms in
preparation for deleting the Pcd completely.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Following the discussion at [1] and as the ArmLib relies on them,
move ArmPkg/Chipset/ArmV7[|Mmu].h files to the MdePkg.
Update the path to correctly include the moved files.
[1] https://edk2.groups.io/g/devel/message/111566
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
This reverts commit 32460bb5b1, which is
no longer needed as ArmVirtQemu now has its own special implementation
for ArmMonitorLib.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This reverts commit 865229bcc8, and
restores the old state where dynamic PCDs are only used when TPM support
is configured.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This reverts commit c98f7f7550, which is
no longer needed: the SMCCC conduit will be converted back to being
hardcoded, as PrePi based ArmVirtPkg build cannot support dynamic PCDs,
and falling back to patchable PCDs does not work either.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Whether SMCCC calls use HVC or SMC generally depends on the exception
level that the firmware executes at, but also on whether or not EL2 is
implemented.
This is almost always known at build time, which is why the default
ArmMonitorLib used to model this as a feature PCD. However, on QEMU,
things are not that simple.
However, SMCCC specifies that the conduit is the same as the one used
for PSCI calls (which has been retrofitted into SMCCC when it was
defined). Given that QEMU provides this information via the device tree,
let's use it to select the conduit, using a special ArmMonitorLib
implementation.
This also removes the need to set the associated PCD at runtime, given
that its updated value will no longer be used.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
When building ArmVirtQemuKernel with CLANGDWARF (which does not require
a GCC workaround where -mgeneral-regs-only is needed to ensure
-mstrict-align works as expected), the C code invoked from the PrePi
startup code may contain instructions that access the FP/SIMD register
file. This means that the FP/SIMD must be enabled before making such
calls, and this is currently not the case. So fix that, by moving the
call to ArmEnableVFP() early into the asm startup code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Enable the non-hardcode version of FdtNorFlashQemuLib in ArmVirtQemu.dsc
and ArmVirtQemuKernel.dsc, and it can work rightly after enabling it.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4770
Build-tested (with "ArmVirtQemu.dsc" and "ArmVirtQemuKernel.dsc").
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Co-authored-by: Xianglai Li <lixianglai@loongson.cn>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add the RngDxe driver to the build, backed by either RNDR or TRNG, one
of which is expected to be available in most cases:
- RNDR is implemented by the 'max' CPU that QEMU implements in TCG mode
- TRNG is implemented by the KVM hypervisor, which backs QEMU's 'host'
CPU
Other TCG modes (e.g., the 'cortex-a*' CPUs) implement neither, which
should prevent the RngDxe driver from dispatching entirely, resulting
in the same situation as before.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Committed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
MdeLibs.inc sets default library class resolutions which are much more
general than the ones that might be specified in ArmVirt.dsc.inc. So the
latter should be included *after* MdeLibs.inc to ensure that its
definitions take precedence.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Committed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
On ARM systems, whether SMC or HVC instructions need to be used to issue
monitor calls is typically dependent on the exception level, but there
are also cases where EL1 might use SMC instructions, so there is no hard
and fast rule.
For ArmVirtQemu, this does depend strictly on the exception level, so
set the default to HVC (for EL1 execution) and override it to SMC when
booted at EL2.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Committed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Currently, only TPM2 builds enable the PCD PEIM, which is a prerequisite
for being able to use dynamic PCDs already at the PEI stage. This
facility will be used for other reasons too so move those pieces out of
code block that are conditional on TPM2_ENABLE
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Committed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This moves the PcdMonitorConduitHvc from PcdsFeatureFlag.Common to
PcdsFixedAtBuild.Common
This is a follow on to the previous commit:
ArmPkg: Allow SMC/HVC monitor conduit to be specified at runtime
ArmVirtQemu may execute at EL2, in which case monitor calls are
generally made using SMC instructions instead of HVC instructions.
Whether or not this is the case can only be decided at runtime, and so
the associated PCD needs to be settable at runtime, if the platform
definition chooses so. This implies a boolean PCD, given that a feature
PCD is build-time configurable only.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch adds Hash2DxeCrypto to ArmVirtPkg. The Hash2DxeCrypto is
used to provide the hashing protocol services.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch adds "virtio-rng-pci" to the PlatformBuildLib.py
This adds Rng services to the guest VM
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The optimization that enabled entry with MMU and caches enabled at EL1
removed the strict alignment requirement for XIP code (roughly, any code
that might execute with the MMU and caches off, which means SEC and PEI
phase modules but also *all* BASE libraries), on the basis that QEMU can
only run guest payloads at EL2 in TCG emulation, which used to ignore
alignment violations, and execution at EL1 would always occur with the
MMU enabled.
This assumption no longer holds: not only does QEMU now enforce strict
alignment for memory accesses with device semantics, there are also
cases where this code might execute at EL2 under virtualization (i.e.,
under NV2 nested virtualization) where the strict alignment is required
too.
The latter case could be optimized too, by enabling VHE and pretending
execution is occurring at EL1, which would allow the existing logic for
entry with the MMU enabled to be reused. However, this would leave
non-VHE CPUs behind.
So in summary, strict alignment needs to be enforced for any code that
may execute with the MMU off, so drop the override that sets the XIP
flags to the empty string.
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The FACS may still exist when the reduced hardware flag is set in FADT;
it is optional. Since it contains the hardware signature field which
indicates that a hibernated system should boot cleanly instead of
attempting to resume, a platform may choose to expose it. Propagate it
correctly.
Also avoid a NULL pointer dereference if the platform doesn't provide
a DSDT.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <881dd0a2558ecbdfa02c844722d8a1103ab97ab3.camel@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: uncrustify]
Moved the PlatformBootManagerLib to OvmfPkg and renamed to
PlatformBootManagerLibLight for easy use by other ARCH.
Build-tested only (with "ArmVirtQemu.dsc and OvmfPkgX64.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4663
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Lazlo Ersek <lersek@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Move the PcdTerminalTypeGuidBuffer and PcdUninstallMemAttrProtocol into
OvmfPkg so other ARCH can easily use it.
Build-tested only (with "ArmVirtQemu.dsc and OvmfPkgX64.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Move the FdtSerialPortAddressLib to Ovmfpkg so that other ARCH can
easily use it.
Build-tested only (with "ArmVirtQemu.dsc and OvmfPkgX64.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Moved PcdDeviceTreeInitialBaseAddress and PcdDeviceTreeAllocationPadding
to OvmfPkg for easier use by other architectures.
Build-tested only (with "ArmVirtQemu.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add the long lost CI for CloudHv on AArch64.
As CloudHv CI works nearly the same way with other VMMs like KvmTool,
thus we can easily create its CI configuration based on KvmTool.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Shim's PE loader uses the EFI memory attributes protocol in a way that
results in an immediate crash when invoking the loaded image, unless the
base and size of its executable segment are both aligned to 4k.
If this is not the case, it will strip the memory allocation of its
executable permissions, but fail to add them back for the executable
region, resulting in non-executable code. Unfortunately, the PE loader
does not even bother invoking the protocol in this case (as it notices
the misalignment), making it very hard for system firmware to work
around this by attempting to infer the intent of the caller.
So let's introduce a QEMU command line option to indicate that the
protocol should not be exposed at all, and a PCD to set the default for
this option when it is omitted.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Update the debug level comments in ArmVirt.dsc.inc to sync with
MdePkg/Include/Library/DebugLib.h.
Signed-off-by: Rebecca Cran <rebecca@os.amperecomputing.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add an instance of ImagePropertiesRecordLib which will be used by the
DXE Core.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Since the code is most regularly tested in CI, distro/versioning
details are updated to match the latest CI configuration.
CI has moved from Ubuntu 18.04 to Ubuntu 22.04 since the time of the
file's creation, but the code is actually built in a Fedora container
so Fedora is mentioned as the primary build/test environment.
Updates the following information:
- Build OS: Fedora 37 Linux
- Supported Configuration: Additional DSCs added
- Python: 3.12.x
- Packaging Tool: dnf instead of apt
- Container Details: Added
- Primary Build Example: QemuBuild.py instead of PlatformBuild.py
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Message-Id: <20231030230902.849-1-mikuback@linux.microsoft.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: don't specify the number of supported firmware builds]
Adds the varpolicy EFI shell command to all DSC files that
currently include other dynamic shell commands from ShellPkg.
This command allows variable policies to be dumped in the EFI
shell for convenient auditing and debug.
Use the command in the EFI shell as follows:
- `"varpolicy"` dumps platform variables
- `"varpolicy -?"` shows help text
- `"varpolicy -b"` pages output as expected
- `"varpolicy -s"` shows accurate variable statistic information
- `"varpolicy -p"` shows accurate UEFI variable policy information
- `"varpolicy-v -b"` dumps all information including variable data hex dump
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Julien Grall <julien@xen.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Message-Id: <20231030203112.736-5-mikuback@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
For the RELEASE target, all ArmVirtPkg DSCs inherit BaseDebugLibNull from
"ArmVirt.dsc.inc"; keep that.
For NOOPT and DEBUG:
- switch the lib class resolution pair (BaseDebugLibSerialPort +
FdtPL011SerialPortLib) that is set as the default for all module types
in "ArmVirt.dsc.inc" to DebugLibFdtPL011UartRam;
- switch the lib class resolution pair (BaseDebugLibSerialPort +
EarlyFdtPL011SerialPortLib) that is set as an override for SEC,
PEI_CORE, PEIM modules in "ArmVirt.dsc.inc" to
DebugLibFdtPL011UartFlash;
- switch the lib class resolution pair (DxeRuntimeDebugLibSerialPort +
FdtPL011SerialPortLib) that is set as an override for DXE_RUNTIME_DRIVER
modules in "ArmVirt.dsc.inc" to DxeRuntimeDebugLibFdtPL011Uart;
- mask all of the above DebugLib class resolution changes in
"ArmVirtKvmTool.dsc", because "ArmVirtKvmTool.dsc" uses
BaseSerialPortLib16550 rather than PL011 UARTs,
- mask all of the above DebugLib class resolution changes in
"ArmVirtXen.dsc" too, because "ArmVirtXen.dsc" uses
XenConsoleSerialPortLib rather than PL011 UARTs.
I regression-tested this change for "ArmVirtKvmTool.dsc" and
"ArmVirtXen.dsc" by building them for both DEBUG and RELEASE, both before
the patch and after, and comparing the edk2 build report files (focusing
on lib class resolutions). There are no changes.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-10-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce three new DebugLib instances, forked from
MdePkg/Library/BaseDebugLibSerialPort. All three instances rely on
PL011UartLib rather than SerialPortLib so that they can customize the
PL011 UART that the debug messages are written to. All three instances
direct the debug output to the first such PL011 UART that *differs* from
the one specified in the Device Tree's /chosen node's "stdout-path"
property.
From these, DxeRuntimeDebugLibFdtPL011Uart is identical to
DebugLibFdtPL011UartRam, with the addition that UART access is permanently
disabled when the containing DXE_RUNTIME_DRIVER module is notified about
exiting boot services.
The contexts in which these DebugLib instances run are identical to those
in which the corresponding SerialPortLib instances run. The particular
original dependency chain is
DxeRuntimeDebugLibSerialPort (DXE_RUNTIME_DRIVER)
FdtPL011SerialPortLib
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
and the new dependency chain is
DxeRuntimeDebugLibFdtPL011Uart (DXE_RUNTIME_DRIVER)
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
The ArmVirtPkg DSC files will be switched to the new library instances in
a separate patch.
This patch is worth viewing with "git show --find-copies-harder".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-9-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce three new DebugLib instances, forked from
MdePkg/Library/BaseDebugLibSerialPort. All three instances rely on
PL011UartLib rather than SerialPortLib so that they can customize the
PL011 UART that the debug messages are written to. All three instances
direct the debug output to the first such PL011 UART that *differs* from
the one specified in the Device Tree's /chosen node's "stdout-path"
property.
From these, DebugLibFdtPL011UartRam mirrors FdtPL011SerialPortLib: it
relies on the EarlyPL011BaseAddress GUID HOB, and initializes the UART --
a UART different from FdtPL011SerialPortLib's -- only once in the lifetime
of the containing module. Suitable for module types that can only execute
from RAM (i.e., all types different from SEC, PEI_CORE, PEIM), except
DXE_RUNTIME_DRIVER.
(Note that OVMF uses a similar set of dedicated DebugLib instances
(PlatformDebugLibIoPort) for logging to the (x86-only) isa-debugcon device
from various firmware phases.)
The contexts in which these DebugLib instances run are identical to those
in which the corresponding SerialPortLib instances run. The particular
original dependency chain is
BaseDebugLibSerialPort (not SEC, PEI_CORE, PEIM, DXE_RUNTIME_DRIVER)
FdtPL011SerialPortLib
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
and the new dependency chain is
DebugLibFdtPL011UartRam (not SEC, PEI_CORE, PEIM, DXE_RUNTIME_DRIVER)
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
Note that FdtPL011SerialPortLib remains in use (just not via
BaseDebugLibSerialPort); for instance by MdeModulePkg/Universal/SerialDxe,
which produces the SerialIo protocol, underlying the UEFI console.
The ArmVirtPkg DSC files will be switched to the new library instances in
a separate patch.
This patch is worth viewing with "git show --find-copies-harder".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-8-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce three new DebugLib instances, forked from
MdePkg/Library/BaseDebugLibSerialPort. All three instances rely on
PL011UartLib rather than SerialPortLib so that they can customize the
PL011 UART that the debug messages are written to. All three instances
direct the debug output to the first such PL011 UART that *differs* from
the one specified in the Device Tree's /chosen node's "stdout-path"
property.
From these, DebugLibFdtPL011UartFlash mirrors EarlyFdtPL011SerialPortLib:
it parses the initial Device Tree, and initializes the UART -- a UART
different from EarlyFdtPL011SerialPortLib's -- for every message written.
Suitable for SEC, PEI_CORE, PEIM.
(Note that OVMF uses a similar set of dedicated DebugLib instances
(PlatformDebugLibIoPort) for logging to the (x86-only) isa-debugcon device
from various firmware phases.)
The contexts in which these DebugLib instances run are identical to those
in which the corresponding SerialPortLib instances run. The particular
original dependency chain is
BaseDebugLibSerialPort (SEC, PEI_CORE, PEIM)
EarlyFdtPL011SerialPortLib
PcdDeviceTreeInitialBaseAddress
FdtSerialPortAddressLib
PL011UartLib
and the new dependency chain is
DebugLibFdtPL011UartFlash (SEC, PEI_CORE, PEIM)
PcdDeviceTreeInitialBaseAddress
FdtSerialPortAddressLib
PL011UartLib
Note that EarlyFdtPL011SerialPortLib remains in use (just not via
BaseDebugLibSerialPort), namely for direct SerialPortLib calls from SEC,
PEI_CORE, PEIM. See for example commit 56035d1c8b
("ArmPlatformPkg/PrePeiCore: Print the firmware version early in boot",
2022-10-25).
The ArmVirtPkg DSC files will be switched to the new library instances in
a separate patch.
This patch is worth viewing with "git show --find-copies-harder".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-7-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
PlatformPeiLib produces the EarlyPL011BaseAddress GUID HOB, and
FdtPL011SerialPortLib consumes it. Extend the HOB such that it also carry
the base address of the PL011 UART meant for DebugLib usage -- namely the
first UART that is *not* designated by the /chosen node's "stdout-path"
property. Implement this policy in PlatformPeiLib.
Note that as far as the SerialPortLib+console UART is concerned, this
patch makes no difference. That selection remains consistent with the
pre-patch state, and therefore consistent with EarlyFdtPL011SerialPortLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-6-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Convert both EarlyFdtPL011SerialPortLib and PlatformPeiLib at the same
time to clients of FdtSerialPortAddressLib (so that both "early" and
"late" serial output continue going to a common serial port). If the
device tree specifies just one serial port, this conversion makes no
difference, but if there are multiple ports, the output is written to the
port identified by /chosen "stdout-path".
In this patch, DebugLib output is not separated yet from the UEFI console.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-5-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
I strongly dislike when *small* local variable declaration changes are
muddled by whitespace changes. When that happens, a reviewer can choose
from two suboptimal options: display the patch with "git show -b", which
creates confusion in *other* parts of the patch, or display the patch with
just "git show", which then produces an unjustifiedly large hunk for the
sequence of declarations.
For avoiding that in subsequent patches, adjust some whitespace in this
patch in isolation. Functionally this is a no-op; "git show -b" produces
empty output.
Note that uncrustify is (of course) unhappy with this patch, but that's
fine -- this patch is in the middle of a series, and by the end of the
series (which is where uncrustify is run in CI) the whitespace is going to
be tight.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
This is only a refactoring; the patch is not supposed to cause any
observable change.
Build-tested only (with "ArmVirtKvmTool.dsc").
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-3-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce a new library class + instance for:
- collecting serial port base addresses from the device tree,
- collecting the /chosen stdout-path serial port base address from the
device tree.
The logic is loosely based on the following functions:
- SerialPortGetBaseAddress()
[ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c]
- PlatformPeim() [ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c]
- GetSerialConsolePortAddress()
[ArmVirtPkg/Library/Fdt16550SerialPortHookLib/EarlyFdt16550SerialPortHookLib.c]
which are going to be converted to clients of the new library later.
Copyright notices from those other files are preserved.
The new library fixes the following warts, found by reading the existent
code:
- Neither of the three functions check whether the "reg" property exists.
(This may be implicitly checked when they compare the property size to
16.)
- GetSerialConsolePortAddress() uses ScanMem8() for locating a colon (":")
node path separator in "stdout-path", when AsciiStrStr() could work just
as fine. While ScanMem8() is likely faster, "stdout-path" is presumably
very short, and ScanMem8() introduces an extra lib class dependency
(namely BaseMemoryLib).
- If ScanMem8() fails to locate a colon in "stdout-path", then
GetSerialConsolePortAddress() re-measures the length of the whole
"stdout-path" property. This is conceptually (if not performance-wise)
disturbing, because we know the whole size of the "stdout-path" property
from the property lookup just before, so we only need to subtract the
NUL-terminator for learning the length.
- GetSerialConsolePortAddress() does not check if the first (or only) node
path inside the "stdout-path" property is empty. (Not a big deal, the
subsequent alias resolution should simply fail.)
- GetSerialConsolePortAddress() does not verify if the node path retrieved
(and potentially alias-resolved) from "stdout-path" can be located in
the device tree; it assumes it.
- Code is duplicated (of course) between SerialPortGetBaseAddress() and
PlatformPeim(), but more surprisingly, all three functions embed the
same code for verifying the "status" property of the serial port node,
and for checking and reading its "reg" property.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-2-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
FdtPL011SerialPortLib claims that it's usable from the DXE_CORE. That's
not correct: the DXE_CORE calls DEBUG() and ASSERT() before it calls
ProcessLibraryConstructorList(). Via the BaseDebugLibSerialPort instance,
those DEBUG() and ASSERT() calls result in SerialPortWrite() calls, before
ProcessLibraryConstructorList() called either our constructor
FdtPL011SerialPortLibInitialize(), or BaseDebugLibSerialPortConstructor().
(And even if the DXE_CORE called the latter function early enough, it
would just invoke our SerialPortInitialize() function -- which does
nothing.)
This means that the earliest DXE_CORE debug messages are lost.
Rename FdtPL011SerialPortLibInitialize() to SerialPortInitialize(), so
that the same initialization occur through the constructor and the public
SerialPortInitialize() library API.
Turn SerialPortInitialize() calls after the first one into no-ops.
Our SerialPortLib APIs already use (mSerialBaseAddress != 0) to track
initialization. Rework those checks to actually initialize the library if
that hasn't happened yet.
The following new lines appear in the log:
> CoreInitializeMemoryServices:
> BaseAddress - 0x48000000 Length - 0xF8000000 MinimalMemorySizeNeeded - 0x38C8000
> InstallProtocolInterface: [EfiLoadedImageProtocol] 46EFC3E0
> ProtectUefiImageCommon - 0x46EFC3E0
> - 0x0000000046EB2000 - 0x0000000000068000
(0x46EB2000 is the load address of the DXE Core.)
Reported-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
FEAT_VHE, introduced in ARMv8.1, adds a virtual EL2 timer.
However, this library verifies that exactly 3 or 4 12-byte timer
interrupts are provided in input DT, ASSERTing when the new timer
is added.
Change the assert to >= 36.
Extend the current logic, also initializing PcdArmArchTimerHypVirtIntrNum
if 5 interrupts are provided.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Sami Mujawar
Ard Biesheuvel
Oliver Smith-Denny
Michael Kubacki
Leif Lindholm
Pierre Gondois
Chao Li
Flickdm
Laszlo Ersek
David Woodhouse
Jianyong Wu
Rebecca Cran
Taylor Beebe