summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-09-21MdeModulePkg/XhciDxe:1ms delay before access MMIO reg during resetFeng Tian
Some XHCI host controllers require to have extra 1ms delay before accessing any MMIO register during HC reset. As this delay is not defined by XHCI spec, we use this workaround to fix the issue. Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Feng Tian <feng.tian@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2016-09-21BaseTools: Update toolsetup.bat to set PYTHONPATH env to run python sourceLiming Gao
When python tool exe doesn't exist, toolsetup.bat will set up PYTHONPATH, and set python tool dos script directory into system PATH. Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Erik Bjorge <erik.c.bjorge@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
2016-09-21BaseTools: Update Python Makefile not to depend on PYTHON_FREEZER_PATHLiming Gao
If PYTHON_FREEZER_PATH is not set, Python tools will not be freeze. Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Erik Bjorge <erik.c.bjorge@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
2016-09-21BaseTools: Update python tool to call external tools with shell true modeLiming Gao
Python tool may run from source as the dos batch files. So, update python code to call external tools with shell true mode. Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Erik Bjorge <erik.c.bjorge@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
2016-09-21BaseTools: Add Windows batch files to run python tool from SourceLiming Gao
Add 13 windows batch files for every python tool. Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Erik Bjorge <erik.c.bjorge@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
2016-09-20MdeModulePkg PCD: Update PCD database structure definition to match BaseToolsStar Zeng
To follow PI1.4a, BaseTools has be updated to fix artificial limitation of SkuId range. This patch is to update PCD database structure definition to match BaseTools. Note: The source code and BaseTools need to be upgraded at the same time, and if they are not upgraded at the same time, build error like below will be triggered to help user identify the problem. "Please make sure the version of PCD PEIM Service and the generated PCD PEI Database match." Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@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>
2016-09-20BaseTools: Follow PI1.4a to fix artificial limitation of PCD SkuId rangeYonghong Zhu
Current BaseTools follow previous PI spec to use UINT8 for SkuId, to follow PI1.4a, BaseTools need to be updated to fix artificial limitation of PCD SkuId range. This patch is to update BaseTools to use UINT64 for SkuId, since the PCD database structure needs to be naturally aligned, the PCD database structure layout is adjusted to keep the natural alignment and version is updated to 6. Note: As the PCD database structure layout is adjusted, the structure definition in MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h and PCD drivers also need to be updated. That means the source code and BaseTools need to be upgraded at the same time, and if they are not upgraded at the same time, build error like below will be triggered to help user identify the problem. "Please make sure the version of PCD PEIM Service and the generated PCD PEI Database match." 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>
2016-09-20IntelFsp2Pkg: Align #Pragma in UPD header files to rest of EDK2 PkgsSatya Yarlagadda
Changed the GenCfgOpt.py script to insert pragma pack(1) instead of pragma pack (push, 1) in the upd header files generated during fsp build. This is to align with rest of the EDKII pkgs pragma pack usage. Also, this scripts generates UnusedUpdSpace for UPD address gaps. Currently it uses UIN16/UINT32/UINT64 for 2/4/8 bytes instead of UINT8[], thus causing upd space waste to have Natural Alignment. Hence changed the script to use UINT8[] for any unusedUpd fields above 1 byte. Cc: Maurice Ma <maurice.ma@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Satya Yarlagadda <satya.p.yarlagadda@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
2016-09-20NetworkPkg: Correct the DNS token return status by RCODEJiaxin Wu
When HostNameToIp() and GeneralLookUp() are called with a invalid host name, RCODE (4 bit field is set as part of responses) error will returned in packet to identify the domain name referenced in the query does not exist. So, EFI_NOT_FOUND should be returned directly. Current implementation only check the RCODE in successful condition. Need update the code for more error check according to RFC 1035 4.1.1 section. Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Tested-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Reviewed-by: Sriram Subramanian <sriram-s@hpe.com>
2016-09-15ArmVirtPkg/HighMemDxe: move to FDT client protocolArd Biesheuvel
Use the FDT client protocol rather than parsing the DT directly using fdtlib. While we're at it, update the code so it deals correctly with memory nodes that describe multiple disjoint regions in their "reg" properties, and make the code work with #address-cells/#size-cells properties of <1> as well as <2>. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-09-15ArmVirtPkg/FdtClientDxe: add methods to iterate over memory nodesArd Biesheuvel
Add high level methods to iterate over all 'reg' properties of all DT nodes whose device_type properties have the value "memory". Since we are modifying the FdtClient protocol, update the protocol and the only existing implementation at the same time. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-09-15ArmVirtPkg/FdtClientDxe: report address and size cell count directlyArd Biesheuvel
The FDT client protocol methods dealing with "reg" properties return the size of a "reg" element. Currently, we have hardcoded this as '8', since #address-cells == #size-cells == 2 in most cases. However, for different values, have a single 'reg' element size is not unambiguous, since - however unlikely - if #address-cells != #size-cells, we do not know which is which. So before adding more methods to the protocol, fix up this oversight. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-09-15ArmVirtPkg/FdtClientDxe: fix check for size of "reg" propertiesArd Biesheuvel
Currently, the code in FdtClientDxe assumes #address-cells/#size-cells values of <2>. Since DT "reg" properties always consist of <base, size> tuples, this means the size of the entire property should always be a multiple of 16 bytes (i.e, 4 * sizeof(UINT32), not 8. So fix this. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-09-15BaseTools: Fix the bug to handle the read-only fileYonghong Zhu
change the 'r+b' to 'rb' for some file's open, since these files we only read it and no need to write. It can fix the bug that the file's attribute had been set to read-only. 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>
2016-09-15IntelFrameworkPkg/FrameworkSpecConformance.txt: Update the URLYonghong Zhu
Update the URL since http://edk2.tianocore.org is not valid Cc: Liming Gao <liming.gao@intel.com> Cc: Jeff Fan <jeff.fan@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> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
2016-09-15edksetup.sh: update the URL in edksetup.shYonghong Zhu
Update the URL since http://edk2.tianocore.org is not valid 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>
2016-09-14ArmPkg/DefaultExceptionHandlerLib: improve formatting of backtraceArd Biesheuvel
Implement the backtrace formattting suggested by Andrew, i.e., IRQ Exception at 0x000000005BE182B0 PC 0x00005BE182B0 (0x00005BE14000+0x000042B0) [ 0] ArmCpuDxe.dll PC 0x00005BE15770 (0x00005BE14000+0x00001770) [ 0] ArmCpuDxe.dll PC 0x00005EF08CC8 (0x00005EEEB000+0x0001DCC8) [ 1] DxeCore.dll PC 0x00005EF09008 (0x00005EEEB000+0x0001E008) [ 1] DxeCore.dll PC 0x00005EEF6ACC (0x00005EEEB000+0x0000BACC) [ 1] DxeCore.dll PC 0x00005EF0963C (0x00005EEEB000+0x0001E63C) [ 1] DxeCore.dll PC 0x00005EF09A38 (0x00005EEEB000+0x0001EA38) [ 1] DxeCore.dll PC 0x00005EF01560 (0x00005EEEB000+0x00016560) [ 1] DxeCore.dll PC 0x00005EF02FB4 (0x00005EEEB000+0x00017FB4) [ 1] DxeCore.dll PC 0x00005EF03098 (0x00005EEEB000+0x00018098) [ 1] DxeCore.dll PC 0x00005EF0460C (0x00005EEEB000+0x0001960C) [ 1] DxeCore.dll PC 0x00005EF005C4 (0x00005EEEB000+0x000155C4) [ 1] DxeCore.dll PC 0x00005EF00360 (0x00005EEEB000+0x00015360) [ 1] DxeCore.dll PC 0x00005EF003C8 (0x00005EEEB000+0x000153C8) [ 1] DxeCore.dll PC 0x00005EF128D0 (0x00005EEEB000+0x000278D0) [ 1] DxeCore.dll PC 0x00005EF12930 (0x00005EEEB000+0x00027930) [ 1] DxeCore.dll PC 0x00005EEEF594 (0x00005EEEB000+0x00004594) [ 1] DxeCore.dll PC 0x00005EF0CF18 (0x00005EEEB000+0x00021F18) [ 1] DxeCore.dll PC 0x00005EF1A310 (0x00005EEEB000+0x0002F310) [ 1] DxeCore.dll PC 0x00005EEF1808 (0x00005EEEB000+0x00006808) [ 1] DxeCore.dll PC 0x00005EEF1E48 (0x00005EEEB000+0x00006E48) [ 1] DxeCore.dll PC 0x00005EF0A838 (0x00005EEEB000+0x0001F838) [ 1] DxeCore.dll PC 0x00005EEED70C (0x00005EEEB000+0x0000270C) [ 1] DxeCore.dll PC 0x00005EEEC93C (0x00005EEEB000+0x0000193C) [ 1] DxeCore.dll PC 0x00005EEEC024 (0x00005EEEB000+0x00001024) [ 1] DxeCore.dll [ 0] /home/ard/build/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/ArmPkg/Drivers/CpuDxe/CpuDxe/DEBUG/ArmCpuDxe.dll [ 1] /home/ard/build/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-09-14Vlv2TbltDevicePkg:Signal End of Dxe Event.lushifex
According to PI spec,DxeSmmReadyToLock protocol is published immediately after signaling of the End of Dxe Event. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: lushifex <shifeix.a.lu@intel.com>
2016-09-14UefiCpuPkg/SecCore: Re-install SEC platform information(2) PPIJeff Fan
In SecTemporaryRamDone(), we will build one privated GUIDed-HOB to save CPU BIST Data and re-install SEC platform information(2) PPI. Then other PEI drivers could get CPU BIST data from the private GUIDed-HOB by new installed PPI. Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
2016-09-14UefiCpuPkg/SecCore: Abstract worker function GetBistFromHob()Jeff Fan
Abstract one worker function to get CPU BIST from the GUIDed-HOB. Add SecPlatformInformationBist() and SecPlatformInformation2Bist() to invoke GetBistFromHob(). Add in/out for parameter in function header. Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
2016-09-14UefiCpuPkg/SecCore: Add SecBist.cJeff Fan
Add SecBist.c and copy GetBistInfoFromPpi() and SecPlatformInformation2() from UefiCpuPkg/CpuMpPei/CpuBist.c. And update SecMain.c, SecMain.inf and UefiCpuPkg.dsc accordinlgy to pass build. Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
2016-09-14UefiCpuPkg/CpuMpPei: Build GUIDed-HOB to store all CPU BIST DataJeff Fan
Build gEfiSecPlatformInformation2PpiGuid GUIDed-HOB to store all CPU BIST data that could be used not only by SecPlatformInformation2(), but also by CPU MP Dxe driver to get CPU BIST data. Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
2016-09-14UefiCpuPkg/CpuMpPei: Fix BistData ouput errorJeff Fan
ProcessorInfo.ProcessorId is UINT64 type even it's valid value is UINT32. Use %x only output the low 4 bytes and keep the high 4 bytes in stack that will be output as the second parameter BistData. Typecast ProcessorInfo.ProcessorId to UINT32 could make BistData output correctly. Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
2016-09-14UefiCpuPkg/CpuMpPei: Add parameter BistInformationSizeJeff Fan
Add one OPTIONAL parameter BistInformationSize for GetBistInfoFromPpi(). Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
2016-09-14UefiCpuPkg/CpuDxe: Fix duplicated status code reportJeff Fan
If CPU Bist data is not zero, we will report Status code. But there is one bug that will report each processor's status code duplicated with NumberOfData times. This fix is to exchange the loop order on NumberOfData and mNumberOfProcessors. It could make sure the report status code only once for each processor. Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
2016-09-13MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phasesArd Biesheuvel
The new accelerated ARM and AARCH64 implementations take advantage of features that are only available when the MMU and Dcache are on. So restrict the use of this library to the DXE phase or later. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-09-13MdePkg/BaseMemoryLibOptDxe: add accelerated AARCH64 routinesArd Biesheuvel
This adds AARCH64 support to BaseMemoryLibOptDxe, based on the cortex-strings library. All string routines are accelerated except ScanMem16, ScanMem32, ScanMem64 and IsZeroBuffer, which can wait for another day. (Very few occurrences exist in the codebase) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-09-13MdePkg/BaseMemoryLibOptDxe: add accelerated ARM routinesArd Biesheuvel
This adds ARM support to BaseMemoryLibOptDxe, partially based on the cortex-strings library (ScanMem) and the existing CopyMem() implementation from BaseMemoryLibStm in ArmPkg. All string routines are accelerated except ScanMem16, ScanMem32, ScanMem64 and IsZeroBuffer, which can wait for another day. (Very few occurrences exist in the codebase) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-09-13MdePkg/BaseMemoryLib: widen aligned accesses to 32 or 64 bitsArd Biesheuvel
Since the default BaseMemoryLib should be callable from any context, including ones where unaligned accesses are not allowed, it implements InternalCopyMem() and InternalSetMem() using byte accesses only. However, especially in a context where the MMU is off, such narrow accesses may be disproportionately costly, and so if the size and alignment of the access allow it, use 32-bit or even 64-bit loads and stores (the latter may be beneficial even on a 32-bit architectures like ARM, which has load pair/store pair instructions) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-09-13ArmVirtPkg/FdtParser: avoid unaligned accesses with the MMU offArd Biesheuvel
When parsing the device tree to find the memory node, we are still running with the MMU off, which means unaligned memory accesses are not allowed. Since the FDT only mandates 32-bit alignment, 64-bit quantities are not guaranteed to appear naturally aligned, and so should be accessed using 32-bit accesses instead. Reported-by: Julien Grall <julien.grall@arm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-09-13ArmPkg/ArmMmuLib: base page table VA size on GCD memory map sizeArd Biesheuvel
As reported by Eugene, the practice of sizing the address space in the virtual memory system based on the maximum address in the table passed to ArmConfigureMmu() is problematic, since it fails to take into account the fact that the GCD memory space may be extended at a later time, both for memory and for MMIO. So instead, choose the VA size identical to the GCD memory map size, which is based on PcdPrePiCpuMemorySize on ARM systems. Reported-by: Eugene Cohen <eugene@hp.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Eugene Cohen <eugene@hp.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-09-13ArmPkg/ArmMmuLib: use a pool allocation for the root tableArd Biesheuvel
Currently, we allocate a full page for the root translation table, even if the configured translation only requires two entries (16 bytes) for the root level, which happens to be the case for a 40 bit VA. Likewise, for a 36-bit VA space, the root table only needs 16 entries of 8 bytes each, adding up to 128 bytes. So switch to a pool allocation for the root table if we can, but take into account that the architecture requires it to be naturally aligned to its size, i.e., a 64 byte table requires 64 byte alignment, whereas pool allocations in general are only guaranteed to be aligned to 8 bytes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-09-13ArmPkg/ArmMmuLib: remove bogus alignment of page allocationsArd Biesheuvel
In commit 7d189f99d81c ("ArmPkg/Mmu: Fix bug of aligning new allocated page table"), we fixed a flaw in the logic regarding alignment of newly allocated translation table pages. However, we all failed to spot that aligning page based allocations to page size is rather pointless to begin with, so simply allocate a single page each time we add new pages to the translation tables. Also, drop the unnecessary cast. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-09-13ArmPkg/ArmMmuLib: deobfuscate GetRootTranslationTableInfo ()Ard Biesheuvel
The relations between T0SZ, the number of translation levels and the size/alignment of the root table can be expressed in simple arithmetic expressions, so get rid of the lookup table. Note that this disregards the fact that the maximum value of T0SZ is 39 not 42 (as one would expect for the smallest VA size using 2 levels) but since this corresponds to a VA size of 32 MB and 4 MB, respectively, neither of which are sufficient to run UEFI, we can safely ignore the distinction. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-09-13OvmfPkg: Fix typing errors in header filesThomas Huth
Correct some typos in the header files of the OvmfPkg (which have been discovered with the codespell utility). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-09-12OvmfPkg: Fix typing errorsThomas Huth
Correct some typos (discovered with the codespell utility) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-12OvmfPkg: convert C files with LF line terminators to CRLFLaszlo Ersek
Run "unix2dos" on the affected files. "git show -b" produces no diff for this patch. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
2016-09-12OvmfPkg/IndustryStandard: make "Xen/grant_table.h" pure ASCIILaszlo Ersek
The header file includes the UTF-8 encoding (0xE2 0x80 0x99) of the U+2019 (RIGHT SINGLE QUOTATION MARK) code point. Replace it with a simple apostrophe (U+0027, ASCII 0x27). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
2016-09-12MdeModulePkg/HiiDB: Handle the "&READONLY" tag in <KeywordResp> correctlyDandan Bi
This patch is to fix the incorrect logic when handling the "&READONLY" tag in <KeywordResp>. 1. In UEFI spec, the "&READONLY" tag is in upper case, but using the lower case in current codes by mistake. 2. The logic in checking the ReadOnly flag is not correct. Whether having "&READONLY" tag must be consistent with the result of "ExtractReadOnlyFromOpCode" function. 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: Liming Gao <liming.gao@intel.com>
2016-09-12MdeModulePkg/UiApp: Fix incorrect question idDandan Bi
For a question, its question id can not be zero. This patch is to fix the issue that using zero as question id. 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: Liming Gao <liming.gao@intel.com>
2016-09-12Nt32Pkg: Fix VS2010/VS2012 build failureDandan Bi
Initialize the variable "OptionNumber". 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>
2016-09-09OptionRomPkg: .dsc fixes for ARM/AARCH64 and USB driversLeif Lindholm
Drivers under OptionRomPkg wouldn't build standalone, since ARM and AARCH64 were missing from SUPPORTED_ARCHITECTURES. So add them. Also, add some compiler libraries needed for ARM/AARCH64 GCC toolchains (CompilerIntrinsicsLib and BaseSwStackCheckLib). Also, the UsbNetworking drivers were not listed under [Components], so failed to build standalone. This patch adds them. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2016-09-09ArmPkg/ArmGicLib: use correct loop variableArd Biesheuvel
The ArmGicLib API function GicGetCpuRedistributorBase () declares GicCpuRedistributorBase to iterate over the redistributors of all CPUs, but then inadvertently advances GicRedistributorBase instead. Reported-by: "Oliyil Kunnil, Vishal" <vishalo@qti.qualcomm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-09-09ArmPkg/DefaultExceptionHandlerLib: trim module name in backtrace outputArd Biesheuvel
As reported by Vishal, the new backtrace output would be more useful if it did not contain the full absolute path of each module in the list. So strip off everything up to the last forward slash or backslash in the string. Example output: IRQ Exception at 0x000000005EF110E0 DxeCore.dll loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EF121F0) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EF1289C) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEFB6B4) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEFAA44) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEFB450) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEF938C) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEF8D04) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEFA8E8) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEF3C14) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEF3E48) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EF0C838) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEEF70C) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEEE93C) loaded at 0x000000005EEED000 called from DxeCore.dll (0x000000005EEEE024) loaded at 0x000000005EEED000 Suggested-by: "Oliyil Kunnil, Vishal" <vishalo@qti.qualcomm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-09-09ArmPlatformPkg/NorFlashDxe: use strictly aligned CopyMem()Ard Biesheuvel
The UEFI spec stipulates that unaligned accesses should be enabled on CPUs that support them, which means all of them, given that we no longer support pre-v7 ARM cores, and the AARCH64 bindings mandate support for unaligned accesses unconditionally. This means that one should not assume that CopyMem () is safe to call on regions that may be mapped using device attributes, which is the case for the NOR flash. Since we have no control over the mappings when running under the OS, and given that write accesses require device mappings, we should not call CopyMem () in the read path either, but use our own implementation that is guaranteed to take alignment into account. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-09-09MdePkg/BaseLib AARCH64: terminate stack frame list on stack switchArd Biesheuvel
When switching to the DXE phase stack, set the frame pointer to zero so that code walking the stack frame will not try to access stack frames belonging to the old stack. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-09-09BaseTools/EfiRom: supply missing machine type lookup stringsLaszlo Ersek
"EfiRom --dump" does not recognize the 0x8664 machine type: > EFI ROM header contents > EFI Signature 0x0EF1 > Compression Type 0x0001 (compressed) > Machine type 0x8664 (unknown) > Subsystem 0x000B (EFI boot service driver) > EFI image offset 0x0050 (@0xF650) Add lookup strings for the remaining EFI_IMAGE_MACHINE_* numeric macros that can be found in "BaseTools/Source/C/Include/IndustryStandard/PeImage.h". The strings follow Table 12. "UEFI Image Types" from the UEFI v2.6 spec. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-09-08ShellPkg/UefiHandleParsingLib: fix retval for empty child controller arrayLaszlo Ersek
The ParseHandleDatabaseForChildControllers() function intends to work like this: (1) It allocates a "HandleBufferForReturn" local array that's guaranteed to be big enough for all found handles, (2) it collects the handles, both counting them in the (mandatory) "MatchingHandleCount" output parameter, and saving them in the local "HandleBufferForReturn" array, (3) if the caller is not interested in the actual handles, then "HandleBufferForReturn" is released, (4) if the caller is interested in the handles, and we've found some, then "HandleBufferForReturn" is passed out through the "MatchingHandleBuffer" output parameter, (5) if the caller is interested in the actual handles, but we've found none, then the "MatchingHandleBuffer" output parameter is set to NULL. The ASSERT() at the end of the function makes this clear, but the implementation does not conform to (5). Fix it. Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Tapan Shah <tapandshah@hpe.com> Reported-by: Tapan Shah <tapandshah@hpe.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=112 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Tapan Shah <tapandshah@hpe.com>
2016-09-08ShellPkg/UefiHandleParsingLib: fix IN/OUT notation in child ctrlr parsingLaszlo Ersek
"MatchingHandleCount" is an output parameter of ParseHandleDatabaseForChildControllers(). Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Tapan Shah <tapandshah@hpe.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Tapan Shah <tapandshah@hpe.com>
2016-09-08ShellPkg: pci -i -_e to print next capabilityAbdul Lateef Attar
According to PCI spec the next AER capability is relative to the beginning of PCI configuration space. Hence substract the base offset to get the next capability. "-_e" option is changed from TypeFlag to TypeValue, so that user can specify individual AER capability to print. e.g. pci 00 00 01 -i -_e <capability-id> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Abdul Lateef Attar <abdul-lateef.attar@hpe.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>