Qiu Shumin [Fri, 5 Dec 2014 02:33:45 +0000 (02:33 +0000)]
ShellBinPkg: Ia32/X64 Shell binary update.
The binaries of ShellBinPkg are generated with ShellPkg project 16473. The binaries are built with no debug information by building with "RELEASE" target.
Yao, Jiewen [Fri, 5 Dec 2014 00:28:11 +0000 (00:28 +0000)]
Specify little-endian, and then use the “Standard size” from the chart.
Enhance python tool.
The default being native size (and alignment) means by default the standard sizes are not used, which might cause different behavior on difference compiler.
Randy Pawell [Thu, 4 Dec 2014 00:55:50 +0000 (00:55 +0000)]
NetworkPkg: Source fixes and cleanup for ARMGCC compiles
- Fix EFI_IPv4_ADDRESS usages to use a macro to copy the structure
instead of direct assignment, to avoid runtime alignment errors.
- Delete excess local variables that are initialized but otherwise unused.
- Add LibraryClasses.ARM & AARCH64 section in NetworkPkg.dsc file,
containing a CompilerIntrinsicsLib null-library, required for successful
standalone package builds (copied from MdeModulePkg.dsc).
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Randy Pawell <randy_pawell@hp.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16472 6f19259b-4bc3-4df7-8a09-765794883524
Randy Pawell [Thu, 4 Dec 2014 00:32:24 +0000 (00:32 +0000)]
MdeModulePkg: Source fixes and cleanup for ARMGCC compiles
- Fix EFI_IPv4_ADDRESS usages to use a macro to copy the structure
instead of direct assignment, to avoid runtime alignment errors.
- Fix a EFI_INPUT_KEY usage in TerminalDxe to use CopyMem() to copy the
structure instead of direct assignment, to avoid runtime alignment error.
- Delete excess local variables that are initialized but otherwise unused.
- CompilerIntrinsicsLib library now imported for AARCH64, as well as ARM.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Randy Pawell <randy_pawell@hp.com> Reviewed-by: Olivier Martin <Olivier.Martin@arm.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16471 6f19259b-4bc3-4df7-8a09-765794883524
DXE FpdtStatusCodeHandler is required to be unregistered even if StatusCodeReport is disabled. This change makes sure FpdtStatusCodeHandler be always unregistered.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Vincent Zimmer <vincent.zimmer@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16470 6f19259b-4bc3-4df7-8a09-765794883524
Bruce Cran [Tue, 2 Dec 2014 21:30:41 +0000 (21:30 +0000)]
StdLib/BsdSocketLib: Fix function declaration mismatch with definition.
Replace the existing old-style function declarations for Field, cvtbase and spectHex in BsdSocketLib with real prototypes. This allows StdLib to build using the GCC48 toolchain.
Laszlo Ersek [Fri, 28 Nov 2014 10:24:56 +0000 (10:24 +0000)]
MdePkg: UefiScsiLib: do not encode LUN in CDB for other SCSI commands
The TEST UNIT READY, INQUIRY, MODE SENSE, REQUEST SENSE and READ CAPACITY
commands define bits [7:5] of Cdb[1] as Reserved (potentially as part of a
larger Reserved bitfield):
Command Reserved bitfield in Cdb[1] SCSI spec reference
------------------ --------------------------- -------------------
TEST UNIT READY all bits SPC-4 6.37
INQUIRY bits [7:2] SPC-4 6.4.1
MODE SENSE (6) bits [7:4] SPC-4 6.11.1
MODE SENSE (10) bits [7:5] SPC-4 6.12
REQUEST SENSE bits [7:1] SPC-4 6.29
READ CAPACITY (10) bits [7:1] SBC-3 5.16
READ CAPACITY (16) bits [7:5] SBC-3 5.17
Update the UefiScsiLib functions accordingly.
(In ScsiReadCapacity16Command() the LUN has not been encoded, so there we
just remove the useless ScsiIo->GetDeviceLocation() call, with its
auxiliary local variables.)
The EFI_SCSI_TARGET_MAX_BYTES and EFI_SCSI_LOGICAL_UNIT_NUMBER_MASK macros
become unused with this patch, remove them too.
Laszlo Ersek [Fri, 28 Nov 2014 10:24:41 +0000 (10:24 +0000)]
MdePkg: UefiScsiLib: do not encode LUN in CDB for READ and WRITE
The "SCSI Block Commands - 2" (SBC-2) standard defines bits [7:5] of the
CDB byte 1 as Reserved, for the READ and WRITE commands.
The updated "SCSI Block Commands - 3" (SBC-3) standard defines the same
bitfield as RDPROTECT and WRPROTECT, respectively.
After reviewing the above standards, and the following commits:
- SVN r8331 (git 676e2a32),
- SVN r8334 (git 6b3ecf5c),
we've determined that UefiScsiLib is incorrect in encoding the LUN in this
bitfield for the READ and WRITE commands.
Encoding a nonzero LUN there creates unintended RDPROTECT and WRPROTECT
values, which the recipient device is required to reject if it does not
support protection information, with CHECK CONDITION, ILLEGAL REQUEST,
INVALID FIELD IN CDB:
In practice this flaw breaks UefiScsiLib minimally on SCSI disks with
nonzero LUNs that are emulated by QEMU (after QEMU commit 96bdbbab, part
of v1.2.0).
Qin Long [Wed, 26 Nov 2014 08:21:54 +0000 (08:21 +0000)]
Correct the alignment calculation of PE/COFF attribute certificate entry.
This is to resolve the possible certificate entry retrieving issue caused by un-aligned (8-bytes) VirtualAddress in some PE/COFF image, which may break secure boot.
Chen Fan [Fri, 21 Nov 2014 22:46:36 +0000 (22:46 +0000)]
EmulatorPkg/MpService: StartupAllAPs should verify processor state before setting state
if any enabled APs are not in idle state, StartupAllAPs() should return immediately,
and must not change the other idled processor state. so we checked the state before
changed them.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16416 6f19259b-4bc3-4df7-8a09-765794883524
PCD to CsmSupportLib. Since that "namespace" GUID is declared in
OvmfPkg/OvmfPkg.dec, and we've not used anything from OvmfPkg/OvmfPkg.dec
in CsmSupportLib.inf thus far, this is a new [Packages] dependency and
must be named.
Laszlo Ersek [Thu, 20 Nov 2014 09:58:28 +0000 (09:58 +0000)]
OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration explicit
The ACPI payload that OVMF downloads from QEMU via fw_cfg depends on the
PCI enumaration and resource assignment performed by
MdeModulePkg/Bus/Pci/PciBusDxe.
Namely, although the ACPI payload is pre-generated in qemu during machine
initialization, in
For this reason we must not dispatch AcpiPlatformDxe before PciBusDxe
completes the enumeration.
Luckily, the PI Specification 1.3 defines
EFI_PCI_ENUMERATION_COMPLETE_GUID in Volume 5, "10.9 End of PCI
Enumeration Overview", as an indicia to inform the platform when the PCI
enumeration process has completed. PciBusDxe installs this protocol at the
end of the PciEnumerator() function.
Let's add this GUID to the Depex section of AcpiPlatformDxe, in order to
state the dependency explicitly.
On Xen, and on older QEMU where the linker/loader fw_cfg interface is
unavailable, this introduces a harmless ordering constraint -- we'll
always include PciBusDxe in OVMF, so the dependency will always be
satisfied.
I tested this change as follows:
- I dumped the ACPI tables in a Fedora 20 guest, before and after the
change, and compared them. The only thing that actually changed was the
FACS address. (Which I promptly tested with S3 suspend/resume.) Plus, of
course, the FACP checksum changed, because the FACP links the FACS.
- Tested S3 in my Windows Server 2008 R2 and Windows Server 2012 R2 guests.
Scott Duplichan [Wed, 19 Nov 2014 18:21:37 +0000 (18:21 +0000)]
OvmfPkg: Fix build failure with gcc44, gcc45
OvmfPkg/XenBusDxe/XenHypercall.h:19:31: error: redefinition of typedef 'XENBUS_DEVICE'
OvmfPkg/XenBusDxe/XenBusDxe.h:86:31: note: previous declaration of 'XENBUS_DEVICE' was here
Scott Duplichan [Tue, 18 Nov 2014 02:38:20 +0000 (02:38 +0000)]
BaseTools: Modify gcc 4.8 and 4.9 tool chain definition to support building from Windows.
Here is a new patch that adds Windows support for both gcc 4.8.x and gcc 4.9.x.
This time testing is more thorough: boot testing using Duet for all 4 combinations of
IA32/X64 and gcc 4.8.2 and gcc 4.9.1 passes. A Windows hosted gcc 4.8.2 has been added here:
http://sourceforge.net/projects/edk2developertoolsforwindows/
The environment variable settings for Windows look like:
set UEFI_BUILD_TOOLS=%cd%\tools
set NASM_PREFIX=%UEFI_BUILD_TOOLS%\nasm211\
set GCC48_BIN=%UEFI_BUILD_TOOLS%\gcc482-x86\bin\
set GCC48_DLL=%UEFI_BUILD_TOOLS%\gcc482-x86\dll\;%GCC48_BIN%
set GCC48_ARM_PREFIX=%UEFI_BUILD_TOOLS%\gcc482-arm\bin\
set GCC48_AARCH64_PREFIX=%UEFI_BUILD_TOOLS%\gcc482-aarch64\bin\
set GCC49_BIN=%UEFI_BUILD_TOOLS%\gcc491-x86\bin\
set GCC49_DLL=%UEFI_BUILD_TOOLS%\gcc491-x86\dll\;%GCC49_BIN%
set GCC49_ARM_PREFIX=%UEFI_BUILD_TOOLS%\gcc491-arm\bin\
set GCC49_AARCH64_PREFIX=%UEFI_BUILD_TOOLS%\gcc491-aarch64\bin\
Gabriel Somlo [Mon, 17 Nov 2014 19:09:12 +0000 (19:09 +0000)]
OvmfPkg: PlatformBdsLib: Dynamic PCI Interrupt Line register setup
Remove hard-coded list of PCI devices for which the Interrupt Line
register is initialized. Instead, provide a "visitor" function to
initialize the register only for present and applicable PCI devices.
At this time, we match the behavior of SeaBIOS (file src/fw/pciinit.c,
functions *_pci_slot_get_irq() and "map the interrupt" block from
pci_bios_init_device()).
Laszlo Ersek [Fri, 14 Nov 2014 13:47:14 +0000 (13:47 +0000)]
SecurityPkg: VariableServiceSetVariable(): fix dbt <-> GUID association
SVN r16380 ("UEFI 2.4 X509 Certificate Hash and RFC3161 Timestamp
Verification support for Secure Boot") broke the "dbt" variable's
association with its expected namespace GUID.
According to "MdePkg/Include/Guid/ImageAuthentication.h", *all* of the
"db", "dbx", and "dbt" (== EFI_IMAGE_SECURITY_DATABASE2) variables have
their special meanings in the EFI_IMAGE_SECURITY_DATABASE_GUID namespace.
However, the above commit introduced the following expression in
VariableServiceSetVariable():
which is incorrect, because this way "dbt" will match outside of the
intended namespace / GUID.
The error was caught by gcc:
> SecurityPkg/VariableAuthenticated/RuntimeDxe/Variable.c: In function
> 'VariableServiceSetVariable':
>
> SecurityPkg/VariableAuthenticated/RuntimeDxe/Variable.c:3188:71: error:
> suggest parentheses around '&&' within '||' [-Werror=parentheses]
>
> } else if (CompareGuid (VendorGuid, &gEfiImageSecurityDatabaseGuid) &&
> ^
> cc1: all warnings being treated as errors
Laszlo Ersek [Fri, 14 Nov 2014 10:24:33 +0000 (10:24 +0000)]
CryptoPkg: OpenSslSupport.h: edk2-ize offsetof() macro for gcc-4.8 / X64
Code added in SVN r16339 ("CryptoPkg Updates to support RFC3161 timestamp
signature verification.") introduced many new uses of the offsetof()
macro. Since the offsetof() macro in "OpenSslSupport.h" casts a pointer to
an "int", it triggers a large number of
error: cast from pointer to integer of different size
[-Werror=pointer-to-int-cast]
errors when building CryptoPkg with gcc-4.8 for X64.
Remedy this by directing offsetof() to the OFFSET_OF() macro in
"MdePkg/Include/Base.h" (which matches how "OpenSslSupport.h" resolves the
va_*() macros too).
Scott Duplichan [Fri, 14 Nov 2014 10:23:55 +0000 (10:23 +0000)]
OvmfPkg: QemuVideoDxe: the VBE shim needs no 64-bit shifts (VS2010)
The SegmentC local variable has type EFI_PHYSICAL_ADDRESS for (justified)
style reasons. However, the 64-bit bit-shifts that it undergoes result in
intrinsic calls when built with VS2010 for Ia32 / NOOPT.
The concrete value of SegmentC, 0xC0000, and the results of the bitops
that are based on it, are statically computeable. Cast SegmentC to UINT32
before subjecting it to bitwise operations; we can see in advance that
this won't lead to range loss.
Scott Duplichan [Fri, 14 Nov 2014 10:23:43 +0000 (10:23 +0000)]
OvmfPkg: flash driver: drop needlessly wide multiplication (VS2010)
The current types of subexpressions used in QemuFlashPtr() are as follows.
(We also show the types of "larger" subexpressions, according to operator
binding.)
When building with VS2010 for Ia32 / NOOPT, the 64-by-32 bit
multiplication is translated to an intrinsic, which is not allowed in
edk2.
Recognize that "Lba" is always bounded by "mFdBlockCount" (an UINTN) here
-- all callers of QemuFlashPtr() ensure that. In addition, the flash chip
in question is always under 4GB, which is why we can address it at all on
Ia32. Narrow "Lba" to UINTN, without any loss of range.
Laszlo Ersek [Fri, 14 Nov 2014 10:23:33 +0000 (10:23 +0000)]
OvmfPg: flash driver: drop gratuitous 64-by-32 bit divisions (VS2010)
In the InitializeVariableFvHeader() function, all three of "Offset",
"Start" and "BlockSize" have type UINTN. Therefore the (Offset /
BlockSize) and (Start / BlockSize) divisions can be compiled on all
platforms without intrinsics.
"Offset" and "Start" are cast to UINT64 (== EFI_LBA), which leads to
64-by-32 bit divisions on Ia32, breaking the VS2010 / NOOPT / Ia32 build.
The simplest way to fix them is to realize we don't need casts at all.
(The prototypes of QemuFlashEraseBlock() and QemuFlashWrite() are visible
via "QemuFlash.h", and they will easily take our UINTN quotients as
UINT64.)
Suggested-by: Scott Duplichan <scott@notabs.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16383 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek [Fri, 14 Nov 2014 10:23:21 +0000 (10:23 +0000)]
OvmfPg: flash driver: fix type of EFI_SIZE_TO_PAGES argument (VS2010)
The MarkMemoryRangeForRuntimeAccess() function passes the Length parameter
(of type UINT64) to the macro EFI_SIZE_TO_PAGES(). When building for the
Ia32 platform, this violates the interface contract of the macro:
[...] Passing in a parameter that is larger than UINTN may produce
unexpected results.
In addition, it trips up compilation by VS2010 for the Ia32 platform and
the NOOPT target -- it generates calls to intrinsics, which are not
allowed in edk2.
Fix both issues with the following steps:
(1) Demote the Length parameter of MarkMemoryRangeForRuntimeAccess() to
UINTN. Even a UINT32 value is plenty for representing the size of the
flash chip holding the variable store. Length parameter is used in the
following contexts:
- passed to gDS->RemoveMemorySpace() -- takes an UINT64
- passed to gDS->AddMemorySpace() -- ditto
- passed to EFI_SIZE_TO_PAGES() -- requires an UINTN. This also guarantees
that the return type of EFI_SIZE_TO_PAGES() will be UINTN, hence we can
drop the outer cast.
(2) The only caller of MarkMemoryRangeForRuntimeAccess() is
FvbInitialize(). The latter function populates the local Length variable
(passed to MarkMemoryRangeForRuntimeAccess()) from
PcdGet32(PcdOvmfFirmwareFdSize). Therefore we can simply demote the local
variable to UINTN in this function as well.
- There's only one other use of Length in FvbInitialize(): it is passed to
GetFvbInfo(). GetFvbInfo() takes an UINT64, so passing an UINTN is fine.
Suggested-by: Scott Duplichan <scott@notabs.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16382 6f19259b-4bc3-4df7-8a09-765794883524
Qin Long [Fri, 14 Nov 2014 08:41:12 +0000 (08:41 +0000)]
UEFI 2.4 X509 Certificate Hash and RFC3161 Timestamp Verification support for Secure Boot
Main ChangeLogs includes:
1. Introduce the new GUID and structure definitions for certificate hash and timestamp support;
2. Update Image Verification Library to support DBT signature checking;
3. Update the related SecureBoot Configuration Pages;
Merge PciInitialization() and AcpiInitialization() into a single
function, PciAcpiInitialization(), and use a PCD set during PEI to
detect the underlying platform type (PIIX4 or Q35/MCH) and therefore
the addresses of the registers to be initialized.
Add LNK[A-H] routing target initialization for the Q35 platform.
Additionally, initialize PCI_INTERRUPT_LINE registers for the typical
set of PCI devices included by QEMU with the Q35 machine type. The
corresponding PIIX4 initialization of PCI_INTERRUPT_LINE registers is
cleaned up and the list of PIIX4 PCI devices updated to the list
typically included with QEMU.
NOTE: The list of PCI devices for which we initialize PCI_INTERRUPT_LINE
is hard-coded, and, depending on how QEMU devices are configured on
the command line, may miss some devices, or (harmlessly) attempt to
initialize devices which are not present in the system. A subsequent
patch will replace this hard-coded list with a mechanism to correctly
initialize PCI_INTERRUPT_LINE for applicable present PCI devices only.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16379 6f19259b-4bc3-4df7-8a09-765794883524
Gabriel Somlo [Fri, 14 Nov 2014 00:38:53 +0000 (00:38 +0000)]
OvmfPkg: AcpiTimerLib: Switch additional stages to PCD-based Dxe instance
Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against
a valid, non-asserting version of PcdLib, then switch them over to using
the "Dxe" instance of AcpiTimerLib (instead of the "Base" version).
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16378 6f19259b-4bc3-4df7-8a09-765794883524
Gabriel Somlo [Fri, 14 Nov 2014 00:38:35 +0000 (00:38 +0000)]
OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM
Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may
utilize global variables, use the "Base" AcpiTimerLib instance
(instead of BaseRom) to take advantage of the improved efficiency
of storing the timer register IO address in a global variable.
This leaves only SEC using the BaseRomAcpiTimerLib instance.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16377 6f19259b-4bc3-4df7-8a09-765794883524
Gabriel Somlo [Fri, 14 Nov 2014 00:38:17 +0000 (00:38 +0000)]
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
Gabriel Somlo [Fri, 14 Nov 2014 00:37:39 +0000 (00:37 +0000)]
OvmfPkg: Add PCD for Host Bridge dev. ID (PcdOvmfHostBridgePciDevId)
Set from PEI, this PCD allows subsequent stages (specifically
DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform
type (e.g. PIIX4 or Q35/MCH) without the need to further query the
Host Bridge for its Device ID.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16374 6f19259b-4bc3-4df7-8a09-765794883524
Jordan Justen [Thu, 13 Nov 2014 18:30:09 +0000 (18:30 +0000)]
UefiCpuPkg/CpuDxe: Startup APs
This sequence should happen:
* CpuMp.c: Allocate a stack for the APs
* ApStartup.c: Send Start IPI to wake APs in 16-bit real mode
* MpAsm.S: AP enters CpuDxe driver code without stack
- AP grabs a lock
- AP sets up stack
- AP calls CpuMp.c:ApEntryPointInC
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16370 6f19259b-4bc3-4df7-8a09-765794883524
Chen Fan [Thu, 13 Nov 2014 18:29:13 +0000 (18:29 +0000)]
UefiCpuPkg/CpuDxe: introduce ResetApStackless()
If timeout expires before AP returns from Procedure, the AP should
be terminated, we introduce ResetApStackLess() to send init IPI
to let AP exit Procedurce and re-available.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16366 6f19259b-4bc3-4df7-8a09-765794883524
projects / mirror_edk2.git / log