RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
ShellCommandRunMemMap() is updated to handle the case of unaccepted
memory type.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
Unaccepted memory is a kind of new memory type,
CoreInitializeGcdServices() and CoreGetMemoryMap() are updated to handle
the unaccepted memory type.
Ref: microsoft/mu_basecore@97e9c31
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined in MdeModulePkg. The
files which use the definition are updated as well.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined for unaccepted memory.
But this defitinion has not been officially in the PI spec. Base
on the code-first we define EFI_RESOURCE_MEMORY_UNACCEPTED at
MdeModulePkg/Include/Pi/PrePiHob.h and update EFI_RESOURCE_MAX_MEMORY_TYPE
to 8. After BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is officially published
in PI spec, we will re-visit here.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined for unaccepted memory.
But this defitinion has not been officially in the PI spec. Base
on the code-first we define BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED at
MdeModulePkg/Include/Pi/PrePiHob.h.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Check the memory block pointer before freeing it.
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Add myself as reviewer for the DynamicTablesPkg.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The ACPI specification updated some terms in accordance with:
s1.1.1 Principle of Inclusive Terminology
Update the PCCT parser accordincly with these new terms.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The following tables can now be generated by the DynamicTablesPkg:
- PCCT
- PPTT
- SRAT
Update the documentation accordingly.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
For Pcc address space, the AccessSize field of a Register is
used to delcare the Pcc Subspace Id. This Id can be up to 256.
Cf. ACPI 6.4, s14.7 Referencing the PCC address space
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Platform Communication Channel Table (PCCT) generator collates
the relevant information required for generating a PCCT table from
configuration manager using the configuration manager protocol.
The DynamicTablesManager then install the PCCT table.
From ACPI 6.4, s14 PLATFORM COMMUNICATIONS CHANNEL (PCC):
The platform communication channel (PCC) is a generic mechanism
for OSPM to communicate with an entity in the platform.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Introduce the following CmObj in the ArmNameSpaceObjects:
- CM_ARM_MAILBOX_REGISTER_INFO
- CM_ARM_PCC_SUBSPACE_CHANNEL_TIMING_INFO
- CM_ARM_PCC_SUBSPACE_GENERIC_INFO
- CM_ARM_PCC_SUBPSACE_TYPE0_INFO
- CM_ARM_PCC_SUBPSACE_TYPE1_INFO
- CM_ARM_PCC_SUBPSACE_TYPE2_INFO
- CM_ARM_PCC_SUBPSACE_TYPE3_INFO
- CM_ARM_PCC_SUBPSACE_TYPE4_INFO
- CM_ARM_PCC_SUBPSACE_TYPE5_INFO
These objects allow to describe mailbox registers, pcc timings
and PCCT subspaces. They prepare the enablement of a PCCT generator.
Also add the CmObjParsers associated to each object.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The second model of the _PRT object is used. Indeed:
- the interrupts described are not re-configurable
- OSes are aware of the polarity of PCI legacy interrupts,
so there is no need to accurately describe the polarity.
Also, fix a comment for the CM_ARM_PCI_INTERRUPT_MAP_INFO obj.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
commit 13136cc311 ("DynamicTablesPkg: FdtHwInfoParserLib:
Parse Pmu info")
adds support for pmu parsing. Thus, remove the wrong comment.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
commit 691c5f7762 ("DynamicTablesPkg: Deprecate Crs specific methods
in AmlLib")
deprecates some APIs. Finally remove them.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add missing fields to the following CmObjParser objects:
- EArmObjGicDInfo
- EArmObjCacheInfo
and fix wrong formatting of:
- EArmObjLpiInfo
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The CmObjParsers of the following objects was inverted, probably
due to a wrong ordering placement in the file defining the structures:
-EArmObjGTBlockTimerFrameInfo
-EArmObjPlatformGTBlockInfo
Assign the correct parser for each object, and re-order the
structures in the file defining them.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
commit 0d23c447d6 ("DynamicTablesPkg: Add support to specify FADT
minor revision")
adds new 'MinorRevision' field to CM_STD_OBJ_ACPI_TABLE_INFO.
Reflect the change in this patch to the CmObjectParser.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
commit de200b7e2c ("DynamicTablesPkg: Update ArmNameSpaceObjects for
IORT Rev E.d")
adds new CmObj structures and fields to the ArmNameSpaceObjects.
Update the CmObjectParser accordingly.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add a PrintString to print strings in the CmObjParser.
String must be NULL terminated and no buffer overrun check
is done by this function.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
In C, the 'long long' types are 64-bits. The 'll' printf length
specifier should be used to pring these values. Just '%x' allows to
print values that are on 16-bits or more. Use that instead.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4100
ScsiDiskDxe driver updates ControllerNameTable with common string
"SCSI Disk Device" for all SCSI disks. Due to this, when multiple
SCSI disk devices connected, facing difficulty in identifying correct SCSI
disk device. As per SCSI spec, standard Inquiry Data is having the fields
to know Vendor and Product information. Updated "ControllerNameTable" with
Vendor and Product information. So that, device specific name can be
retrieved using ComponentName protocol.
Cc: Vasudevan Sambandan <vasudevans@ami.com>
Cc: Sundaresan Selvaraj <sundaresans@ami.com>
Signed-off-by: Cheripally Gopi <gopic@ami.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Disable/Restore HpetTimer before and after running the Dxe
CpuExceptionHandlerLib unit test module. During the UnitTest, a
new Idt is initialized for the test. There is no handler for timer
intrrupt in this new idt. After the test module, HpetTimer does
not work any more since the comparator value register and main
counter value register for timer does not match. To fix this issue,
disable/restore HpetTimer before and after Unit Test if HpetTimer
driver has been dispatched. We don't need to send Apic Eoi in this
unit test module.When disabling timer, after RaiseTPL(), if there
is a pending timer interrupt, bit64 of Interrupt Request Register
(IRR) will be set to 1 to indicate there is a pending timer
interrupt. After RestoreTPL(), CPU will handle the pending
interrupt in IRR.Then TimerInterruptHandler calls SendApicEoi().
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Migrate to the virt specific NOR flash driver as the ArmPlatformPkg is
going away.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Switch to the virt specific NorFlashDxe driver implementation that was
added recently.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
NOR flash emulation under KVM involves switching between two modes,
where array mode is backed by a read-only memslot, and programming mode
is fully emulated, i.e., the memory region is not backed by anything,
and the faulting accesses are forwarded to the VMM by the hypervisor,
which translates them into NOR flash programming commands.
Normally, we are limited to the use of device attributes when mapping
such regions, given that the programming mode has MMIO semantics.
However, when running under KVM, the chosen memory attributes only take
effect when in array mode, since no memory mapping exists otherwise.
This means we can tune the memory mapping so it behaves a bit more like
a ROM, by switching to EFI_MEMORY_WC attributes. This means we no longer
need a special CopyMem() implementation that avoids unaligned accesses
at all cost.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Currently, when dealing with small updates that can be written out
directly (i.e., if they only involve clearing bits and not setting bits,
as the latter requires a block level erase), we iterate over the data
one word at a time, read the old value, compare it, write the new value,
and repeat, unless we encountered a value that we cannot write (0->1
transition), in which case we fall back to a block level operation.
This is inefficient for two reasons:
- reading and writing a word at a time involves switching between array
and programming mode for every word of data, which is
disproportionately costly when running under KVM;
- we end up writing some data twice, as we may not notice that a block
erase is needed until after some data has been written to flash.
So replace this sequence with a single read of up to twice the buffered
write maximum size, followed by one or two buffered writes if the data
can be written directly. Otherwise, fall back to the existing block
level sequence, but without writing out part of the data twice.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
NorFlashWriteSingleWord() switches into programming mode and back into
array mode for every single word that it writes. Under KVM, this
involves tearing down the read-only memslot, and setting it up again,
which is costly and unnecessary.
Instead, move the array mode switch into the callers, and only make the
switch when the writing is done.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
We never boot from NOR flash, and generally rely on the firmware volume
PI protocols to expose the contents. So drop the block I/O protocol
implementation from VirtNorFlashDxe.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
We only use NOR flash for firmware volumes, either for executable images
or for the variable store. So we have no need for exposing disk I/O on
top of the NOR flash partitions so let's remove it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
We inherited a feature from the ArmPlatformPkg version of this driver
that never gets enabled. Let's remove it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
QEMU's mach-virt is loosely based on ARM Versatile Express, and inherits
its NOR flash driver, which is now being used on other QEMU emulated
architectures as well.
In order to permit ourselves the freedom to optimize this driver for
use under KVM emulation, let's clone it into OvmfPkg, so we have a
version we can hack without the risk of regressing bare metal platforms.
The cloned version is mostly identical to the original, but it depends
on the newly added VirtNorFlashPlatformLib library class instead of the
original one from ArmPlatformPkg. Beyond that, only cosmetic changes
related to #include order etc were made.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Create a new library class in Ovmf that duplicates the existing
NorFlashPlatformLib, but which will be tied to the VirtNorFlashDxe
driver that will be introduced in a subsequent patch. This allows us to
retire the original from ArmPlatformPkg.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Clang does not support undoing the effects of -mstrict-align by passing
the -mno-strict-align counterpart, so appending the latter to the
compiler's XIPFLAGS does not work. Instead, clear the flags entirely.
This also removes -mgeneral-regs-only, but this is fine - we can
tolerate SIMD codegen in PEIMs or BASE libraries as they run with the
MMU and caches enabled.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The TPM discovery code relies on a dynamic PCD to communicate the TPM
base address to other components. But no other code relies on dynamic
PCDs in the PEI phase so let's drop the PCD PEIM when TPM support is not
enabled.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Due to the way we inherited the formerly fixed PCDs to describe the
system memory base and size from ArmPlatformPkg, we ended up with a
MemoryInit PEIM that relies on dynamic PCDs to communicate the size of
system memory between the constructor of one of its library dependencies
and the core module. This is unnecessary, and forces us to incorporate
the PCD PEIM as well, for no good reason. So instead, let's use a HOB.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Some PEIMs register for shadow execution explicitly, but others exist
that don't care and can happily execute in place. Since the emulated NOR
flash is just RAM, shadowing has no performance benefits so let's only
do this if needed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The variable PEIM is included in the build but its runtime prerequisites
are absent so it is never dispatched. Just drop it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Now that we have all the pieces in place, switch the AArch64 version of
ArmVirtQemu to a mode where the first thing it does out of reset is
enable a preliminary ID map that covers the NOR flash and sufficient
DRAM to create the UEFI page tables as usual.
The advantage of this is that no manipulation of memory occurs any
longer before the MMU is enabled, which removes the need for explicit
coherency management, which is cumbersome and bad for performance.
It also means we no longer need to build all components that may execute
with the MMU off (including BASE libraries) with strict alignment.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
In order to allow booting with the MMU and caches enabled really early,
we need to ensure that the code that populates the page tables can
access those page tables with the statically defined ID map active.
So let's put the permanent PEI RAM in the first 128 MiB of memory, which
we will cover with this initial ID map (as it is the minimum supported
DRAM size for ArmVirtQemu).
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
To substantially reduce the amount of processing that takes place with
the MMU and caches off, implement a version of ArmPlatformLib specific
for QEMU/mach-virt in AArch64 mode that carries a statically allocated
and populated ID map that covers the NOR flash and device region, and
128 MiB of DRAM at the base of memory (0x4000_0000).
Note that 128 MiB has always been the minimum amount of DRAM we support
for this configuration, and the existing code already ASSERT()s in DEBUG
mode when booting with less.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Use the appropriate PCD definition in the ArmVirtQemu DSC so that the
boot timeout is taken from the Timeout variable automatically, which is
what Linux tools such as efibootmgr expect.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
When the memory protections were implemented and enabled on ArmVirtQemu
5+ years ago, we had to work around the fact that GRUB at the time
expected EFI_LOADER_DATA to be executable, as that is the memory type it
allocates when loading its modules.
This has been fixed in GRUB in August 2017, so by now, we should be able
to tighten this, and remove execute permissions from EFI_LOADER_DATA
allocations.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Update maintainers.txt to add Igor from AMI
as the reviewer of RedfishPkg.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Nickle Wang <nickle@csie.io>
Cc: Igor Kulchytskyy <igork@ami.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4119
Earlier version of FSP header may not have MultiPhase fields present in
the FspInfoHeader so the handler should verify header revision before
accessing the MultiPhase fields from the header.
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: Nate DeSimone <nathaniel.l.desimone@intel.com>
gSerialDevTempate should be gSerialDevTemplate
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Copy code from PrePi to PrePeiCore that prints the firmware version
and build date early in the boot process.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Recent model Chromebooks only return ACK, but not
BAT_SUCCESS, which causes hanging and failed ps2k init.
To mitigate this, make the absence of BAT_SUCCESS reply
non-fatal, and reduce the no-reply timeout from 4s to 1s.
Tested on google/dracia and purism/librem_14
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Min M Xu
Abner Chang
Pierre Gondois
Cheripally Gopi
Tan, Dun
Ard Biesheuvel
Chao Li
Chasel Chiu
Nate DeSimone
Rebecca Cran
Matt DeVillier