The Mantis ticket 1353 <https://mantis.uefi.org/mantis/view.php?id=1353>
and Mantis ticket 1472 <https://mantis.uefi.org/mantis/view.php?id=1472>
updated the description of the port multiplier port number parameter in
SATA Device Path Node and ATA Pass-Through Protocol.
Now, this parameter should be set to 0xFFFF instead of 0 to indicate that
an ATA device is directly attached on the controller port.
Please note that this is an incompatible change. The consumer of SATA
device path or ATA_PASS_THRU needs to re-examine its usage to follow UEFI
2.5 mantis 1353 and 1472.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The UEFI2.5 Errata (Mantis ticket 1472 -
https://mantis.uefi.org/mantis/view.php?id=1472) updated
'PortMultiplierPort' parameter description for the following services in
EFI_ATA_PASS_THRU_PROTOCOL:
1. PassThru
2. BuildDevicePath
3. ResetDevice
Now, if there is no port multiplier on a ATA controller port, the
PortMultiplierPort parameter should be set to 0xFFFF instead of 0.
Please note that this is an incompatible semantic change. The consumer of
EFI_ATA_PASS_THRU_PROTOCOL needs to re-examine its usage to follow UEFI
2.5 Errata mantis 1472.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The UEFI2.5 spec (Mantis ticket 1353 -
https://mantis.uefi.org/mantis/view.php?id=1353) updated the Port
Multiplier Port Number description of SATA device path to use 0xFFFF when
the device is directly connected to the HBA.
Please note that this is an incompatible semantic change. The consumer of
SATA device path needs to re-examine its usage to follow UEFI 2.5 mantis
1353.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Enhance the error handling:
1. When the device is unlocked at BIOS phase and system does a warm reboot,
the device may be still in unlock status if it uses external power. For
such case, we would still popup password window to ask user input. If
user presses ESC key here, we would force the system shut down or ask
user input again to avoid security hole.
2. When user reach max retry count, force shutdown.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
If two attempts added on different NIC and enable
MPIO attribute, then change the attempts order. If
both two attempts succeed to connect the target,it
should abort the later one in the order and uninstall
ExtScsiPassThruProtocol Interface, But now it
unistall it twice.
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Reviewed-By: Ye Ting <ting.ye@intel.com>
Reviewed-By: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-By: Wu Jiaxin <jiaxin.wu@intel.com>
Since the only reason for keeping a local copy mRT of the gRT pointer
is to be able to call GetVariable/SetVariable at runtime, use the
UefiRuntimeLib helpers instead, so that we can drop mRT altogether.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
PL031RealTimeClockLib is a base library that could potentially (although
unlikely) be incorporated into other modules than the DXE_RUNTIME_DRIVER
module that it was intended to complement.
This means the library has no business whatsoever setting the Runtime
Service table pointers directly (since we have no way of knowing which
instance will 'win', and the pointers may end up referring to a module
that is not a DXE_RUNTIME_DRIVER). So remove the assignment altogether.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Add a PCD to allow the platform to mask in/out specific features of
the LAN9118 device advertised during auto-negotiation.
For example, the Juno ARM Development Platform doesn't support full
duplex mode. This PCD will allow the platform developer to prevent the
full duplex modes from being advertised.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
[ardb: change default feature mask so that full duplex is disabled]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Make the implementation of RouteConfig/ExtractConfig function
follow the UEFI spec.
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
It should start from the last '\x' position + 1 to find next '\x'
character.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The patch re-factors the code without functionality impact.
Next patch will add code to support OVMF above Xen.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Change PciHostBridgeDxe driver to not install the
PciHostBridgeResourceAllocation protocol and let
PciRootBridgeIo.Configuration() return the correct PCI resource
assignment information when the ResourceAssigned is TRUE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Some platform doesn't require PciBus driver to assign resource
to PCI devices which causes PciRootBridgeIo.Configuration() cannot
return correct resource information to caller.
When resource assignment by PciBus is not mandatory, only light
version of PCI bus enumeration is performed, which only collects
the device resource consumption and publishes the PciIo instance.
The corresponding logic is in PciEnumeratorLight() in PciBus driver.
But PciEnumeratorLight() still depends on
PciRootBridgeIo.Configuration() returns the starting bus number in
order to search down to find all PCI devices under the root bridge.
When ResourceAssigned in PCI_ROOT_BRIDGE returned by
PciHostBridgeGetRootBridges() is TRUE, PciHostBridge driver treats
the Bus/Io/Mem/MemAbove4G/PMem/PMemAbove4G as the resource that are
*actually assigned* to the root bridge, instead of the resource that
*can be assigned* to the root bridge.
So that PciRootBridgeIo.Configuration() can return the correct
information.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In order to match the previous commit, Base must be strictly larger than
Limit if some type of aperture is not available on a PCI root bridge.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
When the aperture base equals to aperture limit, the old code treats
the aperture as non-existent. It's not correct because it indicates
a range starting with base and the length is 1.
The new code corrects the comparing bug.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
To support UEFI Secure Boot and the Linux persistent store with UEFI
variables, set PcdMaxVariableSize to 0x2000 bytes as is done in OvmfPkg.
For reference, the related Ovmf commits: 8cee3de72d441ca9
Also increase the maximum size for Authenticated variables in order to
handle a larger Signature List size as is done in OvmfPkg. Related Ovmf
commit: f5404a3e
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Linn Crosetto <linn@hpe.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Pass the serial port baudrate, register stride, input clock rate and
ID from coreboot to CorebootPayloadPkg.
Change-Id: I37111d23216e4effa2909337af7e8a6de36b61f7
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
Skip non-bridge devices which are not enabled either for memory or I/O
access.
Change-Id: I1a39c69a8556b6b9cefd1a2bb191f7e0744ddfb0
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
Remove trailing white space from PciEnumeratorSupport.c.
Change-Id: Ia2f354151d46c09b140e2b42609d76fbbf8333f9
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
Ensure communication between the host and the UEFI system running
CorebootPayloadPkg. In cases where the host has flow control enabled
and the serial connection is providing the flow control signals, the
host will not be able to send data to the UEFI system because DTR and
RTS are not present. The host may also discard all output data from
the UEFI system because DTR is not present. By setting DTR and RTS
in the UART initialization code this case works properly.
Change-Id: I393f57104d111472cafcae01d4e43d4ea837be3b
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
Now that the LAN9118-specific MMIO accessors provide the required
delays, remove the redundant stalls.
Stalls in delay loops are kept, as these give time for work to happen
beyond synchronisation of the device register file.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Migrate the existing code to use the new LAN9118 MMIO wrappers, ensuring
that timing requirements are respected.
The newly redundant stalls will be removed in a subsequent patch.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
As described in the LAN9118 datasheet, delays are necessary after some
reads and writes in order to ensure subsequent reads do not see stale
data.
This patch adds helpers to provide these delays automatically, by
performing dummy reads of the BYTE_TEST register (as recommended in the
LAN9118 datasheet). This approach allows the device register file itself
to provide the required delay, avoiding issues with early write
acknowledgement, or re-ordering of MMIO accesses aganist other
instructions (e.g. the delay loop).
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Commit a4626006bb ("EmbeddedPkg/Lan9118Dxe: use MemoryFence")
replaced some stalls with memory fences, on the presumption that these
were erroneously being used to order memory accesses. However, this was
not the case.
LAN9118 devices require a timing delay between state-changing
reads/writes and subsequent reads, as updates to the register file are
asynchronous and the effects of state-changes are not immediately
visible to subsequent reads.
This delay cannot be ensured through the use of memory barriers, which
only enforce observable ordering, and not timing. Thus, converting these
stalls to memory fences was erroneous, and may result in stale values
being read.
This reverts commit a4626006bb.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
When we split a block entry into a table entry, the UXN/PXN/XN permission
attributes are inherited both by the new table entry and by the new block
entries at the next level down. Unlike the NS bit, which only affects the
next level of lookup, the XN table bits supersede the permissions of the
final translation, and setting the permissions at multiple levels is not
only redundant, it also prevents us from lifting XN restrictions on a
subregion of the original block entry by simply clearing the appropriate
bits at the lowest level.
So drop the code that sets the UXN/PXN/XN bits on the table entries.
Reported-by: "Oliyil Kunnil, Vishal" <vishalo@qti.qualcomm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
DmaMap () only allows uncached mappings to be used for creating consistent
mappings with operation type MapOperationBusMasterCommonBuffer. However,
if the buffer passed to DmaMap () happens to be aligned to the CWG, there
is no need for a bounce buffer, and we perform the cache maintenance
directly without ever checking if the memory attributes of the buffer
adhere to the API.
So add some debug code that asserts that the operation type and the memory
attributes are consistent.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
In the DmaMap () operation, if the region to be mapped happens to be
aligned to the Cache Writeback Granule (CWG) (whose value is typically
64 or 128 bytes and 2 KB maximum), we remap the memory as uncached.
Since remapping memory occurs at page granularity, while the buffer and the
CWG may be much smaller, there is no telling what other memory we affect
by doing this, especially since the operation is not reverted in DmaUnmap().
So remove the remapping call.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
DmaMap () operations of type MapOperationBusMasterCommonBuffer should
return a mapping that is coherent between the CPU and the device. For
this reason, the API only allows DmaMap () to be called with this operation
type if the memory to be mapped was allocated by DmaAllocateBuffer (),
which in this implementation guarantees the coherency by using uncached
mappings on the CPU side.
This means that, if we encounter a cached mapping in DmaMap () with this
operation type, the code is either broken, or someone is violating the
API, but simply proceeding with a double buffer makes no sense at all,
and can only cause problems.
So instead, actively reject this operation type for cached memory mappings.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Comparing a GCD attribute field directly against EFI_MEMORY_UC and
EFI_MEMORY_WT is incorrect, since it may have other bits set as well
which are not related to the cacheability of the region. So instead,
test explicitly against the flags EFI_MEMORY_WB and EFI_MEMORY_WT,
which must be set if the region may be mapped with cacheable attributes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
We manage to use both an AND operation with 'gCacheAlignment - 1' and a
modulo operation with 'gCacheAlignment' in the same compound if statement.
Since gCacheAlignment is a global of which the compiler cannot guarantee
that it is a power of two, simply use the AND version in both cases.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The allocation function UncachedAllocatePages () may return NULL, in
which case our implementation of DmaAllocateBuffer () should return
EFI_OUT_OF_RESOURCES rather than silently ignoring the NULL value and
returning EFI_SUCCESS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The patch aligns to the IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe
driver not flush the UART in Reset() and SetAttributes() function.
It was found the flush causes hang on certain PCI serial devices.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Eric Jin <eric.jin@intel.com>
The RamDiskDxe driver originally uses a variable-length HII varstore to
retrieve the HII checkbox status of each registered RAM disk.
However, HII does not support the variable-length varstore feature.
Therefore, only the checkbox status for the first 8 RAM disks are tracked
for the following definition of HII varstore structure considering the
alignment:
typedef struct {
UINT64 Size;
UINT8 RamDiskList[0];
} RAM_DISK_CONFIGURATION;
This commit uses the private data of each registered RAM disks to track
the HII checkbox status instead to resolve the issue.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The RamDiskDxe driver in MdeModulePkg now will use EFI_ACPI_TABLE_PROTOCOL
and EFI_ACPI_SDT_PROTOCOL during reporting RAM disks to NVDIMM Firmware
Interface Table (NFIT).
A Pcd 'PcdInstallAcpiSdtProtocol' controls whether the
EFI_ACPI_SDT_PROTOCOL will be produced. Its default value is set to FALSE
in MdeModulePkg. To make the NFIT reporting feature working properly under
OVMF, the patch will set the Pcd to TRUE in OVMF DSC files.
Also, the RamDiskDxe driver will sometimes report a NVDIMM Root Device
using ASL code which is put in a Secondary System Description Table (SSDT)
according to the ACPI 6.1 spec.
Locating the SSDT requires modifying the [Rule.Common.DXE_DRIVER] field in
OVMF FDF files.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
The RamDiskDxe now will report RAM disks with reserved memory type to NFIT
in the ACPI table.
This commit will also make sure that an NVDIMM root device exists in the
\SB scope before reporting any RAM disk to NFIT.
To properly report the NVDIMM root device, one will need to append the
following content in the [Rule.Common.DXE_DRIVER] field in platform FDF
files:
RAW ACPI Optional |.acpi
RAW ASL Optional |.aml
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
This adds a partial stack dump (256 bytes at either side of the stack
pointer) to the CPU state dumping routine that is invoked when taking an
unexpected exception. Since dereferencing the stack pointer may itself
fault, ensure that we don't enter the dumping routine recursively.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
The default exception handler, which is essentially the one that is invoked
for unexpected exceptions, ends with an ASSERT (FALSE), to ensure that
execution halts after dumping the CPU state. However, ASSERTs are compiled
out in RELEASE builds, and since we simply return to wherever the ELR is
pointing, we will not make any progress in case of synchronous aborts, and
the same exception will be taken again immediately, resulting in the string
'Exception at 0x....' to be printed over and over again.
So use an explicit deadloop instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
when there's no volume label 'Info' can be NULL
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
For Pyrite SSC device, it may not supports Active Key, So
add check logic before enable it.
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
This patch is used to cleanup unused structure
definition.
Cc: Zhang Chao B <chao.b.zhang@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Hao Wu
Eric Dong
Feng Tian
Zhang, Lubo
Ard Biesheuvel
Ryan Harkin
Yonghong Zhu
Dandan Bi
Zhang, Chao B
Ruiyu Ni
Linn Crosetto
Leahy, Leroy P
Mark Rutland
Michael Zimmermann
Jiaxin Wu