Laszlo Ersek [Fri, 18 Mar 2016 18:52:46 +0000 (19:52 +0100)]
IntelFrameworkModulePkg: LegacyBootMaintUiLib: remove set but unused variables
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Laszlo Ersek [Fri, 18 Mar 2016 18:51:28 +0000 (19:51 +0100)]
IntelFrameworkModulePkg: DxeCapsuleLib: remove set but unused variables
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Laszlo Ersek [Fri, 18 Mar 2016 18:50:08 +0000 (19:50 +0100)]
IntelFrameworkModulePkg: BiosVideo: remove set but unused variable
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Laszlo Ersek [Fri, 18 Mar 2016 18:41:34 +0000 (19:41 +0100)]
EmulatorPkg: CpuRuntimeDxe: remove set but unused variables
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Laszlo Ersek [Thu, 24 Mar 2016 09:48:21 +0000 (10:48 +0100)]
CorebootPayloadPkg: PlatformBdsLib: remove set but unused variables
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Prince Agyeman <prince.agyeman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Laszlo Ersek [Thu, 24 Mar 2016 09:47:03 +0000 (10:47 +0100)]
CorebootPayloadPkg: FbGop: remove set but unused variables
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Prince Agyeman <prince.agyeman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
This retypes some stack base PCD as 64-bit, and fixes up a number of references
to 64-bit PCDs (including the retypes ones), to use the correct PcdGet64()
accessors. Note that, in the case of FixedPcdGet64, this does not actually
caused any problems, since that resolves to an immediate value. But the
generic PcdGetxx accessors should be typed according to the size of the PCD.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leo Duran <leo.duran@amd.com>
[ard.biesheuvel: fixed up some instances in the 32-bit ARM code] Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Zhang Lubo [Thu, 24 Mar 2016 08:59:22 +0000 (16:59 +0800)]
NetworkPkg:Fix Http boot download issue.
When http boot download the second time without return
out of the boot manager, the DHCP process will start twice
with the same Boot file uri and print the information twice
which we not expected. This is caused by wrong logic
of handling the device path of the boot file when loading it.
Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo <lubo.zhang@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Gary Lin [Mon, 21 Mar 2016 09:04:36 +0000 (17:04 +0800)]
SecurityPkg/SecureBootConfigDxe: Declare EFIAPI for the ChooseFile handlers
The SecureBootConfig now uses ChooseFile() from FileExplorerLib
to select the certificates to be enrolled into PK, KEK, DB, DBX,
or DBT, and the corresponding handlers to get the content of the
file. Per the definition of CHOOSE_HANDLER, the handler must use
EFIAPI as the calling convention. However, the calling convention
was not specified the following handlers: UpdatePKFromFile(),
UpdateKEKFromFile(), UpdateDBFromFile(), UpdateDBXFromFile(), and
UpdateDBTFromFile(). When compiling the firmware with gcc, the
default calling convention is not compatible with EFIAPI, so the
handlers interpreted the argument the wrong way and passed the
wrong device path to UpdatePage(), and the system crashed when
the user tried to enroll a certificate into the key database.
This commit specifies the calling convention for those functions
so that gcc can generate the right code.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Ard Biesheuvel [Thu, 24 Mar 2016 06:15:45 +0000 (07:15 +0100)]
ShellPkg/UefiShellDebug1CommandsLib: remove unused but set variable
Remove variable FStartRow that is declared, assigned but never referenced.
This fixes a warning emitted by GCC when -Wunused-but-set-variable is in
effect.
Ruiyu Ni [Wed, 23 Mar 2016 05:54:51 +0000 (13:54 +0800)]
MdeModulePkg/PciBus: Should reserve enough bus number for HPC
When there is no bridge before the HPC (hot plug controller),
the issue cannot be seen.
But when there are bridges before the HPC, the PciBus will only
use the value (= <CurrentBusNumber> + <ReservedBusNumber>) as the
sub-ordinary bus number for HPC.
The correct sub-ordinary bus number should be:
<CurrentBusNumber> + <OccupiedBusNumber>(by earlier bridges) +
<ReservedBusNumber>.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Tapan Shah [Fri, 18 Mar 2016 16:28:03 +0000 (11:28 -0500)]
ShellPkg: Modify the 'dh' Shell command to dump the Firmware Management Protocol Image Descriptor Information.
Modify 'dh' shell command to dump FirmwareManagement Protocol information.
Add FirmwareManagement image descriptor V1 and V2 structure definition in UefiHandleParsingLib.h to support decoding V1/V2 revisions.
Marvin Häuser [Tue, 22 Mar 2016 14:53:08 +0000 (14:53 +0000)]
MdePkg: Move SMBIOS data into the IndustryStandard header.
As the SMBIOS table types belong to the SMBIOS standard, they were
moved from the SMBIOS Protocol header into the SMBIOS
IndustryStandard header without the EFI_-prefix. Defines with the
EFI_-prefix have been kept in the Protocol header for
backwards-compatibility, resolving to the IndustryStandard defines.
The same has been done with the C types.
The SMBIOS table header structure had been duplicated -
SMBIOS_STRUCTURE in the IndustryStandard header and
EFI_SMBIOS_TABLE_HEADER in the Protocol file - and thus the
Protocol type was replaced with a typedef to the InudstryStandard's.
This doesn't only make it easier to maintain, but it also prevents
potential future issues as the Protocol type has been aligned, while
the standard and the IndustryStandard header declare it as
byte-packed.
This has worked well till now only because the members of the
structure do not require alignment yet.
Fu Siyuan [Thu, 17 Mar 2016 01:27:07 +0000 (09:27 +0800)]
NetworkPkg: Fix HII related problem in HTTP boot driver.
According to UEFI spec, HII_Config_Access.RouteConfig() should return success
if the required configuration has been processed. Current HTTP boot driver
may return error code in some situation, which failed the UEFI SCT test.
This patch fix this issue by removing the returned error status code and adding
extra check point in the Callback() function, which will pop up a message box
if user input an unsupported URI string.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Dong Eric <eric.dong@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Dandan Bi [Tue, 22 Mar 2016 07:37:54 +0000 (15:37 +0800)]
MdeModulePkg/FileExplorerLib.h: Remove the redefinition of typedefs
Xcode clang seems unhappy with both FileExplorerLib.h and
Protocol/FileExplorer.h both defining CHOOSE_HANDLER, now
remove the definition in FileExplorerLib.h.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Andrew Fish <afish@apple.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Laszlo Ersek [Fri, 4 Mar 2016 18:30:45 +0000 (19:30 +0100)]
OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXE
The main observation about the 64-bit PCI host aperture is that it is the
highest part of the useful address space. It impacts the top of the GCD
memory space map, and, consequently, our maximum address width calculation
for the CPU HOB too.
Thus, modify the GetFirstNonAddress() function to consider the following
areas above the high RAM, while calculating the first non-address (i.e.,
the highest inclusive address, plus one):
- the memory hotplug area (optional, the size comes from QEMU),
- the 64-bit PCI host aperture (we set a default size).
While computing the first non-address, capture the base and the size of
the 64-bit PCI host aperture at once in PCDs, since they are natural parts
of the calculation.
(Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path
(see the InitializePlatform() -> MemMapInitialization() condition), nor
are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them,
through our PciHostBridgeLib instance.)
Set 32GB as the default size for the aperture. Issue#59 mentions the
NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these
cards may have 24GB of memory (probably 16GB + 8GB BARs).
As a strictly experimental feature, the user can specify the size of the
aperture (in MB) as well, with the QEMU option
-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536
The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning
that the property is experimental, unstable, and might go away any time.
Gerd has proposed heuristics for sizing the aperture automatically (based
on 1GB page support and PCPU address width), but such should be delayed to
a later patch (which may very well back out "X-PciMmio64Mb" then).
For "everyday" guests, the 32GB default for the aperture size shouldn't
impact the PEI memory demand (the size of the page tables that the DXE IPL
PEIM builds). Namely, we've never reported narrower than 36-bit addresses;
the DXE IPL PEIM has always built page tables for 64GB at least.
For the aperture to bump the address width above 36 bits, either the guest
must have quite a bit of memory itself (in which case the additional PEI
memory demand shouldn't matter), or the user must specify a large aperture
manually with "X-PciMmio64Mb" (and then he or she is also responsible for
giving enough RAM to the VM, to satisfy the PEI memory demand).
Laszlo Ersek [Fri, 4 Mar 2016 16:23:35 +0000 (17:23 +0100)]
OvmfPkg: PlatformPei: factor out GetFirstNonAddress()
Factor out the expression that is currently the basis of the address width
calculation into a standalone function. In the next patches we'll raise
the return value under certain circumstances.
Laszlo Ersek [Sun, 13 Mar 2016 14:34:07 +0000 (15:34 +0100)]
OvmfPkg: AcpiPlatformDxe: enable PCI IO and MMIO while fetching QEMU tables
Now that the previous patches ensure that we can access all PCI devices in
AcpiPlatformDxe, we can enable IO and MMIO decoding for all of them while
we contact QEMU for the ACPI tables. See more details in the patch titled:
In particular, this patch will prevent the bug when the 64-bit MMIO
aperture is completely missing from QEMU's _CRS, and consequently Linux
rejects 64-bit BARs with the error message
pci 0000:00:03.0: can't claim BAR 4 [mem 0x800000000-0x8007fffff 64bit
pref]: no compatible bridge window
Laszlo Ersek [Sun, 13 Mar 2016 17:09:57 +0000 (18:09 +0100)]
OvmfPkg: AcpiPlatformDxe: when PCI is enabled, wait for Platform BDS's cue
This patch doesn't change the behavior of AcpiPlatformDxe when
PcdPciDisableBusEnumeration is TRUE -- that is, when the driver runs on
Xen (OvmfPkg and ArmVirtPkg both), or when the driver runs on QEMU as part
of ArmVirtPkg but no PCI host bridge was found by VirtFdtDxe. In these
cases the driver continues to install the ACPI tables immediately.
However, when PcdPciDisableBusEnumeration is FALSE (i.e., when the driver
runs on QEMU as part of OVMF, or as part of ArmVirtPkg and VirtFdtDxe
finds a PCI host bridge), we now delay the ACPI table download from QEMU.
We wait until the Platform BDS tells us that root bridges have been
connected, and PciIo instances are available.
QEMU's ACPI table generator can only create meaningful _CRS objects --
apertures -- for the root buses if all of the PCI devices behind those
buses are actively decoding their IO and MMIO resources, at the time of
the firmware fetching the "etc/table-loader" fw_cfg file. This is not a
QEMU error; QEMU follows the definition of BARs (which are meaningless
when decoding is disabled).
Currently we hook up AcpiPlatformDxe to the PCI Bus driver's
gEfiPciEnumerationCompleteProtocolGuid cue. Unfortunately, when the PCI
Bus driver installs this protocol, it's *still* not the right time for
fetching "etc/table-loader": although resources have been allocated and
BARs have been programmed with them, the PCI Bus driver has also cleared
IO and MMIO decoding in the command registers of the devices.
Furthermore, we couldn't reenable IO and MMIO decoding temporarily in our
gEfiPciEnumerationCompleteProtocolGuid callback even if we wanted to,
because at that time the PCI Bus driver has not produced PciIo instances
yet.
Our Platform BDSes are responsible for connecting the root bridges, hence
they know exactly when the PciIo instances become available -- not when
PCI enumeration completes (signaled by the above protocol), but when the
ConnectController() calls return.
This is when our Platform BDSes should explicitly cue in AcpiPlatformDxe.
Then AcpiPlatformDxe can temporarily enable IO and MMIO decoding for all
devices, while it contacts QEMU for the ACPI payload.
This patch introduces the event group GUID that we'll use for unleashing
AcpiPlatformDxe from our Platform BDSes.
This patch follows the implementation seen in MdePkg's UefiLib instance,
so that FrameworkUefiLib also covers the UefiLib.h library class header
completely.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Tue, 22 Mar 2016 16:01:22 +0000 (17:01 +0100)]
IntelFrameworkPkg/FrameworkUefiLib: move InternalEmptyFunction to UefiLib.c
The InternalEmptyFunction() is currently only used by code in
"UefiNotTiano.c" -- "Library functions that abstract areas of conflict
between framework and UEFI 2.0.". In the next patches,
InternalEmptyFunction() will be used from "UefiLib.c" as well, hence
promote it to "general utility" status: move the function definition to
"UefiLib.c", and place the function declaration (which is already extern)
into "UefiLibInternal.h".
Fix a typo in the function's name while at it.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Tue, 22 Mar 2016 16:07:14 +0000 (17:07 +0100)]
MdePkg/UefiLib: introduce EfiEventGroupSignal
This is a small convenience function that eases signaling an event group
(identified by GUID). An example where it can be used is Platform BDS
signaling the End-of-DXE event group.
The naming follows EfiNamedEventSignal().
The patch modifies the library class header, and updates the most commonly
used library instance at once. Other library instances in the edk2 tree
will be adapted in the following patches.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Tue, 22 Mar 2016 16:01:22 +0000 (17:01 +0100)]
MdePkg/UefiLib: move InternalEmptyFunction to UefiLib.c
The InternalEmptyFunction() is currently only used by code in
"UefiNotTiano.c" -- "Library functions that abstract areas of conflict
between framework and UEFI 2.0.". In the next patches,
InternalEmptyFunction() will be used from "UefiLib.c" as well, hence
promote it to "general utility" status: move the function definition to
"UefiLib.c", and place the function declaration (which is already extern)
into "UefiLibInternal.h".
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Yonghong Zhu [Wed, 23 Mar 2016 06:54:36 +0000 (14:54 +0800)]
BaseTools: not include the undefined macro in response file
In last Nmake patch, when we generate the response file, we would replace
all the Macros in the make file. Once there have undefined macro used,
the tool direct report error. In this patch, we use following solution to
resolve the failure.
1. Add all the defined macros into AutoGenObject macro dict
2. For the undefined macros which used in the Make file, when we generate
the response file, we not include this macro, let make phase to handle.
Dandan Bi [Tue, 22 Mar 2016 02:50:23 +0000 (10:50 +0800)]
MdeModulePkg/BootMaintenanceManagerUiLib: Remove type casting in ChooseFile
The type casting is not necessary and now remove it.
Cc: Liming Gao <liming.gao@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Gary Lin <glin@suse.com>
Dandan Bi [Tue, 22 Mar 2016 02:38:01 +0000 (10:38 +0800)]
MdeModulePkg/BootMaintManagerUiLib: Declare EFIAPI for ChooseFile handler
The BootMaintenanceManagerUiLib use ChooseFile() from FileExplorerLib
to select files. And the third parameter in ChooseFile() is CHOOSE_HANDLER,
per the definition of CHOOSE_HANDLER, it must use EFIAPI as the calling
convention. But the calling convention was not specified for following
handlers: CreateBootOptionFromFile, CreateDriverOptionFromFile,
BootFromFile. Now specifies the calling convention for those functions.
Cc: Liming Gao <liming.gao@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Gary Lin <glin@suse.com>
There is no asynchronous operations to the registered RAM disks link list
maintained within RamDiskDxe driver, therefore, the TPL raise and restore
operations when dealing with the link list are unnecessary.
Hao Wu [Tue, 8 Mar 2016 01:35:14 +0000 (09:35 +0800)]
MdeModulePkg RamDiskDxe: Uninstall DEVICE_PATH_PROTOCOL with correct param
Previously, the code uninstalls the DEVICE_PATH_PROTOCOL with the device
path given by caller of the 'RamDiskUnregister' function. The given device
path might be different from the one used to install the
DEVICE_PATH_PROTOCOL.
The 'DisconnectController' function calls after
'UninstallMultipleProtocolInterfaces' are unnecessary, since
'DisconnectController' is called inside function
'UninstallMultipleProtocolInterfaces'.
Ard Biesheuvel [Thu, 17 Mar 2016 13:55:00 +0000 (14:55 +0100)]
ArmPkg/AArch64Mmu: use correct AP[] bits in ArmClearMemoryRegionReadOnly
The function ArmClearMemoryRegionReadOnly() was supposed to undo the
effect of ArmSetMemoryRegionReadOnly(), but instead, it sets the permissions
to EL0-no access, EL1-read-only. Since the EL0 bit should be 1 to align
with EL2/3 (where the bit is SBO), use TT_AP_RW_RW instead, which makes the
entry read-write for EL0 when executing at EL1, and read-write for all other
levels.
This replaces the somewhat opaque preprocessor based stack/unstack macros
with open coded ldp/stp sequences to preserve the interrupted context
before handing over to the exception handler in C.
This removes various arithmetic operations on the stack pointer, and
reduces the exception return critical section to its minimum size (i.e.,
the bare minimum required to populate the ELR and SPSR registers and invoke
the eret).
Ard Biesheuvel [Thu, 17 Mar 2016 10:39:01 +0000 (11:39 +0100)]
ArmPkg/ArmExceptionLib: avoid indirect call if using vector table in place
If we are using the vector table in place, there is no need to make an
indirect call to the common handler routine from the vector table entries,
so just use a straight branch instruction in that case.
Ard Biesheuvel [Thu, 17 Mar 2016 10:33:58 +0000 (11:33 +0100)]
ArmPkg/ArmExceptionLib: make build time define visible to the compiler
The global gArmRelocateVectorTable is a build time constant, but due to
its external linkage and lack of constness, the compiler does not see that.
So turn it into a static boolean, and at the same time, make the function
CopyExceptionHandlers() (which is only called if gArmRelocateVectorTable is
set) static as well, so that the compiler can eliminate it completely if
we are using the vector table in place.
Ard Biesheuvel [Thu, 17 Mar 2016 07:55:39 +0000 (08:55 +0100)]
ArmPkg/ArmExceptionLib: don't restore ESR and FAR upon exception return
ESR and FAR are populated by the hardware upon exception entry, and
describe the exception, not the interrupted context. So there is no point
in restoring their values before returning from the exception.
Ard Biesheuvel [Thu, 17 Mar 2016 07:54:11 +0000 (08:54 +0100)]
ArmPkg/ArmExceptionLib: stack FPSR on common path
We have three code paths to stack/unstack the exception context, one for
each of EL3, EL2 and EL1. However, they all access the same copy of FPSR
so move that access to the common path.
Ard Biesheuvel [Wed, 16 Mar 2016 15:45:39 +0000 (16:45 +0100)]
ArmPkg/ArmExceptionLib: fold exception handler prologue into vector table
Unlike the AArch32 vector table, which has room for a single instruction
for each exception type, the AArch64 exception table has 128 byte slots,
which can easily hold the shared prologues that are emitted out of line.
So refactor this code into a single macro, and expand it into each vector
table slot. Since the address of the command handler entry point is no
longer patched in by the C code, we can just emit the literal into each
vector entry directly.
Ard Biesheuvel [Thu, 17 Mar 2016 08:07:28 +0000 (09:07 +0100)]
ArmPkg/AsmMacroIoLibV8: remove undocumented assumption from ELx macros
The macros EL1_OR_EL2() and EL1_OR_EL2_OR_EL3() allow conditional execution
of assembly sequences based on the current exception level, by jumping to
caller supplied labels 1f, 2f or 3f. However, the jump to 1f is actually
a fallthrough, which means the EL1 code needs to follow right after the
macro invocation, and the 1f label is ignored.
Yonghong Zhu [Wed, 16 Mar 2016 03:06:44 +0000 (11:06 +0800)]
BaseTools: Fix nmake failure due to command-line length limitation
NMAKE is limited to command-line length of 4096 characters. Due to the
large number of /I directives specified on command line (one per include
directory), the path length of WORKSPACE is multiplied by the number of
/I directives and can exceed the limit.
This patch:
1. Add new build option -l, --cmd-len to set the maximum command line
length, default value is 4096.
2. Generate the response file only if the command line length exceed its
maximum characters (default is 4096) when build the module. Cover
PP_FLAGS, CC_FLAGS, VFRPP_FLAGS, APP_FLAGS, ASLPP_FLAGS, ASLCC_FLAGS and
ASM_FLAGS.
3. The content of the response file is combine from the FLAGS option and
INC option.
4. When build failure, it would print out the response file's file
location and its content.
Star Zeng [Fri, 18 Mar 2016 01:52:44 +0000 (09:52 +0800)]
MdeModulePkg DxeCore: Address boundary check for Type AllocateAddress
Check for Type AllocateAddress,
if NumberOfPages is 0 or
if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ADDRESS or
if (Start + NumberOfBytes) rolls over 0 or
if Start is above MAX_ADDRESS or
if End is above MAX_ADDRESS,
return EFI_NOT_FOUND.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Fri, 18 Mar 2016 23:08:47 +0000 (00:08 +0100)]
OvmfPkg/PlatformPei: suppress wrong VS2008 warning (use of uninited local)
VS2008 seems to think that the "PciExBarBase" variable (introduced in
commit 7b8fe63561b4) can be evaluated for the
AddReservedMemoryBaseSizeHob() function call with its value being
uninitialized / indeterminate. This is not the case (see
"mHostBridgeDevId"); suppress the warning.
Reported-by: David Woodhouse <dwmw2@infradead.org>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/8871/focus=9431 Cc: David Woodhouse <dwmw2@infradead.org> 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: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Star Zeng [Thu, 17 Mar 2016 05:31:44 +0000 (13:31 +0800)]
MdeModulePkg PlatformVarCleanupLib: Locate VarCheck protocol when using
Do not locate VarCheck protocol in Constructor, then the
gEdkiiVarCheckProtocolGuid could be removed from [Depex].
It will be more flexible for the library Consumer to work without VarCheck
protocol installed, for example at recovery boot mode with EmuRuntimeDxe.
The unused UefiLib is also been removed from [LibraryClasses] in *.inf.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Ard Biesheuvel [Wed, 16 Mar 2016 14:04:18 +0000 (15:04 +0100)]
Omap35xxPkg: drop CpuExceptionHandlerLib library class resolution
Remove the null resolution for CpuExceptionHandlerLib: this version will
no longer work once we update ARM's CpuDxe to depend on the ARM specific
version. Since this module does not actually rely on it, let's just remove
all mention of it.
Ard Biesheuvel [Wed, 16 Mar 2016 14:03:40 +0000 (15:03 +0100)]
BeagleBoardPkg: move to ARM version of CpuExceptionHandlerLib
Change our resolution for the previously unused CpuExceptionHandlerLib
from the null implementation to the newly added implementation specific
to AARCH64 and ARM. This is needed since our CpuDxe will start using it
in a subsequent patch.
Ard Biesheuvel [Wed, 16 Mar 2016 10:03:55 +0000 (11:03 +0100)]
ArmVirtPkg/ArmVirtQemu: move to ARM version of CpuExceptionHandlerLib
Change our resolution for the previously unused CpuExceptionHandlerLib
from the null implementation to the newly added implementation specific
to AARCH64 and ARM. This is needed since our CpuDxe will start using it
in a subsequent patch.
Cohen, Eugene [Mon, 7 Mar 2016 15:16:35 +0000 (15:16 +0000)]
ArmPkg: ARM/AArch64 implementation of CpuExceptionHandlerLib
Introduce ARM and AArch64 instances of the CpuExceptionHandlerLib which
provides exception handling and registration of handlers regardless of
execution phase.
Two variants of the ArmExceptionLib are provided: one where exception
handlers reside within the module (meeting appropriate architectural
alignment requirements for the vector table) and another one that will
relocate a copy of thee xception handlers to an address specified by
PcdCpuVectorBaseAddress. The ArmRelocateExceptionLib is intended for use
in cases where ArmExceptionLib is too large for the application
(uncompressed XIP images) as driven by the vector table alignment padding.
The AArch64 build of this library supports execution at EL1, EL2, and EL3
exception levels.
Tested on ARM, and AArch64 with SEC, DXE Core, and CpuDxe modules.
ConSplitter's Absolute Pointer should scale virtual device's resolution like what Simple Pointer do.
Before this change, caller will get Virtual device's resolution but physical device's current point.
This change let caller get Virtual device's resolution with virtual device's current point.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Derek Lin <derek.lin2@hpe.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Qiu Shumin [Tue, 8 Mar 2016 02:26:29 +0000 (10:26 +0800)]
ShellPkg: Per UEFI Shell 2.2 SPEC to make Shell supports 'NoNesting'.
This patch makes Shell support -nonesting invocation option. This option
specifies that EFI_SHELL_PROTOCOL.Execute API nesting of a new Shell
instance is optional and dependent on the 'nonesting' Shell environment
variable.
Fu Siyuan [Mon, 14 Mar 2016 02:43:42 +0000 (10:43 +0800)]
NetworkPkg: Fix the driver model issue in HTTP Boot driver.
The HTTP Boot driver have some UEFI driver model problems which will make the
code ASSERT when it's disconnected.
First, the driver opens the HttpSb protocol BY_CHILD without BY_DRIVER attribute.
So the driver binding stop won't be called when HTTP driver is disconnected, so
a child handle is left and made HTTP driver binding stop function goes into error.
This patch remove this unnecessary OpenProtocol and only unload the HII from when
both the IP4 and IP6 stack have been stopped completely.
The second issue is the HTTP boot driver always use the driver's image handle as
it's driver binding handle, it's not correct. HTTP Boot driver provides 2 separate
driver binding protocols from IP4 and IP6 stack, so it has 2 driver binding handle.
So this patch fix the code to use correct driver binding handle when create/open
a HTTP child handle.
Dandan Bi [Tue, 15 Mar 2016 01:44:16 +0000 (09:44 +0800)]
MdeModulePkg/DriverSampleDxe: Uninstall the ConfigAccess protocol
In DriverSampleInit, has installed the configAccess protocol to
the DriverHandle[1], but don't uninstall it in DriverSampleUnload.
Now uninstall the configAccess protocol.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Yonghong Zhu [Thu, 25 Feb 2016 08:13:31 +0000 (16:13 +0800)]
BaseTools: add new command line option to support override PCD value
this patch add new feature to support override PCD value on the command
line. The value from the command line is the highest priority.
1.Add option(--pcd) to support both PcdName and TokenSpaceGuild.PcdName
2.For void* type PCD, use following format:
cstring PCD: --pcd PcdName="string"
unicodestring PCD: --pcd PcdName=L"string"
CArray PCD: --pcd PcdName=B"{0x1, 0x2}"
3.Build Report, use *B to show the PCD value was overridden in the
command line.
4.Error Condition:
Report error if the PCD is not found
Report error if the PcdName is found under multiple different TokenSpaceGuid
Report error if PCD value syntax is incorrect
Report error if void* type PCD value exceed its max size
Ruiyu Ni [Tue, 15 Mar 2016 08:10:40 +0000 (16:10 +0800)]
OvmfPkg/LegacyRegion: Support legacy region manipulation of Q35
Current implementation only supports legacy region of 440 chip.
When QEMU is launched in Q35 mode using CSM enabled OVMF image,
LegacyBios driver fails to start due to the legacy region
[0xC0000, 0xFFFFF] cannot be written.
v2:
* just updates the comments.
v3:
* uses PcdOvmfHostBridgePciDevId as Jordan suggested.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Justen Jordan <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Marvin Haeuser [Sun, 21 Feb 2016 00:46:59 +0000 (08:46 +0800)]
BaseTools: Support recent versions of cx_freeze.
This patch fixes the assumed invalid command to start recent versions
of cx_freeze on Windows, which are python and not Windows
executables. To launch them correctly, the '$(PYTHON_HOME)\python'
prefix has been added, so that Python can interpret the tool.
Star Zeng [Mon, 14 Mar 2016 01:48:26 +0000 (09:48 +0800)]
MdeModulePkg: Add PcdMaxPeiPerformanceLogEntries16 PROMPT&HELP STR to *.uni
Commit 7c50b3434377cbb49ce4514ee31339000a5cadc0 introduced
PcdMaxPeiPerformanceLogEntries16 to support > 256 PEI performance log
entries, but its PROMPT&HELP STR were forgotten to be added into *.uni.
Haojian Zhuang [Mon, 14 Mar 2016 05:30:37 +0000 (13:30 +0800)]
ArmPlatformPkg: PL061: support multiple controller
Support multiple PL061 controllers. If platform gpio driver couldn't be
found, PL061 gpio driver will continue to load PcdPL061GpioBase as the
register base.
It could be compatible with the use case of current PL061 gpio driver.
Haojian Zhuang [Mon, 14 Mar 2016 05:30:36 +0000 (13:30 +0800)]
EmbeddedPkg: enhance for multiple gpio controllers
EmbeddedGpio only supports one gpio controller in one platform. Now
create PLATFORM_GPIO_CONTROLLER to support multiple gpio controllers
in one platform.
Yonghong Zhu [Sun, 13 Mar 2016 10:13:04 +0000 (18:13 +0800)]
BaseTools/BPDG: Fix the bug to get the PCD Size
The original bug is only consider int format of PcdSize, but forgot the
Hex format. The fix is use the already exist variable PCD.PcdBinSize
which done to translate PCD size cover both format.
Michael Kinney [Tue, 8 Mar 2016 22:54:30 +0000 (14:54 -0800)]
UefiCpuPkg/Include: Add top level MSR include file
Add top level MSR include file that includes the Architecural MSR
include file and all family specific MSR files from the Msr
subdirectory
Intel(R) 64 and IA-32 Architectures Software Developer's
Manual, Volume 3, December 2015, Chapter 35
Model-Specific-Registers (MSR).
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>