Scott Duplichan [Fri, 10 Apr 2015 02:41:36 +0000 (02:41 +0000)]
CorebootPayloadPkg: Add NOOPT build to accommodate source level debugging
Add NOOPT build to accommodate source level debugging. The NOOPT build
avoids the use of compiler optimization so that every local variable is
accessible by a source level debugger.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17149 6f19259b-4bc3-4df7-8a09-765794883524
Scott Duplichan [Fri, 10 Apr 2015 02:41:01 +0000 (02:41 +0000)]
CorebootModulePkg: Change CbParseAcpiTable prototype to avoid gcc fail
Use of void** as a generic pointer to pointer is a Microsoft extension
to the C language and is not supported by gcc. Without this change, gcc
compile fails with error:
passing argument 1 of 'CbParseAcpiTable' from incompatible pointer type
note: expected 'void **' but argument is of type
'struct EFI_ACPI_3_0_ROOT_SYSTEM_DESCRIPTION_POINTER **'
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Maurice Ma <maurice.ma@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17144 6f19259b-4bc3-4df7-8a09-765794883524
Scott Duplichan [Fri, 10 Apr 2015 02:05:48 +0000 (02:05 +0000)]
CorebootModulePkg: Fix build failure with 32-bit NOOPT target
Fix build failure with 32-bit NOOPT target by replacing direct shift
of 64-bit integer with a function call. Otherwise Microsoft tool chains
will generate a call to function __allshl and fail to link.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Maurice Ma <maurice.ma@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17142 6f19259b-4bc3-4df7-8a09-765794883524
Elvin Li [Fri, 10 Apr 2015 01:37:41 +0000 (01:37 +0000)]
MdeModulePkg: Roll back report status code change in RuntimeDriverSetVirtualAddressMap.
Roll back report status code to original place in RuntimeDriverSetVirtualAddressMap.
Per UEFI spec, the call to SetVirtualAddressMap() must be done with the physical mappings.
We can not assume virtual address could work in SetVirtualAddressMap (), so we can not call
report status code interface with virtual address.
Scott Duplichan [Fri, 10 Apr 2015 00:42:30 +0000 (00:42 +0000)]
CorebootModulePkg: Add EFIAPI to OnReadyToBoot to fix gcc compile fail
Make OnReadyToBoot function match the prototype in UefiLib.h. The change
only affects gcc builds because EFIAPI ABI differs from the default ABI
when building with gcc.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17137 6f19259b-4bc3-4df7-8a09-765794883524
Scott Duplichan [Thu, 9 Apr 2015 03:09:17 +0000 (03:09 +0000)]
UefiCpuPkg: Avoid "error A2085" when DDK3790 tool chain is used
The DDK3790 tool chain fails when the PAUSE instruction is assembled:
error A2085: instruction or register not accepted in current CPU mode The solution is to use the .686 directive along with the .xmm directive.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17134 6f19259b-4bc3-4df7-8a09-765794883524
Tapan Shah [Tue, 7 Apr 2015 20:39:22 +0000 (20:39 +0000)]
ShellPkg: fix mv and cp command related issues
1.mv deletes file/directory when trying to move it to non-existing file system.
2.mv causes RSOD in system when trying to move same file at the same location.
3.Refactor mv and cp command with command name passed-in.
remove redundant move status error message when file failed to move across file system.
ShellPkg: UefiShellDebug1CommandsLib: fix hex string parsing in SETVAR
The ShellCommandRunSetVar() function calls the ShellIsHexOrDecimalNumber()
UefiShellLib function to determine if the data string in the SETVAR
command is a string of hexadecimal bytes.
However, ShellIsHexOrDecimalNumber() calls ShellConvertStringToUint64()
for validation. Therefore SETVAR rejects hex strings that cannot be
interpreted as UINT64 values due to range errors, despite the fact that
the hexadecimal data string of the SETVAR command is supposed to describe
an arbitrary array of bytes, rather than UINT64 values.
The internal library function InternalShellIsHexOrDecimalNumber() comes
close, as the first idea for the fix, however it is not quite right
either; it removes a leading minus sign, plus it allows 0x / 0X prefixes.
This would not be correct for the SETVAR command.
Instead, add a trivial utility function that is specific to the SETVAR
implementation. IsStringOfHexNibbles() accepts empty strings for
simplicity, but where we call it we have already ensured that the data
string is not empty (because that is handled earlier by the "delete
variable" branch of SETVAR). An even number of nibbles is also enforced
near the call site.
Elvin Li [Tue, 7 Apr 2015 03:33:07 +0000 (03:33 +0000)]
IntelFrameworkModulePkg: Put report status code after event was signaled per PI spec.
For PI spec vol3,
"EFI_SW_DXE_BS_PC_LEGACY_BOOT_EVENT The event with GUID EFI_EVENT_LEGACY_BOOT_GUID was signaled."
"EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT The EFI_EVENT_GROUP_READY_TO_BOOT event was signaled."
However, in current code base, they are reported before events were signaled.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Elvin Li <elvin.li@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17124 6f19259b-4bc3-4df7-8a09-765794883524
Elvin Li [Tue, 7 Apr 2015 03:31:17 +0000 (03:31 +0000)]
MdeModulePkg: Put report status code after event was signaled per PI spec.
For PI spec vol3,
"EFI_SW_DXE_BS_PC_VIRTUAL_ADDRESS_CHANGE_EVENT The EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event was signaled."
However, in current code base, it is reported before events were signaled.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Elvin Li <elvin.li@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17123 6f19259b-4bc3-4df7-8a09-765794883524
Copy below two library instances from IntelFrameworkModulePkg to MdeModulePkg. Then, Platform dsc can
refer to them from MdeModulePkg, and remove the dependency of IntelFrameworkModulePkg. The ones in
IntelFrameworkModulePkg are still kept for compatibility.
1. PeiDxeDebugLibReportStatusCode
2. LzmaCustomDecompressLib
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: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17112 6f19259b-4bc3-4df7-8a09-765794883524
Ronald Cron [Thu, 2 Apr 2015 13:49:05 +0000 (13:49 +0000)]
EmbeddedPkg/Lan9118Dxe: Fix the reset after a receiver or transmitter error
The Lan9118 driver did not recover after a receiver error as the error
handling code stopped the transmitter but did not restart it. Added the
restart of the transmitter.
Added also the restart of the receiver after a transmitter error and
the reactivation of the LEDs after all resets.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <ronald.cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17106 6f19259b-4bc3-4df7-8a09-765794883524
Felix Polyudov [Thu, 2 Apr 2015 06:40:02 +0000 (06:40 +0000)]
MdePkg: Missing GUID variable in DiskInfo.h
The DiskInfo.h defines EFI_DISK_INFO_NVME_INTERFACE_GUID, but does not declare a corresponding EFI_GUID variable.
The attached patch adds "extern" statement for the variable in DiskInfo.h. It also adds variable definition to MdePkg.dec.
Jeff Fan [Wed, 1 Apr 2015 07:51:15 +0000 (07:51 +0000)]
SourceLevelDebugPkg: Use CPU Local APIC timer to handle timeout.
Use CPU Local APIC timer to handle timeout when read data from debug port, instead of the TimerLib in Debug Communication lib instances.
It could remove much duplicated code in Debug Communication Lib instances.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17089 6f19259b-4bc3-4df7-8a09-765794883524
Liming Gao [Tue, 31 Mar 2015 08:24:58 +0000 (08:24 +0000)]
MdeModulePkg: Remove unused internal structure in PeiCore
PeiCore calls REPORT_STATUS_CODE_WITH_EXTENDED_DATA() with its internal structure for Image
dispatcher. No code consumes it. But, it brings confuse.
DxeCore and SmmCore calls REPORT_STATUS_CODE_WITH_EXTENDED_DATA() with Handle only.
To be consistent, update PeiCore to be same to DxeCore and SmmCore.
Maurice Ma [Tue, 31 Mar 2015 01:06:23 +0000 (01:06 +0000)]
Pkg-Module: CorebootModulePkg
Initial coreboot UEFI payload code check in. It provides UEFI services on top of coreboot that allows UEFI OS boot.
CorebootModulePkg is the source code package of coreboot support modules that will be used to parse the coreboot tables and report memory/io resources.
It supports the following features:
- Support Unified Extensible Firmware Interface (UEFI) specification 2.4.
- Support Platform Initialization(PI) specification 1.3.
- Support execution as a coreboot payload.
- Support USB 3.0
- Support SATA/ATA devices.
- Support EFI aware OS boot.
The following features are not supported currently and have not been validated:
- GCC Tool Chains
- SMM Execution Environment
- Security Boot
It was tested on a Intel Bay Trail CRB platform.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17084 6f19259b-4bc3-4df7-8a09-765794883524
Maurice Ma [Tue, 31 Mar 2015 01:03:03 +0000 (01:03 +0000)]
Pkg-Module: CorebootModulePkg
Initial coreboot UEFI payload code check in. It provides UEFI services on top of coreboot that allows UEFI OS boot.
CorebootModulePkg is the source code package of coreboot support modules that will be used to parse the coreboot tables and report memory/io resources.
It supports the following features:
- Support Unified Extensible Firmware Interface (UEFI) specification 2.4.
- Support Platform Initialization(PI) specification 1.3.
- Support execution as a coreboot payload.
- Support USB 3.0
- Support SATA/ATA devices.
- Support EFI aware OS boot.
The following features are not supported currently and have not been validated:
- GCC Tool Chains
- SMM Execution Environment
- Security Boot
It was tested on a Intel Bay Trail CRB platform.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17082 6f19259b-4bc3-4df7-8a09-765794883524
Maurice Ma [Tue, 31 Mar 2015 00:56:01 +0000 (00:56 +0000)]
Pkg-Module: CorebootPayloadPkg
Initial coreboot UEFI payload code check in. It provides UEFI services on top of coreboot that allows UEFI OS boot.
CorebootPayloadPkg is source code package of coreboot Payload Modules, Provides definitions of payload image's layout and lists the modules required in DSC file.
It supports the following features:
- Support Unified Extensible Firmware Interface (UEFI) specification 2.4.
- Support Platform Initialization(PI) specification 1.3.
- Support execution as a coreboot payload.
- Support USB 3.0
- Support SATA/ATA devices.
- Support EFI aware OS boot.
The following features are not supported currently and have not been validated:
- GCC Tool Chains
- SMM Execution Environment
- Security Boot
It was tested on a Intel Bay Trail CRB platform.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17081 6f19259b-4bc3-4df7-8a09-765794883524
Ard Biesheuvel [Fri, 27 Mar 2015 21:25:16 +0000 (21:25 +0000)]
OvmfPkg: XenConsoleSerialPortLib: deal with output overflow
It is the responsibility of the SerialPortLib implementation
to deal with flow control if the underlying medium cannot keep
up with the inflow of data.
So in our SerialPortWrite () function, we should spin as long
as we need to in order to deliver all the data instead of giving
up and returning a smaller value than the number of bytes we were
given. Also, remove the 'if (Sent > 0)' condition on the signalling
of the event channel: if the buffer is full and we haven't been able
to add any more data, it makes perfect sense to signal the event
channel again, even if we have done so before when we did write
the data.
Also, this patch brings the implementation of XenSerialPortLib
in sync with the library class documentation.
Ard Biesheuvel [Fri, 27 Mar 2015 17:27:14 +0000 (17:27 +0000)]
MdePkg: fix ARM version of InternalMathSwapBytes64 ()
The ARM asm implementation of InternalMathSwapBytes64 () does
interesting things if bit 7 of operand r1 (upper 32 bits of the
input value) is set. After the recursive swap, bit 7 ends up in
the sign bit position, after which it is right shifted with sign
extension, and or'ed with the upper half of the output value.
This means SwapBytes64 (0x00000080_00000000) returns an incorrect
value of 0xFFFFFFFF_80000000.
Gabriel Somlo [Thu, 26 Mar 2015 19:06:07 +0000 (19:06 +0000)]
OvmfPkg: Q35: Use correct ACPI PM control register:bit
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Fu Siyuan [Thu, 26 Mar 2015 04:49:30 +0000 (04:49 +0000)]
PXE driver bug fix.
1. Update the parameter check of PXE.UdpRead() to align with spec definition.
2. Update PXE driver to use EFI_PXE_BASE_CODE_UDP_OPFLAGS_ANY_DEST_IP when calling UdpRead to receive server discovery message.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17075 6f19259b-4bc3-4df7-8a09-765794883524
Brian J. Johnson [Wed, 25 Mar 2015 01:51:23 +0000 (01:51 +0000)]
PeCoffExtraActionLibDebug: Restore debug registers in PeCoffExtraActionLibDebug
PeCoffExtraActionLibDebug uses the debug registers to pass module load information to the
DebugAgent, then restores the old register values.
However, it was missing code to restore Dr7 in the
DEBUG_LOAD_IMAGE_METHOD_SOFT_INT3 case. This broke hardware breakpoints and watchpoints.
It could also lose modifications the debugger made to Cr4.
Restore the Dr7 and Cr4 values correctly in the
DEBUG_LOAD_IMAGE_METHOD_SOFT_INT3 case, as well as the
DEBUG_LOAD_IMAGE_METHOD_IO_HW_BREAKPOINT case.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brian J. Johnson <bjohnson@sgi.com> Reviewed-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@17071 6f19259b-4bc3-4df7-8a09-765794883524
Cinnamon Shia [Mon, 23 Mar 2015 05:39:51 +0000 (05:39 +0000)]
NT32Pkg: Fix build errors from building secure boot with NT32 X64
Root cause: The CryptoPkg\Library\IntrinsicLib needs override MSFT build option to remove /Oi and /GL,
but it doesn’t work because of the build option override in Nt32Pkg.dsc.
Solution: Remove /X in BaseTools/Conf/tools_def.template
Laszlo Ersek [Mon, 16 Mar 2015 19:57:34 +0000 (19:57 +0000)]
OvmfPkg: include XHCI driver
QEMU commit aa685789 ("xhci: generate a Transfer Event for each Transfer
TRB with the IOC bit set") fixed an emulation problem in QEMU; we can now
drive that host controller with edk2's XhciDxe. Include it in OvmfPkg, as
XHCI emulation is reportedly more virtualization-friendly than EHCI,
consuming less CPU.
The driver can be tested with the following QEMU command line options:
-device nec-usb-xhci -device usb-kbd
This patch should not regress existing QEMU command lines (ie. trigger an
ASSERT() in XhciDxe that fails on pre-aa685789 QEMU) because QEMU's
"-device nec-usb-xhci" has never before resulted in USB devices that
worked with edk2 firmware builds, hence users have never had a reason to
add that option.
Now that they learn about XHCI support in OVMF by reading this commit
message, they (or their packagers) will also know to update qemu to aa685789 or later (in practice that means the upcoming 2.3 release), at
least if they want to use '-device nec-usb-xhci' with edk2, for the first
time ever.
Laszlo Ersek [Mon, 16 Mar 2015 19:57:06 +0000 (19:57 +0000)]
ArmVirtualizationPkg/ArmVirtualizationQemu: include XHCI driver
The "virt" machine type of qemu-system-(arm|aarch64) had no PCIe support
prior to qemu commit
4ab29b82 arm: Add PCIe host bridge in virt machine
With that commit, the "virt" board acquired the capability to expose an
XHCI controller. Using a USB keyboard as example, the command line options
were
-device nec-usb-xhci -device usb-kbd
However, due to a slight XHCI emulation bug in QEMU -- dating back to
several years earlier -- edk2's XHCI driver would encounter a failed
ASSERT().
This emulation problem has been fixed in QEMU commit
aa685789 xhci: generate a Transfer Event for each Transfer TRB with the
IOC bit set
and now edk2's XHCI driver works well on QEMU's "nec-usb-xhci" device.
Let's enable the driver in ArmVirtualizationQemu, as XHCI emulation is
reportedly more virtualization-friendly than EHCI, consuming less CPU.
(ArmVirtualizationXen is not modified because it includes no USB-related
drivers at all.)
This patch should not regress existing QEMU command lines (ie. expose the
failed ASSERT()) because QEMU's "-device nec-usb-xhci" has never before
resulted in USB devices that worked with edk2 firmware builds, hence users
have never had a reason to add that option.
Now that they learn about XHCI support in ArmVirtualizationQemu by reading
this commit message, they (or their packagers) will also know to update
qemu to aa685789 or later (in practice that means the upcoming 2.3
release), at least if they want to use '-device nec-usb-xhci' with edk2,
for the first time ever.
Laszlo Ersek [Mon, 16 Mar 2015 19:56:54 +0000 (19:56 +0000)]
ArmVirtualizationPkg: build UEFI shell from source
Including a prebuilt shell executable in the firmware binary is suboptimal
practice, especially given that the source code of the UEFI shell resides
in the same edk2 tree. Benefits of building the shell from source are
partly technical (a developer patching the shell can actually see the
results), partly ideological (the nominally built-from-source firmware is
actually built from source). "Security" might be worth a mention too.
The stanza for the [Components.common] section of
"ArmVirtualization.dsc.inc" originates from under OvmfPkg.
Elvin Li [Mon, 16 Mar 2015 02:41:48 +0000 (02:41 +0000)]
MdeModulePkg: Add SMBIOS 64-bit support for SMBIOS 3.0.
Add SMBIOS 64-bit entry point and 64-bit table support for SMBIOS 3.0.
Introduce PcdSmbiosEntryPointProvideMethod to produce 32-bit or 64-bit
SMBIOS table.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Elvin Li <elvin.li@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17051 6f19259b-4bc3-4df7-8a09-765794883524