Commit Graph

22014 Commits

Author SHA1 Message Date
Ruiyu Ni 76d1c752cb MdeModulePkg/UsbBus: Correct debug message
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-06-02 12:59:28 +08:00
Ruiyu Ni b659b503fa MdeModulePkg/UsbBus: Fix system hang when failed to uninstall UsbIo
When "reconnect -r" is typed in shell, UsbFreeInterface() is called
to uninstall the UsbIo and DevicePath. But When a UsbIo is opened
by a driver and that driver rejects to close the UsbIo in Stop(),
the uninstall doesn't succeed.
But UsbFreeInterface () frees the DevicePath memory without check
whether the uninstall succeeds.
It leads to the DXE core database contain a DevicePath instance but
that instance's memory is freed.
Assertion happens when someone calls InstallProtocol(DevicePath)
because the InstallProtocol() checks all DevicePath instance to
find whether the same one exits in database.

We haven't seen any USB device driver which rejects to close UsbIo
in Stop(), but it's very likely.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
2017-06-02 12:59:27 +08:00
dann frazier a6b5380642 BaseTools/GCC ARM/AARCH64: Force disable PIE
After Debian's toolchain switched to PIE by default, our edk2 builds began
to fail to build (GCC49 w/ gcc 6.3). This patch fixes the build by forcing
off PIE for both ARM and AARCH64 builds.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: dann frazier <dannf@debian.org>

Add -fno-pic as well for ARM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-06-01 08:30:23 +00:00
Hao Wu 8bef878bea Maintainers.txt: Update maintainers for DuetPkg & Nt32Pkg
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-06-01 09:01:49 +08:00
Hao Wu 3719c2aa87 MdeModulePkg/Xhci: Fill the 'interval' field for ISO endpoint context
https://bugzilla.tianocore.org/show_bug.cgi?id=510

The commit fills the 'Interval' field of the Endpoint Context data for
isochronous endpoints. It will resolve the error when a Configure
Endpoint Command is sent to an isochronous endpoint.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-06-01 08:54:03 +08:00
Hao Wu 213da0b540 MdeModulePkg/PrintLib: Avoid reading content beyond the format string
https://bugzilla.tianocore.org/show_bug.cgi?id=567

In functions DxePrintLibPrint2ProtocolVaListToBaseList() and
InternalPrintLibSPrintMarker(), when processing ASCII format strings, if
the format string walker pointer 'Format' is pointing at the end of the
format string (i.e. '\0'), the following expression:
*(Format + 1)
will read an undefined value.

Though this value won't affect the functionality, since it will be masked
by variable 'FormatMask':
(*(Format + 1) << 8)) & FormatMask
(FormatMask is 0xff for ASCII format string)

This commit adds additional logic to avoid reading undefined content.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-06-01 08:46:40 +08:00
Hao Wu b1d4b9651e MdePkg/BasePrintLib: Avoid reading content beyond the format string
https://bugzilla.tianocore.org/show_bug.cgi?id=567

In function BasePrintLibSPrintMarker(), when processing ASCII format
strings, if the format string walker pointer 'Format' is pointing at the
end of the format string (i.e. '\0'), the following expression:
*(Format + 1)
will read an undefined value.

Though this value won't affect the functionality, since it will be masked
by variable 'FormatMask':
(*(Format + 1) << 8)) & FormatMask
(FormatMask is 0xff for ASCII format string)

This commit adds additional logic to avoid reading undefined content.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-06-01 08:46:31 +08:00
Hao Wu 4fc8277133 MdePkg/DevicePathLib: Reverse the byte order of BD_ADDR for Bluetooth
For the following two functions:
DevPathFromTextBluetooth()
DevPathToTextBluetooth()

The Bluetooth device address "UINT8  Address[6]" is displayed with the
order from Address[5] to Address[0]. This commit reverses the order.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-05-31 10:28:41 +08:00
Laszlo Ersek b9036ebee9 QuarkPlatformPkg/SpiFvbServices: correct NumOfLba vararg type in EraseBlocks()
According to the PI spec, Volume 3,
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():

