The driver binding start function in SNP.c goes through all the BARs and get
the last BAR index for use. Theoretically it should work with all valid BARs,
but we got reports some device did always use the first valid BAR, so we change
the logic in SNP to use the first found BAR index instead of the last one.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18455 6f19259b-4bc3-4df7-8a09-765794883524
Since Shell will remove the quotes in parameters, setvar cannot receive the quotes from ="ascii" or =L"unicode". User should add ^ to escape quotes in setvar data.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18454 6f19259b-4bc3-4df7-8a09-765794883524
The fix r18449 missed 1 line which will cause Http.Request() ASSERT. This patch
will correct this error.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18453 6f19259b-4bc3-4df7-8a09-765794883524
This patch updates the HttpDxe driver to use the DPC mechanism to avoid long
time delay when single event.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18451 6f19259b-4bc3-4df7-8a09-765794883524
This patch contains a bug fix in HTTP driver that the RxToken is not closed,
this is one of the main reasons which lower the HTTP download speed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18450 6f19259b-4bc3-4df7-8a09-765794883524
This patch updates the HTTP driver to use a shared buffer for URL parsing to
avoid memory allocation for each HTTP request.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18449 6f19259b-4bc3-4df7-8a09-765794883524
The original HTTP boot driver always save the received message body in its cache,
it bring a large of memory allocation during HTTP download. This patch updates
the HTTP boot driver to only cache data when caller doesn't provide a buffer for
download (which is usually used when caller want to get the required buffer size).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18448 6f19259b-4bc3-4df7-8a09-765794883524
HTTP boot driver uses block size of 1024 when receiving HTTP message body,
but typically the MTU of Ethernet is 1500 bytes so it makes 1 TCP segment data
split into 2 Http.Response call. This patch enlarges the block size to avoid
this issue.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18447 6f19259b-4bc3-4df7-8a09-765794883524
1. Fix a bug of removing the checkpoint for STATIC modifier
2. Fix a bug of parsing CONST variable
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen <hesheng.chen@intel.com>
Reviewed-by: YangX Li <yangx.li@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18446 6f19259b-4bc3-4df7-8a09-765794883524
SVN commit r18077 ("BaseTools/GenFw: move .debug contents to .data to
save space") removed the separate .debug section after moving its
contents into .text or .data. However, this change does not take into
account that some of these contents need to appear at a 32-bit aligned
offset. So align the debug data RVA to 32 bits.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18443 6f19259b-4bc3-4df7-8a09-765794883524
The specification of the EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru()
function documents the EFI_BAD_BUFFER_SIZE return status, and the
EFI_EXT_SCSI_STATUS_HOST_ADAPTER_DATA_OVERRUN_UNDERRUN host adapter
status.
These allow an EFI_EXT_SCSI_PASS_THRU_PROTOCOL implementation to request
higher layers in the stack (in this instance, UefiScsiLib and ScsiDiskDxe)
to break up the transfer into smaller pieces.
These conditions percolate up the stack correctly: the retry loops in
ScsiDiskDxe's ScsiDiskReadSectors() and ScsiDiskWriteSectors() functions
correctly and transparently update the transfer size (ByteCount),
accommodating any shortening requested by lower levels of the stack. After
the loop -- if the request ultimately succeeds -- SectorCount is even
recalculated from the final ByteCount, to see how many sectors the outer
loop should advance.
However, the inner (ie. retry) loops both have the same error: when the
underlying protocols request the transfer to be shortened, the decrease in
transfer size (ie. ByteCount) should immediately be reflected in
SectorCount. Otherwise the sector count encoded in the CDB will exceed the
transfer size, which is a permanent error.
This issue has been witnessed while booting
en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso
on the 32-bit build of OVMF, from a virtio-scsi CD-ROM:
(1) "cdboot.efi" correctly requested (from far atop) a long read:
Timeout=940000000
CdbLength=10
DataDir=Read
InTransferLength=134215680
OutTransferLength=0
SenseDataLength=108
Cdb: 28 00 00 00 25 DD 00 FF FF 00
^ ^^^^^^^^^^^ ^^^^^
| | |
| | number of 2KB sectors to read,
| | corresponding to 2048 * 65535 = 134215680 bytes
| | (see InTransferLength above)
| |
| LBA to read from
|
READ (10)
(2) In turn, the EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru() function
provided by "OvmfPkg/VirtioScsiDxe/VirtioScsi.c" asked for the request
to be shortened:
InTransferLength=16776704
OutTransferLength=16776704
SenseDataLength=0
HostAdapterStatus=EFI_EXT_SCSI_STATUS_HOST_ADAPTER_DATA_OVERRUN_UNDERRUN
TargetStatus=0
Status=EFI_BAD_BUFFER_SIZE
(3) Then ScsiDiskReadSectors() in
"MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c" retried the request
with correctly shortened transfer length, but incorrectly unchanged
sector count:
Timeout=940000000
CdbLength=10
DataDir=Read
InTransferLength=16776704 <--- updated as requested
OutTransferLength=0
SenseDataLength=108
Cdb: 28 00 00 00 25 DD 00 FF FF 00
^ ^^^^^^^^^^^ ^^^^^
| | |
| | not changed!
| |
| LBA to read from
|
READ (10)
(4) Since 65535 sectors of 2KB each wouldn't fit in a buffer of approx.
16MB, QEMU's virtio-scsi controller unconditionally rejected this
request with VIRTIO_SCSI_S_OVERRUN, which VirtioScsiDxe then mapped
to:
InTransferLength=16776704
OutTransferLength=0
SenseDataLength=0
HostAdapterStatus=EFI_EXT_SCSI_STATUS_HOST_ADAPTER_DATA_OVERRUN_UNDERRUN
TargetStatus=0
Status=EFI_DEVICE_ERROR
(5) After two more tries of the same, ScsiDiskDxe passed up the error,
which ultimately caused "cdboot.efi" to BSOD.
Many thanks to Larry Cleeton from Microsoft for helping debug
"cdboot.efi".
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18438 6f19259b-4bc3-4df7-8a09-765794883524
Acting specifically upon this error condition from UefiScsiLib (and
ultimately from EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru()) in the
- ScsiDiskRead10(),
- ScsiDiskWrite10(),
- ScsiDiskRead16(),
- ScsiDiskWrite16()
functions allows us to retry these operations from ScsiDiskReadSectors()
and ScsiDiskWriteSectors(), with adjusted transfer sizes, without
investigating further error details like Host Adapter Status, Target
Status, and Sense Data.
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18437 6f19259b-4bc3-4df7-8a09-765794883524
PXE driver's LoadFile protocol should check the input parameter
FilePath to see whether it's a supported device path.If not,
it should return invalid parameter, do not continue PXE boot.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18436 6f19259b-4bc3-4df7-8a09-765794883524
PXE driver's LoadFile protocol should check the input parameter
FilePath to see whether it's a supported device path.If not,
it should return invalid parameter, do not continue PXE boot.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18435 6f19259b-4bc3-4df7-8a09-765794883524
EFI_SCSI_IO_PROTOCOL has alignment requirement on any data buffer
used in SCSI data transfer. As a wrap of this protocol, UefiScsiLib
have same request. Adding EFI_INVALID_PARAMETER return status in
function comments to ask the caller to guarantee this alignment.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18434 6f19259b-4bc3-4df7-8a09-765794883524
When boot from Shell we can use '-delay [num]' as optional data. If blank space exist after '[num]' Shell will fail. This patch add error handling to avoid this failure.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18431 6f19259b-4bc3-4df7-8a09-765794883524
For 32-bit ARM platforms, it is essential that system memory starts
below the 4 GB limit, since that is the only memory we can address
using the UEFI spec mandated 1:1 mapping. So assert that this is the
case.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18429 6f19259b-4bc3-4df7-8a09-765794883524
When executing on a LPAE capable 32-bit ARM platform, we support
up to 40 bits of physical address space so set PcdPrePiCpuMemorySize
accordingly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18428 6f19259b-4bc3-4df7-8a09-765794883524
On 32-bit ARM, split system memory into a region below (and up to) 4 GB
and a region above 4 GB. This is necessary to get the DXE core to consider
the former as the resource descriptor that describes the primary memory
region that also covers the PHIT region.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18427 6f19259b-4bc3-4df7-8a09-765794883524
Make sure that the PEI memory region is carved out of memory that is
32-bit addressable, by taking MAX_ADDRESS into account (which is
defined as '4 GB - 1' on ARM)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18426 6f19259b-4bc3-4df7-8a09-765794883524
During page entry attribute update, if there are table entries
between starting BlockEntry and LastBlockEntry, table entries will be
set as block entries and the allocated memory of the tables will be
leaked.
So instead, we break the inner loop when we find a table entry and run
outer loop again to step into the table by the same logic.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
[ardb: move termination condition check inside the loop]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18425 6f19259b-4bc3-4df7-8a09-765794883524
Below code has bug since *BlockEntrySize and *TableLevel are not
updated accordingly:
if (IndexLevel == PageLevel) {
// And get the appropriate BlockEntry at the next level
BlockEntry = (UINT64*)TT_GET_ENTRY_FOR_ADDRESS (TranslationTable, \
IndexLevel + 1, RegionStart);
// Set the last block for this new table
*LastBlockEntry = TT_LAST_BLOCK_ADDRESS(TranslationTable, \
TT_ENTRY_COUNT);
}
Also it doesn't check recursively to get the last level, e.g. the
initial PageLevel is 1 and we already have level 2 and 3 tables at
this address.
What's more, *LastBlockEntry was not updated when we get a table and
IndexLevel != PageLevel.
So we reorganize the sequence, only updating TranslationTable,
PageLevel and BlockEntry in the loop, and setting the other output
parameters with the final PageLevel before returning.
And LastBlockEntry is only an OUT parameter.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18424 6f19259b-4bc3-4df7-8a09-765794883524
There is a hidden bug for below code:
(1 << BaseAddressAlignment) & *BlockEntrySize
From disassembly code, we can see the literal number 1 will be treated
as INT32 by compiler by default, and we'll get 0xFFFFFFFF80000000 when
BaseAddressAlignment is equal to 31. So we will always get 31 when
alignment is larger than 31.
if ((1 << BaseAddressAlignment) & *BlockEntrySize) {
5224: f9404be0 ldr x0, [sp,#144]
5228: 2a0003e1 mov w1, w0
522c: 52800020 mov w0, #0x1 // #1
5230: 1ac12000 lsl w0, w0, w1
5234: 93407c01 sxtw x1, w0
The bug can be replayed on QEMU AARCH64; by adding some debug print,
we can see lots of level 1 tables created (for block of 1GB) even
when the region is large enough to use 512GB block size.
Use LowBitSet64() in BaseLib instead to fix the bug.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18423 6f19259b-4bc3-4df7-8a09-765794883524
The bug can be triggered when alignment of Base is larger than Length
by 2 level of page granularity, e.g.
Base is 0x4000_0000, Length is 0x1000
The original code will change 2MB page level and we will get a
negative remaining length.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18422 6f19259b-4bc3-4df7-8a09-765794883524
The code has a simple bug on calculating aligned page table address.
We can just use AllocateAlignedPages in MemoryAllocationLib instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18421 6f19259b-4bc3-4df7-8a09-765794883524
The mBmPerfHeader.Count isn't reset to 0 in BmWriteBootToOsPerformanceData()
so when the actual performance data entry count exceeds the LimitCount,
the performance data collection breaks on condition
if (mBmPerfHeader.Count == LimitCount), but 2nd time calling this function
will not break on condition if (mBmPerfHeader.Count == LimitCount) because
the mBmPerfHeader.Count always bigger than LimitCount, which results buffer
overrun.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18417 6f19259b-4bc3-4df7-8a09-765794883524
UefiDebugLibDebugPortProtocol is an implementation of DebugLib.
It calls EFI_DEBUGPORT_PROTOCOL.Write in DebugPrint and DebugAssert.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Masamitsu MURASE <masamitsu.murase@gmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18414 6f19259b-4bc3-4df7-8a09-765794883524
Add driver to produce EFI_REGULAR_EXPRESSION_PROTOCOL. Based on
Oniguruma v5.9.6 (BSD 2-clause license), which provides full Unicode
support, and POSIX ERE and Perl regex syntaxes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cecil Sheng <cecil.sheng@hpe.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18413 6f19259b-4bc3-4df7-8a09-765794883524
Add driver to produce EFI_REGULAR_EXPRESSION_PROTOCOL. Based on
Oniguruma v5.9.6 (BSD 2-clause license), which provides full Unicode
support, and POSIX ERE and Perl regex syntaxes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cecil Sheng <cecil.sheng@hpe.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18411 6f19259b-4bc3-4df7-8a09-765794883524
This patch is used to fix suspicious dereference of pointer 'FieldCount'
before NULL check.
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: Fu Siyuan <siyuan.fu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18409 6f19259b-4bc3-4df7-8a09-765794883524
When HTTP server is unavailable,HttpCloseConnection will enter
infinite loop to wait for TCP4->close Event return, So we need to
decide the Http Instance state whether in the appropriate state
before close it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18400 6f19259b-4bc3-4df7-8a09-765794883524
Per IA32 SDM, if CPUID.80000008H is not available, software may assume that the
processor supports a 36-bit physical address size.
However, for such old processors (For example, Quark processor),
MtrrValidBitsMask and MtrrValidAddressMask values are reverted and wrong in
MtrrLib. MtrrValidBitsMask should be 0xFFFFFFFFFULL and MtrrValidAddressMask
should be 0xFFFFFF000ULL.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18396 6f19259b-4bc3-4df7-8a09-765794883524
Commit r18308 ("ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID
before initializing") introduced a LcdIdentify() function to the PL111
LCD driver that makes it fail gracefully when executed on hardware that
does not have the IP. However, the LcdGraphicsOutputDxe driver is shared
with the HdLcd driver, which now fails to build due to the fact that it
has no LcdIdentity() function. So add a dummy implementation that always
returns 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18395 6f19259b-4bc3-4df7-8a09-765794883524
Like the ArmVirtPkg platforms up until SVN r17713, the ArmPlatformPkg
platforms built with the Intel BDS fail to signal the end-of-DXE event
'gEfiEndOfDxeEventGroupGuid' when entering the BDS phase, which results
in some loss of functionality, i.e., variable reclaim in the VariableDxe
drivers, and the splitting of the memory regions that is part of the recently
added UEFI 2.5 properties table feature.
As discussed on the edk2-devel mailing list here:
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109
it is up to the platform BDS to signal that event, since there may be
platform specific ordering constraints with respect to the signalling
of the event that are difficult to honor at the generic level.
So add the SignalEvent () call to PlatformBdsInit () of ArmPlatformPkg's
PlatformBdsLib implementation for the Intel BDS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18394 6f19259b-4bc3-4df7-8a09-765794883524
The logic we have in place for i440fx does not work reliably on q35. For
example, if the guest has 2GB of RAM, we allow the PCI root bridge driver
to allocate the legacy video RAM BAR from the [2048 MB, 2816 MB] range,
which falls strictly outside of the Q35 PCI host MMIO aperture that QEMU
configures, and advertizes in ACPI.
In turn, PCI BARs that exist outside of the PCI host aperture that is
exposed in ACPI break Windows guests.
Allocating PCI MMIO resources at or above 3GB on Q35 ensures that we stay
within QEMU's aperture. (See the "w32.begin" assignments in
"hw/pci-host/q35.c".) Furthermore, in pc_q35_init() (file
"hw/i386/pc_q35.c"), QEMU ensures that the low RAM never "leaks" above
3GB.
The i440fx logic is left unchanged.
The Windows guest malfunction on Q35 was reported by Jon Panozzo of Lime
Technology, Inc.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jon Panozzo <jonp@lime-technology.com>
Cc: "Gabriel L. Somlo" <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Jonathan Panozzo <jonp@lime-technology.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18393 6f19259b-4bc3-4df7-8a09-765794883524
Bruce Cran reported the following issue:
With iasl version 20150410-64 building OvmfX64 (using OvmfPkg/build.sh
-a X64 -t GCC49 -b RELEASE) results in a couple of warnings about
methods that should be serialized:
.../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.iiii
95: Method (_CRS, 0) {
Remark 2120 - Control Method should be made Serialized ^ (due to
creation of named objects within)
.../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.iiii
235: Method (PCRS, 1, NotSerialized) {
Remark 2120 - Control Method should be made Serialized ^ (due to
creation of named objects within)
The ACPI 6.0 spec justifies the above warnings in "19.6.82 Method (Declare
Control Method)":
[...] The serialize rule can be used to prevent reentering of a method.
This is especially useful if the method creates namespace objects.
Without the serialize rule, the reentering of a method will fail when it
attempts to create the same namespace object. [...]
Cc: Bruce Cran <bruce@cran.org.uk>
Reported-by: Bruce Cran <bruce@cran.org.uk>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18392 6f19259b-4bc3-4df7-8a09-765794883524
We have an old bug in BootModeInitialization(): firmware is supposed to
clear the CMOS register 0xF after reading it for the last time. QEMU only
sets this register to 0xFE in "hw/timer/mc146818rtc.c", function
rtc_notify_suspend(), and never clears it. However, SeaBIOS does clear it
in "src/post.c" and "src/resume.c", so let's follow suit.
We've never noticed this until now because the register gets mysteriously
cleared on non-resume reboots when OVMF runs on qemu-system-x86_64. But on
qemu-system-i386, this bug breaks a (suspend, resume, reboot) triplet:
after the last step OVMF thinks it's resuming because when it actually
resumed (in the middle step), it failed to clear the register.
BootModeInitialization() is the perfect function to clear the register,
right after setting mBootMode: the function is executed on both normal
boot and on S3 resume; it succeeds DebugDumpCmos() -- so the dump is not
affected by this patch --; and everything that relies on S3 vs. normal
boot after we clear the register uses mBootMode anyway.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18391 6f19259b-4bc3-4df7-8a09-765794883524
Fu Siyuan
Qiu Shumin
Hess Chen
Liming Gao
Dandan Bi
Ard Biesheuvel
Laszlo Ersek
Zhang Lubo
Feng Tian
Heyi Guo
Cecil Sheng
Eric Dong
Ruiyu Ni
Masamitsu MURASE
Jiaxin Wu
Yao, Jiewen
Jeff Fan