The BOOLEAN IsFinal variable initialization isn't properly seen by
MSVC. To make it compile OVMF the variable needs to be initialized.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Mauro Faccenda <faccenda@gmail.com>
Reviewed-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@15214 6f19259b-4bc3-4df7-8a09-765794883524
This duplicate message was intended to be removed from r15207
before it was committed. (It was pointed out by Wei Liu.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15213 6f19259b-4bc3-4df7-8a09-765794883524
BootMonFs (file system used on the VExpress NOR Flash) is now supported on
both NOR Flash regions.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15209 6f19259b-4bc3-4df7-8a09-765794883524
The function ArmWriteVBar had a UINT32 parameter.
Need to change it to UINT.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15208 6f19259b-4bc3-4df7-8a09-765794883524
In the next commit we will update the Xen boot path
to also use this function.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15206 6f19259b-4bc3-4df7-8a09-765794883524
This will be called from a unified MemDetect function.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15203 6f19259b-4bc3-4df7-8a09-765794883524
The typo was a check for the string "BaseTool" instead of "BaseTools".
Also fixed the issue where the script returned success even when
configuration failed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15200 6f19259b-4bc3-4df7-8a09-765794883524
Once we support ACPI S3, then we can restore this to
being allocated as ACPI NVS memory.
At that time we should also have a way to disable
S3 support in QEMU. When we detect that S3 is
disabled in QEMU, then we can allocate this as regular
Boot Services Data memory.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bill Paul <wpaul@windriver.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15198 6f19259b-4bc3-4df7-8a09-765794883524
When this option is passed to qemu, it appends the word HALT to the
"bootorder" fw_cfg file, as last entry. For example,
/pci@i0cf8/ethernet@3/ethernet-phy@0
/pci@i0cf8/scsi@4/disk@0,0
HALT
The option's purpose is to prevent SeaBIOS from booting from devices that
have not been specified explicitly (with bootindex=N device properties nor
-boot options). When SeaBIOS sees HALT, it doesn't proceed to boot from
default locations (after boot fails from all of the listed locations).
The HALT string currently causes OVMF to reject the entire "bootorder"
fw_cfg contents, with "parse error". This is not good, because since a
recent libvirt commit, libvirt unconditionally passes "-boot strict=on" to
qemu. Consequently, the boot order logic in QemuBootOrder.c has stopped
working for libvirt users.
OVMF's SetBootOrderFromQemu() function actually implements the idea behind
"-boot strict=on": it drops all boot options not in the fw_cfg list. (*)
Therefore, let's recognize HALT, and just do what we've been doing all
along.
(*) Except the UEFI shell, according to the survival policy in
BootOrderComplete(), but the memory mapped UEFI shell is not expressible
via fw_cfg anyway, and its preservation has been requested on edk2-devel.
Hence it's a good boot option to keep in any case.
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@15197 6f19259b-4bc3-4df7-8a09-765794883524
This will be needed to update the boot flow for S3 resume.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15196 6f19259b-4bc3-4df7-8a09-765794883524
The Xen and QEMU/KVM paths were calling this at nearly
the same time in the boot flow anyhow, so just make
the call in one spot.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15195 6f19259b-4bc3-4df7-8a09-765794883524
And, update NameString IScsiDxeStrings[] to IScsi4DxeStrings[] to match its BASE_NAME
Signed-off-by: Gao, Liming <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15186 6f19259b-4bc3-4df7-8a09-765794883524
If the structure layout in UsbBusPei is changed, then the UsbBotPei will not work.
1. As the maximum number of endpoints is 16, use UINT16 type rather than UINT8 for DataToggle.
2. DataToggle needs to be reset to 0 when endpoint stall is cleared, do it in PeiUsbControlTransfer().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15185 6f19259b-4bc3-4df7-8a09-765794883524
This means we can use ShellExecute without thinking which shell
environment is in use. However it still isn't ideal: if
mEfiShellEnvironment2->Execute returns EFI_INVALID_PARAMETER, we can't tell
whether Execute() received an invalid parameter (e.g. ParentImageHandle was
NULL), or whether we tried to execute a command with an invalid parameter
(for example CommandLine "ls -hurdygurdy").
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brendan Jackman <Brendan.Jackman@arm.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jaben Carsey <Jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15183 6f19259b-4bc3-4df7-8a09-765794883524
Due to the ASSERT_EFI_ERROR, this patch is necessary only to ensure specified
behaviour in RELEASE builds.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brendan Jackman <Brendan.Jackman@arm.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jaben Carsey <Jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15181 6f19259b-4bc3-4df7-8a09-765794883524
When the exit status of the command run by the shell is other than
SHELL_SUCCESS, the shell image will now exit with EFI_ABORTED, placing the
commands exit status (which is a SHELL_STATUS) in ExitData.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brendan Jackman <Brendan.Jackman@arm.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jaben Carsey <Jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15180 6f19259b-4bc3-4df7-8a09-765794883524
This has no change in the behavior of the LS command, but it removes the printing logic from the main recursive function. This is the first step toward changing the code flow without affecting the look and feel.
The long term goal is correcting the recursion to be more clean and useful to users.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15179 6f19259b-4bc3-4df7-8a09-765794883524
Update the LastBlockEntry return value when allocating a new page table block
and the parent page table entry is not valid. Discovered when producing page
table entries for a memory region that spans multiple page table entries of a
parent page table block. Not very memory space efficient because the rest of
the code could calculate a required page level that is deeper than some blocks
of the memory region might require. Case that found the problem:
MemoryRegion->VirtualBase = 0
MemoryRegion->Length = 0x7F000000
This fix will create an un-needed level of page table for address
range 0 -> 0x40000000
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
Reviewed-By: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15177 6f19259b-4bc3-4df7-8a09-765794883524
Linux and its DTB required to be loaded in the first 128MB of the system memory.
Moving UEFI firmware above this limit ensures some XIP runtime code (part of the
UEFI firmware) are not overwritten when loading Linux kernel.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15168 6f19259b-4bc3-4df7-8a09-765794883524
The commit on Fri Dec 6 2013: "ArmPlatformPkg/ArmPlatformStackLib:
Do not directly use PcdArmPrimaryCore" has made the function
ArmPlatformStackSet() overwrites the registers r6 and r7.
These registers are used by PrePi to store the MPIDR and the the base
of the system memory region used by UEFI.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15167 6f19259b-4bc3-4df7-8a09-765794883524