> The variable argument list is a list of tuples. Each tuple describes a
> range of LBAs to erase and consists of the following:
> * An EFI_LBA that indicates the starting LBA
> * A UINTN that indicates the number of blocks to erase

(NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)

In this driver, the NumOfLba local variable is defined with type UINTN,
but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kelly Steele <kelly.steele@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reported-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: Michael D Kinney <michael.d.kinney@intel.com>
2017-05-29 14:42:36 +02:00
Laszlo Ersek d0d7289cce Nt32Pkg/FvbServicesRuntimeDxe: correct NumOfLba vararg type in EraseBlocks()
According to the PI spec, Volume 3,
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():

> The variable argument list is a list of tuples. Each tuple describes a
> range of LBAs to erase and consists of the following:
> * An EFI_LBA that indicates the starting LBA
> * A UINTN that indicates the number of blocks to erase

(NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)

In this driver, the NumOfLba local variable is defined with type UINTN,
but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Reported-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: Hao Wu <hao.a.wu@intel.com>
2017-05-29 14:42:12 +02:00
Laszlo Ersek d98e939f4f DuetPkg/FvbRuntimeService: correct NumOfLba vararg type in EraseBlocks()
According to the PI spec, Volume 3,
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():

> The variable argument list is a list of tuples. Each tuple describes a
> range of LBAs to erase and consists of the following:
> * An EFI_LBA that indicates the starting LBA
> * A UINTN that indicates the number of blocks to erase

(NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)

In this driver, the NumOfLba local variable is defined with type UINTN,
but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Reported-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: Hao Wu <hao.a.wu@intel.com>
2017-05-29 14:41:42 +02:00
Ard Biesheuvel f4d3ba87bb BaseTools/Scripts: fix GccBase.lds line endings
Replace a <LF> line ending that was introduced inadvertently by a
recent commit with the correct <CR><LF>

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-05-28 12:07:02 +00:00
Jeff Fan 71d8226ac6 UefiCpuPkg/MpInitLib: Force to enable X2APIC if CPU number > 255
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
2017-05-27 13:30:04 +08:00
Jeff Fan c6b0feb396 UefiCpuPkg/MpInitLib: Check APIC mode change around AP function
If APIC ID values are changed during AP functions execution, we need to update
new APIC ID values in local data structure accordingly.

But if APIC mode change happened during AP function execution, we do not support
APIC ID value changed.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
2017-05-27 13:30:00 +08:00
Jeff Fan 6661abb695 UefiCpuPkg/CpuCommonFeaturesLib: Support X2APIC enable
Current X2APIC is enabled in MpInitLib (used by CpuMpPei and CpuDxe) to follow
SDM suggestion. That means we only enable X2APIC if we found there are any
initial CPU ID value >= 255.

This patch is to provide one chance for platform to enable X2APIC even there is
no any initial CPU ID value >= 255.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
2017-05-27 13:29:38 +08:00
Paulo Alcantara df642d70e3 MdeModulePkg: Fix potential memory leaks in DxeHttpLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paulo Alcantara <pcacjr@gmail.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
2017-05-27 09:50:10 +08:00
Laszlo Ersek aff463c825 Vlv2TbltDevicePkg/FvbRuntimeDxe: correct NumOfLba vararg type in EraseBlocks()
According to the PI spec, Volume 3,
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():

> The variable argument list is a list of tuples. Each tuple describes a
> range of LBAs to erase and consists of the following:
> * An EFI_LBA that indicates the starting LBA
> * A UINTN that indicates the number of blocks to erase

(NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)

In this driver, the NumOfLba local variable is defined with type UINTN,
but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.

Cc: David Wei <david.wei@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Mang Guo <mang.guo@intel.com>
Reported-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-05-26 14:41:13 +08:00
Yonghong Zhu 687bde9cac BaseTools: Correct if condition expression for DatumType == 'VOID*'
Correct the if condition expression for DatumType == 'VOID*'. Current
this condition is not work since the DatumType is changed before we do
the value judgement.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-05-25 11:16:39 +08:00
Michael Kinney 0fff7d6740 MdeModulePkg/DebugSupportDxe: Fix XCODE5 build failure
https://bugzilla.tianocore.org/show_bug.cgi?id=572

