Jiewen Yao [Tue, 13 Sep 2016 10:43:30 +0000 (18:43 +0800)]
SecurityPkg/TPM2: Move Tpm2PcrAllocateBanks() to Tpm2CommandLib
This patch just moves function Tpm2CommandAllocPcr() from
DxeTcg2PhysicalPresenceLib.c to Tpm2CommandLib as Tpm2PcrAllocateBanks()
and no functionality change.
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
ArmPkg/AsmMacroIoLib: force word alignment for functions
Without an explicit .align directive, the Clang assembler defaults to
no alignment, which may result in instructions appearing misaligned in
the final executable. So use word alignment in all cases.
ArmVirtPkg: move all platforms to MdePkg/ BaseMemoryLib implementations
The BaseMemoryLibStm implementation under ArmPkg/ is being deprecated,
in favor of the generic versions under MdePkg, now that ARM and AARCH64
support has been added to both the generic C version (BaseMemoryLib) and
the accelerated version (BaseMemoryLibOptDxe). The latter uses unaligned
accesses and special cache maintenance instructions, and can therefore
not be used when the MMU is off.
So move to BaseMemoryLibOptDxe for the DXE phase and later, and to the
generic BaseMemoryLib before that.
As reported by Vishal, CompareGuid() is a hotspot, and switching from
BaseMemoryLibStm in ArmPkg/ to BaseMemoryLibOptDxe causes a noticeable
performance regression due to the fact that BaseMemoryLibOptDxe uses
unaligned accessors explicitly to implement CompareGuid() and the related
functions.
Since BaseMemoryLibOptDxe on ARM and AARCH64 can only be used in contexts
where unaligned accesses are allowed, reimplement these functions for ARM
and AARCH64 specifically, using wide accessors that can tolerate any
misalignment.
MdePkg/BaseMemoryLibOptDxe ARM: fix arithmetic bugs in CompareMem()
Fix two bugs:
- Erroneous shift of 2 in a bytes to bits conversion.
- Use reverse subtract rather than negate for value that is subsequently
used as operand #2 in a shift operation.
Jeff Fan [Tue, 20 Sep 2016 08:17:26 +0000 (16:17 +0800)]
UefiCpuPkg/SecCore: SecPlatformInformation(2) are optional PPIs
Currently, this is ASSERT() if neither SecPlatformInformation2 nor
SecPlatformInformation PPIs are found. This is not correct. Per PI specification
both of them are optional PPI. Platform may not install them.
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Jeff Fan [Tue, 20 Sep 2016 08:03:18 +0000 (16:03 +0800)]
QuarkPlatformPkg/PlatformSecLib: Fix stack pointer issue in Flat32.S
ESP should be set to top of eSRAM range that aligns with Flat32.asm. Because CPU
BIST data will be located at top of STACK, this issue leads Platform Sec Lib
cannot get the correct CPU BIST information.
This fix is to address below issue:
https://tianocore.acgmultimedia.com/show_bug.cgi?id=123
Cc: Steven Shi <Steven.shi@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Kelly Steele <kelly.steele@intel.com> Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Star Zeng [Wed, 31 Aug 2016 06:47:36 +0000 (14:47 +0800)]
MdeModulePkg PCD: Update PCD database structure definition to match BaseTools
To follow PI1.4a, BaseTools has be updated to fix artificial limitation of
SkuId range.
This patch is to update PCD database structure definition to match BaseTools.
Note: The source code and BaseTools need to be upgraded at the same time,
and if they are not upgraded at the same time, build error like below will
be triggered to help user identify the problem.
"Please make sure the version of PCD PEIM Service and the generated
PCD PEI Database match."
BaseTools: Follow PI1.4a to fix artificial limitation of PCD SkuId range
Current BaseTools follow previous PI spec to use UINT8 for SkuId, to
follow PI1.4a, BaseTools need to be updated to fix artificial limitation
of PCD SkuId range.
This patch is to update BaseTools to use UINT64 for SkuId, since the
PCD database structure needs to be naturally aligned, the PCD database
structure layout is adjusted to keep the natural alignment and version
is updated to 6.
Note: As the PCD database structure layout is adjusted, the structure
definition in MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h and
PCD drivers also need to be updated. That means the source code and
BaseTools need to be upgraded at the same time, and if they are not
upgraded at the same time, build error like below will be triggered
to help user identify the problem.
"Please make sure the version of PCD PEIM Service and the generated
PCD PEI Database match."
IntelFsp2Pkg: Align #Pragma in UPD header files to rest of EDK2 Pkgs
Changed the GenCfgOpt.py script to insert pragma pack(1) instead of
pragma pack (push, 1) in the upd header files generated during fsp build.
This is to align with rest of the EDKII pkgs pragma pack usage.
Also, this scripts generates UnusedUpdSpace for UPD address gaps.
Currently it uses UIN16/UINT32/UINT64 for 2/4/8 bytes instead of UINT8[],
thus causing upd space waste to have Natural Alignment. Hence changed the
script to use UINT8[] for any unusedUpd fields above 1 byte.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Satya Yarlagadda <satya.p.yarlagadda@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
NetworkPkg: Correct the DNS token return status by RCODE
When HostNameToIp() and GeneralLookUp() are called with a invalid
host name, RCODE (4 bit field is set as part of responses) error
will returned in packet to identify the domain name referenced in
the query does not exist. So, EFI_NOT_FOUND should be returned
directly.
Current implementation only check the RCODE in successful condition.
Need update the code for more error check according to RFC 1035 4.1.1
section.
Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Tested-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Reviewed-by: Sriram Subramanian <sriram-s@hpe.com>
ArmVirtPkg/HighMemDxe: move to FDT client protocol
Use the FDT client protocol rather than parsing the DT directly using
fdtlib. While we're at it, update the code so it deals correctly with
memory nodes that describe multiple disjoint regions in their "reg"
properties, and make the code work with #address-cells/#size-cells
properties of <1> as well as <2>.
ArmVirtPkg/FdtClientDxe: add methods to iterate over memory nodes
Add high level methods to iterate over all 'reg' properties of all DT
nodes whose device_type properties have the value "memory". Since we are
modifying the FdtClient protocol, update the protocol and the only existing
implementation at the same time.
ArmVirtPkg/FdtClientDxe: report address and size cell count directly
The FDT client protocol methods dealing with "reg" properties return
the size of a "reg" element. Currently, we have hardcoded this as '8',
since #address-cells == #size-cells == 2 in most cases. However, for
different values, have a single 'reg' element size is not unambiguous,
since - however unlikely - if #address-cells != #size-cells, we do not
know which is which.
So before adding more methods to the protocol, fix up this oversight.
ArmVirtPkg/FdtClientDxe: fix check for size of "reg" properties
Currently, the code in FdtClientDxe assumes #address-cells/#size-cells
values of <2>. Since DT "reg" properties always consist of <base, size>
tuples, this means the size of the entire property should always be a
multiple of 16 bytes (i.e, 4 * sizeof(UINT32), not 8. So fix this.
BaseTools: Fix the bug to handle the read-only file
change the 'r+b' to 'rb' for some file's open, since these files we only
read it and no need to write. It can fix the bug that the file's attribute
had been set to read-only.
Jeff Fan [Fri, 9 Sep 2016 07:14:32 +0000 (15:14 +0800)]
UefiCpuPkg/SecCore: Re-install SEC platform information(2) PPI
In SecTemporaryRamDone(), we will build one privated GUIDed-HOB to save CPU BIST
Data and re-install SEC platform information(2) PPI. Then other PEI drivers
could get CPU BIST data from the private GUIDed-HOB by new installed PPI.
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
Jeff Fan [Fri, 9 Sep 2016 07:08:56 +0000 (15:08 +0800)]
UefiCpuPkg/SecCore: Abstract worker function GetBistFromHob()
Abstract one worker function to get CPU BIST from the GUIDed-HOB. Add
SecPlatformInformationBist() and SecPlatformInformation2Bist() to invoke
GetBistFromHob(). Add in/out for parameter in function header.
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
Jeff Fan [Fri, 9 Sep 2016 07:00:30 +0000 (15:00 +0800)]
UefiCpuPkg/SecCore: Add SecBist.c
Add SecBist.c and copy GetBistInfoFromPpi() and SecPlatformInformation2() from
UefiCpuPkg/CpuMpPei/CpuBist.c. And update SecMain.c, SecMain.inf and
UefiCpuPkg.dsc accordinlgy to pass build.
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
Jeff Fan [Fri, 9 Sep 2016 06:36:39 +0000 (14:36 +0800)]
UefiCpuPkg/CpuMpPei: Build GUIDed-HOB to store all CPU BIST Data
Build gEfiSecPlatformInformation2PpiGuid GUIDed-HOB to store all CPU BIST data
that could be used not only by SecPlatformInformation2(), but also by CPU MP Dxe
driver to get CPU BIST data.
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
Jeff Fan [Fri, 9 Sep 2016 06:17:57 +0000 (14:17 +0800)]
UefiCpuPkg/CpuMpPei: Fix BistData ouput error
ProcessorInfo.ProcessorId is UINT64 type even it's valid value is UINT32. Use %x
only output the low 4 bytes and keep the high 4 bytes in stack that will be
output as the second parameter BistData. Typecast ProcessorInfo.ProcessorId to
UINT32 could make BistData output correctly.
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
Jeff Fan [Fri, 9 Sep 2016 05:39:50 +0000 (13:39 +0800)]
UefiCpuPkg/CpuDxe: Fix duplicated status code report
If CPU Bist data is not zero, we will report Status code. But there is one bug
that will report each processor's status code duplicated with NumberOfData
times. This fix is to exchange the loop order on NumberOfData and
mNumberOfProcessors. It could make sure the report status code only once for
each processor.
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases
The new accelerated ARM and AARCH64 implementations take advantage of
features that are only available when the MMU and Dcache are on. So
restrict the use of this library to the DXE phase or later.
This adds AARCH64 support to BaseMemoryLibOptDxe, based on the cortex-strings
library. All string routines are accelerated except ScanMem16, ScanMem32,
ScanMem64 and IsZeroBuffer, which can wait for another day. (Very few
occurrences exist in the codebase)
MdePkg/BaseMemoryLibOptDxe: add accelerated ARM routines
This adds ARM support to BaseMemoryLibOptDxe, partially based on the
cortex-strings library (ScanMem) and the existing CopyMem() implementation
from BaseMemoryLibStm in ArmPkg.
All string routines are accelerated except ScanMem16, ScanMem32,
ScanMem64 and IsZeroBuffer, which can wait for another day. (Very few
occurrences exist in the codebase)
MdePkg/BaseMemoryLib: widen aligned accesses to 32 or 64 bits
Since the default BaseMemoryLib should be callable from any context,
including ones where unaligned accesses are not allowed, it implements
InternalCopyMem() and InternalSetMem() using byte accesses only.
However, especially in a context where the MMU is off, such narrow
accesses may be disproportionately costly, and so if the size and
alignment of the access allow it, use 32-bit or even 64-bit loads and
stores (the latter may be beneficial even on a 32-bit architectures like
ARM, which has load pair/store pair instructions)
ArmVirtPkg/FdtParser: avoid unaligned accesses with the MMU off
When parsing the device tree to find the memory node, we are still running
with the MMU off, which means unaligned memory accesses are not allowed.
Since the FDT only mandates 32-bit alignment, 64-bit quantities are not
guaranteed to appear naturally aligned, and so should be accessed using
32-bit accesses instead.
ArmPkg/ArmMmuLib: base page table VA size on GCD memory map size
As reported by Eugene, the practice of sizing the address space in the
virtual memory system based on the maximum address in the table passed
to ArmConfigureMmu() is problematic, since it fails to take into account
the fact that the GCD memory space may be extended at a later time, both
for memory and for MMIO. So instead, choose the VA size identical to the
GCD memory map size, which is based on PcdPrePiCpuMemorySize on ARM
systems.
ArmPkg/ArmMmuLib: use a pool allocation for the root table
Currently, we allocate a full page for the root translation table, even
if the configured translation only requires two entries (16 bytes) for
the root level, which happens to be the case for a 40 bit VA. Likewise,
for a 36-bit VA space, the root table only needs 16 entries of 8 bytes
each, adding up to 128 bytes.
So switch to a pool allocation for the root table if we can, but take into
account that the architecture requires it to be naturally aligned to its
size, i.e., a 64 byte table requires 64 byte alignment, whereas pool
allocations in general are only guaranteed to be aligned to 8 bytes.
ArmPkg/ArmMmuLib: remove bogus alignment of page allocations
In commit 7d189f99d81c ("ArmPkg/Mmu: Fix bug of aligning new allocated
page table"), we fixed a flaw in the logic regarding alignment of newly
allocated translation table pages. However, we all failed to spot that
aligning page based allocations to page size is rather pointless to
begin with, so simply allocate a single page each time we add new pages
to the translation tables.
The relations between T0SZ, the number of translation levels and the
size/alignment of the root table can be expressed in simple arithmetic
expressions, so get rid of the lookup table.
Note that this disregards the fact that the maximum value of T0SZ is
39 not 42 (as one would expect for the smallest VA size using 2 levels)
but since this corresponds to a VA size of 32 MB and 4 MB, respectively,
neither of which are sufficient to run UEFI, we can safely ignore the
distinction.
OvmfPkg/IndustryStandard: make "Xen/grant_table.h" pure ASCII
The header file includes the UTF-8 encoding (0xE2 0x80 0x99) of the U+2019
(RIGHT SINGLE QUOTATION MARK) code point. Replace it with a simple
apostrophe (U+0027, ASCII 0x27).
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Dandan Bi [Mon, 5 Sep 2016 06:55:49 +0000 (14:55 +0800)]
MdeModulePkg/HiiDB: Handle the "&READONLY" tag in <KeywordResp> correctly
This patch is to fix the incorrect logic when handling the "&READONLY" tag
in <KeywordResp>.
1. In UEFI spec, the "&READONLY" tag is in upper case, but using the lower
case in current codes by mistake.
2. The logic in checking the ReadOnly flag is not correct. Whether having
"&READONLY" tag must be consistent with the result of
"ExtractReadOnlyFromOpCode" function.
Cc: Liming Gao <liming.gao@intel.com> 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> Reviewed-by: Liming Gao <liming.gao@intel.com>
OptionRomPkg: .dsc fixes for ARM/AARCH64 and USB drivers
Drivers under OptionRomPkg wouldn't build standalone, since ARM and
AARCH64 were missing from SUPPORTED_ARCHITECTURES. So add them.
Also, add some compiler libraries needed for ARM/AARCH64 GCC
toolchains (CompilerIntrinsicsLib and BaseSwStackCheckLib).
Also, the UsbNetworking drivers were not listed under [Components],
so failed to build standalone. This patch adds them.
The ArmGicLib API function GicGetCpuRedistributorBase () declares
GicCpuRedistributorBase to iterate over the redistributors of all
CPUs, but then inadvertently advances GicRedistributorBase instead.
ArmPkg/DefaultExceptionHandlerLib: trim module name in backtrace output
As reported by Vishal, the new backtrace output would be more useful if
it did not contain the full absolute path of each module in the list.
So strip off everything up to the last forward slash or backslash in the
string.
Example output:
IRQ Exception at 0x000000005EF110E0
DxeCore.dll loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EF121F0) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EF1289C) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEFB6B4) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEFAA44) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEFB450) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEF938C) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEF8D04) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEFA8E8) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEF3C14) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEF3E48) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EF0C838) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEEF70C) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEEE93C) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEEE024) loaded at 0x000000005EEED000
ArmPlatformPkg/NorFlashDxe: use strictly aligned CopyMem()
The UEFI spec stipulates that unaligned accesses should be enabled
on CPUs that support them, which means all of them, given that we
no longer support pre-v7 ARM cores, and the AARCH64 bindings mandate
support for unaligned accesses unconditionally.
This means that one should not assume that CopyMem () is safe to call
on regions that may be mapped using device attributes, which is the
case for the NOR flash. Since we have no control over the mappings when
running under the OS, and given that write accesses require device
mappings, we should not call CopyMem () in the read path either, but
use our own implementation that is guaranteed to take alignment into
account.
MdePkg/BaseLib AARCH64: terminate stack frame list on stack switch
When switching to the DXE phase stack, set the frame pointer to zero so
that code walking the stack frame will not try to access stack frames
belonging to the old stack.
BaseTools/EfiRom: supply missing machine type lookup strings
"EfiRom --dump" does not recognize the 0x8664 machine type:
> EFI ROM header contents
> EFI Signature 0x0EF1
> Compression Type 0x0001 (compressed)
> Machine type 0x8664 (unknown)
> Subsystem 0x000B (EFI boot service driver)
> EFI image offset 0x0050 (@0xF650)
Add lookup strings for the remaining EFI_IMAGE_MACHINE_* numeric macros
that can be found in
"BaseTools/Source/C/Include/IndustryStandard/PeImage.h". The strings
follow Table 12. "UEFI Image Types" from the UEFI v2.6 spec.
ShellPkg/UefiHandleParsingLib: fix retval for empty child controller array
The ParseHandleDatabaseForChildControllers() function intends to work like
this:
(1) It allocates a "HandleBufferForReturn" local array that's guaranteed
to be big enough for all found handles,
(2) it collects the handles, both counting them in the (mandatory)
"MatchingHandleCount" output parameter, and saving them in the local
"HandleBufferForReturn" array,
(3) if the caller is not interested in the actual handles, then
"HandleBufferForReturn" is released,
(4) if the caller is interested in the handles, and we've found some, then
"HandleBufferForReturn" is passed out through the
"MatchingHandleBuffer" output parameter,
(5) if the caller is interested in the actual handles, but we've found
none, then the "MatchingHandleBuffer" output parameter is set to NULL.
The ASSERT() at the end of the function makes this clear, but the
implementation does not conform to (5). Fix it.
Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Tapan Shah <tapandshah@hpe.com> Reported-by: Tapan Shah <tapandshah@hpe.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=112
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Tapan Shah <tapandshah@hpe.com>
According to PCI spec the next AER capability is relative to
the beginning of PCI configuration space. Hence substract the
base offset to get the next capability.
"-_e" option is changed from TypeFlag to TypeValue, so that
user can specify individual AER capability to print.
e.g. pci 00 00 01 -i -_e <capability-id>
For historical reasons, the files under ArmLib are split up into 'common'
files under Common/, containing common C files as well as AArch64 and Arm
specific asm files, and ArmV7 and AArch64 files under ArmV7/ and AArch64/,
respectively. This presumably dates back to the time when ArmLib supported
different revisions of the 32-bit architecture (i.e., pre-V7)
Since the PI spec requires V7 or later, we can simplify this to Arm/ and
AArch64, which aligns ArmLib with the majority of other modules that carry
ARM or AArch64 specific code.
So move the files around so that shared files live at the same level as
ArmBaseLib.inf, and ARM/AArch64 specific files live in Arm/ or AArch64/,
respectively.
ArmPlatformPkg: remove EFI_MEMORY_UC attribute from normal memory
On ARM systems, mapping normal memory as device memory may have unintended
side effects, given that unaligned accesses or loads and stores with special
semantics (e.g., load/store exclusive) may fault or may not work as expected.
Similarly, DC ZVA instructions are only supported on normal memory, not
device memory.
So remove the EFI_MEMORY_UC attribute that we set by default on system RAM.
If any region requires this attribute, it is up to the driver to set this
attribute, and to ensure that no offending operations are performed on it.
ArmVirtPkg: restrict mapping attributes of normal memory to EFI_MEMORY_WB
In general, on an ARM system, mapping normal memory as device memory may
have unintended side effects, given that unaligned accesses or loads and
stores with special semantics (e.g., load/store exclusive) may fault or
may not work as expected.
Under KVM, the situation is even worse, since the host may not expect the
guest to perform uncached accesses, and so writes to such an uncached
region may get lost completely.
Since the only safe mapping type under KVM is EFI_MEMORY_WB, remove all
other memory type attributes.
ArmVirtPkg: replace all ArmLib resolutions with ArmBaseLib
The various ArmLib flavors are identical in practice, and a new
ArmBaseLib has been introduced that can replace all of them. So replace
all occurrences with ArmBaseLib.
BeagleBoardPkg EmbeddedPkg Omap35xxPkg: move to ArmBaseLib
The various ArmLib flavors are identical in practice, and a new
ArmBaseLib has been introduced that can replace all of them. So replace
all occurrences with ArmBaseLib.
Dennis Chen [Mon, 5 Sep 2016 11:38:20 +0000 (19:38 +0800)]
ArmPkg ArmPlatformPkg ArmVirtPkg: ARM GICv2/v3 Base Address width fix-up
According to the ACPI 6.0/6.1 spec, the physical base address of GICC,
GICD, GICR and GIC ITS is 64-bit. So change the type of the various GIC
base address PCDs to 64-bit, and fix up all users.
OvmfPkg/QemuBootOrderLib: drop too strict "/HD(" suffix from vblk prefix
Translating QEMU's virtio-block OpenFirmware device path to a UEFI device
path prefix was one of the earliest case handled in QemuBootOrderLib. At
that time, I terminated the translation output (the UEFI devpath prefix)
with a "/HD(" suffix.
The intent was for the translation to prefix-match only boot options with
HD() device path nodes in them, that is, no auto-generated "device level"
boot options. This was motivated by prioritizing specific boot options
created by OS installers over auto-generated "device level" options.
However, practice has shown that:
- OS installers place their installed boot options first in the boot order
anyway,
- other device types (SATA disks, virtio-scsi disks), where "/HD(" is not
appended, work just fine,
- requiring "/HD(" actually causes problems: after the OS-installed
specific boot option has been lost (or purposely removed), the
auto-generated "device level" boot option does the right thing (see the
Default Boot Behavior under
<http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>).
The "/HD(" requirement causes such boot options to be dropped, which
prevents "fallback.efi" from running.
Relax the matching by removing the "/HD(" suffix from the translated
prefix.
ArmPkg/DefaultExceptionHandlerLib AARCH64: add minimal backtrace to crash dump
When dumping the CPU state after an unhandled fault, walk the stack
frames and decode the return addresses so we can show a minimal
backtrace. Unfortunately, we do not have sufficient information to
show the function names, but at least we can see the modules and the
return addresses inside the modules.
projects / mirror_edk2.git / log