As of SVN 15115, the PEI core needs a MigratePeiServicesTablePointer function.
Background: The ArmPkg variant of the PeiServicesTablePointerLib implements
the standard PEI Services table retrieval mechanism as defined in the
PI Specification Volume 1 section 5.4.4 using the TPIDRURW registers.
No special action is required on ARM to migrate the PEI Services table
pointer after main memory initialization but a function must be implemented
nonetheless.
Michael Kinney [Wed, 25 Nov 2015 17:01:02 +0000 (17:01 +0000)]
UefiCpuPkg/CpuS3DataDxe: Add module to initialize ACPI_CPU_DATA for S3
This module initializes the ACPI_CPU_DATA structure and registers the
address of this structure in the PcdCpuS3DataAddress PCD. This is a
generic/simple version of this module. It does not provide a machine
check handler or CPU register initialization tables for ACPI S3 resume.
It also only supports the number of CPUs reported by the MP Services
Protocol, so this module does not support hot plug CPUs. This module
can be copied into a CPU specific package and customized if these
additional features are required.
This patch series is in response to the OvmfPkg patch series from
Laszlo Ersek that enables SMM on OVMF. The v4 version of the patch
series from Laszlo includes an OVMF specific CPU module to initialize
the ACPI_CPU_DATA structure.
This proposed patch series replaces the patches listed below.
Yao, Jiewen [Wed, 25 Nov 2015 08:40:49 +0000 (08:40 +0000)]
Install LoadedImage protocol for PiSmmCore.
PiSmmCore installs LoadedImage for each SMM driver. However itself is missing.
So we follow DxeCore style, let PiSmmCore installs LoadedImage protocol for itself,
then the SMM image information is complete.
Yao, Jiewen [Wed, 25 Nov 2015 04:28:46 +0000 (04:28 +0000)]
Move RestoreSmmConfigurationInS3 function to PerformPreTasks().
In this way, we can centralize the silicon configuration in
PerformRemainingTasks()/PerformPreTasks() function.
If there are more features need to be configured, they can put in
PerformRemainingTasks()/PerformPreTasks() only.
Yao, Jiewen [Wed, 25 Nov 2015 04:23:01 +0000 (04:23 +0000)]
Eliminate EFI_IMAGE_MACHINE_TYPE_SUPPORTED.
Move Gdt initialization from InitializeMpServiceData() to CPU Arch specific function.
We create SmmFuncsArch.c for hold CPU specific function, so that
EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64) can be removed.
For IA32 version, we always allocate new page for GDT entry, for easy maintenance.
For X64 version, we fixed TssBase in GDT entry to make sure TSS data is correct.
Remove TSS fixup for GDT in ASM file.
Yao, Jiewen [Wed, 25 Nov 2015 04:05:49 +0000 (04:05 +0000)]
Uninstall LoadedImage protocol if SMM driver returns error and is unloaded.
Original code does not uninstall LoadedImage protocol if SMM driver returns error and is unloaded.
It causes a wrong LoadedImage protocol existing in system.
Jeff Fan [Wed, 25 Nov 2015 02:47:59 +0000 (02:47 +0000)]
UefiCpuPkg/CpuMpPei: Enable x2APIC mode on BSP/APs
If x2APIC flag is set, enable x2APIC mode on all APs and BSP. Before we wakeup
APs to enable x2APIC mode, we should wait all APs have finished initialization.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18934 6f19259b-4bc3-4df7-8a09-765794883524
R_ARM_REL32 are relative relocations, so we don't need to do anything
special when performing the ELF to PE/COFF conversion, since our memory
layout is identical between the two binary formats. So just allow them.
Ard Biesheuvel [Tue, 24 Nov 2015 07:48:06 +0000 (07:48 +0000)]
ArmLib/ArmV7Mmu: use 64-bit type for mapping region size
The way the v7 MMU code is invoked by the Xen port is somewhat of
a pathological case, since it describes its physical memory space
using a single cacheable region that covers the entire addressable
range. When clipping this region to the part that is 1:1 addressable,
we end up with a region of exactly 4 GB in size, which just exceeds
the range of the UINT32 variable we use in FillTranslationTable() to
track our progress while populating the page tables. So promote it
to UINT64 instead.
Ard Biesheuvel [Tue, 24 Nov 2015 07:44:41 +0000 (07:44 +0000)]
ArmVirtPkg/ArmVirtPlatformLib: reduce ID map size to GCD region size
The ID mapping routines on virtual platforms simply map the entire
hardware supported physical address space as device memory, and then
punch some holes for regions that need to be mapped cacheable.
On virtual platforms hosted on CPUs that support a large physical
address range, this may result in a lot of overhead, i.e., 4 KB of page
tables for each 512 GB of address space, which quickly adds up (i.e.,
2 MB for the architectural maximum of 48 bits).
Since there may be a platform specific limit to the size of the (I)PA
space that is not reflected by CPU id registers, restrict the range of
the ID mapping to gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize bits.
This makes sense by itself, since we cannot manipulate mappings above
that limit anwyay (because they are not covered by GCD), and it allows
the PCD be set to a lower value by platforms whose (I)PA space is
smaller than the hardware supported maximum.
Ard Biesheuvel [Tue, 24 Nov 2015 07:44:28 +0000 (07:44 +0000)]
ArmVirtPkg/ArmVirtQemu: limit the (I)PA space to 40 bits
KVM uses a fixed size of 40 bits for its intermediate physical address
space, so there is no need to support anything beyond that even if the
host hardware does.
Align to old BDS behavior (IntelFrameworkModulePkg/BDS) to always create
MemoryTypeInfo variable regardless of the PcdResetOnMemoryTypeInformationChange
value.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18926 6f19259b-4bc3-4df7-8a09-765794883524
Dandan Bi [Mon, 23 Nov 2015 09:37:24 +0000 (09:37 +0000)]
MdeModulePkg:Refine the UiApp
Use new created libraries(Boot Manager,Device Manager,Boot Maintenance
Manager) in UiApp.So remove and refine relative code in UiApp.And update
the Nt32Pkg.dsc and MdeModulePkg.dsc.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18924 6f19259b-4bc3-4df7-8a09-765794883524
Heyi Guo [Mon, 23 Nov 2015 07:48:33 +0000 (07:48 +0000)]
ArmPkg: Invalidate cache after allocating UC memory
It is implied that the memory returned from UncachedMemoryAllocationLib
should have cache invalidated. So we invalidate memory range after
changing memory attribute to uncached.
Leif Lindholm [Fri, 20 Nov 2015 13:14:59 +0000 (13:14 +0000)]
ArmPkg: ArmLib: purge incorrect ArmDrainWriteBuffer () alias
In ArmLib, there exists an alias for ArmDataSynchronizationBarrier,
named after one of several names for the pre-ARMv6 cp15 operation that
was formalised into the Data Synchronization Barrier in ARMv6.
This alias is also the one called from within ArmLib, in preference of
the correct name. Through the power of code reuse, this name slipped
into the AArch64 variant as well.
Jordan Justen [Fri, 20 Nov 2015 08:22:46 +0000 (08:22 +0000)]
UefiCpuPkg/CpuDxe: Don't use gBS->Stall
The CpuDxe driver may run before the gEfiMetronomeArchProtocolGuid
protocol is installed. gBS->Stall does not work until this arch
protocol is installed.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18914 6f19259b-4bc3-4df7-8a09-765794883524
Jeff Fan [Fri, 20 Nov 2015 01:23:52 +0000 (01:23 +0000)]
UefiCpuPkg/SmmFeatureLib: Check SmmFeatureControl by Code_Access_Chk
Bit SMM_Code_Access_Chk (SMM-RO) in MSR_SMM_MCA_CAP is defined in SDM.
If set to 1 indicates that the SMM code access restriction is supported and the
MSR_SMM_FEATURE_CONTROL is supported.
If this bit is not set, we needn't to access register SmmFetureControl.
Otherwise, #GP exception may happen.
We need to check if SmmFeatureControl support or not by checking
SMM_Code_Access_Chk (SMM-RO) in MSR_SMM_MCA_CAP.
Because MSR_SMM_MCA_CAP is SMM-RO register, we should move this check from
SmmCpuFeaturesLibConstructor (non-SMM) to SmmCpuFeaturesInitializeProcessor
(SMM).
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@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> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18906 6f19259b-4bc3-4df7-8a09-765794883524
Jeff Fan [Fri, 20 Nov 2015 01:22:00 +0000 (01:22 +0000)]
UefiCpuPkg: Not touch SmmFeatureControl if Code_Access_Chk not Set
Bit SMM_Code_Access_Chk (SMM-RO) in MSR_SMM_MCA_CAP is defined in SDM.
If set to 1 indicates that the SMM code access restriction is supported and the
MSR_SMM_FEATURE_CONTROL is supported.
If this bit is not set, we needn't to access register SmmFetureControl.
Otherwise, #GP exception may happen.
Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@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> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18905 6f19259b-4bc3-4df7-8a09-765794883524
Mark Rutland [Thu, 19 Nov 2015 14:39:48 +0000 (14:39 +0000)]
ArmPkg/ArmPlatformPkg: position vectors relative to base
We currently rely on .align directives to ensure that each exception
vector entry is the appropriate offset from the vector base address.
This is slightly fragile, as were an entry to become too large (greater
than 32 A64 instructions), all following entries would be silently
shifted until they meet the next alignment boundary. Thus we might
execute the wrong code in response to an exception.
To prevent this, introduce a new macro, VECTOR_ENTRY, that uses .org
directives to position each entry at the precise required offset from
the base of a vector. A vector entry which is too large will trigger a
build failure rather than a runtime failure which is difficult to debug.
For consistency, the base and end of each vector is similarly annotated,
with VECTOR_BASE and VECTOR_END, which provide the necessary alignment
and symbol exports. The now redundant directives and labels are removed.
Mark Rutland [Thu, 19 Nov 2015 14:14:25 +0000 (14:14 +0000)]
ArmPkg: correct TTBR1_EL1 settings in TCR_EL1
As EDK2 runs in an idmap, we do not use TTBR1_EL1, nor do we configure
it. TTBR1_EL1 may contain UNKNOWN values if it is not programmed since
reset.
Prior to enabling the MMU, we do not set TCR_EL1.EPD1, and hence the CPU
may make page table walks via TTBR1_EL1 at any time, potentially using
UNKNOWN values. This can result in a number of potential problems (e.g.
the CPU may load from MMIO registers as part of a page table walk).
Additionally, in the presence of Cortex-A57 erratum #822227, we must
program TCR_EL1.TG1 == 0b1x (e.g. 4KB granule) regardless of the value
of TCR_EL1.EPD1, to ensure that EDK2 can make forward progress under a
hypervisor which makes use of PAR_EL1.
This patch ensures that we program TCR_EL1.EPD1 and TCR_EL1.TG1 as above
to avoid these issues. TCR_EL1.TG1 is set to 4K for all targets, as any
CPU capable of running EDK2 must support this granule, and given
TCR_EL1.EPD1, programming the field is not detrimental in the absence of
the erratum.
Ard Biesheuvel [Wed, 18 Nov 2015 16:18:40 +0000 (16:18 +0000)]
ArmPkg/ArmV7Mmu: handle memory regions over 4 GB correctly
The ARM_MEMORY_REGION_DESCRIPTOR array provided by the platform may
contain entries that extend beyond the 4 GB boundary, above which
we can't map anything on 32-bit ARM. If this is the case, map only
the 1:1 addressable part.
Ard Biesheuvel [Wed, 18 Nov 2015 15:59:59 +0000 (15:59 +0000)]
ArmPkg/ArmV7Lib: take MP extensions into account when programming TTBR
Bits 0 and 6 of the TTBRx system registers have different meanings
depending on whether a system implements the Multiprocessing
Extensions. So use separate memory attribute definitions for MP and
non-MP.
Ard Biesheuvel [Wed, 18 Nov 2015 15:59:42 +0000 (15:59 +0000)]
ArmPkg/ArmV7Lib: fix definition of TTBR_NON_INNER_CACHEABLE
The definition of TTBR_NON_INNER_CACHEABLE should be bit 0 cleared, not
bit 0 set. Furthermore, the name is inconsistent with the other definitions
so rename it to TTBR_INNER_NON_CACHEABLE.
Ard Biesheuvel [Wed, 18 Nov 2015 15:59:22 +0000 (15:59 +0000)]
ArmPkg/ArmV7Mmu: introduce feature PCD to map normal memory non-shareable
Even though mapping normal memory (inner) shareable is usually the
correct choice on coherent systems, it may be desirable in some cases
to use non-shareable mappings for normal memory, e.g., when hardware
managed coherency is not required and the memory system is not fully
configured yet. So introduce a PCD PcdNormalMemoryNonshareableOverride
that makes cacheable mappings of normal memory non-shareable.
Ard Biesheuvel [Wed, 18 Nov 2015 15:58:26 +0000 (15:58 +0000)]
ArmPkg/ArmV7Lib: add support for reading the ID_MMFR0 system register
Implement an accessor function for the ID_MMFR0 system register, which
contains information about the VMSA implementation. We will need this
to access the number of shareability levels and the nature of their
implementations.
The definition TTBR_WRITE_THROUGH_NO_ALLOC makes little sense, since
a) its meaning is unclear in the context of TTBRx, since write through
always implies Read-Allocate and no Write-Allocate
b) its definition equals the definition of TTBR_WRITE_BACK_ALLOC
So instead, rename it to TTBR_WRITE_THROUGH and update the definition
to reflect the name.
Ard Biesheuvel [Wed, 18 Nov 2015 11:51:06 +0000 (11:51 +0000)]
ArmPkg/Mmu: set required XN attributes for device mappings
To prevent speculative intruction fetches from MMIO ranges that may
have side effects on reads, the architecture requires device mappings
to be created with the XN or UXN/PXN bits set (for the ARM/EL2 and
EL1&0 translation regimes, respectively.)
Note that, in the ARM case, this involves moving all accesses to a
client domain since permission attributes like XN are ignored from
a manager domain. The use of a client domain is actually mandated
explicitly by the UEFI spec.
Ard Biesheuvel [Wed, 18 Nov 2015 11:50:50 +0000 (11:50 +0000)]
ArmVExpressPkg/ArmVExpressLibRTSM: map NOR flash as normal memory
Some users of this library (i.e., FVP-AArch64 and RTSM-A15_MPCore)
may be built to execute straight from NOR flash. Since device mappings
should have the XN attribute set (according to the architecture), mapping
the NOR flash as a device may prevent it from being executable.
Since the NOR flash DXE driver is perfectly capable of setting the correct
attributes for the region it needs to write to, and since we will be
executing from DRAM by that time anyway, we can simply map the NOR flash
as normal memory initially.
Ard Biesheuvel [Wed, 18 Nov 2015 11:50:33 +0000 (11:50 +0000)]
ArmVirtPkg/ArmVirtPlatformLib: map executable NOR region as normal memory
The ARM architecture version 7 and later mandates that device mappings
have the XN (non-executable) bit set, to prevent speculative instruction
fetches from read-sensitive regions. This implies that we should not map
regions as device if we want to execute from them, so the NOR region that
contains our FD image should be mapped as normal memory instead.
The MMU code deals correctly with overlapping ARM_MEMORY_REGION_DESCRIPTOR
entries, and later entries in the array take precedence over earlier ones.
So simply add an entry to the end of the array that overrides the mapping
attributes of the FD image, wherever it resides.
The function GcdAttributeToArmAttribute() is not used anywhere in the
code base, and is only defined for AARCH64 and not for ARM. It also
fails to set the bits for shareability and non-executability that we
require for correct operation. So remove it.
Star Zeng [Wed, 18 Nov 2015 10:13:31 +0000 (10:13 +0000)]
MdeModulePkg PeiCore: PeiInstallPeiMemory improper ASSERT test on second call
The ASSERT (PrivateData->PeiMemoryInstalled) in if (PrivateData->PeiMemoryInstalled)
condition is useless, it should be ASSERT (FALSE) to follow the code's expectation.
Ruiyu Ni [Wed, 18 Nov 2015 05:05:22 +0000 (05:05 +0000)]
MdeModulePkg: Change BootLogoEnableLogo use INTN for minus value
The parameter name is also changed from Coordinate* to Offset* to
reflect that it's the offset to the location specified by Attribute.
For example, when the Attribute is Center, OffsetX and OffsetY are
used to specify the offset to the Center. OffsetX = 100 means
100 pixels right to the Center.
Ruiyu Ni [Wed, 18 Nov 2015 05:04:23 +0000 (05:04 +0000)]
MdeModulePkg: Change PlatformLogo.GetImage use INTN for minus value
The parameter name is also changed from Coordinate* to Offset* to
reflect that it's the offset to the location specified by Attribute.
For example, when the Attribute is Center, OffsetX and OffsetY are
used to specify the offset to the Center. OffsetX = 100 means
100 pixels right to the Center.
Mark Rutland [Tue, 17 Nov 2015 13:58:19 +0000 (13:58 +0000)]
ArmPkg: ensure DebugAgentVectorTable is 2K-aligned
We force alignment to 2K after generating the DebugAgentVectorTable
symbol, and hence DebugAgentVectorTable itself may not be 2K-aligned,
and table entries may not be at the correct offset from the
DebugAgentVectorTable base address.
Fix this by forcing alignment before generating the
DebugAgentVectorTable symbol.
Laszlo Ersek [Mon, 16 Nov 2015 18:29:14 +0000 (18:29 +0000)]
MdeModulePkg: SmmLockBoxPeiLib: work without EFI_PEI_SMM_COMMUNICATION_PPI
The RestoreLockBox() and RestoreAllLockBoxInPlace() functions handle the
case when EFI_PEI_SMM_COMMUNICATION_PPI.Communicate() returns
EFI_NOT_STARTED: they access the SMRAM directly, for restoring LockBox
data.
This occurs if a PEIM needs to restore LockBox data *before* the SMBASE is
relocated and the SMI handler is installed for all processors.
One such PEIM is UefiCpuPkg/Universal/Acpi/S3Resume2Pei. On the S3 resume
path, in function S3RestoreConfig2(), LockBox data are restored *before*
the SmmRestoreCpu() function of UefiCpuPkg/PiSmmCpuDxeSmm is called via
SmmS3ResumeState->SmmS3ResumeEntryPoint. (The latter SmmRestoreCpu()
function is responsible for the SMBASE relocation.)
If a platform knows that its PEIMs restore LockBox data *only* before
SMBASE relocation -- e.g., due to S3Resume2Pei being the platform's only
SmmLockBoxPeiLib client --, then the platform might not want to include
"UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf" at all (hence
not provide EFI_PEI_SMM_COMMUNICATION_PPI) -- because all of those
restores would be serviced by direct SMRAM access anyway.
Currently the absence of EFI_PEI_SMM_COMMUNICATION_PPI is not supported by
SmmLockBoxPeiLib, but it's not hard to implement. Handle it the same as
when EFI_PEI_SMM_COMMUNICATION_PPI.Communicate() returns EFI_NOT_STARTED:
restore LockBox data directly from SMRAM.
Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18823 6f19259b-4bc3-4df7-8a09-765794883524
Zhang Lubo [Fri, 13 Nov 2015 09:35:54 +0000 (09:35 +0000)]
NetworkPkg: Httpboot will fail the 2nd time result by wrong TCP state.
If the 2nd boot quickly after the first succeed boot, it will function well.
But if you wait for some time after 1nd succeed boot and boot again, the
TCP state may change from established to closed wait as the http server send
fin flag, then boot fail occurred.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo <lubo.zhang@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18783 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng [Fri, 13 Nov 2015 02:43:37 +0000 (02:43 +0000)]
MdeModulePkg PeiCore: PEI dispatcher need retry to process NOT_DISPATCHED FV
A corner case like below will cause a NOT_DISPATCHED FV has no opportunity to
be dispatched.
1. FV_RECOVERY has SecCore, PeiCore and some other PEI modules, a module will
report FVMAIN_COMPACT and FV_RECOVERY2 in sequence.
2. FVMAIN_COMPACT has a FV image file with GUIDED FV image section in it.
3. FV_RECOVERY2 has DxeIpl and other PEI modules, the DxeIpl will install
SectionExtractionPpi
If ALL the PEIMs in FV_RECOVERY and FV_RECOVERY2 have DEPEX satisfied and
executed in one loop, PeimNeedingDispatch will be always FALSE, FVMAIN_COMPACT
will have no opportunity to be decompressed and dispatched as DxeIpl executes
after the first processing to FVMAIN_COMPACT.
The patch is to set PeimNeedingDispatch to TRUE when ProcessFvFile() not successfully,
then the NOT_DISPATCHED FV could have another opportunity to be processed.
Ard Biesheuvel [Thu, 12 Nov 2015 11:40:57 +0000 (11:40 +0000)]
ArmPkg/ArmLib: mark all cached mappings as (inner) shareable
Mark all cached memory mappings as shareable (or inner shareable on
AArch64) so that our view of memory is kept coherent by the hardware.
This is relevant for things like coherent DMA and virtualization (where
a guest may migrate to another core) but in general, since UEFI on ARM
is mostly used in a context where the secure firmware and possibly a
secure OS are already up and running, it is best to refrain from using
any non-shareable mappings.
Ard Biesheuvel [Thu, 12 Nov 2015 07:29:21 +0000 (07:29 +0000)]
ArmPlatformPkg: bring DS-5 scripts in line with linker script changes
The ARM and AARCH64 linker scripts have recently been updated so that
the memory layouts of the ELF and PE/COFF versions of each module are
identical. In particular, this means that the ELF images now have a
hole before the first section rather than starting at offset 0x0, which
means we no longer have to correct for this difference when loading the
ELF image into the debugger.
Yonghong Zhu [Wed, 11 Nov 2015 06:30:42 +0000 (06:30 +0000)]
BaseTools/GenFw: add new option to not zero PE/COFF optional header fields
Add new option --keepoptionalheader and that flag does not zero PE/COFF
optional header fields including the version fields. It can support the
case that the PE/COFF optional header would be kept.
Liming Gao [Wed, 11 Nov 2015 02:16:35 +0000 (02:16 +0000)]
MdePkg: Add more DataBits support to Port80 output
The BasePostCodeLibPort80 instance just prints UINT8 to IoPort 80. Some boards
may support 16bit or 32bit. To support them, new PCD PcdPort80DataWidth is
introduced to specify the width of data bits to Port80.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18765 6f19259b-4bc3-4df7-8a09-765794883524
Eugene Cohen [Tue, 10 Nov 2015 10:02:24 +0000 (10:02 +0000)]
MdeModulePkg PeiCore: Fix issue AuthenticationStatus is not propagated correctly
This patch fixes an issue in PEI with encapsulated FV images where the
AuthenticationStatus is not correctly propagated down to child FV
handles. The PEI core registers for callbacks for both FvInfo and
FvInfo2 PPIs. These callbacks process the FVs which will recurse as
necessary to find more encapsulated FVs. (FvInfo2 is an updated PPI
that includes an AuthenticationStatus field - the original FvInfo did
not include this.)
When encapsulated FV processing occurs the PEI core installs both
FvInfo and FvInfo2 PPIs. The original implementation installs FvInfo
first and FvInfo2 second. As soon as the FvInfo PPI is installed the
notification callback handler immediately fires causing recursive FV
processing to occur. Since there is no AuthenticationStatus provided
for the original FvInfo the callback assumes AuthenticationStatus is
zero (unsigned / unverified) even though the parent FV may have been
verified.
This changes the order of FvInfo and FvInfo2 installs to ensure that
the notification callback occurs for FvInfo2 first and appropriate
AuthenticationStatus data can be propagated from parent FV to child
FV.
Zhang Lubo [Tue, 10 Nov 2015 02:18:31 +0000 (02:18 +0000)]
NetworkPkg: Report Http Errors to screen when http layer occurs an error
Http server will return error status in http header when http connection
cannot be established,so the http boot driver should print the error code
code to the screen and the users can know what happened.
Yao, Jiewen [Tue, 10 Nov 2015 02:03:40 +0000 (02:03 +0000)]
Add error handling for TPM in S3 resume failure.
If TPM2_Startup(TPM_SU_STATE) to return an error, the system
firmware that resumes from S3 MUST deal with a TPM2_Startup
error appropriately.
For example, issuing a TPM2_Startup(TPM_SU_CLEAR) command and
configuring the device securely by taking actions like extending
a separator with an error digest (0x01) into PCRs 0 through 7.
projects / mirror_edk2.git / log