Update X64 AsmFuncs.S to resolve a build failure using the
XCODE5 tool chain.  This change updates AsmFuncs.S to match
AsmFuncs.asm and AsmFuncs.nasm.

The error generated in XCODE5 build is:

error: invalid instruction mnemonic 'movzxw'
    movzxw 8(%rax), %rax
    ^~~~~~

The correct instruction is

    movzwq 8(%rax), %rax

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-05-24 16:44:21 -07:00
Michael Kinney c8206f22fd MdeModulePkg/RegularExpressionDxe: Fix XCODE5 build failure
https://bugzilla.tianocore.org/show_bug.cgi?id=572

The ErrorMessage local variable in OnigurumaMatch() should
be type OnigUChar instead of type CHAR8.  This resolves
a build failure with the XCODE5 tool chain.

Cc: Andrew Fish <afish@apple.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-05-24 16:43:46 -07:00
Ard Biesheuvel 00b00cc57b BaseTools/Scripts: discard .gnu.hash section in GCC builds
Some builds of GCC/binutils will default to using the GNU flavor of
the symbol hash table, and will emit it into a section called .gnu.hash
rather than .hash. We have no use for its contents, and GenFw ignores
it anyway, so it shouldn't really matter what we do with it.

However, due to a workaround for AARCH64 we have in GenFw to deal with
older GCCs that corrupt section-based relocations when merging sections
during the final link, we need the ELF and PE/COFF views of the binary
to be identical. Since we don't place the .gnu.hash section explicitly,
it may end up at the beginning of the ELF binary, causing other sections
to be shifted in the ELF view but not in the PE/COFF view.

So let's add .gnu.hash to the GCC linker script. We don't care about its
contents so add it to the /DISCARD/ section.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-05-24 06:09:39 -07:00
Star Zeng a0284a9a58 MdeModulePkg MemoryProfileInfo: Use PdbStringOffset to get PDB info
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=570
Use PdbStringOffset to get PDB info, it will have no functional impact,
and will just make the code more generic.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2017-05-24 15:27:35 +08:00
Star Zeng f248539538 MdeModulePkg SmiHandlerProfile: Use fixed data type in data structure
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=568

Use fixed data type in data structure and make the structure
be natural aligned.
Without this update, the code must assume DXE and SMM are using
same data type (same size of UINTN), but it may be not true at
some case, for example, after standalone SMM feature is enabled.
With this update, the data structure will be phase independent
and convenient for consumer to parse the data.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2017-05-24 15:27:34 +08:00
Star Zeng 8ced192d5c MdeModulePkg SmiHandlerProfile: Fix no PDB case handling incorrectly
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=569

The PdbStringOffset should be set to 0 for no PDB case,
then SmiHandlerProfileInfo can use it to know whether
there is PCD info or not.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2017-05-24 15:27:34 +08:00
Hao Wu d727614c91 ShellPkg/UefiShellLib: Avoid reading undefined content before string
https://bugzilla.tianocore.org/show_bug.cgi?id=566

In function InternalShellPrintWorker(), if the string in variable
'mPostReplaceFormat2' starts with character L'%', the following
expression:

*(ResumeLocation-1) == L'^' at line 2831

will read an undefined value before the starting of string
'mPostReplaceFormat2'.

This commit adds additional logic to avoid reading undefined content.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
2017-05-24 13:17:51 +08:00
Yonghong Zhu 2d49938845 BaseTools: Fix the bug that different DSC file use same build output
We meet a corner case that build different DSC file, but the DSC file use
same build output directory, and the different DSC file use a same PCD
with different Pcd Type, it cause build failure.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-05-24 13:14:32 +08:00
Yonghong Zhu 99adfe9f51 BaseTools: Fix incremental build bug on DynamicPcd Token Generation
During incremental build, we meet the bug that the different drivers use
the different token for the same DynamicPcd.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-05-24 13:13:39 +08:00
Laszlo Ersek 1c47fcd465 OvmfPkg: make the 4MB flash size the default (again)
Xen gained support for the 4MB flash image in Xen commit 0d6968635ce5
("hvmloader: avoid tests when they would clobber used memory",
2017-05-19), which is part of Xen 4.9.0-rc6.

