Commit Graph

15408 Commits

Author SHA1 Message Date
Olivier Martin 92141e1777 MdeModulePkg/FvSimpleFileSystemDxe: Fixed ARM compiler error
Some compilers requires an empty line at the end of the file.
ARM compiler version 5 is one of these compilers:
error  #1-D: last line of file ends without a newline

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16918 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-25 02:24:04 +00:00
Elvin Li 0c8cd06707 MdePkg: Fixed wrong definition in smbios.h.
SlotTypeAgp8X should be used per SMBIOS spec.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Elvin Li <elvin.li@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16917 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-25 01:02:41 +00:00
Laszlo Ersek a065efc7c7 MdeModulePkg: list ARM and AARCH64 as valid architectures for some modules
"ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc" references
these drivers:
- Pci/PciBusDxe
- Pci/EhciDxe
- Pci/UhciDxe
- Usb/UsbBusDxe
- Usb/UsbKbDxe

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16916 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:05:50 +00:00
Laszlo Ersek 4c7ee75dfc MdePkg: BasePciLibPciExpress: list ARM and AARCH64 as valid architectures
"ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc" references
this PciLib instance.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16915 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:04:35 +00:00
Laszlo Ersek e17b1db501 ArmVirtualizationPkg/ArmVirtualizationQemu: add USB keyboard input
Similarly to the previous patch, we can now multiplex input from the USB
keyboard.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16914 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:04:30 +00:00
Laszlo Ersek d01c77bb47 ArmVirtualizationPkg/ArmVirtualizationQemu: add VGA console output
Alex Graf's QEMU patchset enables "-device VGA" for the virt machtype as
well. We can now include OvmfPkg/QemuVideoDxe in the firmware, and set
PcdDefaultConOutPaths such that the console output is multiplexed to the
video window as well. (Our platform BDS lib doesn't (yet) locate the VGA
device automatically.)

OvmfPkg/PlatformDxe is included too; it allows users to select a video
resolution. (Note that PcdSetupVideoHorizontalResolution and
PcdSetupVideoVerticalResolution are independent; see git commit 848834cb
(SVN r16311) for explanation.)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16913 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:04:25 +00:00
Laszlo Ersek a8c2de1d7d ArmVirtualizationPkg: PlatformIntelBdsLib: fix multiconsole setup
In the following call chain:

PlatformBdsPolicyBehavior()
  PlatformBdsConnectConsole()
    InitializeConsolePipe() x 3
      BdsConnectDevicePath() [ArmPkg/Library/BdsLib/BdsFilePath.c]

the three InitializeConsolePipe() function calls pass through
- (&gST->ConsoleOutHandle, &gST->ConOut),
- (&gST->ConsoleInHandle, &gST->ConIn),
- (&gST->StandardErrorHandle, &gST->StdErr)

to BdsConnectDevicePath(), in ArmPkg's BdsLib.

At least when more than one console device paths are specified in the
ConIn / ConOut / ErrOut variables, the above resuls in:
- unchanged protocol interfaces (ConOut, ConIn, StdErr) in the system
  table (because ConSplitterDxe installs its non-NULL interfaces first),
- but, changed handles in the system table.

