https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
CoDCheckCapsuleOnDiskFlag() is to check if CapsuleOnDisk flag in
"OsIndications" Variable is enabled. It is used to indicate whether
capsule on disk is provisioned in normal boot path.
CoDClearCapsuleOnDiskFlag() is to to clear CapsuleOnDisk flags,
including "OsIndications" and "BootNext" variable.
CoDRelocateCapsule() is to relocate the capsules from EFI system
partition. Depends on PcdCapsuleInRamSupport, there are two solutions
to relocate the capsule on disk images:
When Capsule In Ram is supported, the Capsule On Disk images are
relocated into memory, and call UpdateCapsule() service to deliver
the capsules.
When Capsule In Ram is not supported, the Capsule On Disk images are
relocated into a temp file which will be stored in root directory on
a platform specific storage device. CapsuleOnDiskLoadPei PEIM will
retrieve the capsules from the relocation temp file and report
capsule hobs for them.
CoDRemoveTempFile() is to remove the relocation temp file in the next
boot after capsules are processed.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1840
1. Add missing '\n' in usage.
2. Fix the dead loop of CapsuleApp -L.
3. Fix the bug that CapsuleApp -OD cannot perform capsules in sub-
folder.
4. Optimize the handling for option -NR and -OD to support both
'CapsuleApp <Capsule> -OD -NR' and 'CapsuleApp <Capsule> -NR -OD'.
5. Check if Capsule-On-Disk is supported by "OsIndicationsSupported"
variable firstly before processing capsules. If not supported, prompt
an error message and quit the process.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
This patch will add Capsule On Disk related definition, including
GUID, PPI and PCDs:
The Capsule On Disk Name GUID indicates the capsule is to store
Capsule On Disk file names.
The Pei Capsule On Disk PPI provides service to retrieve capsules
from Capsule On Disk temp relocation file on mass storage devices
and create capsule hob for these capsules.
Pei Boot In CapsuleOnDisk Mode Ppi indicates current boot mode is
capsule on disk mode.
PcdCapsuleOnDiskSupport is used to enable/disable Capsule On Disk.
PcdCapsuleInRamSupport is used to enable/disable Capsule In Ram.
PcdCoDRelocationFileName specifies the Capsule On Disk temp
relocation file name.
PcdCodRelocationDevPath specifies platform specific device to store
Capsule On Disk temp relocation file.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1412
Original logic:
Connect the graphics device -> connect it as graphics consoles
and initialize its parameters(Mode = -1, invalid) -> connect it
as console spliter and add the device to the list(use SetMode to
set mode to the user defined mode or the best mode the devices
supported if the mode is invalid. *clear the screen at this phase*)
Changed logic:
Connect the graphics device -> connect it as graphics consoles
and initialize its parameters(initialize the mode to the user
defined mode or the best mode. *directly set the mode value without
using SetMode, that would not clear the screen) -> connect it as
console spliter and add the device to the list(use SetMode to set
mode to the user defined mode or the best mode the devices supported
if the mode is invalid. *now the mode is already set, so it would
not clear the screen*).
Also remove the section of SetMode for debug version.
Impact: as the text mode may not be an invalid value, the SetMode
may have no chance to be called during reconnect the graphics device.
That means the screen may not be cleaned after finishing reconnect
operation. There is one common condition: shell command "recoonect -r".
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
find that the extended config space is not (fully) implemented. In
LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
0xFFFF_FFFF at a given config space offset, after which the loop gets
stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
0xFFFF_FFFF most likely as well).
Another scenario (not related to virtualization) for triggering the above
is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
topology -- intervenes between a PCI Express Root Port and a PCI Express
Endpoint. The Conventional PCI bus limits the accessible config space of
the PCI Express Endpoint, even though the endpoint advertizes the PCI
Express capability. Here's a diagram, courtesy of Alex Williamson:
[PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
->| |<- Conventional PCI bus
Catch reads of 0xFFFF_FFFF in LocatePciExpressCapabilityRegBlock(), and
break out of the scan with a warning message. The function will return
EFI_NOT_FOUND.
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1862
Current implementation of function AhciModeInitialization() has an
incorrect assumption that the value in the CAP (offset 00h) register will
always be greater than the highest bit set for the value in the PI (offset
0Ch) register.
This will lead to an issue that hard disk devices may not be found in the
non-S3 boot path for some AHCI controller capabilities.
More specifically, variable 'PortInitializeBitMap' will have the value
from 'Private->PortBitMap', which will be 0xFFFFFFFF in non-S3 boot path.
When the CAP register is of value 0x1 and PI register with value 0x4
(meaning port 2 is available), the current logic will only enumerate port
0. And the device attached behind port 2 will not be enumerated.
To address this issue, variable 'PortInitializeBitMap' will now take the
bitwise and result between 'Private->PortBitMap' and the value read from
the PI register.
Please note that there will be no function impact for S3 path, since in
this case, the bits being set in 'Private->PortBitMap' will be a subset
of the bits being set in the PI register. Their bitwise and operation will
still be the value of 'Private->PortBitMap'.
Cc: Maggie Chu <maggie.chu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Network related modules have been included in NetworkPkg.dsc.
They can be removed from MdeModulePkg.dsc.
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
DEPEX from PEI storage stack.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1777
BootInRecoveryMode Ppi dependency should be removed from PEI storage stack
drivers. Besides recovery, more features are using the storage stack.
Platform can apply Ppi dependency in Recovery FV which contains full
storage driver stack. Platform storage stack modules, such as host
controller init PEI module, should also remove this dependency.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
This is a shell application to dump dynamic PCD settings.
Type DumpDynPcd -?/h/H to get help information.
Type DumpDynPcd -v/V to get version information.
Type DumpDynPcd [PcdName] to get Pcd information.
https://bugzilla.tianocore.org/show_bug.cgi?id=1541
v2:1.Add static for global variables.
2.Change the parameter amount of InternalStrnCatGrow in DumpDynPcd.c.
3.Add open brace according to EDK II C Coding Standards Specification.
4.Remove the dependency on ShellPkg.dec in DumpDynPcd.inf.
v3:Add static for all global variables and internal functions.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1597
Currently RTData are allocated at/after ReadyToBoot to store the
contents in HiiDatabase and the HII configurations for OS runtime
utilization.
Some platforms may meet S4 resume issue since the allocation after
ReadyToBoot cause memory map change.
Now this patch is to do some overallocation to minimize the number
of memory allocations after ReadyToBoot and also add warning
message when do allocation after ReadyToBoot.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
After commit 57df17fe26, some static check reports suspicious NULL pointer
deference at line:
Entry->MachineType = Entry->Emulator->MachineType;
^^^^^^^^^^^^^^^
within function PeCoffEmuProtocolNotify().
However, 'Entry->Emulator' is guaranteed to have a non-NULL value when
previous call to the CoreHandleProtocol() returns EFI_SUCCESS.
This commit will re-write the return status check for CoreHandleProtocol()
to add explicit NULL pointer check for protocol instance pointer.
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1483
This commit will add the PEI BlockIO (2) PPIs support for AHCI mode ATA
devices.
More specifically, the driver will consume the ATA AHCI host controller
PPI for ATA controllers working under AHCI code within the system. And
then produces the below additional PPIs for each controller:
EFI PEI Recovery Block IO PPI
EFI PEI Recovery Block IO2 PPI
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1483
Due to the limited resource on the VTd DMA buffer size in the PEI phase,
the driver will limit the maximum transfer block number for 48-bit
addressing.
According to PCDs:
gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSize|0x00400000
gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSizeS3|0x00200000
The default buffer size allocated for IOMMU mapping is:
* 4M bytes for non-S3 cases;
* 2M bytes for S3
For ATA devices in 48-bit address mode, the maximum block number is
currently set to 0xFFFF. For a device with block size equal to 512 bytes,
the maximum buffer allowed for mapping within AhciPei driver will be close
to 32M bytes. Thus, this commit will limit the 48-bit mode maximum block
number to 0x800, which means 1M-byte maximum buffer for mapping when the
block size of a device is 512 bytes. By doing so, potential failure on
calls to the IOMMU 'Map' service can be avoided.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The DxeCapsuleLibFmp code accesses the ESRT table to decide whether
a certain capsule is an FMP capsule. Since the UEFI spec mandates
that the ESRT resides in EfiBootServicesData memory, this results
in problems at OS runtime, since the firmware implementation itself
cannot access memory that has not been virtually remapped.
So let's take a private copy of the ESRT at ReadyToBoot, and store
it in EfiRuntimeServicesData memory. The ESRT's size is order 10s
of bytes so the memory footprint is going to be negligigble.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