The previously default 2MB can be explicitly selected with

  -D FD_SIZE_2MB

or

  -D FD_SIZE_IN_KB=2048

Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit bba8dfbec3)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: reference Xen commit in commit message]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-05-23 17:46:11 +02:00
Michael Kinney 3b2928b469 UefiCpuPkg/MpInitLib: Fix X64 XCODE5/NASM compatibility issues
https://bugzilla.tianocore.org/show_bug.cgi?id=565

Fix NASM compatibility issues with XCODE5 tool chain.
The XCODE5 tool chain for X64 builds using PIE (Position
Independent Executable).  For most assembly sources using
PIE mode does not cause any issues.

However, if assembly code is copied to a different address
(such as AP startup code in the MpInitLib), then the
X64 assembly source must be implemented to be compatible
with PIE mode that uses RIP relative addressing.

The specific changes in this patch are:

* Use LEA instruction instead of MOV instruction to lookup
  the addresses of functions.

* The assembly function RendezvousFunnelProc() is copied
  below 1MB so it can be executed as part of the MpInitLib
  AP startup sequence.  RendezvousFunnelProc() calls the
  external function InitializeFloatingPointUnits().  The
  absolute address of InitializeFloatingPointUnits() is
  added to the MP_CPU_EXCHANGE_INFO structure that is passed
  to RendezvousFunnelProc().

Cc: Andrew Fish <afish@apple.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
2017-05-22 19:43:46 -07:00
Jeff Fan ac63e9392e UefiCpuPkg/DxeMpInitLib.inf: Add missing SynchronizationLib
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
2017-05-23 10:12:04 +08:00
Michael Kinney 1c020add31 MdeModulePkg/LogoDxe: Return error if HII Package not present
https://bugzilla.tianocore.org/show_bug.cgi?id=554

Update LogoDxe module to print a DEBUG() message and exit
with an error instead of ASSERT_EFI_ERROR() if the HII
Image Package with the logo image is not present.

If a tool chain does not support generation of PE/COFF
resource sections, then this module can not produce the logo
from an HII Image Package.  XCODE5 is an example of a tool
chain that does not currently support generation of PE/COFF
resource sections.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-05-22 16:30:11 -07:00
Sami Mujawar 0e07733023 ArmPlatformPkg: Timer access for non-secure EL1/0
According to Section 2.3.6 of the "UEFI Specification 2.6 Errata A";
the primary CPU must be configured such that 'Timer access must be
provided to non-secure EL1 and EL0 by setting bits EL1PCTEN and
EL1PCEN in register CNTHCTL_EL2.'

This commit adds this missing set-up to the PrePi and PrePeiCore
modules.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2017-05-22 15:20:04 +01:00
Sami Mujawar 23d6348f92 ArmPkg: Add CNTHCTL_EL2 support functions
Added helper functions for reading and writing the
CNTHCTL_EL2 register.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2017-05-22 15:19:34 +01:00
Ruiyu Ni 7320b8ed18 MdeModulePkg/BDS: Fix a buffer overflow bug
KeyOption points to a buffer holding the content of Key####.
So its size is smaller than EFI_BOOT_MANAGER_KEY_OPTION.
Old code to assign value to KeyOption->OptionNumber modifies
the memory outside of the KeyOption buffer.

The patch fixes this bug.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
2017-05-22 09:43:47 +08:00
Long Qin a9fb7b7803 CryptoPkg/BaseCryptLib: Add NULL pointer checks in DH and P7Verify
Add more NULL pointer checks before using them in DhGenerateKey and
Pkcs7GetCertificatesList functions to eliminate possible dereferenced
pointer issue.

Cc: Ting Ye <ting.ye@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long <qin.long@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ting Ye <ting.ye@intel.com>
2017-05-22 08:57:48 +08:00
Michael Kinney 112f4ada2e edk2: Add .DS_Store to .gitignore for macOS
https://bugzilla.tianocore.org/show_bug.cgi?id=558

