Re: [edk2] AARCH64: Timer Dxe

Hi, Can some ARM expert help me with my queries below. The overall context is that I cannot get the 'ArmPlatformPkg/Bds/Bds.c' auto-timeout to trigger. The following snippet of code shows how the timeout is created as a event using the CreateEvent and SetTimer APIs. However I cannot the SetTi

Re: [edk2] AARCH64: Timer Dxe

On 06/13/15 10:52, Sharma Bhupesh wrote: > Hi, > > Can some ARM expert help me with my queries below. > > The overall context is that I cannot get the 'ArmPlatformPkg/Bds/Bds.c' > auto-timeout to trigger. > > The following snippet of code shows how the timeout is created as a event > using the

[edk2] PXB changes for QEMU, and extra root buses for OVMF, round 2

Following up on this cross-posted message, I will send two patch sets, one for QEMU (to qemu-devel) and another for OVMF (to edk2-devel). With both in place, OVMF supports multiple PCI root buses, and SeaBIOS recognizes boot options that reference devices behind PXBs. * Background. Since the last

Re: [edk2] AARCH64: Timer Dxe

> On Jun 13, 2015, at 1:52 AM, Sharma Bhupesh > wrote: > > Hi, > > Can some ARM expert help me with my queries below. > > The overall context is that I cannot get the 'ArmPlatformPkg/Bds/Bds.c' > auto-timeout to trigger. > > The following snippet of code shows how the timeout is created as

[edk2] [PATCH v2 15/24] OvmfPkg: PciHostBridgeDxe: kill RootBridgeNumber and RootBridgeAttribute

There is no need to store these constants in dedicated static storage duration objects; we can simply open-code them, simplifying the code. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- OvmfPkg/PciHostBridgeDxe/PciHos

[edk2] [PATCH v2 12/24] OvmfPkg: PlatformBdsLib: refine PCI host bridge assertion

The ASSERT() in SetPciIntLine() assumes that Device 0 on "the" root bus corresponds to the PCI host bridge (00:00). This used to be true, but because we're going to have extra root buses (with nonzero bus numbers), soon this assumption may no longer hold. Check for the zero root bus number explicit

[edk2] [PATCH v2 22/24] OvmfPkg: PciHostBridgeDxe: shorten search for extra root buses

QEMU provides an fw_cfg file called "etc/extra-pci-roots", containing a little-endian UINT64 value that exposes the number of extra root buses. We can use this value to terminate the scan as soon as we find the last extra root bus. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off

[edk2] [PATCH v2 03/24] OvmfPkg: PciHostBridgeDxe: rewrap IoFifo source files to 79 columns

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- OvmfPkg/PciHostBridgeDxe/IoFifo.h| 11 ++- OvmfPkg/PciHostBridgeDxe/Ia32/IoFifo.S | 7 --- OvmfPkg/PciHostBridgeDxe/Ia32/IoFifo.asm | 7 --- Ovm

[edk2] [PATCH v2 06/24] OvmfPkg/PciHostBridgeDxe/PciHostBridge.h: strip trailing ws from code

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- OvmfPkg/PciHostBridgeDxe/PciHostBridge.h | 34 ++-- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.h

[edk2] [PATCH v2 13/24] OvmfPkg: PlatformBdsLib: connect all PCI root buses

Currently we only connect the root bus with bus number 0, by device path. Soon we will possibly have several extra root buses, so connect all root buses up-front (bus number zero and otherwise), by protocol GUID. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek

[edk2] [PATCH v2 21/24] OvmfPkg: PciHostBridgeDxe: look for all root buses

