Ard Biesheuvel [Wed, 12 Dec 2018 10:04:44 +0000 (11:04 +0100)]
MdePkg/BaseMemoryLibOptDxe ARM: add missing function annotations
ARM uses the low order bit of a branch target address to decide in
which execution mode (ARM or Thumb) a function needs to be called.
In order for this to work across object files, ELF function symbols
will have the low bit set if they were emitted in Thumb mode and
cleared otherwise. This annotation is only emitted if the ELF symbols
are annotated as function, since taking the address of some data
symbol (e.g., a literal) should not produce a value with the low bit
set, even if it appears in an object file containing Thumb code.
This means that all functions coded in assembler must have this
function annotation, or they may end up getting called in the
wrong mode, crashing the program.
We currently permit R_ARM_GOT_PREL relocations in the ELF32 conversion
routines, under the assumption that relative relocations are fine as
long as the section layout is the same between ELF and PE/COFF.
However, as is the case with any proxy generating relocation, it is
up to the linker to emit an entry in the GOT table and populate it
with the correct absolute address, which should also be fixed up at
PE/COFF load time. Unfortunately, the relocations covering the GOT
section are not emitted into the static relocation sections processed
by GenFw, but only in the dynamic relocation section as a R_ARM_RELATIVE
relocation, and so GenFw fails to emit the correct PE/COFF relocation
data for GOT entries.
Since GOT indirection is pointless anyway for PE/COFF modules running
in UEFI context, let's just drop the references to R_ARM_GOT_PREL from
GenFw, resulting in a build time failure rather than a runtime failure
if such relocations do occur.
Ard Biesheuvel [Tue, 11 Dec 2018 12:01:10 +0000 (13:01 +0100)]
ArmVirtPkg/PrePiUniCoreRelocatable CLANG38: work around build issues
The self-relocating PrePi module that is used by the ArmVirtQemuKernel
and ArmVirtXen targets runs the linker in PIE mode so that it emits
dynamic relocations into the final image in a way that permits the
module to relocate itself into place before calling into the C code.
When building these targets using the CLANG38 toolchain, we switch
from the BFD to the GOLD linker, which behaves a bit differently when
building PIE executables, and insists on emitting GOT indirected symbol
references throughout, which means a) that we end up with absolute
addresses (which need to be fixed up at load time) for no good reason,
and b) we have to add support for handling GOT entries to GenFw if we
want to convert them into PE/COFF.
So instead, let's emit a shared library. Since the ELF image only serves
as the input to GenFw, this does not lead to any loss of functionality,
although it does require the -Bsymbolic linker option to be added to
ensure that no symbol based dynamic relocations are emitted (which
would, e.g., permit lazy binding for shared libraries). So for all
other toolchains, the linker option changes are a no-op.
Then, we have to convince CLANG38/GOLD that there is no need to refer
to symbols via a GOT entry. This is done by forcing hidden visibility
for all symbols in all components that make up the PrePi SEC module:
this informs the linker that a symbol is never exported or preempted,
making it safe to refer to it directly from anywhere in the code,
rather than indirectly via a GOT entry.
Ard Biesheuvel [Tue, 11 Dec 2018 09:21:25 +0000 (10:21 +0100)]
ArmVirtPkg/ArmVirtQemuKernel ARM: make some PCD settings apply to ARM
Move some PCD settings outs of the [PcdsFixedAtBuild.AARCH64] block,
so that they apply to 32-bit ARM as well. Without this change, the
ARM build doesn't work.
Ard Biesheuvel [Mon, 10 Dec 2018 14:13:39 +0000 (15:13 +0100)]
BaseTools/tools_def AARCH64 RELEASE: move GCC49/GGC5 to 4 KB alignment
Since 4 KB section alignment is required when mapping PE/COFF images
with strict permissions, update the default section alignment when
using GCC49 and GCC5 in RELEASE mode. Note that XIP modules such as
SEC, PEIMs or PEI core are not affected by this change, since the
override to 32 byte aligment remains in effect.
Ard Biesheuvel [Sat, 8 Dec 2018 10:24:31 +0000 (11:24 +0100)]
MdeModulePkg/FileExplorerLib: avoid packed struct for program data
Struct packing is only necessary for data structures whose in-memory
representation is covered by the PI or UEFI specs, and may deviate
from the ordinary C rules for alignment.
So in case of FileExplorerLib, this applies to the device path struct
only, and other structures used to carry program data should not be
packed, or we may end up with alignment faults on architectures such
as ARM, which don't permit load/store double or multiple instructions
to access memory locations that are not 32-bit aligned.
E.g., the following call in FileExplorerLibConstructor()
will perform a double-word store on the first argument, passed in
register r0, assuming that the pointer type of the argument is
enough to guarantee that the value is suitably aligned.
Eric Dong [Mon, 10 Dec 2018 07:32:14 +0000 (15:32 +0800)]
UefiCpuPkg/Cpuid.h: Sync CPUID definition to latest SDM.
Update CPUID definition to follow SDM 2018'11 version, changes Include:
1. Add new fields to the existed data structure, impact CPUIDs include:
1. CPUID_THERMAL_POWER_MANAGEMENT 0x06
CPUID_THERMAL_POWER_MANAGEMENT_EAX
2. CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS 0x07
CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_EBX
CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_ECX
3. CPUID_ARCHITECTURAL_PERFORMANCE_MONITORING 0x0A
CPUID_ARCHITECTURAL_PERFORMANCE_MONITORING_EDX
4. CPUID_EXTENDED_STATE 0x0D
CPUID_EXTENDED_STATE_MAIN_LEAF_EAX
CPUID_EXTENDED_STATE_SUB_LEAF_ECX
5. CPUID_INTEL_RDT_ALLOCATION 0x10
CPUID_INTEL_RDT_ALLOCATION_ENUMERATION_SUB_LEAF_EBX
6. CPUID_INTEL_SGX 0x12
CPUID_INTEL_SGX_CAPABILITIES_0_SUB_LEAF_EAX
2. Add new data structures which not existed before, impact CPUID includes:
1. CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS 0x07
CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_EDX
3. Remove fields which defined before, impact CPUID includes:
1. CPUID_INTEL_RDT_ALLOCATION 0x10
CPUID_INTEL_RDT_ALLOCATION_L3_CACHE_SUB_LEAF 0x01
CPUID_INTEL_RDT_ALLOCATION_L3_CACHE_SUB_LEAF_ECX
4. Add new sub leaf which not existed before, impact CPUID includes:
1. CPUID_INTEL_RDT_ALLOCATION 0x10
CPUID_INTEL_RDT_ALLOCATION_MEMORY_BANDWIDTH_SUB_LEAF 0x03
5. Add new CPUIDs which not exist before, new CPUIDs include:
1. CPUID_DETERMINISTIC_ADDRESS_TRANSLATION_PARAMETERS 0x18
2. CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION 0x1F
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
BaseLib interfaces are used in this library but not declared in module's
inf file. This patch fix this situation to keep inf and its code in
consistency. No functionality or interface change are involved.
Cc: Qin Long <qin.long@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
Today's implementation reuses the 32bit MMIO resource requested by
all PCI devices MMIO BARs when shadowing the option ROM.
Take a simple example, a system has only one PCI device. It requires
8MB 32bit MMIO and contains a 4MB option ROM. Today's implementation
only requests 8MB (max of 4M and 8M) 32bit MMIO from
PciHostBridgeResourceAllocation protocol. Let's assume the MMIO range
[3GB, 3GB+8MB) is allocated. The 3GB base address is firstly
programmed to the option ROM BAR for option ROM shadow. Then the
option ROM decoding is turned off and 3GB base address is programmed
to the 32bit MMIO BAR.
It doesn't cause issues when the device doesn't request too much
MMIO.
But when the device contains a 64bit MMIO BAR which requests 4GB MMIO
and a 4MB option ROM. Let's assume [3GB, 3GB+8MB) 32bit MMIO range is
allocated for the option ROM. When the option ROM is being shadowed,
64bit MMIO BAR is programmed to value 0, which means [0, 4GB) MMIO is
given to the 64bit BAR.
The range overlaps with the option ROM range which may cause the
device malfunction (e.g.: option ROM cannot be read out) when the
device has two separate decoders: one for MMIO BAR, the other for
option ROM.
The patch requests dedicated MEM32 resource for Option ROMs and
moves the Option ROM shadow logic after all MMIO BARs are programmed.
The MMIO BAR setting to 0 when shadowing Option ROM is also skipped
because the MMIO BAR already contains the correct value.
Sughosh Ganu [Mon, 3 Dec 2018 07:19:02 +0000 (12:49 +0530)]
StandaloneMM: Update permissions for Standalone MM drivers memory area
The StandaloneMM image executes in S-EL0 on reference Arm platforms
and is deployed by the trusted firmware as BL32 image. Memory for the
Standalone MM drivers is marked as RW+XN initially, allowing the
drivers to be loaded into the memory. Once loaded, the memory
attributes need to be changed to RO+XN for rodata sections and RO+X
for code sections.
Achieve this through the extra action 'UpdatePeCoffPermissions' to
request the privileged firmware in EL3 to update the permissions.
Sughosh Ganu [Mon, 3 Dec 2018 07:19:01 +0000 (12:49 +0530)]
StandaloneMM: Include the newly added library class for MMU functions
The MMU functions needed for StandaloneMM image are now exported
through a separate library class. Make the corresponding change in the
core's entry point inf file so that it references the correct library
class for modifying the MMU attributes.
Achin Gupta [Mon, 3 Dec 2018 07:20:54 +0000 (12:50 +0530)]
StandaloneMmPkg: Zero data structure explicitly
Introduction of the -mstrict-align flag results in GCC attempting
to use memset to zero out the InitMmFoundationSvcArgs structure.
In the absence of this C library function, this patch explicitly
zeroes this data structure prior to use.
Achin Gupta [Mon, 3 Dec 2018 07:20:53 +0000 (12:50 +0530)]
StandaloneMmPkg: Enforce alignment check for AArch64
On AArch64, Standalone MM during the SEC phase runs in S-EL0 with
SCTLR_EL1.A=1. This patch adds the -mstrict-align compiler flag to
ensure that the generated code is compliant with the runtime
alignment checks.
On AArch64, we can only use 48 address bits while running in UEFI,
while the GCD and UEFI memory maps may describe up to 52 bits of
physical address space. For this reason, MAX_ADDRESS was reduced
to 48 bits, to ensure that the firmware does not inadvertently
attempt to allocate memory that we cannot access.
However, MAX_ADDRESS is used in runtime drivers as well, and
runtime drivers may deal with kernel virtual addresses, which have
bits [63:48] set. In fact, the OS may be running with 64 KB pages
and pass addresses into the runtime services that use up to 52
bits of address space, either with the top bits set or cleared,
even if the physical address space does not extend beyond 48 bits.
In summary, changing MAX_ADDRESS is a mistake, and needs to be
reverted.
This patch is one of build tool performance improvement
series patches.
This patch is going to use join function instead of
string += string2 statement.
Current code use string += string2 in a loop to combine
a string. while creating a string list in a loop and using
"".join(stringlist) after the loop will be much faster.
[V2]
Optimize this patch so that it can be easy to review.
This patch is just apply the change to original files while
not create new similar files.
[V1]
This patch is one of build tool performance improvement
series patches.
This patch is going to use python list to store the parser data
instead of using sqlite database.
The replacement solution is as below:
SQL insert: list.append()
SQL select: list comprehension. for example:
Select * from table where field = “something”
->
[ item for item in table if item[3] == “something”]
SQL update: python map function. for example:
Update table set field1=newvalue where filed2 = “something”.
-> map(lambda x: x[1] = newvalue,
[item for item in table if item[2] == “something”])
SQL delete: list comprehension.
With this change, We can save the time of interpreting SQL statement
and the time of write database to file system
Currently, AutoGen and GenFds run in different python interpreters. The
parser are duplicated. This patch is going to create new API for GenFds
and have the build to call that API instead of executing GenFds.py. As
such, the GenFds and build can share the parser data.
This patch is expected to save the time of GenFds about 2~3 seconds.
More details will be logged in BZ.
This is the summary measure data generated from python cProfile for
building Ovmf.
Currently: 8379147 function calls (8135450 primitive calls) in 12.580 seconds
After applying this patch: 3428712 function calls (3418881 primitive calls) in 8.944 seconds
Feng, Bob C [Thu, 1 Nov 2018 14:57:08 +0000 (22:57 +0800)]
BaseTool: Filter out unused structure pcds
V2:
Fixed the issue that V1 adds new check
to the Pcds in the platform unused library INF files.
It breaks the existing platform.
V1?
The current code handle all the structure pcds
even if there is no module or library use them.
This patch is going to filter out the unused structure pcds.
Ard Biesheuvel [Wed, 5 Dec 2018 08:15:48 +0000 (09:15 +0100)]
BaseTools/CommonLib: drop the use of MAX_ADDRESS
The macro MAX_ADDRESS represents the largest virtual address that
is valid for a certain architecture. For the BaseTools, this quantity
is irrelevant, since the same tools can be used to build for different
targets.
Since we only refer to it in a single place, which is an ASSERT() that
doesn't seem particularly useful (it ensures that memcpy() will not
be called with arguments that will make it read beyond the end of the
address space and wrap around), let's drop the ASSERT and all references
to MAX_ADDRESS.
Shenglei Zhang [Fri, 30 Nov 2018 02:30:05 +0000 (10:30 +0800)]
BaseTools: Remove tools only used by DuetPkg
Given that DuetPkg will be removed, tools only used by
DuetPkg can also be removed after its removal operation.
https://bugzilla.tianocore.org/show_bug.cgi?id=1322
v2:Remove these tools in Makefile and GNUmakefile.
v4:Remove these tools in BinWrappers/PosixLike/ and
UserManuals.
Shenglei Zhang [Fri, 30 Nov 2018 02:30:38 +0000 (10:30 +0800)]
DuetPkg: Remove DuetPkg
DuetPkg depends on Legacy BIOS to provide a UEFI environment.
It was invented in the era when UEFI environment is hard to find.
Since now UEFI is very popular in PC area, we could stop the
official support of this package and remove it from the master.
https://bugzilla.tianocore.org/show_bug.cgi?id=1322
Ard Biesheuvel [Thu, 29 Nov 2018 12:22:46 +0000 (13:22 +0100)]
BaseTools/CommonLib: drop definition of MAX_UINTN
The maximum value that can be represented by the native word size
of the *target* should be irrelevant when compiling tools that
run on the build *host*. So drop the definition of MAX_UINTN, now
that we no longer use it.
Ard Biesheuvel [Thu, 29 Nov 2018 12:05:38 +0000 (13:05 +0100)]
BaseTools/CommonLib: get rid of 'native' type string parsing routines
Parsing a string into an integer variable of the native word size
is not defined for the BaseTools, since the same tools may be used
to build firmware for different targets with different native word
sizes.
Ard Biesheuvel [Wed, 5 Dec 2018 07:56:58 +0000 (08:56 +0100)]
BaseTools/CommonLib: add definition of MAX_UINT32
Since we will be dropping the definition of MAX_UINTN, whose meaning
is ambiguous for the BaseTools, add a definition of MAX_UINT32 that
we can switch to.
Ard Biesheuvel [Thu, 29 Nov 2018 12:13:32 +0000 (13:13 +0100)]
BaseTools/CommonLib: use explicit 64-bit type in Strtoi()
Don't use the native word size string to number parsing routines,
but instead, use the 64-bit one and cast to UINTN.
Currently, the only user is in Source/C/DevicePath/DevicePathFromText.c
which takes care to use Strtoi64 () unless it assumes the value fits
in 32-bit, so this change is a no-op even on 32-bit build hosts.
Ard Biesheuvel [Thu, 29 Nov 2018 12:00:20 +0000 (13:00 +0100)]
BaseTools/CommonLib: avoid using 'native' word size in IP address handling
In the context of the BaseTools, there is no such thing as a native word
size, given that the same set of tools may be used to build a firmware
image consisting of both 32-bit and 64-bit modules.
So update StrToIpv4Address() and StrToIpv6Address() to use UINT64
types instead of UINTN types when parsing strings.
Shenglei Zhang [Fri, 23 Nov 2018 05:43:41 +0000 (13:43 +0800)]
BaseTools: Remove GenVtf
GenVtf C tool is IPF specific. IPF support has been removed
from edk2 trunk. This tool can be removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1349
v2:Remove GenVtf in Makefile and GNUmakefile.
v3:Remove BinWrappers/PosixLike/GenVtf and the user manual
of GenVtf.
Ard Biesheuvel [Fri, 30 Nov 2018 11:28:29 +0000 (12:28 +0100)]
ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping
QEMU/mach-virt is rather unhelpful when it comes to tracking down
NULL pointer dereferences that occur while running in UEFI: since
we have NOR flash mapped at address 0x0, inadvertent reads go
unnoticed, and even most writes are silently dropped, unless you're
unlucky and the instruction in question is one that KVM cannot
emulate, in which case you end up with a QEMU crash like this:
and a warning in the host kernel log that load/store instruction
decoding is not supported by KVM.
Given that the first page of the flash device is not actually
used anyway, let's reduce the mappings of the peripheral space
and the flash device (both of which cover page #0) to only cover
what is actually required:
For ArmVirtQemu, the resulting virtual mapping looks roughly like:
- [0, 4K) : flash, unmapped
- [4K, 2M) : flash, mapped as WB+X RAM
- [2M, 64M) : flash, unmapped
- [64M, 128M) : varstore flash, will be mapped by the NOR flash driver
- [128M, 256M) : peripherals, mapped as device
- [256M, 1GB) : 32-bit MMIO aperture, translated IO aperture, ECAM,
will be mapped by the PCI host bridge driver
- [1GB, ...) : RAM, mapped.
After this change, any inadvertent read or write from/to the first
physical page will trigger a translation fault inside the guest,
regardless of the nature of the instruction, without crashing QEMU.
The primary FV contains the firmware boot image, which is not
runtime updatable in our case. So exposing it to the NOR flash
driver is undesirable, since it may attempt to modify the NOR
flash contents. It is also rather pointless, since we don't
keep anything there that we care to expose. (the SEC and PEI
phase modules are not executable from DXE context, and the
contents of the embedded DXE phase FV are exposed by the DXE
core directly via the FVB2 protocol)
So let's disregard the NOR flash block that covers the primary
FV.
Ard Biesheuvel [Fri, 30 Nov 2018 11:28:27 +0000 (12:28 +0100)]
ArmPkg/ArmMmuLib ARM: handle unmapped sections when updating permissions
The ARM ArmMmuLib code currently does not take into account that
setting permissions on a region should take into account that a
region may not be mapped yet to begin with.
So when updating a section descriptor whose old value is zero,
pass in the address explicitly.
Ard Biesheuvel [Fri, 30 Nov 2018 11:28:26 +0000 (12:28 +0100)]
ArmPkg/ArmMmuLib ARM: handle unmapped section in GetMemoryRegion()
GetMemoryRegion() is used to obtain the attributes of an existing
mapping, to permit permission attribute changes to be optimized
away if the attributes don't actually change.
The current ARM code assumes that a section mapping or a page mapping
exists for any region passed into GetMemoryRegion(), but the region
may be unmapped entirely, in which case the code will crash. So check
if a section mapping exists before dereferencing it.
Liming Gao [Thu, 29 Nov 2018 00:55:56 +0000 (08:55 +0800)]
MdeModulePkg: Correct PCD name in MdeModulePkg.uni
https://bugzilla.tianocore.org/show_bug.cgi?id=1363
New PCD PcdVpdBaseAddress64 is added in MdeModulePkg.dec.
Its string token in MdeModulePkg.uni should match to its name.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Bi Dandan <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Reviewed-by: Bi Dandan <dandan.bi@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Ard Biesheuvel [Mon, 26 Nov 2018 21:36:33 +0000 (22:36 +0100)]
BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Mon, 26 Nov 2018 21:35:02 +0000 (22:35 +0100)]
ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Mon, 26 Nov 2018 21:34:05 +0000 (22:34 +0100)]
ArmPlatformPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Mon, 26 Nov 2018 21:22:20 +0000 (22:22 +0100)]
ArmPkg/CpuPei: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Fri, 23 Nov 2018 12:14:28 +0000 (13:14 +0100)]
ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account
In preparation of dropping PcdPrePiCpuMemorySize entirely, base the
maximum size of the identity map on the capabilities of the CPU.
Since that may exceed what is architecturally permitted when using
4 KB pages, take MAX_ADDRESS into account as well.
Ard Biesheuvel [Tue, 27 Nov 2018 12:23:35 +0000 (13:23 +0100)]
MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits
AArch64 supports the use of more than 48 bits for physical and/or
virtual addressing, but only if the page size is set to 64 KB,
which is not supported by UEFI. So redefine MAX_ADDRESS to cover
only 48 address bits.
Ard Biesheuvel [Tue, 27 Nov 2018 14:25:42 +0000 (15:25 +0100)]
ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
entire virtual address space is mapped with EFI_MEMORY_UC attributes,
regardless of whether any devices actually reside there.
Now that we are relaxing the address space limit to more than 40 bits,
mapping all that address space actually takes up more space in page
tables than we have so far made available as temporary RAM. So let's
get rid of the mapping rather than increasing the available RAM, given
that the mapping is not particularly useful anyway.
Ard Biesheuvel [Tue, 27 Nov 2018 14:18:38 +0000 (15:18 +0100)]
ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map
Up until now, we have been getting away with not declaring the ECAM
and translated I/O spaces at all in the GCD memory map, simply because
we map the entire address space with device attributes in the early PEI
code, and so the ECAM space will be mapped wherever it ends up.
Now that we are about to make changes to how ArmVirtQemu reasons
about the size of the address space, it would be better to get rid
of this mapping of the entire address space, since it can get
arbitrarily large without real benefit.
So start by mapping the ECAM and translated I/O spaces explicitly,
instead of relying on the early PEI mapping.
This function is exposed by the MemoryAllocationLib header.
An AllocateZeroPool() function has been added to fix modules depending on
this library and this function.
Liming Gao [Tue, 20 Nov 2018 08:05:56 +0000 (16:05 +0800)]
BaseTools Script: Update ConvertFceToStructurePcd to report warning messages
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1297
When the header files are not found for the used C structure, this script will
report the warning, let user know there is no header file to define C structure.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Wang BinX A <binx.a.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Achin Gupta [Tue, 27 Nov 2018 10:43:57 +0000 (16:13 +0530)]
ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.
The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
Platforms. Privileged firmware e.g. ARM Trusted Firmware sets up its
architectural context including the initial translation tables for the
S-EL1/EL0 translation regime. The MM environment will still request ARM
TF to change the memory attributes of memory regions during
initialization.
The Standalone MM image is a FV that encapsulates the MM foundation
and drivers. These are PE-COFF images with data and text segments.
To initialise the MM environment, Arm Trusted Firmware has to create
translation tables with sane default attributes for the memory
occupied by the FV. This library sends SVCs to ARM Trusted Firmware
to request memory permissions change for data and text segments.
This patch adds a simple MMU library suitable for execution in S-EL0 and
requesting memory permissions change operations from Arm Trusted Firmware.
PI v1.5 Specification Volume 4 defines Management Mode Core Interface
and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
means of communicating between drivers outside of MM and MMI
handlers inside of MM.
This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE runtime
driver for AARCH64 platforms. It uses SMCs allocated from the standard
SMC range defined in DEN0060A_ARM_MM_Interface_Specification.pdf
to communicate with the standalone MM environment in the secure world.
This patch also adds the MM Communication driver (.inf) file to
define entry point for this driver and other compile
related information the driver needs.
Achin Gupta [Tue, 27 Nov 2018 10:43:53 +0000 (16:13 +0530)]
ArmPkg: Add PCDs needed for MM communication driver.
This patch defines PCDs to describe the base address and size of
communication buffer between normal world (uefi) and standalone MM
environment in the secure world.
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:28 +0000 (12:58 +0100)]
ArmPlatformPkg/NorFlashPlatformLib: remove unused Guid member from struct
We no longer use per-instance GUIDs to identify NOR flash banks so
there is no longer a need to define them. Drop the Guid member from
the NOR_FLASH_DESCRIPTION type.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Thomas Abraham <thomas.abraham@arm.com>
Liming Gao [Thu, 22 Nov 2018 14:10:29 +0000 (22:10 +0800)]
MdeModulePkg PCD: Add DynamicEx PcdVpdBaseAddress64 for non SPI platform
https://bugzilla.tianocore.org/show_bug.cgi?id=1356
Current PcdVpdBaseAddress is 32bit static Pcd. NON SPI platform needs to
configure it as Dynamic PCD. Emulator platform (such as NT32) may set its
value to 64bit address.
To meet with this usage, 64bit DynamicEx PcdVpdBaseAddress64 is introduced.
If its value is not zero, it will be used.
If its value is zero, static PcdVpdBaseAddress will be used.
When NON SPI platform enables VPD PCD, they need to set PcdVpdBaseAddress64.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com>
Liming Gao [Thu, 22 Nov 2018 13:41:41 +0000 (21:41 +0800)]
OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain
https://bugzilla.tianocore.org/show_bug.cgi?id=1355
XCODE doesn't support HII resource section. TftpDynamicCommand driver depends
on HII resource section. To let OvmfPkg boot to shell on XCODE5 tool chain,
don't include TftpDynamicCommand driver.
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:27 +0000 (12:58 +0100)]
ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
that are not based on the device tree received from QEMU.
For ArmVirtQemu, this does not really matter, given that the NOR
flash banks are always the same: the PEI code is linked to execute
in place from flash bank #0, and the fixed varstore PCDs refer to
flash bank #1 directly.
However, ArmVirtQemuKernel can execute at any offset, permitting it
to be used as an intermediary loader when running QEMU with secure
world emulation enabled, in which case NOR flash bank #0 is secure
only and contains the secure world firmware. In this case,
NorFlashQemuLib should not expose the first flash bank at all.
To prevent introducing too much internal knowledge about which flash
bank is accessible under which circumstances, let's switch to using
the DTB to decide which flash banks to expose to the NOR flash driver.
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:26 +0000 (12:58 +0100)]
ArmVirtPkg/FdtClientDxe: take DT node 'status' properties into account
DT has a [pseudo-]standardized 'status' property that can be set on
any node, and which signifies that a node should be treated as
absent unless it is set to 'ok' or 'okay'. So take this into account
when iterating over nodes.
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:25 +0000 (12:58 +0100)]
ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks
Currently, each flash bank controlled by ArmPlatformPkg/NorFlashDxe
has its own VendorHw GUID, and instances of NorFlashPlatformLib
describe each bank to the driver, along with the GUID for each.
This works ok for bare metal platforms, but it would be useful for
virtual platforms if we could obtain this information from a
device tree, which would require us to invent GUIDs on the fly,
given that the 'cfi-flash' binding does not include a GUID.
So instead, let's switch to a single GUID for all flash banks,
and update the driver's device path handling to include an index
to identify each bank uniquely.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Thomas Abraham <thomas.abraham@arm.com>
Ard Biesheuvel [Wed, 21 Nov 2018 11:58:24 +0000 (12:58 +0100)]
ArmPlatformPkg/NorFlashDxe: prepare for devicepath format change
A subsequent patch will change the layout of devicepath nodes
produced by this driver. In preparation, make some tweaks to
the code to use a packed struct for the devicepath and to pass
the device index to NorFlashCreateInstance(). These are cosmetic
changes only, the resulting binaries should be identical.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Thomas Abraham <thomas.abraham@arm.com>
Ard Biesheuvel [Fri, 23 Nov 2018 18:54:59 +0000 (19:54 +0100)]
ArmPkg: remove now unused BsdLib.h
The last remaining users of the BdsLib.h header reside in the
edk2-platforms tree, and so it has been copied there. This
allows us to remove the original from ArmPkg.
Internal code quality scanning found 2 constant if
statements related to FixedPcdGet8 () usage.
Since the PCD can be PatchableInModule too, it should be
changed to PcdGet8 () to fix this issue.
Test: Verified on internal platform and booted successfully.
Cc: Jiewen Yao <Jiewen.yao@intel.com> Cc: Desimone Nathaniel L <nathaniel.l.desimone@intel.com> Cc: Wu Hao A <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
MdeModulePkg/Variable: add debug logs in VariableServiceSetVariable
Print debug messages if size of the VariableName plus DataSize exceeds
Max(Auth|Voltaile)VariableSize bytes. The messages will be useful if any
platform specific value of Max(Auth|Voltaile)VariableSize PCDs have to
be changed.
Cc: Star Zeng <star.zeng@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Ard Biesheuvel [Tue, 20 Nov 2018 01:53:13 +0000 (17:53 -0800)]
ArmPkg/ArmSmcPsciResetSystemLib: add missing call to ExitBootServices()
Our poor man's implementation of EnterS3WithImmediateWake () currently
sets a high TPL level to disable interrupts, and simply calls the
PEI entrypoint again after disabling the MMU.
Unfortunately, this is not sufficient: DMA capable devices such as
network controllers or USB controllers may still be enabled and
writing to memory, e.g., in response to incoming network packets.
So instead, do the full ExitBootServices() dance: allocate space and
get the memory map, call ExitBootServices(), and in case it fails, get
the memory map again and call ExitBootServices() again. This ensures
that all cleanup related to DMA capable devices is performed before
doing the warm reset.
In function GetSectionFromAnyFvByFileType, the input parameter "Buffer"
and "size" should not be NULL, so add ASSERT here to avoid any checker
report that the NULL pointer may be used.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
projects / mirror_edk2.git / log