Li YangX [Thu, 8 Oct 2015 09:27:14 +0000 (09:27 +0000)]
BaseTools: Update Build tool to support multiple workspaces
WORKSPACE is still kept.
New PACKAGES_PATH is introduced to specify the additional WORKSPACEs.
In PACKAGES_PATH, ';' is separator in Windows, ':' is separator in Linux.
Build directory is in WORKSPACE. Package, BaseTools and Conf directory
will be found from WORKSPACE and PACKAGES_PATH.
In implementation, BaseTools adds MultipleWorkspace class for
the file path conversion from WORKSPACE and PACKAGES_PATH.
Verify two tree layouts.
Root\edk2\MdePkg
Root\edk2\MdeMdeModulePkg
Root\edk2\...
1. set WORKSPACE=Root\edk2
2. set WORKSPACE=Root, and set PACKAGES_PATH=Root\edk2
1. Change Interrupt for Juno PCI Routing table
Interrupt Number Reference:
http://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_trm.pdf
table 3-3 page 3-7
2. Support for PCI IO range with ACPI on JUNO
DuetPkg: exit pci function loops early if device is not multi-function
When looping through all PCI functions, code should not look for functions
1-7 if function 0 is not present or if function 0 indicates the device is
not multifunction. Prior to this fix the code would use stale data in a
buffer to determine if a device is multifunction even if function 0 is not
present. This fixes a code bug and provides very small performance
improvements.
PCI 2.3 Specification states: They [multifunction devices] are also
required to always implement function 0 in the device. Implementing other
functions is optional and may be assigned in any order.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Joseph Shifflett <joseph.shifflett@hpe.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18575 6f19259b-4bc3-4df7-8a09-765794883524
MdeModulePkg: exit pci function loops early if device is not multi-function
When looping through all PCI functions, code should not look for functions
1-7 if function 0 is not present or if function 0 indicates the device is
not multifunction. Prior to this fix the code would use stale data in a
buffer to determine if a device is multifunction even if function 0 is not
present. This fixes a code bug and provides very small performance
improvements.
PCI 2.3 Specification states: They [multifunction devices] are also
required to always implement function 0 in the device. Implementing other
functions is optional and may be assigned in any order.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Joseph Shifflett <joseph.shifflett@hpe.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18574 6f19259b-4bc3-4df7-8a09-765794883524
Sudeep Holla [Tue, 6 Oct 2015 14:05:37 +0000 (14:05 +0000)]
ArmPlatformPkg/ArmJunoPkg/Madt.aslc: Fix MADT header version
Currently the MADT signature and revision is mapped to v1.0 macros
which results in MADT with incorrect entries in the header for Juno.
This patch fixes these EFI_ACPI_*_0_MULTIPLE_APIC_DESCRIPTION_TABLE
macros by using appropriate v5.0 versions.
Ard Biesheuvel [Tue, 6 Oct 2015 12:51:07 +0000 (12:51 +0000)]
ArmPkg/AArch64Mmu: remove cache maintenance for page tables
All our page tables are allocated from memory whose cacheability
attributes are inherited by the cacheability bits in the MMU control
register, so there is no need for explicit cache maintenance after
updating the page tables. And even if there were, Set/Way operations
are not appropriate anyway for ensuring that these changes make it to
main memory. So just remove the explicit cache maintenance completely.
Ard Biesheuvel [Fri, 2 Oct 2015 14:48:30 +0000 (14:48 +0000)]
BaseTools/AARCH64: use large code model for GCC <= 4.8
As it turns out, upstream GCC only supports the AArch64 'tiny' code
model as of version 4.9. Since the default 'small' code model requires
4 KB section alignment (which is undesirable for the XIP modules),
revert GCC 4.7 and 4.8 to using the 'large' code model instead.
Ard Biesheuvel [Fri, 2 Oct 2015 14:48:21 +0000 (14:48 +0000)]
ArmPkg/Mmu: do not configure block translations at level 0
Now that the AArch64 MMU code correctly identifies and handles
naturally aligned regions of more than 2 MB in size, it will happily
try to use block mappings at level 0 to map huge memory regions, such
as the single cacheable 1:1 mapping we use for Xen domU to map the
entire PA space. However, block mappings are not supported at level 0
so the resulting translation tables will be incorrect, causing
execution to fail as soon as the MMU is enabled.
So use level 1 as the minimum level at which to perform block
translations.
Ard Biesheuvel [Thu, 1 Oct 2015 14:01:24 +0000 (14:01 +0000)]
ArmVExpressPkg: use 4 KB section alignment for ARM DXE_RUNTIME_DRIVER modules
In order to support the Properties Table memory protection feature
on 32-bit ARM, build DXE_RUNTIME_DRIVER type binaries with 4 KB section
alignment by setting the common-page-size linker command line option.
Ard Biesheuvel [Thu, 1 Oct 2015 14:01:16 +0000 (14:01 +0000)]
ArmVirtPkg: use 4 KB section alignment for ARM DXE_RUNTIME_DRIVER modules
In order to support the Properties Table memory protection feature
on 32-bit ARM, build DXE_RUNTIME_DRIVER type binaries with 4 KB section
alignment by setting the common-page-size linker command line option.
Ard Biesheuvel [Thu, 1 Oct 2015 14:01:07 +0000 (14:01 +0000)]
BaseTools/ARM: move to unified GCC linker script
Instead of using the ARM builtin linker script for GNU ld, use the
new unified one instead. This will allow us to increase the section
alignment for DXE_RUNTIME_MODULEs, which is a prerequisite for
enabling the UEFIv2.5 Properties Table memory protection feature.
OvmfPkg: set 4 KB section alignment for DXE_RUNTIME_DRIVER modules
Increase the section alignment to 4 KB for DXE_RUNTIME_DRIVER modules.
This allows the OS to map them with tightened permissions (i.e., R-X for
.text and RW- for .data). This is a prerequisite for enabling the
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA (sic)
feature that was introduced in UEFIv2.5.
The input length should be "The size, in bytes, of Buffer.",
the divide sizeof (UINT16) operation is not needed and incorrect.
Cc: David Wei <david.wei@intel.com> Cc: Tim He <tim.he@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: David Wei <david.wei@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18563 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng [Wed, 30 Sep 2015 04:30:34 +0000 (04:30 +0000)]
IntelFrameworkModulePkg GenericBdsLib: Do not assume perf entry count has no change
Current implementation assumes the performance entry count has no change from
multiple GetPerformanceMeasurement() while loops, it may cause the allocated buffer
for PerfEntriesAsDxeHandle at the first loop to be overflowed if the following loop has
the count changed.
This patch is also to sync the change at
commit R18417 "MdeModulePkg: Fix a performance data buffer overrun issue".
Cc: Ruiyu Ni <ruiyu.ni@intel.com> 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: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18562 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng [Wed, 30 Sep 2015 04:29:50 +0000 (04:29 +0000)]
MdeModulePkg UefiBootManagerLib: Do not assume perf entry count has no change
Current implementation assumes the performance entry count has no change from
multiple GetPerformanceMeasurement() while loops, it may cause the allocated buffer
for PerfEntriesAsDxeHandle at the first loop to be overflowed if the following loop has
the count changed.
This patch is also to sync the change at
commit R17851 "IntelFrameworkModulePkg GenericBdsLib: Resolve array size mismatch".
Cc: Ruiyu Ni <ruiyu.ni@intel.com> 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: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18561 6f19259b-4bc3-4df7-8a09-765794883524
MdeModulePkg Ip4Dxe: Ip4Config2 to request DHCP Option6 DNS server IP
Ip4Config2 protocol implementation must request for DNS server info when the
policy is set to DHCP. And when a DHCP server responds to it with a list of
DNS server addresses, it must parse it and set it for the instance. Without
this, nobody can do a Ip4Config->GetData for DNS server IPs before calling
Dns->Configure(). This will mean a DHCP is initiated when calling
Dns->Configure(), thus causing serious performance issues. This patch
attempts to address this issue.
MdeModulePkg: Add SMBIOS 3.0 support in NetLibGetSystemGuid.
NetLibGetSystemGuid gets the UUID from SMBIOS table to use as the System GUID
(in DHCP and other network use cases). This change adds support to get the
UUID from either SMBIOS 2.x or 3.0, since SMBIOS 3.0 uses a different GUID in
the System Configuration Table.
Ruiyu Ni [Tue, 29 Sep 2015 06:35:33 +0000 (06:35 +0000)]
ShellPkg: Add a simple case to test shell parameter parsing logic
TestArgv.nsh is a very simple shell script to test how the interpreter parses
the parameters. It uses ShellCTestApp.efi to dump the parameters passed from the
interpreter.
TestArgv.log is the desired output created using "TestArgv.nsh > TestArgv.log".
Build all the optional libraries unconditionally so we can catch changes and how they affect the package regardless of the NO_SHELL_PROFILES,
INCLUDE_DP, and INCLUDE_TFTP_COMMAND settings.
MdePkg: remove redundant handling of EFI_IMAGE_REL_BASED_DIR64 relocations
There is AARCH64 specific code in the PE/COFF loader to handle relocations
of type EFI_IMAGE_REL_BASED_DIR64 which is dead code since this type is
handled by generic code and never handed to the AARCH64 specific routine.
So remove it.
ArmVirtPkg: build the TFTP command into the UEFI shell
The TFTP command is easy to use, it has very nice documentation
(accessible with "HELP TFTP" in the shell), and it's a very versatile
tool for downloading files from the host to the guest, via virtual
network, while the guest is in the UEFI shell.
Even better, enabling this command in the shell increases the
uncompressed FVMAIN size only by 8192 bytes, in my AARCH64 build of
VirtArmQemu.dsc, and the final size increase (after LZMA compression)
that is visible in the FVMAIN_COMPACT volume is merely 1976 bytes.
OvmfPkg: build the TFTP command into the UEFI shell
The TFTP command is easy to use, it has very nice documentation
(accessible with "HELP TFTP" in the shell), and it's a very versatile tool
for downloading files from the host to the guest, via virtual network,
while the guest is in the UEFI shell.
Even better, enabling this command in the shell increases the uncompressed
DXEFV size only by 12896 bytes, in my X64 build, and the final size
increase (after LZMA compression) that is visible in the FVMAIN_COMPACT
volume is merely 2576 bytes.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18554 6f19259b-4bc3-4df7-8a09-765794883524
Add the missing EFIAPI calling convention to the CheckPacket() function.
Without it, the gcc build breaks due to the incompatible pointer
assignment in "Mtftp4Token.CheckPacket = CheckPacket".
Ye Ting [Fri, 25 Sep 2015 03:51:46 +0000 (03:51 +0000)]
NetworkPkg:Fix iSCSI driver issue to work with iSCSI LIO target
The patch fixes iSCSI driver can't reinstate itself when configured
in AutoConfigure mode and IPv6 stack is actually used.
The issue occurs when iSCSI driver communicates with
iSCSI LIO target in IPv6 path and the target sends
back TCP FIN packets randomly.
ArmVirtPkg: VirtFdtDxe: detect fw-cfg DMA interface from the DTB
A DMA-like transfer interface has recently been implemented in QEMU for
fw-cfg. For ARM and AARCH64 virtual machines, the binding prescribes a new
8-byte wide register at offset 0x10 in the register block. Make VirtFdtDxe
expose this register if it is present.
Please see "docs/specs/fw_cfg.txt" in the QEMU tree for more information.
Disable the RVCT size optimization that may put sections at an offset
that is not aligned to their own alignment, by adding the --no_legacyalign
switch to the RVCT linker command line. This is necessary since such sections
cannot be correctly converted into PE/COFF sections without padding them at
the front, which defeats the purpose of the optimization anyway.
With the optimization gone, we can also remove the special case for ARM in
GenFw that could result in corrupt PE/COFF images to be emitted. Instead,
sections whose base address is not aligned correctly are outright rejected.
BaseTools/GenFw: remove ARM and RVCT references from ELF64 code
ARM and RVCT apply to 32-bit code only, so remove any references
to them (including the workaround for the linker) from the 64-bit
version of ElfConvert.c
ArmPkg/CpuDxe: Disable interrupt before restoring context
Interrupt must be disabled before we storing ELR and other system
registers, or else ELR will be overridden by interrupt reentrance.
This bug is critical as we may get occasional exception or dead loop
when interrupt reentrance occurs:
After increasing SP ... Before popping out registers
Or
After restoring ELR
The 1st circumstance could also be resolved by optimizing SP operation
(Pop out registers before adding SP back), but the 2nd could not be
resolved by disabling interrupt.
ArmVirtPkg: reduce preallocation of boot services data pages
Commit SVN r18503 ("MdeModulePkg DxeCore: Take the range in resource
HOB for PHIT as higher priority") changed the GCD init logic to take
the sum of the region sizes in gMemoryTypeInformation[] into account
when estimating the minimal amount of memory needed to boot the system.
Unfortunately, as an unintended side effect, this change results in boot
failures of ArmVirtQemu when running with QEMU's default memory size of
128 MB. The reason is that the sum of the gMemoryTypeInformation region
sizes plus the size of the inital PEI region exceeds 128 MB. Since we do
not actually need to preallocate 20,000 pages' worth of BootServicesData
memory, reduce this figure to the more reasonable 12,000.
In this patch, we replace the traditional IDE driver stack that comes from
PcAtChipsetPkg and IntelFrameworkModulePkg with more featureful drivers
from OvmfPkg and MdeModulePkg. The resultant driver stack is compatible
with the previous one, but provides more protocols, on more kinds of
virtual hardware.
Remove the dependent:
- IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
(removing EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3])
As replacement, add:
- OvmfPkg/SataControllerDxe/SataControllerDxe.inf
(supplying EFI_IDE_CONTROLLER_INIT_PROTOCOL [1])
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
(providing EFI_ATA_PASS_THRU_PROTOCOL,
EFI_EXT_SCSI_PASS_THRU_PROTOCOL)
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
(supplying EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3],
providing EFI_BLOCK_IO2PROTOCOL,
EFI_STORAGE_SECURITY_COMMAND_PROTOCOL)
Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de>
[lersek@redhat.com: rewrote commit message]
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18532 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: QemuBootOrderLib: recognize Q35 SATA disks / CD-ROMs
The OpenFirmware device paths that QEMU generates for these disks and
CD-ROMs are very similar to those generated for the i440fx IDE disks and
CD-ROMs (including the same number of devpath nodes necessary for unique
parsing). The interpretations and the translation to UEFI devpath
fragments are different, of course.
(The spaces after "ide@1,1" are inserted below only for illustration
purposes.)
primary or secondary
| master or slave
v v
i440fx IDE: /pci@i0cf8/ide@1,1 /drive@0/disk@0
Q35 SATA: /pci@i0cf8/pci8086,2922@1f,2/drive@1/disk@0
^ ^
| device number
| (fixed 0)
channel (port) number
The similarity is reflected in the translation output (spaces again
inserted for illustration only):
i440fx IDE: PciRoot(0x0)/Pci(0x1,0x1) /Ata(Primary,Master,0x0)
Q35 SATA: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)
^ ^ ^
| | LUN;
| | always 0 on Q35
| port multiplier port
| number; always 0 on Q35
channel (port) number
Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18531 6f19259b-4bc3-4df7-8a09-765794883524
PcAtChipsetPkg: IdeControllerDxe: fix protocol usage hints in the INF file
IdeControllerDxe installs EFI_IDE_CONTROLLER_INIT_PROTOCOL interface(s),
and consumes PciIo. The comments in the INF file state the opposite at the
moment, fix them.
Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18530 6f19259b-4bc3-4df7-8a09-765794883524
MdeModulePkg: AtaAtapiPassThru: select master/slave around DIAG command
Some IDE controllers only update ID fields such as sector information on
specific commands such as the DIAG command.
The master/slave device is therefore selected both before and after
sending the DIAG command; otherwise reading the IDE registers yields the
master's ID fields.
(Reza's patch originally *moved* the master/slave selection from after the
DIAG command before it, however Feng asked for the original master/slave
select to be preserved; effectively making the master/slave select
*bracket* the DIAG command. See this subthread:
<http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10545/focus=10550>.)
Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de>
[feng.tian@intel.com: see above]
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Feng Tian <feng.tian@intel.com>
[lersek@redhat.com: updated commit message]
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18529 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: SataControllerDxe: enable IO / mem access and DMA when binding
When we bind the SATA controller in SataControllerStart(), we read the NP
("Number of Ports") bitfield from the CAP ("HBA Capabilities") register of
the controller. (See the AHCI 1.3.1 spec.)
This register is memory mapped. If we'd like to access it, we must at
least enable memory space access for the device. In addition, Feng Tian
recommended enabling Bus Master DMA in
<http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10545/focus=10659>.
We also enable IO space access for completeness.
Further, because we change the PCI attributes of the device with the above
when binding it, we must also restore its original PCI attributes when
unbinding it. See the Driver Writer's Guide for UEFI 2.3.1 v1.01, section
18.3 "PCI drivers" | 18.3.2 "Start() and Stop()".
(OvmfPkg's copy of SataControllerDxe differs from the same in DuetPkg
because Duet inherits a pre-configured SATA controller from the BIOS, as
explained by Feng. Technically, DuetPkg's SataControllerDxe could also
apply the technique seen in this patch.)
Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Cc: Feng Tian <feng.tian@intel.com> Suggested-by: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18528 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: SataControllerDxe: add cascading error handling to Start()
In the next patch we'll add another PCI operation to
SataControllerStart(), which, on error, has to be rolled back similarly to
other actions already being done in SataControllerStart(). Since that PCI
operation won't provide a non-NULL pointer on success, its rollback isn't
really suitable for the current error handling in SataControllerStart().
Employ the traditional cascading labels instead.
Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18527 6f19259b-4bc3-4df7-8a09-765794883524
Edk2 maintainers reached the consensus that SataControllerDxe was
inherently platform specific, for which reason it was not appropriate for
either PcAtChipsetPkg nor MdeModulePkg. Hence, if OvmfPkg wanted to use
it, it should either reference it directly from under DuetPkg, or copy it.
Given that DuetPkg is another "leaf" platform in edk2, and that in the
upcoming patches we'll actually modify the driver, the ultimate decision
(reached months ago on the list, after Reza's v2 posting) is that OvmfPkg
shall copy the driver.
This patch does that; the only difference being a fresh FILE_GUID in the
INF file.
Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de>
[lersek@redhat.com: updated commit message, generated fresh FILE_GUID]
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18526 6f19259b-4bc3-4df7-8a09-765794883524
Each one of the DisqualifiedModes, IdentifyData and IdentifyValid arrays
in the EFI_SATA_CONTROLLER_PRIVATE_DATA structure is a matrix, represented
as a flat array.
The code currently uses the incorrect formula
Channel * Device
to index them. The right formula is
[Channel][Device]
which can be implemented as
Channel * NumDevicePerChannel + Device
Add a helper function that does this, and replace the incorrect
subscripts.
Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Cc: Feng Tian <feng.tian@intel.com> Reported-by: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18525 6f19259b-4bc3-4df7-8a09-765794883524
Qin Long [Mon, 21 Sep 2015 05:54:03 +0000 (05:54 +0000)]
MdePkg: Add RngLib into MdePkg
Add one library class (RngLib.h) with three GetRandomNumber16/32/64
APIs to provide random number generator services, and one library
instance (BaseRngLib), based on Intel RdRand instruction access,
to provide high-quality random numbers generator.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qin Long <qin.long@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18519 6f19259b-4bc3-4df7-8a09-765794883524
MdeModulePkg: Remove event from protocol database only if registered
In a CloseEvent, an UnregisterProtocolNotify is done unconditionally.
There is a penalty associated with searching the protocol database on
every CloseEvent and impacts performance, especially during Network IO.
Unregister needs to be done only if the Event is for a RegisterProtocolNotify.
So extend the ExFlag in IEVENT to a UINT8 and define new flags that can
be set to indicate if the Event is part of a group, or registered on a
protocol notify. Then in CloseEvent, call UnregisterProtocolNotify only
if the register protocol notify flag is set.
ArmVirtPkg: PlatformIntelBdsLib: signal ReadyToBoot on direct kernel boot
According to the UEFI spec, EFI_EVENT_GROUP_READY_TO_BOOT "is notified by
the system when the Boot Manager is about to load and execute a boot
option". ArmVirtPkg doesn't do this currently when launching a kernel from
the QEMU command line. OvmfPkg does (see git commit 28a34033ee).
At least two edk2-wide callbacks are worth mentioning:
- OnReadyToBoot() in
"MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c" performs
variable reclaim and (optionally) installs variable usage statistics as
a vendor config table;
- OnReadyToBoot() in
"SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c"
installs the image execution info table if it doesn't exist yet, in
SecureBoot-enabled builds.
The binaries of ShellBinPkg are generated with ShellPkg project 18507. The binaries are built with no debug information by building with "RELEASE" target.
Star Zeng [Fri, 18 Sep 2015 02:02:11 +0000 (02:02 +0000)]
MdeModulePkg DxeCore: Take the range in resource HOB for PHIT as higher priority
Take the range in the resource descriptor HOB for the memory region described
by the PHIT as higher priority if it is big enough. It can make the memory bin
allocated to be at the same memory region with PHIT that has more better compatibility
to avoid memory fragmentation for some code practices assume and allocate <4G ACPI memory.
Also let the minimal memory size needed include the total memory bin size needed to
make sure memory bin could be allocated successfully.
Cc: Jiewen Yao <jiewen.yao@intel.com> 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: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18503 6f19259b-4bc3-4df7-8a09-765794883524
1. Fix GCC build fail.
2. It's not correct to cast away constness to allow TrimSpaces() to modify 'commandline'.
This patch makes a copy of 'commandLine' and work with that in the remainder of the function.
Star Zeng [Thu, 17 Sep 2015 08:32:14 +0000 (08:32 +0000)]
MdeModulePkg DxeCore: Relocate HOB List after other tested memory resources added
The HOB List relocation should be at after all the tested memory resources added
(except the memory space that covers HOB List) to the memory services,
because the memory resource found in CoreInitializeMemoryServices()
may have not enough remaining resource for HOB List.
And the memory space that covers HOB List should be processed
after HOB List relocation to avoid the resources allocated by others
to corrupt HOB List before its relocation.
Cc: Jiewen Yao <jiewen.yao@intel.com> 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: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18499 6f19259b-4bc3-4df7-8a09-765794883524
Dandan Bi [Thu, 17 Sep 2015 07:21:22 +0000 (07:21 +0000)]
MdeModulePkg:Fix the bug the incorrect change of StrCpyS function
The pointer to the destination string changed,the max length also changed.Previous change neglect this point.
And base on the code logic,we can use StrCatS to replace StrCpyS.Now this patch is to fix this bug.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18497 6f19259b-4bc3-4df7-8a09-765794883524
Yang Jadis [Thu, 17 Sep 2015 01:42:59 +0000 (01:42 +0000)]
ShellPkg: Fix Shell fail when execute command in ShellProtocol.Execute().
When execute a command with tailing blank spaces in ShellProtocol.Execute() Shell will fail.
This patch move the TrimSpaces operation into ParseCommandLineToArgs function to fix the problem.
NetworkPkg: Fix connection issue after correct SPD and re-enable IPsec
This patch is used to fix connection failure issue after correct the SPD
and re-enable IPsec. The driver should not update the SadEntry's SpdSelector
when doing SpdEntry modification. SadEntry's SpdSelector may not equal to
this edited SpdEntry’s Selector.
Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18484 6f19259b-4bc3-4df7-8a09-765794883524
SecurityPkg: Reduce verbosity of TPM DEBUG messages
Some of the TPM/TPM2 DEBUG messages are at EFI_D_INFO level,
even though they are simply tracing functions that run on every boot even
if there is no TPM installed. Changed verbosity to EFI_D_VERBOSE.
(PcdSetNxForStack == TRUE) breaks a number of GRUB versions that, it turns
out, are still widely in use. Disable PcdSetNxForStack by default for now.
QEMU users can enable it dynamically using the micro-feature added in the
previous patch.
Reported-by: Anthony Perard <anthony.perard@citrix.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Ian Campbell <Ian.Campbell@citrix.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Josh Triplett <josh@joshtriplett.org>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ian Campbell <Ian.Campbell@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18472 6f19259b-4bc3-4df7-8a09-765794883524
The macro trickery is not optimal, but it is caused by PcdSetBool(), which
is itself a macro, and can only take open-coded PCD names (ie. no
variables, like function parameters).
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18471 6f19259b-4bc3-4df7-8a09-765794883524
Since PcdPropertiesTableEnable is used by the DXE Core (in the
InstallPropertiesTable() function, which runs at End-of-Dxe), we must also
change the PcdLib class resolution for that module, from the default
BasePcdLibNull to DxePcdLib.
Traditionally we've considered the DXE Core to be incapable of accessing
dynamic PCDs -- the PCD PPI is not available any longer to the DXE Core,
and the PCD Protocol is not available to it *yet*. There are exceptions
however: if the DXE Core can ensure, by whatever means, that the PCD
Protocol *is* available, then DxePcdLib will just work (the latter even
lists DXE_CORE as an allowed client module type). Namely, DxePcdLib looks
up the PCD Protocol dynamically, on the first library call that actually
needs it (for accessing a dynamic PCD); the lookup doesn't occur in a
library constructor.
And because the DXE Core fetches PcdPropertiesTableEnable at End-of-Dxe,
the PCD Protocol is definitely available then.
In addition, we change the default value of PcdPropertiesTableEnable from
the inherited TRUE to FALSE. It makes no difference at this point (our
runtime DXE drivers are not built with the required 4KB section alignment
anyway), but it's better to be clear about this. The properties table
feature requires OS compatibility, and it breaks Windows 7 minimally.
Therefore the default should be FALSE.
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18470 6f19259b-4bc3-4df7-8a09-765794883524
Plus, because PcdSetNxForStack is used by the DXE IPL PEIM (in the
HandOffToDxeCore() function, and in the CreateIdentityMappingPageTables()
function called by the former), we must change the PcdLib class resolution
for that module, from the default BasePcdLibNull to PeiPcdLib.
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18469 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng [Tue, 15 Sep 2015 07:49:12 +0000 (07:49 +0000)]
MdeModulePkg PiDxeS3BootScriptLib: Remove a hidden assumption.
What to do:
1. Remove a hidden assumption "No SMM driver writes BootScript between
SmmReadyToLock and S3SleepEntryCallback".
1.1. Use SmmExitBootServices and SmmLegacyBoot notification to record
AtRuntime flag.
1.2. Use mBootScriptDataBootTimeGuid LockBox to save boot time boot
script data to handle potential INSERT boot script at runtime in SMM.
2. Do not depend on OS to help restore ACPINvs data and use
EfiReservedMemoryType instead of EfiACPIMemoryNVS.
2.1. Use mBootScriptSmmPrivateDataGuid LockBox to save boot script
SMM private data with BackFromS3 = TRUE at runtime. S3 resume
will help restore it to tell the Library the system is back
from S3.
Why to do:
1. The hidden assumption "No SMM driver writes BootScript between
SmmReadyToLock and S3SleepEntryCallback" will cause confusion to
the library's consumer and block the usage of "SMM driver writes
BootScript after SmmReadyToLock". So Remove the assumption.
2. In original code, there might be a corner case that malicious
code patch ACPINvs boot TableLength field same as SMM boot script.
So that it can skip the table restore. The impact is that BootScript
in SMM may be overridden by malicious code.
--------------------
CopyMem ((VOID*)&TableHeader, (VOID*)mS3BootScriptTablePtr->TableBase, sizeof(EFI_BOOT_SCRIPT_TABLE_HEADER));
if (mS3BootScriptTablePtr->TableLength + sizeof(EFI_BOOT_SCRIPT_TERMINATE) != TableHeader.TableLength) { // TableLength is in NVS
......
//
// NOTE: We should NOT use TableHeader.TableLength, because it is already updated to be whole length.
//
mS3BootScriptTablePtr->TableLength = (UINT32)(mLockBoxLength - sizeof(EFI_BOOT_SCRIPT_TERMINATE)); ? This line can be skipped.
--------------------
So use EfiReservedMemoryType instead of EfiACPIMemoryNVS as the code
has been updated to not depend on OS to help restore ACPINvs data.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18467 6f19259b-4bc3-4df7-8a09-765794883524
Fu Siyuan [Tue, 15 Sep 2015 03:12:15 +0000 (03:12 +0000)]
MdeModulePkg: Change the algorithm in SNP to use the first found BAR index.
The driver binding start function in SNP.c goes through all the BARs and get
the last BAR index for use. Theoretically it should work with all valid BARs,
but we got reports some device did always use the first valid BAR, so we change
the logic in SNP to use the first found BAR index instead of the last one.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18455 6f19259b-4bc3-4df7-8a09-765794883524
ShellPkg: Update the help information for 'setvar' command to follow Shell behavior.
Since Shell will remove the quotes in parameters, setvar cannot receive the quotes from ="ascii" or =L"unicode". User should add ^ to escape quotes in setvar data.
Fu Siyuan [Mon, 14 Sep 2015 09:05:12 +0000 (09:05 +0000)]
NetworkPkg: Update cache management in HTTP boot driver.
The original HTTP boot driver always save the received message body in its cache,
it bring a large of memory allocation during HTTP download. This patch updates
the HTTP boot driver to only cache data when caller doesn't provide a buffer for
download (which is usually used when caller want to get the required buffer size).
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18448 6f19259b-4bc3-4df7-8a09-765794883524
Fu Siyuan [Mon, 14 Sep 2015 09:04:25 +0000 (09:04 +0000)]
NetworkPkg: Enlarge receive block size of HTTP boot driver.
HTTP boot driver uses block size of 1024 when receiving HTTP message body,
but typically the MTU of Ethernet is 1500 bytes so it makes 1 TCP segment data
split into 2 Http.Response call. This patch enlarges the block size to avoid
this issue.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18447 6f19259b-4bc3-4df7-8a09-765794883524
SVN commit r18077 ("BaseTools/GenFw: move .debug contents to .data to
save space") removed the separate .debug section after moving its
contents into .text or .data. However, this change does not take into
account that some of these contents need to appear at a 32-bit aligned
offset. So align the debug data RVA to 32 bits.
MdeModulePkg: ScsiDiskDxe: adapt SectorCount when shortening transfers
The specification of the EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru()
function documents the EFI_BAD_BUFFER_SIZE return status, and the
EFI_EXT_SCSI_STATUS_HOST_ADAPTER_DATA_OVERRUN_UNDERRUN host adapter
status.
These allow an EFI_EXT_SCSI_PASS_THRU_PROTOCOL implementation to request
higher layers in the stack (in this instance, UefiScsiLib and ScsiDiskDxe)
to break up the transfer into smaller pieces.
These conditions percolate up the stack correctly: the retry loops in
ScsiDiskDxe's ScsiDiskReadSectors() and ScsiDiskWriteSectors() functions
correctly and transparently update the transfer size (ByteCount),
accommodating any shortening requested by lower levels of the stack. After
the loop -- if the request ultimately succeeds -- SectorCount is even
recalculated from the final ByteCount, to see how many sectors the outer
loop should advance.
However, the inner (ie. retry) loops both have the same error: when the
underlying protocols request the transfer to be shortened, the decrease in
transfer size (ie. ByteCount) should immediately be reflected in
SectorCount. Otherwise the sector count encoded in the CDB will exceed the
transfer size, which is a permanent error.
Cdb: 28 00 00 00 25 DD 00 FF FF 00
^ ^^^^^^^^^^^ ^^^^^
| | |
| | number of 2KB sectors to read,
| | corresponding to 2048 * 65535 = 134215680 bytes
| | (see InTransferLength above)
| |
| LBA to read from
|
READ (10)
(2) In turn, the EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru() function
provided by "OvmfPkg/VirtioScsiDxe/VirtioScsi.c" asked for the request
to be shortened:
(3) Then ScsiDiskReadSectors() in
"MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c" retried the request
with correctly shortened transfer length, but incorrectly unchanged
sector count:
Timeout=940000000
CdbLength=10
DataDir=Read
InTransferLength=16776704 <--- updated as requested
OutTransferLength=0
SenseDataLength=108
(4) Since 65535 sectors of 2KB each wouldn't fit in a buffer of approx.
16MB, QEMU's virtio-scsi controller unconditionally rejected this
request with VIRTIO_SCSI_S_OVERRUN, which VirtioScsiDxe then mapped
to:
functions allows us to retry these operations from ScsiDiskReadSectors()
and ScsiDiskWriteSectors(), with adjusted transfer sizes, without
investigating further error details like Host Adapter Status, Target
Status, and Sense Data.
NetworkPkg: PXE Driver's LoadFile protocol should check FilePath
PXE driver's LoadFile protocol should check the input parameter
FilePath to see whether it's a supported device path.If not,
it should return invalid parameter, do not continue PXE boot.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo <lubo.zhang@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18436 6f19259b-4bc3-4df7-8a09-765794883524
projects / mirror_edk2.git / log