OvmfPkg's file-based NvVar storage is read back as follows at boot (all
paths under OvmfPkg/Library/):
PlatformBdsPolicyBehavior() [PlatformBdsLib/BdsPlatform.c]
PlatformBdsRestoreNvVarsFromHardDisk()
VisitAllInstancesOfProtocol
for each simple file system:
VisitingFileSystemInstance()
ConnectNvVarsToFileSystem() [NvVarsFileLib/NvVarsFileLib.c]
LoadNvVarsFromFs() [NvVarsFileLib/FsAccess.c]
ReadNvVarsFile()
+-------------> SerializeVariablesSetSerializedVariables() [SerializeVariablesLib/SerializeVariablesLib.c]
| SerializeVariablesIterateInstanceVariables()
| +-------------> IterateVariablesInBuffer()
| | for each loaded / deserialized variable:
| +-|-----------------> IterateVariablesCallbackSetSystemVariable()
| | | gRT->SetVariable()
| | |
| | IterateVariablesInBuffer() stops processing variables as soon as the
| | first error is encountered from the callback function.
| |
| | In this case the callback function is
| IterateVariablesCallbackSetSystemVariable(), selected by
SerializeVariablesSetSerializedVariables().
The result is that no NvVar is restored from the file after the first
gRT->SetVariable() failure.
On my system such a failure
- never happens in an OVMF build with secure boot disabled,
- happens *immediately* with SECURE_BOOT_ENABLE, because the first
variable to restore is "AuthVarKeyDatabase".
"AuthVarKeyDatabase" has the EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
attribute set. Since the loop tries to restore it before any keys (PK, KEK
etc) are enrolled, gRT->SetVariable() rejects it with
EFI_SECURITY_VIOLATION. Consequently the NvVar restore loop terminates
immediately, and we never reach non-authenticated variables such as
Boot#### and BootOrder.
Until work on KVM-compatible flash emulation converges between qemu and
OvmfPkg, improve the SECURE_BOOT_ENABLE boot experience by masking
EFI_SECURITY_VIOLATION in the callback:
- authenticated variables continue to be rejected same as before, but
- at least we allow the loop to progress and restore non-authenticated
variables, for example boot options.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14390 6f19259b-4bc3-4df7-8a09-765794883524
DHCP, PXE, and StdLib socket apps are enabled in OVMF by the sum of:
(a) a UEFI NIC driver,
(b) the generic network stack.
The only choice for (a) used to be the proprietary Intel E1000 driver,
which is cumbersome to obtain and enable.
The iPXE UEFI NIC drivers packaged with qemu-1.5 cover (a) for each NIC
type supported by qemu, and are easy to obtain & configure, even for
earlier qemu versions. Therefore enable (b) per default as well.
This doesn't take up much space; the binaries (b) adds to the firmware
don't seem to need -D FD_SIZE_2MB.
Intel's e1000 driver remains an option, requested by the -D E1000_ENABLE
build flag.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14366 6f19259b-4bc3-4df7-8a09-765794883524
The descriptor table (also known as "queue") consists of descriptors. (The
corresponding type in the code is VRING_DESC.)
An individual descriptor describes a contiguous buffer, to be transferred
uni-directionally between host and guest.
Several descriptors in the descriptor table can be linked into a
descriptor chain, specifying a bi-directional scatter-gather transfer
between host and guest. Such a descriptor chain is also known as "virtio
request".
(The descriptor table can host sereval descriptor chains (in-flight virtio
requests) in parallel, but the OVMF driver supports at most one chain, at
any point in time.)
The first descriptor in any descriptor chain is called "head descriptor".
In order to submit a number of parallel requests (= a set of independent
descriptor chains) from the guest to the host, the guest must put *only*
the head descriptor of each separate chain onto the Available Ring.
VirtioLib currently places the head of its one descriptor chain onto the
Available Ring repeatedly, once for each single (head *or* dependent)
descriptor in said descriptor chain. If the descriptor chain comprises N
descriptors, this error amounts to submitting the same entire chain N
times in parallel.
Available Ring Descriptor table
Ptr to head ----> Desc#0 (head of chain)
Ptr to head --/ Desc#1 (next in same chain)
... / ...
Ptr to head / Desc#(N-1) (last in same chain)
Anatomy of a single virtio-blk READ request (a descriptor chain with three
descriptors):
virtio-blk request header, prepared by guest:
VirtioAppendDesc PhysAddr=3FBC6050 Size=16 Flags=1 Head=1232 Next=1232
payload to be filled in by host:
VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=1232 Next=1233
host status, to be filled in by host:
VirtioAppendDesc PhysAddr=3FBC604F Size=1 Flags=2 Head=1232 Next=1234
Processing on the host side -- the descriptor chain is processed three
times in parallel (its head is available to virtqueue_pop() thrice); the
same chain is submitted/collected separately to/from AIO three times:
virtio_queue_notify vdev VDEV vq VQ#0
virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0
virtqueue_pop vq VQ#0 elem EL#1 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#1
virtqueue_pop vq VQ#0 elem EL#2 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#2
virtio_blk_rw_complete req REQ#0 ret 0
virtio_blk_req_complete req REQ#0 status 0
virtio_blk_rw_complete req REQ#1 ret 0
virtio_blk_req_complete req REQ#1 status 0
virtio_blk_rw_complete req REQ#2 ret 0
virtio_blk_req_complete req REQ#2 status 0
On my Thinkpad T510 laptop with RHEL-6 as host, this probably leads to
simultaneous DMA transfers targeting the same RAM area. Even though the
source of each transfer is identical, the data is corrupted in the
destination buffer -- the CRC32 calculated over the buffer varies, even
though the origin of the transfers is the same, never rewritten LBA.
SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=BF68A44D
The problem is invisible on my HP Z400 workstation.
Fix the request submission by:
- building the only one descriptor chain supported by VirtioLib always at
the beginning of the descriptor table,
- ensuring the head descriptor of this chain is put on the Available Ring
only once,
- requesting the virtio spec's language to be cleaned up
<http://lists.linuxfoundation.org/pipermail/virtualization/2013-April/024032.html>.
Available Ring Descriptor table
Ptr to head ----> Desc#0 (head of chain)
Desc#1 (next in same chain)
...
Desc#(N-1) (last in same chain)
VirtioAppendDesc PhysAddr=3FBC6040 Size=16 Flags=1 Head=0 Next=0
VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=0 Next=1
VirtioAppendDesc PhysAddr=3FBC603F Size=1 Flags=2 Head=0 Next=2
virtio_queue_notify vdev VDEV vq VQ#0
virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0
virtio_blk_rw_complete req REQ#0 ret 0
virtio_blk_req_complete req REQ#0 status 0
SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=1EEB2B07
(The Crc32 was double-checked with edk2's and Linux's guest IDE driver.)
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14356 6f19259b-4bc3-4df7-8a09-765794883524
The README is rather extended than trimmed, so that users grepping for the
file name have a pointer.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14243 6f19259b-4bc3-4df7-8a09-765794883524
Also, add a small delay after the 0xCF9 hard reset request -- on qemu/kvm the
port access is translated to the qemu-internal system reset request by the CPU
thread, and it might progress some more before the IO thread acts upon the
system reset request.
MicroSecondDelay() is implemented by OvmfPkg's own AcpiTimerLib.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14158 6f19259b-4bc3-4df7-8a09-765794883524
The reset requested via the keyboard controller (port 0x64) is actually a
soft reset, but qemu has supported it since forever (plus qemu has not
distinguished between hard reset and soft reset, although this is changing
now). Therefore leave the current IoWrite() in place for compatibility.
On qemu versions with commit 1ec4ba74 ("PIIX3: reset the VM when the Reset
Control Register's RCPU bit gets set"), use the PIIX3 RCR as first choice.
In the future qemu will act differently on soft vs. hard reset requests,
and we should honor that in ResetCold().
Writing to ioport 0xCF9 on qemu builds prior to commit 1ec4ba74 should
have no effect. Access to the PCI host config register went through
several implementations in qemu. Commit 9f6f0423 ("pci_host: rewrite
using rwhandler") seems safe, both before and after.
Commit d0ed8076 ("pci_host: convert conf index and data ports to memory
API") inadvertently dropped the alignment/size check, causing a boot
regression on NetBSD. It was fixed about six months later in commit
cdde6ffc, which is current. Translating that to qemu releases, the bug
was visible from v1.0 to v1.1.0.
On physical hardware cycling between reset methods is sometimes necessary
<http://mjg59.dreamwidth.org/3561.html>. On qemu the port access should
trap immediately.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14157 6f19259b-4bc3-4df7-8a09-765794883524
The value to be written corresponds to hard reset, which is what the ACPI
spec prescribes.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14156 6f19259b-4bc3-4df7-8a09-765794883524
This conversion cannot be split very well into smaller patches. Comparing
version 1 and version 2 (modulo the header fields):
> --- EFI_ACPI_1_0_FIXED_ACPI_DESCRIPTION_TABLE
> +++ EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE
> @@ -1,14 +1,14 @@
> EFI_ACPI_DESCRIPTION_HEADER Header;
> UINT32 FirmwareCtrl;
> UINT32 Dsdt;
> - UINT8 IntModel;
> - UINT8 Reserved1;
> + UINT8 Reserved0;
> + UINT8 PreferredPmProfile;
The INT_MODEL field was present in ACPI 1.0, but eliminated in 2.0.
According to the spec, "platforms should set this field to zero but field
values of one are also allowed to maintain compatibility with ACPI 1.0".
We're setting it to zero.
About Preferred_PM_Profile (taking the place of an 1.0 reserved field),
the specification says:
This field is set by the OEM to convey the preferred power management
profile to OSPM. OSPM can use this field to set default power management
policy parameters during OS installation.
>From <MdePkg/Include/IndustryStandard/Acpi20.h>:
#define EFI_ACPI_2_0_PM_PROFILE_UNSPECIFIED 0
#define EFI_ACPI_2_0_PM_PROFILE_DESKTOP 1
#define EFI_ACPI_2_0_PM_PROFILE_MOBILE 2
#define EFI_ACPI_2_0_PM_PROFILE_WORKSTATION 3
#define EFI_ACPI_2_0_PM_PROFILE_ENTERPRISE_SERVER 4
#define EFI_ACPI_2_0_PM_PROFILE_SOHO_SERVER 5
#define EFI_ACPI_2_0_PM_PROFILE_APPLIANCE_PC 6
For a virtual machine, "unspecified" is the best choice.
> UINT16 SciInt;
> UINT32 SmiCmd;
> UINT8 AcpiEnable;
> UINT8 AcpiDisable;
> UINT8 S4BiosReq;
> - UINT8 Reserved2;
> + UINT8 PstateCnt;
We've been already treating this field as PSTATE_CNT. No change in value.
> UINT32 Pm1aEvtBlk;
> UINT32 Pm1bEvtBlk;
> UINT32 Pm1aCntBlk;
> @@ -20,11 +20,11 @@
> UINT8 Pm1EvtLen;
> UINT8 Pm1CntLen;
> UINT8 Pm2CntLen;
> - UINT8 PmTmLen;
> + UINT8 PmTmrLen;
(Field renaming artifact.)
> UINT8 Gpe0BlkLen;
> UINT8 Gpe1BlkLen;
> UINT8 Gpe1Base;
> - UINT8 Reserved3;
> + UINT8 CstCnt;
We've been already treating this field as CST_CNT. No change in value.
> UINT16 PLvl2Lat;
> UINT16 PLvl3Lat;
> UINT16 FlushSize;
> @@ -34,7 +34,19 @@
> UINT8 DayAlrm;
> UINT8 MonAlrm;
> UINT8 Century;
> - UINT8 Reserved4;
> - UINT8 Reserved5;
> - UINT8 Reserved6;
> + UINT16 IaPcBootArch;
> + UINT8 Reserved1;
The first two octets are now merged into a 16-bit short; otherwise we've
been treating those as boot architecture flags already (see SVN rev
13615). No change in value.
> UINT32 Flags;
The fixed feature flags are not modified, only the macro names (expanding
to identical values) are updated to ACPI 2.0.
The following fields are all new in ACPI 2.0:
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE ResetReg;
> + UINT8 ResetValue;
We don't claim support for the reset register yet.
> + UINT8 Reserved2[3];
> + UINT64 XFirmwareCtrl;
> + UINT64 XDsdt;
The 64-bit physical addresses for the FACS and the DSDT are automatically
filled at installation time, see AddTableToList() and DeleteTable() in
"MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c".
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1aEvtBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1bEvtBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1aCntBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1bCntBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm2CntBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPmTmrBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XGpe0Blk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XGpe1Blk;
We specify the extended addresses for the required and supported PM1a
Event & Control, PM Timer, and GPE0 Register Blocks, and zero the rest, in
accordance with the ACPI 1.0 fields.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14155 6f19259b-4bc3-4df7-8a09-765794883524
In the next patch we're going to specify Extended Addresses of register
blocks in Generic Address Structure format. The GAS is easy to fill if we
want to posit either "unsupported" (all zero) or a given address in a
specific address space. However deriving "unsupported" just from a macro
expanding to zero is unwieldy, so let's avoid the need.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14154 6f19259b-4bc3-4df7-8a09-765794883524
Soon we're going to specify Extended Addresses of register blocks in
Generic Address Structure format. The GAS is easy to fill if we want to
posit either "unsupported" (all zero) or a given address in a specific
address space. However deriving "unsupported" just from a macro expanding
to zero is unwieldy, so let's avoid the need.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14153 6f19259b-4bc3-4df7-8a09-765794883524
Soon we're going to specify Extended Addresses of register blocks in
Generic Address Structure format. The GAS is easy to fill if we want to
posit either "unsupported" (all zero) or a given address in a specific
address space. However deriving "unsupported" just from a macro expanding
to zero is unwieldy, so let's avoid the need.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14152 6f19259b-4bc3-4df7-8a09-765794883524
With reference to
<http://sourceforge.net/mailarchive/message.php?msg_id=30359322>:
"MEMFD is built so MAINFV's contents will be relocated during the build to
address 0x800000", and it "is a firmware volume with most OVMF code/data
uncompressed. [...] Increasing its size has a little impact on the size of
the resulting firmware image since the blank part of the firmware volume
will compress well."
Let's increase the size to 8MB, since the current limit can get in the way
(for example when building-in the Intel3.5 drivers for e1000 with
-D FD_SIZE_2MB -D NETWORK_ENABLE -D SECURE_BOOT_ENABLE).
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14133 6f19259b-4bc3-4df7-8a09-765794883524
Usage of the EFI entry point was made feasible in the kernel
x64 boot protocol 2.12 where a 32-bit & 64-bit entry point
became well defined.
http://git.kernel.org/linus/09c205af
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14132 6f19259b-4bc3-4df7-8a09-765794883524
This should be more compatible with AML parsers in practice
since older versions of ACPICA's OS support would not accept
the previous OVMF format (despite being spec compliant).
(For example, on OpenBSD 5.2 it caused a kernel crash)
ACPICA has fixed this issue in:
https://github.com/otcshare/acpica/commit/5869690a
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14130 6f19259b-4bc3-4df7-8a09-765794883524
We cannot specify a pin-GSI connection for the SCI directly in the _PRT
because that implies ActiveLow polarity, clashing with both qemu and the
MADT we prepare.
With this patch the RHEL-6 guest logs the following:
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11)
The patch amends svn rev 13625. Testing it in a RHEL-6 guest, the problems
described in
<http://sourceforge.net/mailarchive/message.php?msg_id=29660862> do not
reappear.
The code is derived from Paolo Bonzini's patch (originally appearing as
SeaBIOS commit f64a472a, "acpi: reintroduce LNKS"). Said original patch is
copyrighted by Red Hat (our common employer), and it has been relicensed
<http://sourceforge.net/mailarchive/message.php?msg_id=30393854> to form
the basis of this derived patch for edk2. The latter is therefore
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14111 6f19259b-4bc3-4df7-8a09-765794883524
Previously for IA32, we would only try to run qemu. Newer releases
of QEMU now have renamed the x86 qemu to qemu-system-i386.
Now, we search for:
1. qemu-system-i386
2. qemu-system-x86_64
3. qemu
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14101 6f19259b-4bc3-4df7-8a09-765794883524
The Xcode assembler is much pickier than GCC. Also the 64-bit
linker is not a fan of relocations so it is better to us IP
relative code, but at least it removes a relocation entry.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish <afish@apple.com>
[jordan.l.justen@intel.com: use .byte for retfq rather than lret]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14055 6f19259b-4bc3-4df7-8a09-765794883524
We're supposed to zero everything in the kernel bootparams that we don't
explicitly initialise, other than the setup_header from 0x1f1 onwards
for a precisely defined length, which is copied from the bzImage.
We're *not* supposed to just pass the garbage that we happened to find
in the bzImage file surrounding the setup_header.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14052 6f19259b-4bc3-4df7-8a09-765794883524
Boot protocol 2.05 just means that the relocatable_kernel field is present
in the header. We should actually check that it's *set*.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14051 6f19259b-4bc3-4df7-8a09-765794883524
We currently just jump to offset 0x200 in the kernel image, in 64-bit
mode. This is completely broken. If it's a 32-bit kernel, we'll be
jumping into the compressed data payload.
If it's a 64-bit kernel, it'll work... but the 0x200 offset is
explicitly marked as 'may change in the future', has already changed
from 0x100 to 0x200 in the past with no fanfare, and bootloaders are
instructed that they should look at the ELF header to find the offset.
So although it does actually work today, it's still broken in the
"someone needs to whipped for doing it this way" sense of the word.
In fact, the same bug exists in other bootloaders so the 0x200 offset
probably *is* now set in stone. But still it's only valid to use it if
we *know* it's a 64-bit kernel. And we don't. There *is* no ELF header
that we can look at when we're booting a bzImage, and we can't rely on
it having a PE/COFF header either.
The 32-bit entry point is always guaranteed to work, and we need to
support it anyway. So let's just *always* use it, in 32-bit mode, and
then we don't have to make up some horrible heuristics for detecting
32-bit vs. 64-bit kernels.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14045 6f19259b-4bc3-4df7-8a09-765794883524
Move these states from the DSDT to the SSDT. Override the default
configuration if the host has the following qemu commit:
commit 459ae5ea5ad682c2b3220beb244d4102c1a4e332
Author: Gleb Natapov <gleb@redhat.com>
Date: Mon Jun 4 14:31:55 2012 +0300
Add PIIX4 properties to control PM system states.
This patch adds two things. First it allows QEMU to distinguish
between regular powerdown and S4 powerdown. Later separate QMP
notification will be added for S4 powerdown. Second it allows
S3/S4 states to be disabled from QEMU command line. Some guests
known to be broken with regards to power management, but allow to
use it anyway. Using new properties management will be able to
disable S3/S4 for such guests.
Supported system state are passed to a firmware using new fw_cfg
file. The file contains 6 byte array. Each byte represents one
system state. If byte at offset X has its MSB set it means that
system state X is supported and to enter it guest should use the
value from lowest 3 bits.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14003 6f19259b-4bc3-4df7-8a09-765794883524
The ACPI 5.0 specification says:
7.3.4.4 System \_S3 State
[...]
* Dynamic RAM context is maintained.
[...]
This corresponds to the following in the PIIX4 spec:
PMCNTRL -- POWER MANAGEMENT CONTROL REGISTER (IO)
[...]
Bits[12:10] Suspend Type
[...]
001 STR (Suspend To RAM)
Also, this (ie. decimal 1) is the suspend type value that qemu recognizes
as an S3 (suspend to ram) request.
Only the value for PM1a_CNT.SLP_TYP is set (PM1b_CNT.SLP_TYP is left at
zero), since in OVMF we don't report the optional PM1b_EVT_BLK register
block to OSPM. (PM1b_EVT_BLK is defined as 0 in "Platform.h"; see "4.8.1.1
PM1 Event Registers" in the ACPI 5.0 specification.)
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14002 6f19259b-4bc3-4df7-8a09-765794883524
The ACPI 5.0 specification says:
7.3.4.5 System \_S4 State
[...]
* DRAM context is not maintained.
[...]
This corresponds to the following in the PIIX4 spec:
PMCNTRL -- POWER MANAGEMENT CONTROL REGISTER (IO)
[...]
Bits[12:10] Suspend Type
[...]
010 POSCL (Powered On Suspend, Context Lost)
Also, this (ie. decimal 2) is the default suspend type value that qemu
recognizes as an S4 (suspend to disk) request.
Only the value for PM1a_CNT.SLP_TYP is corrected (PM1b_CNT.SLP_TYP is left
at zero), since in OVMF we don't report the optional PM1b_EVT_BLK register
block to OSPM. (PM1b_EVT_BLK is defined as 0 in "Platform.h"; see "4.8.1.1
PM1 Event Registers" in the ACPI 5.0 specification.)
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14001 6f19259b-4bc3-4df7-8a09-765794883524
The qemu standard vga has a MMIO bar in qemu 1.3+.
Use it if available.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13969 6f19259b-4bc3-4df7-8a09-765794883524
Move to a table-driven hardware detection. Add a table with PCI IDs,
card name and variant enum. Use the table for hardware detection and
initialization. Rename Cirrus-specific data and code to carry "cirrus"
in the name.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13967 6f19259b-4bc3-4df7-8a09-765794883524
If QEMU's -kernel parameter was used, then download the
kernel from the FwCfg interface, and launch it. (See -kernel,
-initrd, -append) The application uses the LoadLinuxLib to boot
the kernel image.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13923 6f19259b-4bc3-4df7-8a09-765794883524
This code is based on efilinux's bzimage support.
git://git.kernel.org/pub/scm/boot/efilinux/efilinux.git
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: Matt Fleming <matt.fleming@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13922 6f19259b-4bc3-4df7-8a09-765794883524
This file is from the efilinux project where it resides
under the path loaders/bzimage/bzimage.h.
git://git.kernel.org/pub/scm/boot/efilinux/efilinux.git
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Matt Fleming <matt.fleming@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13920 6f19259b-4bc3-4df7-8a09-765794883524
Structures should not be directly assigned in EDK II
code, since this leads to different behaviours on various
compilers.
Instead, use ZeroMem to zero out the structures.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13878 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg/VirtioBlkDxe/VirtioBlk.c:667: undefined reference to `__umoddi3'
OvmfPkg/VirtioBlkDxe/VirtioBlk.c:750: undefined reference to `__udivdi3'
These operations would come from libgcc in the IA32 build, but OVMF does not
link against libgcc.
Regression-tested the X64 build with Fedora 18 Alpha XFCE and Windows 8
Consumer Preview guests.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13846 6f19259b-4bc3-4df7-8a09-765794883524
AppendDesc() should have a prefix implying its containing library,
VirtioLib. Update its sole client VirtioBlkDxe.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13843 6f19259b-4bc3-4df7-8a09-765794883524
Introduce a new library called VirtioLib, for now only collecting the
following reusable functions with as little changes as possible:
- VirtioWrite()
- VirtioRead()
- VirtioRingInit()
- VirtioRingUninit()
- AppendDesc()
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13842 6f19259b-4bc3-4df7-8a09-765794883524
Separate virtio-blk related macro and type definitions from generic virtio
related ones. Adapt the virtio-blk driver since it needs the latter too.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13841 6f19259b-4bc3-4df7-8a09-765794883524
since they are in fact virtio-blk specific.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13840 6f19259b-4bc3-4df7-8a09-765794883524
This commit consists of:
- a verbatim move ("similarity index 100%" in git parlance),
- an updated #include directive in VirtioBlkDxe/VirtioBlk.h,
- and an OvmfPkg.dec package entry in VirtioBlkDxe/VirtioBlk.inf, so that
the new include directory is searched.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13836 6f19259b-4bc3-4df7-8a09-765794883524
2 nodes in an OpenFirmware device path are sufficient for the generic
check at the beginning of TranslateOfwNodes(). The driver specific
branches check for the necessary nodes individually.
The number of nodes saved for examination is unchanged.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13800 6f19259b-4bc3-4df7-8a09-765794883524
The TimerLib in the OvmfPkg uses a global variable called mPmba and depends on that global being updated. This works for modules loaded into memory, but not XIP modules in ROM/FLASH.
This patch removes the mPmba global variable and instead reads the PIIX4 Power Management Base Address from PCI configuration space when it is needed. This patch also simplifies the initialization logic in the constructor and introduces #defines to eliminate hard coded values in the function implementations. According to the PIIX4 documentation, the IO Space enable bit in the PCI Command Register does not have to be set for the Power Management Base Address to be decoded, so that one op has been removed from the constructor.
I have tested this patch with QEMU and verified that the UDK Debugger us functional when SOURCE_DEBUG_ENABLE is set.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
I also tested it with RHEL-6.3 guest boot/shutdown, Fedora 18 Alpha XFCE
guest boot/shutdown, and Windows 8 Consumer Preview guest
boot/reboot/shutdown. (RHEL-6.3 host.) I didn't notice any adverse effects.
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13783 6f19259b-4bc3-4df7-8a09-765794883524
This patch preserves this information when SOURCE_DEBUG_ENABLE is set.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13780 6f19259b-4bc3-4df7-8a09-765794883524
In OvmfPkgIa32X64.dsc:
Paraphrasing svn rev 13350: gPcAtChipsetPkgTokenSpaceGuid is declared in
PcAtChipsetPkg.dec and used via AcpiPlatformDxe.inf, but with the latest
build tools, since this package builds multiple architectures (IA32 & X64)
and AcpiPlatformDxe is used on X64 only, it is now necessary to place the
gPcAtChipsetPkgTokenSpaceGuid PCD's in the [PcdsFixedAtBuild.X64] section.
In the two other .dsc files:
Make a similar change to keep file contents more easily comparable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[jordan.l.justen@intel.com: change all .dsc files to keep them diffable]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13724 6f19259b-4bc3-4df7-8a09-765794883524
I. There are at least three locations in OvmfPkg that manipulate the PMBA
and related PIIX4 registers.
1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c]
module type: PEIM -- Pre-EFI Initialization Module
(a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6]
2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c]
module type: BASE -- probably callable anywhere after PEI
(a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6]
(b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0
(c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0
3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
module type: DXE_DRIVER -- Driver eXecution Environment
(a) sets SCI_EN, which depends on correct PMBA setting from earlier
(
The relative order of #1 and #3 is dictated minimally by their module
types. Said relative order can be verified with the boot log:
27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580
PlatformPei.efi
28 Platform PEIM Loaded
1259 PlatformBdsInit
1270 PlatformBdsPolicyBehavior
Line 28 is printed by InitializePlatform()
[OvmfPkg/PlatformPei/Platform.c] which is the entry point of that
module. The other two lines are printed by the corresponding functions
in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".
)
Currently #2 (AcpiTimerLibConstructor()) is called in a random spot
(whenever it gets loaded from the firmware image) and masks the
insufficient setup in #1. We shouldn't depend on that, PEI should finish
with IO space being fully accessibe. In addition, PEI should program the
same PMBA value as AcpiTimerLib.
II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and
ensure proper PM configuration for itself (either by confirming or by
doing).
III. Considering a possible cleanup/unification of #2 and #3: timer
functions relying on AcpiTimerLibConstructor(),
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounter()
- GetPerformanceCounterProperties()
- GetTimeInNanoSecond()
may be called before #3 is reached (in Boot Device Selection phase), so we
should not move the initialization from #2 to #3. (Again, AcpiTimerLib
should contain its own setup.)
We should also not move #3 to an earlier phase -- SCI_EN is premature
unless we're about to boot real soon ("enable generation of SCI upon
assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits").
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
The Index Register Base Address bitfield is selected by the binary mask
00000000 00000000 11111111 11000000, 0xFFC0; fix the typo.
Reported-by: Gleb Natapov <gleb@redhat.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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13720 6f19259b-4bc3-4df7-8a09-765794883524
When allocating the BLOCK_MMIO_TO_BLOCK_IO_DEVICE structure, we were
not allocating a large enough amount. We were allocating the size of
the pointer, rather than the size of the structure.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13688 6f19259b-4bc3-4df7-8a09-765794883524
Currently if SOURCE_DEBUG_ENABLE is enabled when building with
GCC44, then the SEC module will not fit into SECFV.
This change increases the size of SECFV to allow this.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13687 6f19259b-4bc3-4df7-8a09-765794883524
Set the boot order based on configuration retrieved from QEMU.
Attempt to retrieve the "bootorder" fw_cfg file from QEMU. Translate the
OpenFirmware device paths therein to UEFI device path fragments. Match the
translated fragments against the enumerated BootOptionList, and rewrite
the BootOrder NvVar so that it corresponds to the order described in
fw_cfg.
The user is expected to configure working boot options first.
Tested via virt-manager's boot order widget.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13683 6f19259b-4bc3-4df7-8a09-765794883524
Including the range of [0xFC000000, 0xFD000000) for PCI MMIO
allocation created a conflict for Xen's HVM loader.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13682 6f19259b-4bc3-4df7-8a09-765794883524
We don't force a platform reset for OVMF when PK is changed in
custom mode setup.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lee Rosenbaum <lee.g.rosenbaum@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13635 6f19259b-4bc3-4df7-8a09-765794883524
Represent the set of possible PCI link target IRQs with
Pcd8259LegacyModeEdgeLevel. This ensures that the 8259 Interrupt
Controller code in PcAtChipsetPkg will treat them as level-triggered too.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13628 6f19259b-4bc3-4df7-8a09-765794883524
Rotate links over devices and pins so that they match qemu.
PIIX4 function 3 (Power Management Module) unconditionally uses the INTA
interrupt pin. SCI from this module requires IRQ9.
Keep other assignments off IRQ9. Only IRQ5, IRQ10, IRQ11 remain for PCI
devices.
Bump OEMRevision in the DSDT.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13625 6f19259b-4bc3-4df7-8a09-765794883524
Kill PDIS and PSRS as they are writing to copies of PIR[A-D], not PIR[A-D]
themselves. Use specialized _DIS and _SRS methods that access PIR[A-D]
directly.
(This should be solvable by passing RefOf (PIRA) etc to PDIS/PSRS, however
the RHEL-6.3 kernel AML parser seems to choke on it. The rules described
in ACPIspec5.0 Table 19-316 "Object Storing and Copying Rules" don't seem
to work:
ACPI Error: Needed [Integer/String/Buffer], found [Reference]
ffff88003ee02420 (20090903/exresop-422)
ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for
[OpcodeName unavailable] (20090903/dswexec-445)
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.LPC_.PDIS] (Node ffff88003f638b50), AE_AML_OPERAND_TYPE
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.LPC_.LNKA._DIS] (Node ffff88003f638a10),
AE_AML_OPERAND_TYPE
When changing the method too, so that it writes to DerefOf (Arg0) instead
of Arg0, ie. explicitly dereferencing rather than expecting the auto-deref
to work:
ACPI Error: Needed type [Reference], found [RegionField]
ffff88003f639858 (20090903/exresop-104)
ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for
[OpcodeName unavailable] (20090903/dswexec-445)
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.LPC_.PDIS] (Node ffff88003f638b50), AE_AML_OPERAND_TYPE
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.LPC_.LNKA._DIS] (Node ffff88003f638a10),
AE_AML_OPERAND_TYPE
In short, when passing a RefOf, it is recognized as a reference inside the
method but mistakenly refused. When trying to deref it explicitly with
DerefOf, then it's suddenly not recognized as a reference.)
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13621 6f19259b-4bc3-4df7-8a09-765794883524
"RTC day of the month alarm feature is not supported".
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13614 6f19259b-4bc3-4df7-8a09-765794883524
- Qemu's PIIX emulation actually supports SMM and ACPI_ENABLE /
ACPI_DISABLE.
- After enabling SMI_CMD (SMI_CMD_IO_PORT), further values to be written
there must be synchronized with qemu: PSTATE_CNT, CST_CNT.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13611 6f19259b-4bc3-4df7-8a09-765794883524
"FWDT" ("firmware data") is allocated as EfiReservedMemoryType, with
AllocateReservedPool(). <MdePkg/Include/Library/MemoryAllocationLib.h>
doesn't seem to provide direct access to EfiACPIReclaimMemory, but at this
point the former seems sufficient.
Based on SeaBIOS commit 2062f2ba by Gerd Hoffmann <kraxel@redhat.com>.
v3:
- coding style fixes:
- BDAT -> FWDT
- __packed -> #pragma pack(1)
- BFLD -> FIRMWARE_DATA, PCI_WINDOW
- Bfld -> FwData
- Ssdt.asl: changed license to 2-clause BSDL, paraphrasing Dsdt.asl
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13573 6f19259b-4bc3-4df7-8a09-765794883524
Fix IO-APIC range size.
Add HPET.
Take LAPIC base from PCD and fix range size.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13572 6f19259b-4bc3-4df7-8a09-765794883524
ConSplitterDxe (UEFI_DRIVER) now uses this library class.
Move the library mapping to the common LibraryClasses section.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13570 6f19259b-4bc3-4df7-8a09-765794883524
UNIXGCC builds larger images than GCC44, and can have issues
fitting into the FD image. Therefore, when using UNIXGCC,
debug will be disabled by default.
The README file is updated with instructions for selectively
enabling debug for UNIXGCC.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13569 6f19259b-4bc3-4df7-8a09-765794883524
This patch adds support for a debug console on the same port that is used
by SeaBIOS. This makes it easier to debug OVMF, because it does not mix
debug and serial output on the same device. It also makes it easier to
leave some of the debug messages on even in release builds.
To enable it, pass "-debugcon stdio -global isa-debugcon.iobase=0x402" to
QEMU.
The new mechanism is enabled by default, but a regular serial console can
be chosen by adding -D DEBUG_ON_SERIAL_PORT to the build options.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: MAX_DEBUG_MESSAGE_LENGTH=>0x100, p=>Ptr]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13562 6f19259b-4bc3-4df7-8a09-765794883524
Tested with the "bootorder" fw_cfg file. Example contents (leading space
added and line terminators transcribed for readability):
/pci@i0cf8/ide@1,1/drive@0/disk@0<LF>
/pci@i0cf8/ide@1,1/drive@1/disk@0<LF>
/pci@i0cf8/ethernet@3/ethernet-phy@0<NUL>
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13549 6f19259b-4bc3-4df7-8a09-765794883524
This patch adds Xen ACPI tables support to OVMF.
Use EFI_ACPI_TABLE_PROTOCOL to publish all Xen ACPI tables in OVMF,
while keeping the Qemu and KVM support.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bei Guan <gbtju85@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13541 6f19259b-4bc3-4df7-8a09-765794883524
Older QEMU versions would load vgabios-cirrus.bin at 0xc0000 in
system RAM. We would then find this ROM, and try to run it, since
it would be our QEMU Video driver.
Now, the QEMU Video driver is just merged into the main OVMF
firmware image, so this support is unused.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13522 6f19259b-4bc3-4df7-8a09-765794883524
This enables qemu to use OVMF with a single -bios option. Based on
<http://lists.xen.org/archives/html/xen-devel/2012-03/msg01992.html>.
v1->v2:
- move xen-devel link from code to commit message
- cover all three FDF files
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: remove vgabios-cirrus.bin from build.sh/README]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13520 6f19259b-4bc3-4df7-8a09-765794883524
Update MADT processing for QEMU to add additional Local APIC
entries to the MADT.
The MADT is still built with a single Local APIC entry.
If the AcpiPlatformDxe driver determines that more processors
are available, then additional Local APIC entries are added
to the MADT at runtime.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13387 6f19259b-4bc3-4df7-8a09-765794883524
Detect QEMU & Xen, and allow each to choose how to publish
the individual ACPI tables.
Currently both paths simply publish the tables unmodified.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13385 6f19259b-4bc3-4df7-8a09-765794883524
This driver is currently a direct copy of
MdeModulePkg/Universal/Acpi/AcpiPlatformDxe.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13384 6f19259b-4bc3-4df7-8a09-765794883524
It is declared in SecurityPkg.dec, but with the latest build tools, since this package builds multiple architectures (IA32 & X64) and there are no IA32 modules used from the SecurityPkg, it is now necessary to place the gEfiSecurityPkgTokenSpaceGuid PCD's in a [PcdsFixedAtBuild.X64] section.
Signed-off-by: lee.g.rosenbaum@intel.com
Reviewed-by: erik.c.bjorge@intel.com
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13350 6f19259b-4bc3-4df7-8a09-765794883524
0xb000 is the address normally used with QEMU.
0x400 also appears to conflict with some debug I/O ports
used by QEMU.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Bei Guan <gbtju85@gmail.com>
Reviewed-by: Bei Guan <gbtju85@gmail.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13279 6f19259b-4bc3-4df7-8a09-765794883524
If the bit is not set, then the only method ACPI defines
for setting it is to use the SMI SCI enable code path.
Since OVMF does not support SMM, we must enable the
bit during boot.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Bei Guan <gbtju85@gmail.com>
Reviewed-by: Bei Guan <gbtju85@gmail.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13278 6f19259b-4bc3-4df7-8a09-765794883524
OVMF does not support SMM. Previously the port value
was set to 0. This should be enough to disable the
SMM ACPI Enable/Disable code paths, but to be
consistent we'll set these fields to 0 as well.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Bei Guan <gbtju85@gmail.com>
Reviewed-by: Bei Guan <gbtju85@gmail.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13277 6f19259b-4bc3-4df7-8a09-765794883524
QEMU hard codes the GPE0 registers at 0xafe0.
Previously the code assumed that the GPE0 block
would move when the PM Base Address of the PIIX4
PCI device was programmed. It appears QEMU does not
emulate this behaviour of the PIIX4 PCI device.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Bei Guan <gbtju85@gmail.com>
Reviewed-by: Bei Guan <gbtju85@gmail.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13276 6f19259b-4bc3-4df7-8a09-765794883524
Contributions.txt documents the contribution process for all
tianocore projects. The conents of Contributions.txt should
match in all cases.
License.txt is a per-project document showing the license terms
used by that project.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13187 6f19259b-4bc3-4df7-8a09-765794883524
If –D SECURE_BOOT_ENABLE is specified with the build command, Secure Boot support is enabled including custom mode setup.
This allows Secure Boot to be configured through setup allowing OvmfPkgX64, OvmfPkgIa32 and OvmfPkg3264 to be a fully functional Secure Boot reference platforms.
Remove redundant library class definitions for BaseCryptLib and OpenSslLib.
Signed-off-by: Lee Rosenbaum <lee.g.rosenbaum@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13160 6f19259b-4bc3-4df7-8a09-765794883524
Adjust PCD settings, library mappings and driver usage
to enable secure-boot when -D SECURE_BOOT_ENABLE=TRUE
is used on the build command line.
Signed-off-by: lgrosenb
Reviewed-by: jljusten
Reviewed-by: mdkinney
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13093 6f19259b-4bc3-4df7-8a09-765794883524
When PcdSecureBootEnable is true, the authenticated variable
FV is created. Otherwise the standard FV is created.
Signed-off-by: lgrosenb
Reviewed-by: jljusten
Reviewed-by: mdkinney
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13092 6f19259b-4bc3-4df7-8a09-765794883524
Note: The CSM16 binary must be copied into the tree at
OvmfPkg/Csm/Csm16/Csm16.bin in order to use CSM_ENABLE.
If CSM_ENABLE is set during the build, then the CSM16 binary
and the CSM support (Legacy BIOS) drivers will be added to
the build.
Signed-off-by: jljusten
Reviewed-by: geekboy15a
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12682 6f19259b-4bc3-4df7-8a09-765794883524
This library installs the legacy interrupt, region
and platform support required for CSM support
drivers.
Signed-off-by: jljusten
Reviewed-by: geekboy15a
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12681 6f19259b-4bc3-4df7-8a09-765794883524
QEMU doesn't support MTRR emulation in some cases,
and therefore the MtrrLib calls may return an error.
In that case, we should silently ignore the error.
Signed-off-by: jljusten
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12618 6f19259b-4bc3-4df7-8a09-765794883524
Locates Xen SMBIOS data and installs it using the SMBIOS
protocol.
Signed-off-by: gavinguan
Reviewed-by: Andrei Warkentin <andreiw@motorola.com>
Signed-off-by: jljusten
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12125 6f19259b-4bc3-4df7-8a09-765794883524
For the first instance of the library that runs, the
base is initialized to 0x400, but we access it at 0x401.
Signed-off-by: jljusten
Reviewed-by: niruiyu
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12121 6f19259b-4bc3-4df7-8a09-765794883524
* Make PlatformPei aware of Xen
* Fix assigned PIO and MMIO ranges to be compatible with Xen
* Reserve Xen HVM address range
* Publish XenInfo HOB
* Don't program PIIX4 PMBA for Xen
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
Reviewed-by: gavinguan
Signed-off-by: jljusten
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12091 6f19259b-4bc3-4df7-8a09-765794883524
XenInfo HOB is used to pass XenInfo from PEI to DXE.
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
Reviewed-by: gavinguan
Reviewed-by: jljusten
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12059 6f19259b-4bc3-4df7-8a09-765794883524
If PIIX4 Power Management Base Address (PMBA) is already
programmed, then read and use it's current setting.
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
Reviewed-by: gavinguan
Signed-off-by: jljusten
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12053 6f19259b-4bc3-4df7-8a09-765794883524
When building:
-D BUILD_NEW_SHELL - Build and include UEFI shell in firmware
-D USE_NEW_SHELL - Include UEFI shell binary build in firmware
The default is to use the older EFI shell.
Signed-off-by: jljusten
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11890 6f19259b-4bc3-4df7-8a09-765794883524
1) Remove section header comment blocks that do not provide any information
2) Combine PCDs listed in multiple sections into a single section that supports multiple PCD types to reduce maintenance overhead
3) Remove ModuleTypeList comments from [Includes], [Protocols], [Ppis], and [Guids] sections that do not properly describe the module type restrictions.
4) Clean up formatting of GUID structure declarations
5) Remove ".common" from section names if they are not required.
6) Order sections consistently as [Defines], [Includes], [LibraryClasses], [Guid], [Ppis], [Protocols], [PcdsFeatureFlag], [PcdsFixedAtBuild], [PcdsPatchableInModule], [PcdsDynamic], and [PcdsDynamicEx]
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11633 6f19259b-4bc3-4df7-8a09-765794883524
In some configurations the UNIXGCC build will run out of
space when a DEBUG build is enabled. This change adjusts
the flash configuration a bit to allow the build succeed
on UNIXGCC.
The final flash image still remains 1MB in size.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11547 6f19259b-4bc3-4df7-8a09-765794883524
This driver provides a UEFI Graphics Output Protocol (GOP) driver
for the QEMU Cirrus VGA hardware. It enables 24-bit color,
and uses the standard 32-bit GOP pixel format whenever possible.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11524 6f19259b-4bc3-4df7-8a09-765794883524
When building in release mode on OVMF, the ASSERT_EFI_ERROR
macro is empty. So, to set the BootMode, in a release build,
it must be outside of ASSERT_EFI_ERROR.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11413 6f19259b-4bc3-4df7-8a09-765794883524
This library provides an interface for converting the system
variables into a binary and also restoring the system variables
from that binary.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11284 6f19259b-4bc3-4df7-8a09-765794883524
The contents of CMOS on boot can describe some aspects of
the system configuration. For example, the size of memory
available to qemu/kvm.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11264 6f19259b-4bc3-4df7-8a09-765794883524
Change from using PcdFlashNvStorageVariableBase to
PcdFlashNvStorageVariableBase64.
This will make sure the EMU Variable FVB will
function in systems with more than 4GB of memory.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11252 6f19259b-4bc3-4df7-8a09-765794883524
Add a single build.sh to replace build32.sh & build64.sh.
The script watches for various parameters:
-a: allows selecting IA32 or X64 (default)
-b: allows selecting RELEASE or DEBUG (default)
-t: allows selecting the toolchain
When running qemu, the script doesn't always add -hda now.
If the user provides a disk parameter (for example, -fda, -hda
or -cdrom), then -hda will not be added to the qemu command line.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11238 6f19259b-4bc3-4df7-8a09-765794883524
When OVMF is run with kvm and grub2 (efi), an exception
occurs when mmx/sse registers are accessed.
As a work around, this change eliminates firmware usage
of these register types.
First, only the BaseMemoryLib implementation
MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
is used.
Second, the GCC compiler is passes the additional
'-mno-mmx -mno-sse' parameters.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11218 6f19259b-4bc3-4df7-8a09-765794883524
These scripts are similar to those found under DuetPkg & UnixPkg.
The scripts simplify building and running OVMF under systems that
have the bash shell available.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11215 6f19259b-4bc3-4df7-8a09-765794883524
This call can cause a reset, and is most critical for ACPI S3/S4
resume situations. OVMF does not support S3/S4.
OVMF does not have true non-volatile variable support, so
this call could cause a continuous reset situation in certain
scenarios. (The BdsLibSaveMemoryTypeInformation may set an
non-volatile variable, and then reset with the assumption that
the variable will still exist during the next boot.)
Additionally, some version of QEMU appear to hang when the
port 64 reset is initiated.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10927 6f19259b-4bc3-4df7-8a09-765794883524
1) Update README describing the QEMU version required for e1000, where to download the UEFI drivers for e1000, and how to enable network drivers in the platform firmware
2) Update DSC/FDF files NETWORK_ENABLE switch to enable e1000 and network driver support
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10697 6f19259b-4bc3-4df7-8a09-765794883524
Remove duplicate FFS file GUID that would cause incremental builds to fail.
Final output file is OVMF.FD and that is what should be used as bios.bin when running QEMU.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10605 6f19259b-4bc3-4df7-8a09-765794883524
This protocol is similar to the standard UEFI BlockIo protocol,
except it has no function calls and simply defines a base address
in memory where reads & writes for the block device should occur.
One planned usage is to fill a memory region with a small disk
image, and allow it to be used as a normal disk by the
standard drivers.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10295 6f19259b-4bc3-4df7-8a09-765794883524
gEfiEdkModulePkgTokenSpaceGuid.PcdDxePcdDatabaseTraverseEnabled does not
exist. Remove references to it in .dsc files and within the comments of
the DXE PCD driver.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10092 6f19259b-4bc3-4df7-8a09-765794883524
In some environments, the accessed bit should be set to allow the
global descriptor table (GDT) to reside in unmodifiable flash
memory.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9675 6f19259b-4bc3-4df7-8a09-765794883524
* Only SEC is uncompressed now
* The MAIN FV with PEI & DXE can easily shrink and grow as needed
* The final output will now be OVMF.Fv rather than OVMF.fd
* The final output size will be a multiple of 64kb
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9672 6f19259b-4bc3-4df7-8a09-765794883524
Previously the interface to the SEC module was:
ESI/RSI - SEC Core entry point
EDI/RDI - PEI Core entry point
EBP/RBP - Start of BFV
Now it is:
RAX/EAX Initial value of the EAX register
(BIST: Built-in Self Test)
DI 'BP': boot-strap processor, or
'AP': application processor
RBP/EBP Address of Boot Firmware Volume (BFV)
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9572 6f19259b-4bc3-4df7-8a09-765794883524
Previously it was:
ESI/RSI - SEC Core entry point
EDI/RDI - PEI Core entry point
EBP/RBP - Start of BFV
Now it is:
RAX/EAX Initial value of the EAX register
(BIST: Built-in Self Test)
DI 'BP': boot-strap processor, or
'AP': application processor
RBP/EBP Address of Boot Firmware Volume (BFV)
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9571 6f19259b-4bc3-4df7-8a09-765794883524
a. Update PciBusDxe module, and move it from IntelFrameworkModulePkg to MdeModulePkg
b. Move IncompatiblePciDeviceSupportDxe module from IntelFrameworkModulePkg to MdeModulePkg
c. Update the related consumes in inf/dsc/fdf
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9350 6f19259b-4bc3-4df7-8a09-765794883524
Align the PE32/32+ images in the ROM for XIP (execute in place) images
to function properly following the change in r9327. Also, convert
pre-memory PEIM's to use the TE image format and strip-relocation
data from image. This saves a little space, and provides a sample
usage of TE images.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9332 6f19259b-4bc3-4df7-8a09-765794883524
Previously the code would expect that the PE32 image was in the
first section of the FFS file. This might not be the case if the
PE32 section is forced to be aligned.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9331 6f19259b-4bc3-4df7-8a09-765794883524
Note:
* This only works before ExitBootServices
* For OVMF, variables are only preserved on the disk if there
is a hard disk connected which has a writeable FAT file system.
The Ovmf/Library/EmuVariableFvbLib library will look for the
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent PCD to be set to
a non-zero value. If set, it is treated as an event handle, and
each write to the EmuVariableFvb will cause the event to be
signaled.
In this change, the OVMF platform BDS library sets up this event,
and sets the PCD so that after each write to the EMU Variable FVB,
the non-volatile variables will be saved out to the file system.
The end result is that NV variables that are written prior to the
ExitBootServices call should be preserved by storing them on the
disk.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9318 6f19259b-4bc3-4df7-8a09-765794883524
OVMF utilizes EmuVariableFvbRuntimeDxe to provide an emulated
variable firmware volume block device for non-volatile variables.
This allows the VariableRuntimeDxe and FaultTolerantWriteDxe
to function without a real non-volatile backing store.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9317 6f19259b-4bc3-4df7-8a09-765794883524
This driver implements a firmware volume block protocol instance
which is stored in system memory.
The MdeModulePkg/Universal/Variable/RuntimeDxe and
MdeModulePkg/Universal/FaultTolerantWriteDxe drivers make use of
this FVB instance to provide variable services.
This driver links to a PlatformFvb library to allow for
platform specific processing to take place when data is written
to the FVB.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9315 6f19259b-4bc3-4df7-8a09-765794883524
This library provides an interface where variables can be saved and restored
using a file in a file system accessible to the firmware. It is expected
that a platform BDS library will use this library. The platform BDS
implementation can decide which devices to connect and then to attempt to use
for saving and restoring NV variables.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9272 6f19259b-4bc3-4df7-8a09-765794883524
Make use of EMU Variable driver's PcdEmuVariableNvStoreReserved to allow
NV variables to persist a VM system reset. The contents of the NV variables
will still be lost when the VM is shut down, but they appear to persist
when the efi shell reset command is run. (Tested with QEMU 0.10.0.)
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9241 6f19259b-4bc3-4df7-8a09-765794883524
QEMU will automatically fill the video BIOS image into memory at the
legacy video BIOS memory location (0xc0000). This code will look
there for a EFI option rom image, and load it if it found. This
allows the video option ROM to be separated out from the main system
firmware image.
QEMU does not appear to emulate the PCI rom expansion method
for making the video BIOS available to the system.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8942 6f19259b-4bc3-4df7-8a09-765794883524
It is not proper for a library implementation to assume the names of function in a parent module.
Instead, they must be designed as the pointers to these two BdsDxe functions and passed in.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8931 6f19259b-4bc3-4df7-8a09-765794883524
Move many libraries to Libraries.common section.
Add basic UEFI_APPLICATION libraries to allow applications
to be easily added to OVMF builds.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8688 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek
jljusten
andrewfish
lzeng14
mdkinney
ydong10
niruiyu
leegrosenbaum
hhtian
lgao4
vanjeff
rsun3
li-elvin
xdu2
gikidy
klu2
geekboy15a
xli24
eric_tian
qhuang8
davidhuang
jchen20