In this patch we assume that root bus number 0 is always there (same as before), and scan the rest of the extra root buses, up to and including 255. When an extra root bus is found, we install the PCI root bridge IO protocol for the previous root bus (which might be bus 0 or just the previous extra

[edk2] [PATCH v2 01/24] OvmfPkg: clone PciHostBridgeDxe from PcAtChipsetPkg

The source code is copied verbatim, with the following two exceptions: - the UNI files are dropped, together with the corresponding UNI references in the INF file, - the INF file receives a new FILE_GUID. The OVMF DSC and FDF files are at once flipped to the cloned driver. Contributed-under: Ti

[edk2] [PATCH v2 18/24] OvmfPkg: PciHostBridgeDxe: release resources on driver entry failure

The entry point of the driver, InitializePciHostBridge(), leaks resources (and installed protocols) in the following cases: - The first root bridge protocol installation fails. In this case, the host bridge protocol is left installed, but the driver exits with an error. - The second or a late

[edk2] [PATCH v2 10/24] OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c: rewrap code, strip trailing ws

In this patch the code and the comments embedded in code are rewrapped to 79 columns, plus any trailing whitespace is stripped. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c

[edk2] [PATCH v2 23/24] OvmfPkg: QemuBootOrderLib: introduce ExtraRootBusMap

SeaBIOS requires the OpenFirmware device paths exported in the "bootorder" fw-cfg file to refer to extra (PXB) root buses by their relative positions (in increasing bus number order) rather than by actual bus numbers. However, OVMF's PCI host bridge / root bridge driver creates PciRoot(UID) device

[edk2] [PATCH v2 19/24] OvmfPkg: PciHostBridgeDxe: use private buffer in RootBridgeIoConfiguration()

On output, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Configuration() function produces a pointer to a buffer of ACPI 2.0 resource descriptors: Resources A pointer to the ACPI 2.0 resource descriptors that describe the current configuration of this PCI root bridge. The storag

[edk2] [PATCH v2 04/24] OvmfPkg: PciHostBridgeDxe: rewrap INF file to 79 columns

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.in

[edk2] [PATCH v2 07/24] OvmfPkg/PciHostBridgeDxe/PciHostBridge.c: rewrap leading comments

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- OvmfPkg/PciHostBridgeDxe/PciHostBridge.c | 579 +--- 1 file changed, 368 insertions(+), 211 deletions(-) diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridg

[edk2] [PATCH v2 16/24] OvmfPkg: PciHostBridgeDxe: embed device path in private root bridge struct

Currently we define a device path for each root bridge statically (for all one of them). Since we'll want to create a dynamic number of root bridges, replace the static device paths with a common template, embed the actual device path into the private root bridge structure, and distinguish the devi

[edk2] [PATCH v2 14/24] OvmfPkg: PciHostBridgeDxe: eliminate nominal support for multiple host bridges

The entry point function of this driver, InitializePciHostBridge(), and the static storage duration objects it relies on, are speculatively generic -- they nominally support more than one host bridges, but (a) the code hardwires the number of host bridges as 1, (b) it's very unlikely that we'd ever

[edk2] [PATCH v2 17/24] OvmfPkg: PciHostBridgeDxe: factor out InitRootBridge() function

This new function incorporates the current loop body found in the entry point function, InitializePciHostBridge(). It will be called once for each root bus discovered. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- Ovm

[edk2] [PATCH v2 05/24] OvmfPkg/PciHostBridgeDxe/PciHostBridge.h: rewrap comments to 79 columns

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- OvmfPkg/PciHostBridgeDxe/PciHostBridge.h | 590 1 file changed, 372 insertions(+), 218 deletions(-) diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridg

[edk2] [PATCH v2 20/24] OvmfPkg: PciHostBridgeDxe: eliminate PCI_HOST_BRIDGE_INSTANCE.RootBridgeNumber

This field was supposed to store the number of root buses created; however we don't need to keep that count persistently. After the entry point returns, nothing reads this field. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Soml

[edk2] [PATCH v2 24/24] OvmfPkg: QemuBootOrderLib: recognize extra PCI root buses

The OFW device path that QEMU exports in the "bootorder" fw_cfg file, for a device that is plugged into the main PCI root bus, is: /pci@i0cf8/... Whereas the same device plugged into the N'th extra root bus results in: /pci-root@N/pci@i0cf8/pci-bridge@0/... (N is in hex.) Extend TranslateP

[edk2] [PATCH v2 08/24] OvmfPkg/PciHostBridgeDxe/PciHostBridge.c: rewrap code, strip trailing ws

In this patch the code and the comments embedded in code are rewrapped to 79 columns, plus any trailing whitespace is stripped. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- OvmfPkg/PciHostBridgeDxe/PciHostBridge.c |

[edk2] [PATCH v2 09/24] OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c: rewrap leading comments

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Regression-tested-by: Gabriel Somlo --- OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c | 1841 1 file changed, 1133 insertions(+), 708 deletions(-) diff --git a/OvmfPkg/PciHostBridgeDxe/PciRootB

[edk2] [PATCH v2 11/24] OvmfPkg: PlatformBdsLib: debug log interrupt line assignments

These messages are helpful for comparing the assignments made by OVMF against those made by SeaBIOS. To SeaBIOS a small debug patch like the following can be applied: > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c > index ac39d23..9e61c22 100644 > --- a/src/fw/pciinit.c > +++ b/src/fw/pciinit.

[edk2] [PATCH v2 00/24] OvmfPkg: support extra PCI root buses

New patches in v2: * [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe Got no feedback from Ray, opted for this. Noted also on the patch itself, with Ray CC'd. * [PATCH v2 23/24] OvmfPkg: QemuBootOrderLib: introduce ExtraRootBusMap Implements the reverse transform described in the p

[edk2] USB3 driver development setup suggestions.

Hello EDK developers, I'm looking for suggestions on the easiest development setup for a USB 3 device Dxe driver. Ideally, I'd prefer a virtualized on a windows host that lets me pass through the USB3 device to the UEFI guest. I have been using Duet and can build and run a basic driver that w

Re: [edk2] USB3 driver development setup suggestions.

> On Jun 13, 2015, at 9:38 AM, Eric Wittmayer wrote: > > Hello EDK developers, > I'm looking for suggestions on the easiest development setup for a USB 3 > device Dxe driver. Ideally, I'd prefer a virtualized on a windows host that > lets me pass through the USB3 device to the UEFI guest. >