This effectively separates the handle fields in the system table from the
protocol interfaces in the same that should always be associated with the
handles. The end result is that clients using the handles break (splitting
/ multiplexing doesn't work for them), while clients directly using the
protocol interfaces work.

Therefore, do not attempt to connect consoles separately. ConSplitterDxe
is dispatched before PlatformBdsPolicyBehavior() is called (the latter
happens in the BDS phase), and ConSplitterDxe installs virtual handles and
protocol interfaces for input / output / error.

BdsLibConnectAll() covers all devices, including consoles; as those
consoles are connected, ConPlatformDxe and ConSplitterDxe pick them up
nicely as "slaves". We just need to make sure that the variables are set
first, for the variables -> ConPlatformDxe -> ConSplitterDxe dependency
chain.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16912 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:04:21 +00:00
Laszlo Ersek a78c4836ea ArmVirtualizationPkg: PlatformIntelBdsLib: kernel boot should provide ACPI
If there is a PCI host, then PCI enumeration (which happens inside
BdsLibConnectAll()) blocks ACPI table installation (correctly). Make sure
we install ACPI tables before trying to direct-boot a QEMU kernel.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16911 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:04:16 +00:00
Laszlo Ersek 10233c9e6e ArmVirtualizationPkg/ArmVirtualizationQemu: enable PCI support
Beyond including the foundational drivers in the DSC and FDF files, we
enable virtio-over-PCI, and turn on QemuBootOrderLib's OFW-to-UEFI device
path translation for PCI devices.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16910 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:04:11 +00:00
Laszlo Ersek ad3359eb43 ArmVirtualizationPkg: clone BasePciExpressLib, cache PCIe config base
The BarExisted() function in
"MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c" raises the TPL to
TPL_HIGH_LEVEL before accessing PCI config space.

The PciExpressLib instance under "MdePkg/Library/BasePciExpressLib" --
serving the PCI config space access -- calls
PcdGet64(PcdPciExpressBaseAddress) in turn, for each such call.

The PcdGet64() function, when issued at TPL_HIGH_LEVEL, triggers an
ASSERT(). PcdGet64() is based on a protocol in this UEFI phase, and
protocol handler services are not allowed above TPL_NOTIFY (see Table 23
"TPL Restrictions" in the UEFI spec).

Clone the library, and in a new constructor, cache the PCD in a global
variable.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16909 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:04:07 +00:00
Laszlo Ersek e5ceb6c9d3 ArmVirtualizationPkg/PciHostBridgeDxe: handle 0 in GetProposedResources()
When there are no devices connected to the root bridge, no resources are
needed. GetProposedResources() currently considers this an invalid
condition (the PI spec doesn't regulate it).

Emitting an empty set of EFI_ACPI_ADDRESS_SPACE_DESCRIPTORs, followed by
the required EFI_ACPI_END_TAG_DESCRIPTOR, allows
PciHostBridgeResourceAllocator() [MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c]
to advance.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16908 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:04:00 +00:00
Laszlo Ersek 1a1d637695 ArmVirtualizationPkg/PciHostBridgeDxe: skip 0 AddrLen in SubmitResources()
According to Volume 5 of the PI spec, 10.8.2 PCI Host Bridge Resource
Allocation Protocol, SubmitResources(),

  It is considered an error if no resource requests are submitted for a
  PCI root bridge. If a PCI root bridge does not require any resources, a
  zero-length resource request must explicitly be submitted.

Under MdeModulePkg/Bus/Pci/PciBusDxe/, we have:

  PciHostBridgeResourceAllocator()                   [PciLib.c]
    ConstructAcpiResourceRequestor(..., &AcpiConfig) [PciEnumerator.c]
    PciResAlloc->SubmitResources(..., &AcpiConfig)
    ASSERT_EFI_ERROR ()

If ConstructAcpiResourceRequestor() finds no resources to request (for
example because no PCI devices are on the root bridge), it places a
zero-length EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR followed by an
EFI_ACPI_END_TAG_DESCRIPTOR in "AcpiConfig"; satisfying the PI spec.

However, PciHostBridgeDxe's SubmitResources() function does not expect
such input; the following part of the code rejects it:

        switch (Ptr->ResType) {

        case 0:

          //
          // Check invalid Address Sapce Granularity
          //
          if (Ptr->AddrSpaceGranularity != 32) {
            return EFI_INVALID_PARAMETER;
          }

Skip EFI_ACPI_ADDRESS_SPACE_DESCRIPTORs with zero AddrLen early. Also,
allow PciHostBridgeResourceAllocator() to proceed to the AllocateResources
phase by setting "ResourceSubmited" to TRUE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16907 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:56 +00:00
Laszlo Ersek b9a44dcae3 ArmVirtualizationPkg/PciHostBridgeDxe: get MMIO BARs from our own aperture
This is our MMIO space map:

> GCD:AddMemorySpace(Base=0000000010000000,Length=000000002EFF0000)
>   GcdMemoryType   = MMIO
>   Capabilities    = 0000000000000001
>   Status = Success
> GCDMemType Range                             Capabilities     Attributes
> ========== ================================= ================ ================
> NonExist   0000000000000000-0000000003FFFFFF 0000000000000000 0000000000000000
> MMIO       0000000004000000-0000000007FFFFFF C000000000000001 8000000000000001

NorFlashDxe adds this, but does not allocate it.

> NonExist   0000000008000000-000000000900FFFF 0000000000000000 0000000000000000
> MMIO       0000000009010000-0000000009010FFF C000000000000001 8000000000000001

Added by RealTimeClockRuntimeDxe, but also not allocated.

> NonExist   0000000009011000-000000000FFFFFFF 0000000000000000 0000000000000000
> MMIO       0000000010000000-000000003EFEFFFF C000000000000001 0000000000000000

Added by ourselves.

> NonExist   000000003EFF0000-000000003FFFFFFF 0000000000000000 0000000000000000
> SystemMem  0000000040000000-00000000BFFFFFFF 800000000000000F 0000000000000008*
> NonExist   00000000C0000000-0000FFFFFFFFFFFF 0000000000000000 0000000000000000

In the EfiPciHostBridgeAllocateResources phase, we allocate memory BARs
bottom up, from whichever MMIO range comes first and has room left.
Unfortunately, this places memory BARs into MMIO ranges that belong to
other devices. (Arguably, their respective drivers should not just add,
but immediately allocate those ranges as well.)

(

  This problem is not seen in OVMF / PcAtChipsetPkg, because there we
  allocate bottom-up from the range

    [max(2GB, top-of-low-RAM), 0xFC000000).

  (See the MMIO resource descriptor HOB created in MemMapInitialization()
  [OvmfPkg/PlatformPei/Platform.c].)

  That MMIO range fits in the static [2GB, 4GB) aperture given in
  "mResAperture" in PcAtChipsetPkg/PciHostBridgeDxe; plus other MMIO
  ranges (IO-APIC, HPET, LAPIC, flash chip) are higher than 0xFC000000.
  Hence the bottom-up BAR allocation in OvmfPkg always finds the right
  MMIO range first.

)

In ArmVirtualizationPkg/PciHostBridgeDxe we can solve the problem by
working our way downwards from the top of our own aperture.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16906 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:51 +00:00
Laszlo Ersek ef8dba7da3 ArmVirtualizationPkg/PciHostBridgeDxe: allocate IO BARs top-down
Currently we allocate IO BARs bottom-up in the
EfiPciHostBridgeAllocateResources phase of the enumeration.

> GCD:AddIoSpace(Base=0000000000000000,Length=0000000000010000)
>   GcdIoType    = I/O
>   Status = Success
> GCDIoType  Range
> ========== =================================
> I/O        0000000000000000-000000000000FFFF

Because the IO aperture is based at zero, the first allocation happens to
get the zero address. However, a zero address for a PCI BAR is considered
unmapped; see eg.:

- <http://www.pcisig.com/reflector/msg00459.html>,

- the (new_addr == 0) part in QEMU, pci_bar_address() [hw/pci/pci.c]:

    new_addr = pci_get_long(d->config + bar) & ~(size - 1);
    last_addr = new_addr + size - 1;
    /* Check if 32 bit BAR wraps around explicitly.
     * TODO: make priorities correct and remove this work around.
     */
    if (last_addr <= new_addr || new_addr == 0 || last_addr >= UINT32_MAX)
    {
        return PCI_BAR_UNMAPPED;
    }

We can avoid this problem by allocating top-down in the IO aperture.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16905 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:46 +00:00
Laszlo Ersek f9a8be423c ArmVirtualizationPkg/PciHostBridgeDxe: MMIO aperture must not be uncached
Quite non-intuitively, we must allow guest-side writes to emulated PCI
MMIO regions to go through the CPU cache, otherwise QEMU, whose accesses
always go through the cache, may see stale data in the region.

This change makes no difference for QEMU/TCG, but it is important for
QEMU/KVM, at the moment.

Because gDS->SetMemorySpaceAttributes() is ultimately implemented by
EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes() -- see
"MdeModulePkg/Core/Dxe/Gcd/Gcd.c" and "ArmPkg/Drivers/CpuDxe/" -- we add
the CPU architectural protocol to the module's DepEx.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16904 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:42 +00:00
Laszlo Ersek 807c26d306 ArmVirtualizationPkg/PciHostBridgeDxe: add room for PCI resource allocation
VirtFdtDxe parses the following address space properties from the DTB (and
saves them in PCDs) :

  ProcessPciHost: Config[0x3F000000+0x1000000)
                  Bus[0x0..0xF]
                  Io[0x0+0x10000)@0x3EFF0000
                  Mem[0x10000000+0x2EFF0000)@0x0

In order to allow PCI enumeration to allocate IO and MMIO resources from
the above ranges for devices, we must add the ranges to the Global
Coherency Domain.

There are two ways for that:
- building resource descriptor HOBs in the HOB producer phase (basically,
  PEI), and letting the DXE core process them,
- calling gDS->AddIoSpace() and gDS->AddMemorySpace() during DXE.

We opt for the second method for simplicity.

In the address space maps, the corresponding ranges change from
"nonexistent" to "IO" and "MMIO", from which the gDS->AllocateIoSpace()
and gDS->AllocateMemorySpace() services can later allocate PCI BARs.

   GCD:AddIoSpace(Base=0000000000000000,Length=0000000000010000)
     GcdIoType    = I/O
     Status = Success
   GCDIoType  Range
   ========== =================================
-> I/O        0000000000000000-000000000000FFFF

   GCD:AddMemorySpace(Base=0000000010000000,Length=000000002EFF0000)
     GcdMemoryType   = MMIO
     Capabilities    = 0000000000000001
     Status = Success
   GCDMemType Range                             Capabilities     Attributes
   ========== ================================= ================ ================
   NonExist   0000000000000000-0000000003FFFFFF 0000000000000000 0000000000000000
   MMIO       0000000004000000-0000000007FFFFFF C000000000000001 8000000000000001
   NonExist   0000000008000000-000000000900FFFF 0000000000000000 0000000000000000
   MMIO       0000000009010000-0000000009010FFF C000000000000001 8000000000000001
   NonExist   0000000009011000-000000000FFFFFFF 0000000000000000 0000000000000000
-> MMIO       0000000010000000-000000003EFEFFFF C000000000000001 0000000000000000
   NonExist   000000003EFF0000-000000003FFFFFFF 0000000000000000 0000000000000000
   SystemMem  0000000040000000-00000000BFFFFFFF 800000000000000F 0000000000000008*
   NonExist   00000000C0000000-0000FFFFFFFFFFFF 0000000000000000 0000000000000000

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16903 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:37 +00:00
Laszlo Ersek 1ff2b5a833 ArmVirtualizationPkg/ArmVirtualizationQemu: enable IO addressing
Set gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize to 16, which determines the
maximum "I/O address width".

This ensures, through the BuildCpuHob() call in
"ArmPkg/Drivers/CpuPei/CpuPei.c", that the inital I/O Space Map will
consist of a 16-bit wide "splittable" entry, when the DXE core starts (see
CoreInitializeGcdServices() in "MdeModulePkg/Core/Dxe/Gcd/Gcd.c"):

  GCD:Initial GCD I/O Space Map
  GCDIoType  Range
  ========== =================================
  NonExist   0000000000000000-000000000000FFFF

Otherwise this range would have size 0, and (since it could not be split)
any gDS->AddIoSpace() calls would fail.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16902 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:32 +00:00
Laszlo Ersek 286c88bcce ArmVirtualizationPkg/PciHostBridgeDxe: accommodate general address spaces
The RootBridgeIoCheckParameter() function currently relies on the range
limit being of the form (2^n - 1). This assumption is not necessarily
true; handle the general case.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16901 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:28 +00:00
Laszlo Ersek 1cfa1957bb ArmVirtualizationPkg/PciHostBridgeDxe: IO space is emulated with MMIO
There is no IO space on ARM, and there are no special instructions that
access it. QEMU emulates the IO space for PCI devices with a special MMIO
range. We're ready to use it at this point, we just have to switch the
Io(Read|Write)(8|16|32) primitives to their MMIO counterparts, because in
"MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c", the IO primitives
correctly ASSERT (FALSE).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16900 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:21 +00:00
Laszlo Ersek 1275aaf430 ArmVirtualizationPkg/PciHostBridgeDxe: translate addresses for IO
Unlike the one in PcAtChipsetPkg, our PciHostBridgeDxe module must handle
address space translation. IO addresses expressed in the respective
aperture are mapped to a different base in CPU address space.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16899 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:16 +00:00
Laszlo Ersek 120a25c287 ArmVirtualizationPkg/PciHostBridgeDxe: abort if there's no PCI host bridge
If VirtFdtDxe found no PCI host in the DTB, then the config space base
address will be left at zero -- the default is set in the DSC --, and we
should exit PciHostBridgeDxe immediately.

This causes gEfiPciRootBridgeIoProtocolGuid not to be installed, which in
turn prevents MdeModulePkg/Bus/Pci/PciBusDxe from binding (see
PciBusDriverBindingSupported()).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16898 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:11 +00:00
Laszlo Ersek aca7e8b6d4 ArmVirtualizationPkg/PciHostBridgeDxe: set Root Bridge apertures from PCDs
Our PciHostBridgeDxe module creates one root bridge on the one and only
host bridge. The resource apertures of the root bridge (bus range, IO
space, MMIO space) are configured with the "mResAperture" array, which at
the moment carries static values inherited from PcAtChipsetPkg.

Set the array as first thing from the PCDs that we parsed from the device
tree.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16897 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:06 +00:00
Laszlo Ersek e1ec934cc3 ArmVirtualizationPkg/PciHostBridgeDxe: ECAM enables 4KB config space
The Enhanced Configuration Access Mechanism provides access to 4096
register bytes per PCIe B/D/F. The MAX_PCI_REG_ADDRESS macro that we're
changing here is used by RootBridgeIoCheckParameter() for verifying config
space boundaries in EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() and
.Write().

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.Martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16896 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:03:02 +00:00
Laszlo Ersek 9595e3cd51 ArmVirtualizationPkg/PciHostBridgeDxe: clone from PcAtChipsetPkg
MdeModulePkg/Bus/Pci/PciBusDxe depends on
EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL and
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL. Here we clone the driver that produces
these from PcAtChipsetPkg, with the following immediate changes:

- a new FILE_GUID is generated;

- the assembly-language Ia32 / X64 specific IoFifo "accelerators" are not
  copied, and their client code (which would be dead code anyway) is
  removed;

- UNI files are not copied: they are used in conjunction with the UEFI
  Packaging Tool (UPT), but the driver under ArmVirtualizationPkg will not
  be part of UDK.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16895 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:02:55 +00:00
Laszlo Ersek 65bb13b0fd ArmVirtualizationPkg/VirtFdtDxe: parse "pci-host-ecam-generic" properties
In the Linux kernel tree,
"Documentation/devicetree/bindings/pci/host-generic-pci.txt" describes the
device tree bindings of a Generic PCI host controller.

Recent QEMU patches from Alexander Graf implement such a controller on the
"virt" machine type of qemu-system-(aarch64|arm):

  pcie@10000000 {
    //
    //                    (devfn<<8, 0, 0)  PCI irq
    //                    ----------------  -------
    interrupt-map-mask = <0x1800 0x0 0x0    0x7>;

    //                                        gic      irq
    //               (devfn<<8, 0, 0)  pin+1  phandle  (type, nr, level)
    //               ----------------  -----  -------- -----------------
    interrupt-map = <   0x0 0x0 0x0    0x1    0x8001   0x0 0x3 0x4
                        0x0 0x0 0x0    0x2    0x8001   0x0 0x4 0x4
                        0x0 0x0 0x0    0x3    0x8001   0x0 0x5 0x4
                        0x0 0x0 0x0    0x4    0x8001   0x0 0x6 0x4
                      0x800 0x0 0x0    0x1    0x8001   0x0 0x4 0x4
                      0x800 0x0 0x0    0x2    0x8001   0x0 0x5 0x4
                      0x800 0x0 0x0    0x3    0x8001   0x0 0x6 0x4
                      0x800 0x0 0x0    0x4    0x8001   0x0 0x3 0x4
                     0x1000 0x0 0x0    0x1    0x8001   0x0 0x5 0x4
                     0x1000 0x0 0x0    0x2    0x8001   0x0 0x6 0x4
                     0x1000 0x0 0x0    0x3    0x8001   0x0 0x3 0x4
                     0x1000 0x0 0x0    0x4    0x8001   0x0 0x4 0x4
                     0x1800 0x0 0x0    0x1    0x8001   0x0 0x6 0x4
                     0x1800 0x0 0x0    0x2    0x8001   0x0 0x3 0x4
                     0x1800 0x0 0x0    0x3    0x8001   0x0 0x4 0x4
                     0x1800 0x0 0x0    0x4    0x8001   0x0 0x5 0x4>;

    #interrupt-cells = <0x1>;

    //
    //                   child base      cpu base
    //        type       address         address         size
    //        ---------  --------------  --------------  --------------
    ranges = <0x1000000  0x0        0x0  0x0 0x3eff0000  0x0    0x10000
              0x2000000  0x0 0x10000000  0x0 0x10000000  0x0 0x2eff0000>;

    //
    //     PCIe config     PCIe config
    //     space base      space size
    //     --------------  -------------
    reg = <0x0 0x3f000000  0x0 0x1000000>;

    //
    // allowed bus numbers; inclusive range
    //
    bus-range = <0x0 0xf>;

    #size-cells = <0x2>;
    #address-cells = <0x3>;
    device_type = "pci";
    compatible = "pci-host-ecam-generic";
  };

Parse those properties of the compatible="pci-host-ecam-generic" node into
PCDs that are relevant for PCI enumeration in edk2:

- gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress controls
  MdePkg/Library/BasePciExpressLib,

- gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration controls
  OvmfPkg/AcpiPlatformDxe at this point,

- the rest have been introduced earlier in this patchset, and will control
  PCI range checks and translation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16894 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:02:50 +00:00
Laszlo Ersek e48f1f15b0 ArmPlatformPkg: introduce PCDs for describing PCI address spaces
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16893 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:02:44 +00:00
Laszlo Ersek 93deff5aca PcAtChipsetPkg/PciHostBridgeDxe: drop PciAddress, PciData
The PciAddress and PciData members of PCI_ROOT_BRIDGE_INSTANCE are never
read; drop them.

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@16892 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:02:39 +00:00
Laszlo Ersek 0b7c6cd401 PcAtChipsetPkg/PciHostBridgeDxe: fix typo in "aperture"
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Olivier Martin <Olivier.martin@arm.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16891 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:02:34 +00:00
Laszlo Ersek 84a75f70e9 OvmfPkg/QemuVideoDxe: enable ARM builds
The only feature not portable to ArmVirtualizationQemu is the VBE shim;
make that dependent on Ia32 / X64.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Olivier Martin <Olivier.martin@arm.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16890 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:02:29 +00:00
Laszlo Ersek cef89a58ee OptionRomPkg: FrameBufferBltLib: drop set but not used variable
BltMemSrc is set in BltLibVideoFill(), but never read.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.Martin@arm.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16889 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 16:02:21 +00:00
Olivier Martin a8577b3a65 ShellPkg/UefiShellLib: Fixed ARM compiler error
ARM Compiler version 5 raises the warning/error (warning treated as error):
#191-D: type qualifier is meaningless on cast type

The compiler team said the warning is valid because from the C90 standard,
section 6.5.3 it is specified that "The properties associated with
qualified types are meaningful only for expressions that are lvalues."

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@16888 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23 11:13:58 +00:00
Laszlo Ersek 818bc86aa7 OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration dynamic
SVN r16411 delayed ACPI table installation until PCI enumeration was
complete, because on QEMU the ACPI-related fw_cfg files should have been
downloaded only after PCI enumeration. Said commit implemented the
dependency by tightening the module's depex.

This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a
matching protocol registration callback. The depex was static, and it
could not handle dynamically discovered situations when the dependency
would turn out invalid.

Namely:

- At the moment, the depex in "QemuFwCfgAcpiPlatformDxe.inf" assumes
  that "ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc"
  lacks PCI support. However, PCI support is about to become run-time
  discoverable on that platform. If PCI support is missing, then
  ArmVirtualizationPkg will set PcdPciDisableBusEnumeration to TRUE.

  Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
  dependency by not registering the callback and installing the ACPI
  tables right away.

- InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets
  PcdPciDisableBusEnumeration to TRUE. This causes
  PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c"
  to set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in
  "MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to
  PciEnumeratorLight(). The installation of
  EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is
  not reached.

  Which means that starting with SVN r16411, AcpiPlatformDxe is never
  dispatched on Xen.

  Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
  dependency by not registering the callback and installing the ACPI
  tables right away.

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: Removed PcdOvmfPciEnabled]
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@16887 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-19 23:46:27 +00:00
Jordan Justen 2c3ce49110 ArmVirtualizationPkg: Set PcdPciDisableBusEnumeration to TRUE
This setting makes OvmfPkg/AcpiPlatformDxe not wait for PCI
enumeration to complete before installing ACPI tables.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16886 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-19 23:46:13 +00:00
Laszlo Ersek 04951644cd OvmfPkg: AcpiPlatformDxe: extract common entry point
Currently the entry point functions of both driver builds
(AcpiPlatformDxe.inf and QemuFwCfgAcpiPlatformDxe.inf) directly contain
the logic that is different between the two builds.

Because we're going to restructure the entry point logic soon, we'd have
to duplicate the same new code between both entry point functions.

Push down the logic in which they differ to a new function:
- InstallAcpiTables() [AcpiPlatform.c]
- InstallAcpiTables() [QemuFwCfgAcpiPlatform.c]

and extract a common entry point function:
- AcpiPlatformEntryPoint() [EntryPoint.c]

which we can soon modify without code duplication.

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@16885 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-19 23:45:57 +00:00
Jordan Justen f186536bdd OvmfPkg/AcpiPlatformDxe: InstallAllQemuLinkedTables => InstallQemuFwCfgTables
This name better aligns with InstallXenTables and InstallOvmfFvTables.

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@16884 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-19 23:45:50 +00:00
Jordan Justen b70c4d07f3 OvmfPkg/AcpiPlatformDxe: FindAcpiTablesInFv => InstallOvmfFvTables
Since this function also installs the tables, this is a better
name. It also aligns with the InstallXenTables name.

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@16883 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-19 23:45:42 +00:00
Jordan Justen 53596a72cd OvmfPkg/AcpiPlatformDxe: Assert if AcpiTable protocol is not found
Since the protocol is in the depex, there is no reason to expect we
might fail to locate the protocol.

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@16882 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17 18:58:05 +00:00
Olivier Martin 460e1e0dab ArmPlatformPkg/ArmVExpress-FVP-AArch64.dsc: Fixed build
The FeaturePcd gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy was not
defined in the correct section.

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@16881 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17 13:11:34 +00:00
Jordan Justen 903f52297f OvmfPkg/QemuFwCfgAcpiPlatformDxe: Move entry point to QemuFwCfgAcpi.c
Having this entry point in QemuFwCfgAcpi.c should not cause a problem
for the other driver which supports Xen and older QEMU versions.

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@16880 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17 00:14:58 +00:00
Andrew Fish cbe2e9ee55 OvmfPkg/build.sh: Use XCODE5 for newer OS X releases
Update OS Major number checking to future proof it, and default to
XCODE5 (clang + lldb).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish <afish@apple.com>
Reviewed-by: Bruce Cran <bruce.cran@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16879 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17 00:05:41 +00:00
Jordan Justen 28a34033ee OvmfPkg/PlatformBdsLib: Signal ReadyToBoot before booting QEMU kernel
Before we launch the QEMU kernel, we should signal the ReadyToBoot
event.

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@16878 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17 00:05:36 +00:00
Jordan Justen 0d696b789f OvmfPkg/build.sh: Allow qemu parameters with spaces
This change allows QEMU parameters to have spaces. For example:
OvmfPkg/build.sh qemu -kernel vmlinuz -append "kernel-param1 param2"

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@16877 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17 00:05:31 +00:00
Olivier Martin 085cfdf2be ArmPlatformPkg/ArmVExpress-FVP-AArch64: Force GICv3 into GICv2 legacy mode
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Tested-by: Ard Biesheuvel <ard@linaro.org>
Reviewed-by: Ard Biesheuvel <ard@linaro.org>



git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16876 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-16 10:27:52 +00:00
Ard Biesheuvel f6d46e2960 ArmPkg/ArmGic: enable ARE bit before driving GICv3 in native mode
The GICv3 driver must use native mode to drive a GICv3 due to
the fact that v2 compatibility is optional in the v3 spec.
However, if v2 compatibility is implemented, it is the default
and needs to be disabled first by setting the Affinity Routing
Enable (ARE) bit.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>

[added PCD that allows forcing the GICv3 driver to drive the GIC in v2 mode]
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Tested-by: Ard Biesheuvel <ard@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>



git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16875 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-16 10:27:02 +00:00
Olivier Martin 41fb5d4634 ArmPkg/ArmGic: Use the GIC Redistributor instead of GIC Distributor for GICv3
GICv3 controller with no GICv2 legacy support must use the GIC
Redistributor registers instead of the GIC Distributor registers
for some operations (eg: enable/disable interrupts).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Tested-by: Ard Biesheuvel <ard@linaro.org>
Reviewed-by: Ard Biesheuvel <ard@linaro.org>



git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16874 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-16 10:23:42 +00:00
Olivier Martin 8705cb3806 ArmPkg/ArmGic: Function to locate the current CPU GIC redistributor
CPU GIC Registributors are located next to each other in the GIC Redistributor
space.
The CPU GIC Redistributor is identified by its CPU affinity Aff3.Aff2.Aff1.Aff0.

This function returns the base address of the GIC Redistributor of
the calling CPU.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Tested-by: Ard Biesheuvel <ard@linaro.org>
Reviewed-by: Ard Biesheuvel <ard@linaro.org>



git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16873 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-16 10:22:07 +00:00
Olivier Martin 919697ae6c ArmPkg/ArmGic: Added GICv3 specific definitions
ARM GICv3 specification introduces some new components and registers.
This patch adds their definitions.

The most important GICv3 component is the GIC Redistributor. It supports
LPIs (Locality-specific peripheral Interrupt), 8+ CPU configuration.
Some GIC distributor registers have moved to the GIC redistributor.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Tested-by: Ard Biesheuvel <ard@linaro.org>
Reviewed-by: Ard Biesheuvel <ard@linaro.org>



git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16872 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-16 10:21:06 +00:00
Olivier Martin 90ed18ca87 ArmPkg/ArmLib.h: Add CPU Affinity definitions
The CPU affinity fields are defined by MPIDR/MPIDR_EL1.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Tested-by: Ard Biesheuvel <ard@linaro.org>
Reviewed-by: Ard Biesheuvel <ard@linaro.org>


git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16871 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-16 10:19:52 +00:00
Elvin Li 54753b60a5 MdeModulePkg: Update SMBIOS revision to 3.0.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Elvin Li <elvin.li@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16870 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-15 05:01:59 +00:00
Elvin Li 6cd35c62fc MdePkg: Add new definitions for SMBIOS 3.0.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Elvin Li <elvin.li@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16869 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-15 05:01:27 +00:00