macOS may generate .DS_Store files in directories.
The .gitignore file is updated to ignore these
.DS_Store files.

Cc: Andrew Fish <afish@apple.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
2017-05-19 15:14:34 -07:00
Michael Kinney 3e1d93c32e BaseTools: Clean up tools_def.template for XCODE5
Reorganize the statements for XCODE5 to match other tool
chains and remove dependency on XCLANG and XCODE32

Cc: Andrew Fish <afish@apple.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
2017-05-19 15:05:33 -07:00
Michael Kinney bdaced0bcf BaseTools: Add -D NO_MSABI_VARGS to X64 XCODE5 CC_FLAGS
https://bugzilla.tianocore.org/show_bug.cgi?id=561

Update BaseTools/Conf/tools_def.template to add the define

-D NO_MSABI_VAARGS

To CC_FLAGS for X64 XCODE5 builds.

The llvm/clang compiler used in XCODE5 builds supports the
_ms_ versions of the vararg builtins, but the compiler
generates build errors.

The recommendation from the XCODE5 experts is to never use
the _ms_ version of the vararg builtins.  The define
NO_MSABI_VARARGS is already supported in MdePkg/Include/Base.h
and forces the use the standard vararg builtins.

Cc: Andrew Fish <afish@apple.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
2017-05-19 15:05:25 -07:00
Michael Kinney 01e9597540 OvmfPkg: Add XCODE5 statements to fix build break
https://bugzilla.tianocore.org/show_bug.cgi?id=559

The XCODE5 tool chain has a FAMILY of GCC.  The
GCC statements in the [BuildOptions] section add
flags that are not compatible with XCODE5.  Add
empty XCODE5 statements in [BuildOptions] sections
to prevent the use of the GCC flags in XCODE5
builds.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-05-19 14:22:13 -07:00
Michael Kinney b9dbc03e5a UefiCpuPkg: Use FINIT instead of hex values
https://bugzilla.tianocore.org/show_bug.cgi?id=560

Update X64 NASM file to match IA32 NASM file
and use FINIT instruction instead of hand
assembled hex values for the FINIT instruction.

Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
2017-05-19 14:15:15 -07:00
Michael Kinney 5b78f30d81 UefiCpuPkg/BaseUefiCpuLib: Use NASM read-only data section name
https://bugzilla.tianocore.org/show_bug.cgi?id=556

NASM requires read-only data sections to use the section
name .rodata.  This fix changes .rdata to .rodata.

The build failure from use of .rdata is seen when using
the XCODE5 tool chain.

Section "7.8.1 macho extensions to the SECTION Directive"
of the NASM documentation at http://www.nasm.us/doc/
describes the section name requirements.

Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Andrew Fish <afish@apple.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>
2017-05-19 14:07:33 -07:00
Michael Kinney 0d0a19cb14 UefiCpuPkg/PiSmmCpuDxeSmm: Add missing JMP instruction
https://bugzilla.tianocore.org/show_bug.cgi?id=555

Add JMP instruction in SmiEntry.S file that is missing.  This
updates SmiEntry.S to match the logic in SmiEntry.asm and
SmiEntry.nasm.

The default BUILDRULEORDER has .nasm higher priority than
.asm or .S, so this issue was not seen with MSFT or GCC
tool chain families.  The XCODE5 tool chain overrides the
BUILDRULEORDER with .S higher than .nasm, so this issue
was only seen when using XCODE5 tool chain when IA32 SMM
is enabled.

Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-05-19 13:59:27 -07:00
Michael Kinney bbd61de5db PcAtChipsetPkg/SerialIoLib: Remove negative value shift
https://bugzilla.tianocore.org/show_bug.cgi?id=553

Remove left shift of negative values that always evaluate
to 0 to address build errors from the llvm/clang compiler
used in the XCODE5 tool chain.

Clang rightfully complains about left-shifting ~DLAB. DLAB is #defined
as 0x01 (an "int"), hence ~DLAB has value (-2) on all edk2 platforms.
Left-shifting a negative int is undefined behavior.

