summaryrefslogtreecommitdiff
path: root/ArmPlatformPkg
AgeCommit message (Collapse)Author
2015-02-23ArmVirtualizationPkg/PciHostBridgeDxe: handle 0 in GetProposedResources()Laszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: skip 0 AddrLen in SubmitResources()Laszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: get MMIO BARs from our own apertureLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: allocate IO BARs top-downLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: MMIO aperture must not be uncachedLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: add room for PCI resource allocationLaszlo Ersek
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-23ArmVirtualizationPkg/ArmVirtualizationQemu: enable IO addressingLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: accommodate general address spacesLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: IO space is emulated with MMIOLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: translate addresses for IOLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: abort if there's no PCI host bridgeLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: set Root Bridge apertures from PCDsLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: ECAM enables 4KB config spaceLaszlo Ersek
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-23ArmVirtualizationPkg/PciHostBridgeDxe: clone from PcAtChipsetPkgLaszlo Ersek
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-23ArmVirtualizationPkg/VirtFdtDxe: parse "pci-host-ecam-generic" propertiesLaszlo Ersek
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-23ArmPlatformPkg: introduce PCDs for describing PCI address spacesLaszlo Ersek
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-19ArmVirtualizationPkg: Set PcdPciDisableBusEnumeration to TRUEJordan Justen
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-17ArmPlatformPkg/ArmVExpress-FVP-AArch64.dsc: Fixed buildOlivier Martin
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-16ArmPlatformPkg/ArmVExpress-FVP-AArch64: Force GICv3 into GICv2 legacy modeOlivier Martin
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-16ArmPkg/ArmGic: Added GICv3 specific definitionsOlivier Martin
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-04ArmPlatformPkg/ArmJunoDxe: Added missing headerOlivier Martin
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@16756 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-03*/Contributions.txt: Update example email addressJordan Justen
Use the example.com domain as recommended in RFC 2606. NOTE: This does not modify the wording of the "TianoCore Contribution Agreement 1.0" section Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Bruce Cran <bruce.cran@gmail.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16724 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-02ArmVirtualizationPkg: add simple ACPI Platform Driver to the QEMU platformLaszlo Ersek
Introduce an ACPI platform driver for ARM / AARCH64 virtual machines. "OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf" downloads ACPI blobs from QEMU over fw_cfg, processes them, and installs the resultant ACPI tables. 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@16698 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-02ArmVirtualizationQemu: ask the hardware for the timer frequencyLaszlo Ersek
Roughly, there are two ways to "measure ticks" in UEFI: - the SetTimer() boot service, which sets up a one-shot or periodic event callback, and takes the interval length in units of 100ns, - the Stall() boot service, which stalls the caller (but does not yield the CPU) for the interval specified. The interval is taken as a number of microseconds. If the platform in question also follows the PI (Platform Init) specification, then it is recommended to implement the above UEFI services on top of the following DXE Architectural Protocols (described in PI Volume 2): - Timer Architectural Protocol: "Used to set up a periodic timer interrupt using a platform specific timer, and a processor-specific interrupt vector. This protocol enables the use of the SetTimer() Boot Service. [...]" - Metronome Architectural Protocol: "Used to wait for ticks from a known time source in a platform. This protocol may be used to implement a simple version of the Stall() Boot Service. [...]" Edk2 in general, and ArmVirtualizationQemu in particular, follow the above pattern. SetTimer() works correctly. The underlying Timer Architectural Protocol is provided by "ArmPkg/Drivers/TimerDxe", and that driver calls the internal function ArmGenericTimerGetTimerFreq() to retrieve the timer frequency. Ultimately it boils down to reading the CNTFRQ_EL0 register. The correct behavior of SetTimer() can be observed for example: - in the grub-efi countdown ("grub-core/kern/arm/efi/init.c"), - in the Intel BDS front page countdown ("IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c"). However, Stall() doesn't work correctly. The underlying Metronome Architectural Protocol is provided by "EmbeddedPkg/MetronomeDxe", which further delegates the job to the TimerLib library class. That in turn is resolved to the "ArmPkg/Library/ArmArchTimerLib" instance, which (finally!) takes the timer frequency from "PcdArmArchTimerFreqInHz". In ArmVirtualizationQemu we currently specify 100MHz for this PCD. Alas, that's incorect for: - both QEMU/TCG (which emulates 62.5MHz, see GTIMER_SCALE in "target-arm/internals.h"), - and KVM (where the host's virtualized timer can tick at 50 MHz, for example). Set the PCD to 0, asking ArmArchTimerLib to interrogate CNTFRQ_EL0 as well. The change can be tested with eg. the following callers of Stall(): - the UEFI Shell's countdown -- before it runs "startup.nsh" -- relies on Stall(), - the UEFI shell command "stall" also uses Stall(). (Time it with a stopwatch.) 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@16692 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-23ArmPlatformPkg: detect correct pl011 fifo depthLeif Lindholm
pl011 releases earlier than r1p5 has a fifo depth of 16 bytes, whereas version r1p5 upwards has a fifo depth of 32 bytes. The pl011 driver was hardwired to 32 byte depth, causing dropped characters on some platforms (including default settings on FVP Base and Foundation models). Update driver to select 16 or 32 on port initialization by checking the component revision. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Olivier Martin <olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16656 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-23ArmPkg/NorFlashDxe : Fix the check of flash addressesRonald Cron
Fix the check to prevent any reading past the end of the nor flash. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <ronald.cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16655 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-23ArmPlatformPkg/ArmJunoPkg/AcpiTables: Updated with new ACPI 5.1 Tables & ↵Olivier Martin
Definitions Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Graeme Gregory <graeme.gregory@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16654 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-23ArmPlatformPkg/ArmJunoPkg: Added the ACPI 5.0 TablesOlivier Martin
These tables are: - Differentiated System Description Table Fields (DSDT) - Firmware ACPI Control Structure (FACS) - Fixed ACPI Description Table (FADT) - Generic Timer Description Table (GTDT) - Multiple APIC Description Table (MADT) - Secondary System Description Table Fields (SSDT) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Graeme Gregory <graeme.gregory@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16652 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-23ArmPlatformPkg/ArmJunoPkg: Added ACPI supportOlivier Martin
This support makes the Juno UEFI Firmware to look into the Firmware Volume for the ACPI Tables. But it does not provide the ACPI Tables. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Graeme Gregory <graeme.gregory@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16651 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-14ArmVirtualizationPkg: PlatformIntelBdsLib: get front page timeout from QEMULaszlo Ersek
Put QemuBootOrderLib's GetFrontPageTimeoutFromQemu() to use, so that ArmVirtualizationPkg's Platform BDS policy can consume QEMU's command line option -boot menu=on,splash-time=N RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1172756 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@16612 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-13ArmPlatformPkg: Fixed builds after some ShellPkg libraries have movedOlivier Martin
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@16605 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-06ArmPlatformPkg/Bds: Signal when the variable 'Fdt' has been updatedOlivier Martin
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@16589 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-06ArmPlatformPkg/Bds: Retrieve the Status when calling RT.SetVariableOlivier Martin
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@16588 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-06ArmPlatformPkg: PCI emulation - Define a vendor and device idRonald Cron
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <Ronald.Cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16587 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-06ArmPlatformPkg/ArmJunoDxe: Close the FDT fileRonald Cron
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <Ronald.Cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16585 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-06ArmJunoDxe/InstallFdt.c: Fix the closing of the simple file system protocolRonald Cron
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <Ronald.Cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16584 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-06ArmPlatformPkg: Make PCI emulation more compliant with the UEFI specRonald Cron
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <Ronald.Cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16583 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-06ArmPlatformPkg/ArmVExpressPkg: Add support for FV filesystems to ARM platformsOlivier Martin
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@16581 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02ArmVirtualizationPkg: Intel BDS: load EFI-stubbed Linux kernel from fw_cfgLaszlo Ersek
A number of tools depend on passing the kernel image, the initial ramdisk, and the kernel command line to the guest on the QEMU command line (options -kernel, -initrd, -append, respectively). At the moment, these QEMU options work, but the guest kernel loaded this way is launched by a minimal binary firmware that is dynamically composed by QEMU. As a consequence, such a kernel has no UEFI environment. This patch enables -kernel, -initrd, -append to work on top of the ArmVirtualizationQemu firmware build. The approach it takes is different from how the same functionality is implemented in OvmfPkg. OvmfPkg contains a full-fledged Linux boot loader (see "OvmfPkg/Library/PlatformBdsLib/QemuKernel.c" and "OvmfPkg/Library/LoadLinuxLib/"). OVMF's LoadLinuxLib sets up the required kernel environment in a sophisticated way (including x86-specific artifacts like the GDT), calls ExitBootServices() itself (for legacy kernels without EFI handover protocol), and jumps to the kernel (using x86 assembly). In ArmVirtualizationPkg's PlatformIntelBdsLib, we require the kernel being loaded to have an EFI stub -- that is, to be a genuine UEFI application. (The EFI stub is not an additional burden for guest kernels -- the EFI stub is a hard requirement anyway because it needs to process the DTB heavily: - it removes memory nodes, - it removes memreserve entries, - it adds UEFI properties to the "chosen" node, - it calculates and installs virt-to-phys mappings with SetVirtualAddressMap() in a way that enables kexec [planned]. Kudos to Ard Biesheuvel for summarizing the above.) An EFI-stubbed Linux guest kernel can be loaded with plain gBS->LoadImage(). The EFI stub will look up its own EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL instance (ie. the device path where it has been loaded from), and it will locate the initial ramdisk named by the "initrd" command line parameter as a *sibling file* on the same device. The initrd file is then loaded using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. This approach enables the EFI stub to load the initial ramdisk from normal EFI System Partitions, from remote PXE/TFTP directories -- and it enables us to provide the initrd from memory as well. In this patch: - We download the kernel image, the initrd image, and the kernel command line, using QEMU's fw_cfg interface. - We create a read-only EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instance that has just a root directory, with the three downloaded files in it. - The handle that carries the simple file system has a single-node VenHw(...) device path (not counting the terminator node). - We load the EFI-stubbed kernel (which is a UEFI application) with gBS->LoadImage(), passing "VenHw(...)/kernel" as device path. This causes gBS->LoadImage() to call back into our filesystem. - Appended to the downloaded command line, we pass "initrd=initrd" to the EFI stub. - Once the EFI stub is running, it loads the initial ramdisk from the "sibling" device path "VenHw(...)/initrd", also calling back into our filesystem. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16578 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02ArmVirtualizationPkg: identify "new shell" as builtin shell for Intel BDSLaszlo Ersek
The default value of this PCD (in "IntelFrameworkModulePkg.dec") identifies the "old shell" from EdkShellBinPkg. Our build includes the "new" shell from ShellBinPkg/UefiShell/UefiShell.inf; let's specify the FILE_GUID of that. Otherwise, no boot option will be generated for the Shell application. 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@16577 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02ArmVirtualizationPkg: PlatformIntelBdsLib: adhere to QEMU's boot orderLaszlo Ersek
We have all the required pieces in place. Let's call SetBootOrderFromQemu() in PlatformBdsPolicyBehavior(). We disable OFW-to-UEFI device path fragment translation for virtio-pci, and enable it only virtio-mmio at this time. 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@16576 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02ArmVirtualizationPkg: VirtFdtDxe: use dedicated VIRTIO_MMIO_TRANSPORT_GUIDLaszlo Ersek
Installing VenHw() device paths with this GUID, for the virtio-mmio transports that we detect, enables other modules to recognize those VenHw() nodes. (Note that the actual value doesn't change.) In addition, to avoid reusing GUIDs in unrelated contexts, detach the driver's FILE_GUID from its previous value. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16573 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02ArmVirtualizationPkg: PlatformIntelBdsLib: add basic policyLaszlo Ersek
In PlatformBdsPolicyBehavior() we should follow the same pattern as in OvmfPkg's: after the consoles are connected, - connect all drivers and devices, - enumerate all boot options, - enter the Intel BDS FrontPage if the user presses a key different from Enter. We set the countdown to 3 seconds, similarly to the timeout that we specify for ARM BDS. 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@16569 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02ArmVirtualizationPkg: clone PlatformIntelBdsLib from ArmPlatformPkgLaszlo Ersek
In the next patch(es) we'll customize the PlatformBdsLib instance used by ArmVirtualizationQemu.dsc. Let's clone it first verbatim from ArmPlatformPkg/Library/PlatformIntelBdsLib, changing only its FILE_GUID. (Also, coding style errors like "missing space before open parenthesis" and "missing space after comma or semicolon" have been cleaned up.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16568 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02ArmVirtualizationPkg: introduce QemuFwCfgLib instance for DXE driversLaszlo Ersek
After reviewing OvmfPkg's use of its own QemuFwCfgLib instances, it is clear that its only pre-DXE fw_cfg dependency concerns S3 support (the QemuFwCfgS3Enabled() call in "PlatformPei/Platform.c"). For ARM guests, S3 is in the distant future, but we can see several shorter term applications for fw_cfg that all reside in DXE: - controlling boot order (to be implemented in PlatformBdsLib for Intel BDS), - supporting -kernel / -initrd / -append boot on QEMU (to be implemented in PlatformBdsLib for Intel BDS, similarly), - loading and linking ACPI tables, - installing SMBIOS tables. Therefore it makes sense to add a simple MMIO-based fw_cfg client library to ArmVirtualizationPkg that for the moment is only available to DXE_DRIVER modules. Because MMIO accesses are costly on KVM/ARM, InternalQemuFwCfgReadBytes() accesses the fw_cfg data register in full words. This speeds up transfers almost linearly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16567 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02ArmVirtualizationPkg: VirtFdtDxe: forward FwCfg addresses from DTB to PCDsLaszlo Ersek
Qemu's firmware configuration interface for ARM consists of two MMIO registers, a 16-bit selector, and a 64-bit data register that allows the guest to transfer data with 8, 16, 32, and 64-bit wide accesses. Parse the base address from the DTB, and expose the registers to the rest of DXE via dynamic PCDs. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16566 6f19259b-4bc3-4df7-8a09-765794883524
2014-12-15ArmPlatformPkg: Fixed buildOlivier Martin
The original patch was assuming PathLib moved to MdeModulePkg. 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@16522 6f19259b-4bc3-4df7-8a09-765794883524
2014-12-12ArmPkg/BdsLib: Rework TFTP bootRonald Cron
Rework the downloading of an image from a TFTP server to do not depend on any "PXE specific" setting of the DHCP server. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron <Ronald.Cron@arm.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16516 6f19259b-4bc3-4df7-8a09-765794883524
2014-12-12ArmPlatformPkg/Bds: Test if OptionalData is NULL before using itOlivier Martin
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@16515 6f19259b-4bc3-4df7-8a09-765794883524
2014-12-12ArmPlatformPkg/Bds: Fixed memory leakOlivier Martin
Device Paths were not freed after calling BDS_LOAD_OPTION_SUPPORT.CreateDevicePathNode() 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@16514 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-08 18:01:08 +0000