ArmPlatformPkg/MemoryInitPeim: handle memory above 4 GB on 32-bit ARM
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)
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.
ArmPkg/Mmu: Increase PageLevel when table found at the targeted level
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.
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.
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.
Ruiyu Ni [Wed, 9 Sep 2015 05:43:44 +0000 (05:43 +0000)]
MdeModulePkg: Fix a performance data buffer overrun issue
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
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.
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.
NetworkPkg: Fix the HttpCloseConnection fail issue
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.
Jeff Fan [Sat, 5 Sep 2015 02:07:02 +0000 (02:07 +0000)]
UefiCpuPkg/MtrrLib: MtrrValidBitsMask and MtrrValidAddressMask wrong
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.
ArmPlatformPkg: signal EndOfDxe event in PlatformBsdInit
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.
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.
OvmfPkg: PlatformPei: force 32-bit MMIO aperture above 3 GB on Q35
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
OvmfPkg: AcpiTables: serialize control methods that create named objects
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
OvmfPkg: PlatformPei: clear CMOS 0xF after setting mBootMode
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.
Dandan Bi [Wed, 2 Sep 2015 08:44:24 +0000 (08:44 +0000)]
MdeModulePkg:Support orderedList with default value
Our tool can support OrderedList which has default value,but doesn't update the
source code in HiiDatabase when parse the ifr data.Now update the code and add
test case in DriverSample.
Qin Long [Wed, 2 Sep 2015 08:12:39 +0000 (08:12 +0000)]
CryptoPkg: Replace string wrapper functions with safe string functions
EDKII core suggests to retire unsafe string functions. This patch is to
replace string wrapper functions with new-added safe string functions
for consistency.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qin Long <qin.long@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18385 6f19259b-4bc3-4df7-8a09-765794883524
This allows the FVP target to be built with UEFI Secure Boot enabled,
by passing -D SECURE_BOOT_ENABLE to the build command line. Note that
this requires the Intel BDS, or you will not be able to enroll
certificates, since the ARM BDS does not provide a GUI to do so.
The FVP Base model is recommended in this case, since the certificate
store is kept in NOR flash.
ArmPlatformPkg/PlatformIntelBdsLib: add splash screen support
Add a call to EnableQuietBoot () to BdsPlatformPolicyBehavior(),
so that a splash screen is shown in case one is present under the
correct GUID in the FV, and we have graphics support.
ArmPlatformPkg/PlatformIntelBdsLib: fix and clean up error handling
InitializeConsolePipe () shadowed its own Status variable, and then
clobbered the top one before printing its error message. Instead,
use a NULL check on the LocateProtocol () output argument.
Also clean up coding style on the error path.
ArmPlatformPkg/PlatformIntelBdsLib: remove ARM BDS dependency
The Intel BDS platform library still depends on the ARM BDS specific
BdsLib. So replace its invocations with GenericBdsLib counterparts,
and fix up where needed, so that we can drop the dependency.
MdeModulePkg/NetworkPkg: Locate IpSec on IP packet processing only if it's installed.
Modified the logic in Ip4Dxe and Ip6Dxe to not locate EFI_IPSEC2_PROTOCOL on each
message transmit/receive. Instead, register a callback in the drivers entry points
on the IpSec protocol installation, and process only if the protocol is installed.
This speeds up the network stacks when IpSec is not installed since there is a
penalty associated with searching the entire handle database on each packet processing.
Laszlo Ersek [Fri, 28 Aug 2015 08:12:51 +0000 (08:12 +0000)]
OvmfPkg: prevent code execution from DXE stack
SVN rev 18166 ("MdeModulePkg DxeIpl: Add stack NX support") enables
platforms to request non-executable stack for the DXE phase, by setting
PcdSetNxForStack to TRUE.
The PCD defaults to FALSE, because:
(a) A non-executable DXE stack is a new feature and causes changes in
behavior. Some platform could rely on executing code from the stack.
(b) The code enabling NX in the DXE IPL PEIM enforces the
PcdSetNxForStack ==> PcdDxeIplBuildPageTables
implication for "64-bit PEI + 64-bit DXE" platforms, with a new
ASSERT(). Some platform might not comply with this requirement
immediately.
Regarding (a), in none of the OVMF builds do we try to execute code from
the stack.
Regarding (b):
- In the OvmfPkgX64.dsc build (which is where (b) applies) we simply
inherit the PcdDxeIplBuildPageTables|TRUE default from
"MdeModulePkg/MdeModulePkg.dec". Therefore we can set PcdSetNxForStack
to TRUE.
- In OvmfPkgIa32X64.dsc, page tables are built by default for DXE. Hence
we can set PcdSetNxForStack to TRUE.
- In OvmfPkgIa32.dsc, page tables used not to be necessary until now.
After we set PcdSetNxForStack to TRUE in this patch, the DXE IPL will
construct page tables even when it is built as part of OvmfPkgIa32.dsc,
provided the (virtual) hardware supports both PAE mode and the XD bit.
Should this setting cause problems in a GPU (or other device) passthru
scenario, with a UEFI_DRIVER in the PCI option rom attempting to execute
code from the stack, the feature can be dynamically disabled on the QEMU
command line, with "-cpu <MODEL>,-nx".
Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: "Zeng, Star" <star.zeng@intel.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18360 6f19259b-4bc3-4df7-8a09-765794883524
Since SVN r18316 / git 5ca29abe5297, the HTTP driver needs the HTTP
utilities driver to parse the headers of HTTP requests. Add the driver
into OVMF so that the HTTP driver can work properly.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18359 6f19259b-4bc3-4df7-8a09-765794883524
Hao Wu [Fri, 28 Aug 2015 07:41:08 +0000 (07:41 +0000)]
MdePkg: Modify string expression of Wi-Fi device path to follow UEFI spec
According to UEFI 2.5 spec, the string expression of a Wi-Fi device node
should be displayed as: Wi-Fi(SSID). However, current code displays it as:
WiFi(SSID).
Hao Wu [Fri, 28 Aug 2015 07:36:55 +0000 (07:36 +0000)]
MdePkg: Modify string expression of BMC device path to follow UEFI spec
According to UEFI 2.5 spec, the string expression of a BMC device node
should be displayed as: BMC(Type,Address). However, current code displays
it as: Bmc(Type,Address).
Jiaxin Wu [Fri, 28 Aug 2015 07:00:32 +0000 (07:00 +0000)]
NetworkPkg: Fix IpSec run into infinite loop issue in some case
v2:
* Update the copyright year and conditional judgment for removing.
When edit one SPEntry in SPD database, the corresponding SA entry will
be updated to the sas list of the new SPD entry. But before that, all
of them should be removed from the original sas list. If not, the list
will be broken into infinite loop.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18352 6f19259b-4bc3-4df7-8a09-765794883524
Qiu Shumin [Fri, 28 Aug 2015 04:51:21 +0000 (04:51 +0000)]
ShellBinPkg: Ia32/X64 Shell binary update.
The binaries of ShellBinPkg are generated with ShellPkg project 18330. The binaries are built with no debug information by building with "RELEASE" target.
Dandan Bi [Thu, 27 Aug 2015 08:35:19 +0000 (08:35 +0000)]
MdeModulePkg:Set default string value
Previously construct Default Value in AltResp for string opcode is String Id,
Now change it to string value if the string opcode has default value.
This change is compatible for SetupBrowser to handle.And add default value
for string in DriverSample to test this case.
Jeff Fan [Thu, 27 Aug 2015 02:05:20 +0000 (02:05 +0000)]
SourceLevelDebugPkg/DebugTimer: Fix the issue if CurrentTimer = Timer
If CPU runs fast and timer runs slow, two GetApicTimerCurrentCount() may return
the same timer count value. We need to consider timer roll-over not happened.
Otherwise, one false timeout flag will be set.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18328 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng [Wed, 26 Aug 2015 09:46:29 +0000 (09:46 +0000)]
MdeModulePkg FaultTolerantWrite: Error handling for erase operation failure
There may be anti-flash wear out feature to forbid erase operation after end of dxe.
The code is missing some error handling for erase operation failure,
it should return directly after the erase operation failed.
Liming Gao [Wed, 26 Aug 2015 06:33:31 +0000 (06:33 +0000)]
BaseTools: Fix the missing depex file in GenFds
If FDF FfsRule describes |.depex for depex file on source build, it may
be missed in the generated FD image. GenFds tool needs to check the
output file list and find the matched one.
Jiaxin Wu [Wed, 26 Aug 2015 06:19:53 +0000 (06:19 +0000)]
NetworkPkg: Update HttpDxe driver to consume EFI_HTTP_UTILITIES_PROTOCOL
v2:
* Register a notification function to be executed for Http utilities protocol
in the drivers entry points.
Since we add EFI_HTTP_UTILITIES_PROTOCOL support, HttpDxe driver should
be updated to remove internal http utilities functions and consume this
protocol directly.
Cc: Ye Ting <ting.ye@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Samer El-Haj-Mahmoud <elhaj@hp.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@18316 6f19259b-4bc3-4df7-8a09-765794883524
Qiu Shumin [Wed, 26 Aug 2015 02:25:42 +0000 (02:25 +0000)]
MdePkg: Make the FileHandleGetFileName return the file name in right format.
1. If the file is not a directory remove the redundant '\' char in file name string returned from UefiFileHandleLib.FileHandleGetFileName.
2. Update function comments.
Feng Tian [Wed, 26 Aug 2015 01:19:09 +0000 (01:19 +0000)]
MdeModulePkg/Xhci: Remove TDs from transfer ring when timeout happens
The error handling for timeout case is enhanced to remove TDs from
transfer ring. The original code only removed s/w URB, but the h/w
transfer descriptor TDs didn't get removed. It would cause data lost
for data stream peripheral, such as usb-to-serial device, from the
s/w perspective.
Qin Long [Wed, 26 Aug 2015 00:59:17 +0000 (00:59 +0000)]
SecurityPkg: Fix one returned code issue in P7Verify Protocol
VerifyBuffer() in PKCS7 Verify Protocol should return EFI_UNSUPPORTED
when the embedded content is found in SignedData but InData is not NULL.
This patch is to comply with the spec definition.
Ard Biesheuvel [Tue, 25 Aug 2015 14:54:36 +0000 (14:54 +0000)]
ShellPkg: use UEFI_APPLICATION module type for Shell components
Some of the libraries under ShellPkg/Library/ are only intended to be
loaded into the Shell by means of a NULL LibraryClass resolution, and
serve no other purpose. Since the Shell itself is a UEFI_APPLICATION, it
makes sense to set the module type of those libraries to UEFI_APPLICATION
as well.
This allows us to use different compiler flags for the Shell application
itself but also for the majority of its constituent parts that are built
separately via these libraries.
Ard Biesheuvel [Tue, 25 Aug 2015 13:11:25 +0000 (13:11 +0000)]
ArmPlatformPkg/FVP: unify support for Foundation and Base models
Now that the PL180 and PL111 drivers know how to behave when executed
on the Foundation model (which does not emulate the hardware), we can
remove the ARM_FOUNDATION_FVP ifdefs and produce a single build that
runs on both the Foundation model and the Base model.
Star Zeng [Tue, 25 Aug 2015 07:05:48 +0000 (07:05 +0000)]
MdeModulePkg PeiCore: Recheck SwitchStackSignal after ProcessNotifyList()
in case PeiInstallPeiMemory() is done in a callback with
EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH, and the callback is registered on
a PPI that is installed in the last PEIM.
At the case, PeiCore SwitchStack code will be not being invoked.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18305 6f19259b-4bc3-4df7-8a09-765794883524