Rather than replacing ~DLAB with ~(UINT32)DLAB, realize that the nonzero
bits of (~(UINT32)DLAB << 7) would all be truncated away in the final
conversion to UINT8 anyway. So just remove (~DLAB << 7).

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-05-19 12:12:06 -07:00
Star Zeng da0df6ca8f MdeModulePkg PCD: Fix TmpTokenSpaceBufferCount not assigned correctly
When DynamicEx PCD is only used in PEI code, but not DXE code,
current implementation of DxePcdGetNextTokenSpace does not assign
TmpTokenSpaceBufferCount correctly, but leaves it as initial value,
then DxePcdGetNextTokenSpace may return incorrect token space guid
and status.

This patch is to fix this issue.

Cc: Liming Gao <liming.gao@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>
2017-05-19 11:32:11 +08:00
Laszlo Ersek f78c8bf2c6 OvmfPkg/README: document 4MB flash layout
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=527
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 23:38:46 +02:00
Laszlo Ersek c9e7907d09 OvmfPkg/PlatformPei: align EmuVariableNvStore at any page boundary
EmuVariableFvbRuntimeDxe now uses a 4KB (EFI_PAGE_SIZE) block size.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 23:38:46 +02:00
Laszlo Ersek 7e8329267e OvmfPkg/EmuVariableFvbRuntimeDxe: change block size to 4KB
EmuVariableFvbRuntimeDxe currently produces a Firmware Volume Block
protocol that is based on a block map of two blocks, each block having
PcdFlashNvStorageFtwSpareSize for size.

(The total size is 2 * PcdFlashNvStorageFtwSpareSize.)

FaultTolerantWriteDxe in turn expects the block size to be a power of two.

In the 4MB build of OVMF, PcdFlashNvStorageFtwSpareSize is 264KB, which is
not a power of two. In order to equip EmuVariableFvbRuntimeDxe for this
build, shrink the block size to 4KB (EFI_PAGE_SIZE), and grow the block
count from 2 to EFI_SIZE_TO_PAGES(2 * PcdFlashNvStorageFtwSpareSize). The
total size remains

  2 * PcdFlashNvStorageFtwSpareSize
  --------------------------------- * EFI_PAGE_SIZE
            EFI_PAGE_SIZE

Right now EmuVariableFvbRuntimeDxe open-codes the block count of 2 in
various limit checks, so introduce a few new macros:
- EMU_FVB_NUM_TOTAL_BLOCKS, for the LHS of the above product,
- EMU_FVB_NUM_SPARE_BLOCKS for the half of that.

Also rework the FVB protocol members to support an arbitrary count of
blocks.

Keep the invariant intact that the first half of the firmware volume hosts
the variable store and the FTW working block, and that the second half
maps the FTW spare area.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=527
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 23:38:45 +02:00
Laszlo Ersek 89f385ce0a OvmfPkg/EmuVariableFvbRuntimeDxe: strip trailing whitespace
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 23:38:45 +02:00
Laszlo Ersek 38292c0872 OvmfPkg/QemuFlashFvbServicesRuntimeDxe: correct NumOfLba vararg type in EraseBlocks()
According to the PI spec, Volume 3,
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():

> The variable argument list is a list of tuples. Each tuple describes a
> range of LBAs to erase and consists of the following:
> * An EFI_LBA that indicates the starting LBA
> * A UINTN that indicates the number of blocks to erase

(NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)

In this driver, the NumOfLba local variable is defined with type UINTN,
but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Reported-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>
2017-05-18 23:38:45 +02:00
Laszlo Ersek 9c4eef656f OvmfPkg/EmuVariableFvbRuntimeDxe: correct NumOfLba vararg type in EraseBlocks()
According to the PI spec, Volume 3,
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():

> The variable argument list is a list of tuples. Each tuple describes a
> range of LBAs to erase and consists of the following:
> * An EFI_LBA that indicates the starting LBA
> * A UINTN that indicates the number of blocks to erase

(NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)

In this driver, the NumOfLba local variable is defined with type UINTN,
but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.

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: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 23:38:45 +02:00