Re: [edk2] CorebootModulePkg: gcc reports conflicting types for 'CbParseAcpiTable'

On Di, 2015-05-26 at 10:48 +0200, Laszlo Ersek wrote: > Hi, > > CorebootModulePkg fails to build with gcc. See error msg below. Shamelessly hijacking the thread, as the coreboot people are nicely in Cc: ... What hardware is the CorebootPkg supposed to work on? Any hardware coreboot boots on? O

Re: [edk2] CorebootModulePkg: gcc reports conflicting types for 'CbParseAcpiTable'

Hi, > CorebootPayloadPkg can support both serial port (in/out) and Framebuffer > (out) as console. serial port @ standard pc location (i.e. iobase=0x3f8)? > The debug output will be on serial port only at this point. Anything specific needed to enable it or is it on by default (in debug

Re: [edk2] CorebootModulePkg: gcc reports conflicting types for 'CbParseAcpiTable'

On Do, 2015-05-28 at 16:14 +, Ma, Maurice wrote: > Hi, Gerb, > > The current UEFI payload can support 16550 UART compatible UART only. > > The serial port I/O base and type (I/O or MMIO) are passed from coreboot to > the UEFI payload. So I probably need serial console support in coreboot to

Re: [edk2] CorebootModulePkg: gcc reports conflicting types for 'CbParseAcpiTable'

Hi, > > Any idea what this could be? > > Yes, you can track this down. Just locate the .dll file referenced in > the above register dump (well, in fact, the same pathname with the > .debug suffix might be even better), and then with the help of > "objdump", you can tie the crash site to the sou

Re: [edk2] CorebootModulePkg: gcc reports conflicting types for 'CbParseAcpiTable'

On Fr, 2015-05-29 at 19:54 +, Ma, Maurice wrote: > Hi, Gerd, > > The current UEFI payload has an assumption that all interrupt sources will be > masked off before transferring to the UEFI payload. > In your case I saw the 8259 interrupts were unmasked before the handoff. > > I tried to add t

Re: [edk2] [patch 0/4] EDKII Usb stack async transfer performance tunning

On Do, 2015-06-04 at 15:24 +0200, Laszlo Ersek wrote: > On 06/04/15 08:16, Tian Feng wrote: > > Update the value of those async polling interval macros from 50ms to 1ms. > > Out of pure curiosity, how does this manifest in CPU consumption? > > USB 1 and 2 are CPU hungry when virtualized. > > USB

[edk2] [PATCH] Add virtio-vga support

The vga compatibility part of virtio-vga is identical to the qemu standard vga, so supporting that is as easy as adding the PCI ID to the list. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gerd Hoffmann --- OvmfPkg/QemuVideoDxe/Driver.c | 5 + 1 file changed, 5

Re: [edk2] [PATCH] Add virtio-vga support

On Di, 2015-06-23 at 14:52 +0200, Laszlo Ersek wrote: > On 06/23/15 14:36, Gerd Hoffmann wrote: > > The vga compatibility part of virtio-vga is identical to the qemu > > standard vga, so supporting that is as easy as adding the PCI ID > > to the list. > > >

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: fix querying of QXL's drawable buffer size

Hi, > The current calculation is correct for stdvga, because on stdvga the value > returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the full video RAM, is > usable for drawing. Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is a qemu bug. We have releases with the bug in the w

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: fix querying of QXL's drawable buffer size

Hi, > If the workaround is stable in your opinion (ie. it can be relied upon > even after the qemu problem with VBE_DISPI_INDEX_VIDEO_MEMORY_64K is > fixed), then I'd probably leave it in, even in the long term. Yes, ROM (bar 2) struct layout is stable. > Jordan, is it enough if I only reword

Re: [edk2] [PATCH v2] OvmfPkg: QemuVideoDxe: work around misreported QXL framebuffer size

ns on the QXL card > (up to > the full size of the video RAM). If a GOP client selects such a > resolution > and draws into the video RAM past the compatibility segment, then the > guest corrupts its communication struct

Re: [edk2] OVMF, Q35 and USB keyboard/mouse

Hi, > So at this point I'm wondering why guests and "info qtree" are contradictory, > and whether the combination of OVMF and OS X tickle some qemu usb emulation > bug differently than all other (working) combinations ? It's due to the way how usb1 compatibility was implemented when ehci was in

Re: [edk2] OVMF, Q35 and USB keyboard/mouse

Hi, > With OVMF, I have EHCI with the high-speed (and working) > keyboard+mouse, but ONLY ONE UHCI device (UHCI3). UHCI1 UHCI2 do not > get detected. Now *that* is really strange, especially as UHCI1 is pci function 0, without probing that successfully you wouldn't see the other pci functions (1

Re: [edk2] [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

Hi, > OK, so I forgot to articulate that with the above patch, I'm seeing > *both* uhci2 and uhci3, but not uhci1. Basically, if uhciX has an > irq_pin less than 2, it won't show up in OSX if booted with ovmf. > We're no longer looking at PIIX, this is q35 with ovmf or without. Can you test wha

Re: [edk2] [PATCH 01/14] OvmfPkg: initialize Q35 platform

On Sa, 2014-09-27 at 18:06 -0400, Gabriel L. Somlo wrote: > Factor out logic to distinguish between Q35 and PIIX4 platforms > into a separate header (OvmfPkg/Include/Library/PciHostBridge.h), > then refer to these macros from all relevant source locations > throughouth OvmfPkg. > > This patch also

Re: [edk2] [PATCH 01/14] OvmfPkg: initialize Q35 platform

Hi, > + mtrr: your CPUs had inconsistent fixed MTRR settings > + mtrr: your CPUs had inconsistent variable MTRR settings > + mtrr: your CPUs had inconsistent MTRRdefType settings > + mtrr: probably your BIOS does not setup all CPUs. > + mtrr: corrected configuration. Sounds like ovmf sets up th

Re: [edk2] [PATCH 01/14] OvmfPkg: initialize Q35 platform

On Mo, 2014-09-29 at 11:10 +0200, Paolo Bonzini wrote: > Il 29/09/2014 09:26, Gerd Hoffmann ha scritto: > >> + mtrr: your CPUs had inconsistent fixed MTRR settings > >> > + mtrr: your CPUs had inconsistent variable MTRR settings > >> > + mtrr: your CPUs h

Re: [edk2] [PATCH v3 6/6] OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initialization

> + // FIXME: This should be accomplished programmatically by enumerating > + //all PCI devices present in the system and computing > + //PCI_INTERRUPT_LINE from PCI_INTERRUPT_PIN, the slot/position > + //of the device, and the available host IRQs (for an example, > + /

[edk2] [Fwd: Build failed in Jenkins: edk2 #753]

Hi, My build throws assembler errors now, looks like binutils are too old to know the system registers. My versions: binutils-aarch64-linux-gnu-2.23.88.0.1-2.el7.x86_64 gcc-aarch64-linux-gnu-4.8.1-5.2.el7.1.x86_64 Any chance this can be fixed? Maybe by using numbers instead if symbolic name

Re: [edk2] [Fwd: Build failed in Jenkins: edk2 #753]

On Di, 2014-10-28 at 10:29 +, Olivier Martin wrote: > I have just tried to use the system register (instead of the coprocessor IDs) > with the GCC49 14.07 Linaro toolchain: > > tianocore/Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPkg/Drivers/ArmGic/ArmGicLib/OUTPUT/GicV3/AArch64/ArmGicV3.iii:35: >

Re: [edk2] [PATCH v3 6/6] OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initialization

On Di, 2014-10-28 at 08:53 -0400, Gabriel Somlo wrote: > On Tue, Oct 28, 2014 at 08:30:29AM +0100, Gerd Hoffmann wrote: > > > + // FIXME: This should be accomplished programmatically by enumerating > > > + //all PCI devices present in the

Re: [edk2] [PATCH v4 0/6] OVMF: Adding support for Qemu Q35 machine type

't get me wrong :) And I may still be too much of an edk2 n00b > to > pull off porting pci_bios_init_devices(). But it sure would be > nice and > elegant to have it done like that... Reviewed-by: Gerd Hoffmann -

Re: [edk2] [PATCH v4 6/6] OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initialization

Hi, > From what I have been able to see, "pci->parent" is always NULL from > the very beginning, so the IRQ is computed based only on the "pin" and > the device number ("pci_bdf_to_dev(pci->bdf)"), and by that I mean > the *original* pci->bdf, not the result of walking up the parent link. On a

Re: [edk2] [PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type

On Do, 2014-11-13 at 15:12 -0500, Gabriel L. Somlo wrote: > - patch 9/9 (dynamic IRQ Line initialization) now works on non-root > buses and pci-to-pci bridges, 100% matching SeaBIOS behavior. The code looks good. Great job! Reviewed-by: Gerd Hoffmann cheers,

Re: [edk2] [PATCH v7] OvmfPkg: PlatformBdsLib: Dynamic PCI Interrupt Line register setup

ce ID along the path to get the same result SeaBIOS does. Oh, right. Yes, it's the root bus slot number you have to look at (slot 24+ on the root bus are the chipset devices). Reviewed-by: Gerd Hoffmann -- Comprehen

Re: [edk2] Any patches for running OVMF on ARM?

Hi, > Gerd has also extended his public, Jenkins-built yum repo at > with "edk2.git-aarch64" and > "edk2.git-arm" -- these are rebuilt from edk2 git every day (more > frequently actually, as far as I remember). It checks the upstream repo once per hour, and if the

Re: [edk2] Latest OVMF vs. QEMU 2.2.0 and PXE boot

ipxe update in December, after the 2.2 release, so you might want try updating to latest master branch or cherry-pick the commit and see whenever that fixes your problem: === cut here === commit c246cee4eedb17ae3932d699e009a8b63240235f Author: Gerd Hoffmann Date: Wed De

Re: [edk2] EFI and Legacy BIOS ROM Modules

Hi, > The relevant ACPI SSDT is here: > http://pastebin.com/Q2qeBdkb > I was told on the nouveau IRC channel that the important method > is _ROM (line 2847). Hmm, my apci-foo isn't good enough to figure what exactly this thing is doing. Seems to somehow calculate and return address of the rom

Re: [edk2] [PATCH v2 00/10] OVMF support for QEMU's PC System Flash

Hi, > I updated the final commit in that tree, as well as the only outstanding > > commit in http://git.infradead.org/users/dwmw2/seabios.git to handle the > > writable UMB stack according to the v0.98 spec update. > > Gerd co-maintains SeaBIOS, I propose to take it up with him. Yep, that one

Re: [edk2] Passing Xen memory map and resource map to OVMF

data structure I can use? What io/mmio ressources do you need to pass on? > As far as I can see, qemu exports an fw_cfg table called "etc/e820". See > qemu commit > > commit 7d67110f2d9a6a2d6b5215a948abc95d07258735 > Author: Gerd Hoffmann > Date: Fri Oct 18 11:31:54 2

Re: [edk2] Passing Xen memory map and resource map to OVMF

On Mi, 2013-11-13 at 11:58 +, Wei Liu wrote: > On Wed, Nov 13, 2013 at 08:03:39AM +0100, Gerd Hoffmann wrote: > > Hi, > > > > > > The first thing that comes in mind is to reuse E820 table for memory map > > > > plus some extra fields for io /

Re: [edk2] Passing Xen memory map and resource map to OVMF

Hi, > > > MMIO holes, IO range created by hvmloader. > > > > Why? All (memory) address space not backed by ram effectively is mmio. > > There is no need to explicitly declare holes ... > > > > Yes there is, because hvmloader is in charge of declaring holes. Why does it declare holes in the

Re: [edk2] Passing Xen memory map and resource map to OVMF

Hi, > > > OVMF > > > should just use whatever it gets. > > > > What would OVMF use them for? > > > > To reserve range for MMIO holes, so that later PCI resource allocation > protocol can only use those ranges. I'm still not convinced you need that in the first place. When booting seabios @

Re: [edk2] Passing Xen memory map and resource map to OVMF

Hi, > > So why ovmf should be different? IMHO it should operate like seabios > > and NOT do pci ressource allocation when running on xen. Ressources are > > already handled already by hvmloader. Doing it again is (a) pointless > > and (b) creates problems like the one we are discussion right

Re: [edk2] Passing Xen memory map and resource map to OVMF

Hi, > There are other examples in the edk2 where PCI enumeration is not required: > 1) DUET, as the PCI enumeration has already been done. That is very simliar to the situation we have when running edk2 on xen (and coreboot), so its worth investigating that route IMHO. cheers, Gerd -

Re: [edk2] [Xen-devel] [PATCH RFC 0/7] OvmfPkg: make OVMF fully working with Xen

Hi, > Second thought on this. > > The main advantage to have a runtime Pcd over build time static > configuration is that we can use single binary for all OVMF use cases. > However currently Xen hvmloader statically embeds firmware blobs in > itself so it doesn't really matter if OVMF is config

Re: [edk2] [edk2 PATCH 0/1] OvmfPkg: grab ACPI tables from QEMU

Hi, > ACPI PciWindow32: Base=0xA000 End=0xFEEF Length=0x5EF0 > begin32=c000 end32=fec0 begin64=0 end64=0 qemu & seabios pick a 32bit window size which allows to cover it with a single mtrr entry. Size must be a power of two for that to work. [root@fedora ~]# cat /pr

Re: [edk2] [edk2 PATCH 0/1] OvmfPkg: grab ACPI tables from QEMU

Hi, > > > btw: q35 has a fixed 1G window, max low ram addr is 0xb00, the > > > remaining address space (0xb000 -> 0xc000) is used for > > > mmconfig. > > Is it really fixed? My understanding is it's programmed by firmware, > you can put mmconfig whereever you want. Not really fixed

Re: [edk2] [edk2 PATCH 0/1] OvmfPkg: grab ACPI tables from QEMU

Hi, > > If you simply relax (drop) the stage-wise hole-setting, that will at > > best create a situation where OVMF and qemu duplicate the logic. This > > info needs to be passed down to OVMF (maybe it already is, somewhere in > > fw_cfg!), in some form that's more approachable than an ACPI tabl

Re: [edk2] OVMF VGA resume status (was: [PATCH 00/22] S3 suspend/resume for OVMF)

Hi, > (1) When booting Linux with OVMF's GOP (doesn't matter with which video > card), the first driver grabbing the card is the efifb driver. This is > reported in dmesg as: > > [0.891094] efifb: probing for efifb > [0.896161] efifb: framebuffer at 0xa400, mapped to >

Re: [edk2] [PATCH 5/6] OvmfPkg: QemuVideoDxe: filter BOCHS modes vs. available frame buffer size

On Fr, 2014-01-31 at 21:05 +0100, Laszlo Ersek wrote: > In the next patch we'll add many new BOCHS modes, some of which require > large frame buffers. > > The size of the primary bar (frame buffer) can be changed with the > > -global qxl-vga.ram_size=NUM_BYTES > > QEMU option. qxl bar #0 hold

Re: [edk2] [PATCH 5/6] OvmfPkg: QemuVideoDxe: filter BOCHS modes vs. available frame buffer size

Hi, > But, indeed, that's my problem exactly. I did look into the qemu source > (and I did notice VBE_DISPI_INDEX_VIDEO_MEMORY_64K), and there are about > five device and/or global properties (from which libvirt uses at least > two) that mess around with sizes related to video ram. ram_size

Re: [edk2] [PATCH 5/6] OvmfPkg: QemuVideoDxe: filter BOCHS modes vs. available frame buffer size

Hi, > QemuVideoBochsModeSetup() > Avail = BochsRead(VBE_DISPI_INDEX_VIDEO_MEMORY_64K) // just grab > // it here > /* filter & populate modes */ Yes, with BochsRead being an external function (/me didn't check) tha

Re: [edk2] OVMF S3 support committed

Hi, Glad to see S3 support being committed. > http://lists.freedesktop.org/archives/dri-devel/2014-February/054549.html > http://lists.freedesktop.org/archives/dri-devel/2014-February/054550.html > > I tested standard VGA (bochsdrmfb, with backports of the above patches); > it works, and the c

Re: [edk2] OVMF S3 support committed

Hi, > > Hmm. Seems we have one more case of cirrusdrm not completely > > (re-)initializing the card. Had that with seabios too. The > > cirrus_mode.c chunk of the cirrusdrm patch fixed it there. Looks like > > cirrusdrm trips over something else with ovmf due to the different > > firmware in

Re: [edk2] [PATCH v2] OvmfPkg: QemuVideoDxe: Int10h stub for Windows 2008 R2 SP1 (stdvga, QXL)

On Fr, 2014-05-16 at 14:59 -0700, Jordan Justen wrote: > I'm planning to tweak the commit message and README to mention both > win7 & win2008 as discussed on irc. > > Reviewed-by: Jordan Justen > > r-b Gerd? Patch looks good to me. Reviewed-by: Ger

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: Int10h stub for Windows 2008 R2 SP1 (stdvga, QXL)

Hi, > Or were you really intending the tools to give the user an explicit > choice of legacy vs. UEFI rather than depending on the OS? That would > kind of suck too. Microsoft does exactly that. Latest hyper-v has "generation 1" (== bios) and "generation 2" (== efi) virtual machines. There ar

Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: Int10h stub for Windows 2008 R2 SP1 (stdvga, QXL)

Hi, > > Which is why I spent the time to enable CSM in the first place, of > > course. Not to mention the fact that having OVMF+CSM as a default > > firmware will serve to accelerate adoption of UEFI in virtual machines, > > and that gives people a *really* easy playground to get involved in EDK

[edk2] Unaligned I/O ?

must be an outw instruction. Hints anyone? thanks, Gerd PS: wip patch attached for reference From 9c4b25e3f338f376aa6c1195a1b5ac08715a7ddb Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Mon, 29 Oct 2012 13:53:00 +0100 Subject: [PATCH] [wip] QemuVideo: add qemu standard vga support Signed-off-by

Re: [edk2] Unaligned I/O ?

lignedIoRead/Write16 Whoa, straight to the lowest level. But works fine. Adds gcc dependency though. Incremental patch attached FYI. thanks, Gerd From 3d38e9b451486b4df2e4e5ea6a223db240ffed86 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Thu, 8 Nov 2012 23:07:57 +0100 Subject: [PATCH 2

Re: [edk2] Unaligned I/O ?

On 11/10/12 00:30, Paolo Bonzini wrote: > Il 08/11/2012 23:17, Gerd Hoffmann ha scritto: >> On 11/08/12 22:23, Jordan Justen wrote: >>> Seems like you're going to need to: >>> * Pull IoRead/Write16 from MdePkg/Library/BaseIoLibIntrinsic into the >>> driver

[edk2] [PATCH 2/3] QemuVideo: Add support for the bochs dispi interface

=df9ffb726ff13f850b8829be1bc85ed621b903ac Signed-off-by: Gerd Hoffmann --- OvmfPkg/QemuVideoDxe/Driver.c | 86 - OvmfPkg/QemuVideoDxe/Gop.c|3 + OvmfPkg/QemuVideoDxe/Initialize.c | 52 ++ OvmfPkg/QemuVideoDxe/Qemu.h | 60 + 4

[edk2] [PATCH 1/3] QemuVideo: prepare to support more hardware

Move to a table-driven hardware detection. Add a table with PCI IDs, card name and variant enum. Use the table for hardware detection and initialization. Rename Cirrus-specific data and code to carry "cirrus" in the name. Signed-off-by: Gerd Hoffmann --- OvmfPkg/QemuVideoDx

[edk2] [PATCH 0/3] QemuVideo: add support for the bochs dispi interface

Hi, This patch series adds support for the bochs dispi interface which is supported by the qemu standard vga (-vga std) and qxl (-vga qxl). cheers, Gerd Gerd Hoffmann (3): QemuVideo: prepare to support more hardware QemuVideo: Add support for the bochs dispi interface QemuVideo

[edk2] [PATCH 3/3] QemuVideo: stdvga mmio bar support

The qemu standard vga has a MMIO bar in qemu 1.3+. Use it if available. Signed-off-by: Gerd Hoffmann --- OvmfPkg/QemuVideoDxe/Driver.c | 88 +++- OvmfPkg/QemuVideoDxe/Gop.c|1 + OvmfPkg/QemuVideoDxe/Qemu.h |8 3 files changed, 86

Re: [edk2] [PATCH 0/3] QemuVideo: add support for the bochs dispi interface

On 11/19/12 13:34, Laszlo Ersek wrote: > Hello Gerd, > > On 11/19/12 10:56, Gerd Hoffmann wrote: > >> This patch series adds support for the bochs dispi interface which is >> supported by the qemu standard vga (-vga std) and qxl (-vga qxl). > > May I ask how you fo

Re: [edk2] [PATCH 0/3] QemuVideo: add support for the bochs dispi interface

On 11/19/12 14:35, Laszlo Ersek wrote: > On 11/19/12 14:21, Gerd Hoffmann wrote: > >> Emacs figured (says "DOS" in the buffer status line), so I assume emacs >> maintains this convention in the source files. Didn't double-check though. > > If Jordan&

Re: [edk2] [PATCH 0/3] QemuVideo: add support for the bochs dispi interface

Hi, >> Ahem. Yes, the files created by "git format-patch" have mixed line end >> conventions. Everything coming from git (commit message, the +++, ---, >> and @@ lines) has just LF, whereas everything coming from the source >> files has CRLF. That sucks indeed. > > This is true for all patch

Re: [edk2] [PATCH 0/3] QemuVideo: add support for the bochs dispi interface

Hi, > I have no feedback on the code contents at this point. > > Regarding the commit message, you'll need to re-submit the patches. Please > see: > OvmfPkg/Contributions.txt (Contributed-under...) Ok, will do, waiting a bit for possible comments on the code before resending. > What happened

[edk2] [PATCH 2/3] QemuVideo: Add support for the bochs dispi interface

From: Gerd Hoffmann Add code to handle qemu-emulated vga cards supporting the bochs dispi interface (standard vga, qxl vga). This requires qemu 1.3+ which provides the bochs dispi interface data register on a aligned io address. See http://git.qemu.org/?p=qemu.git;a=commitdiff;h

[edk2] [PATCH 0/3] QemuVideo: add support for the bochs dispi interface

From: Gerd Hoffmann Hi, This patch series adds support for the bochs dispi interface which is supported by the qemu standard vga (-vga std) and qxl (-vga qxl). cheers, Gerd Gerd Hoffmann (3): QemuVideo: prepare to support more hardware QemuVideo: Add support for the bochs

[edk2] [PATCH 1/3] QemuVideo: prepare to support more hardware

From: Gerd Hoffmann Move to a table-driven hardware detection. Add a table with PCI IDs, card name and variant enum. Use the table for hardware detection and initialization. Rename Cirrus-specific data and code to carry "cirrus" in the name. Contributed-under: TianoCore Co

[edk2] [PATCH 3/3] QemuVideo: stdvga mmio bar support

From: Gerd Hoffmann The qemu standard vga has a MMIO bar in qemu 1.3+. Use it if available. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gerd Hoffmann --- OvmfPkg/QemuVideoDxe/Driver.c | 88 +++- OvmfPkg/QemuVideoDxe

Re: [edk2] [PATCH 3/3] QemuVideo: stdvga mmio bar support

>> +VOID >> +VgaOutb ( >> + QEMU_VIDEO_PRIVATE_DATA *Private, >> + UINTNReg, >> + UINT8Data >> + ); >> + > > Any particular reason why "Reg" is not UINT16? UINTN seems inconsistent with > BochsRead/BochsWrite. It's consistend with outb(). >> @@ -790,

[edk2] [PATCH v2 2/3] QemuVideo: Add support for the bochs dispi interface

From: Gerd Hoffmann Add code to handle qemu-emulated vga cards supporting the bochs dispi interface (standard vga, qxl vga). This requires qemu 1.3+ which provides the bochs dispi interface data register on a aligned io address. See http://git.qemu.org/?p=qemu.git;a=commitdiff;h

[edk2] [PATCH v2 0/3] QemuVideo: add support for the bochs dispi interface

From: Gerd Hoffmann Hi, This patch series adds support for the bochs dispi interface which is supported by the qemu standard vga (-vga std) and qxl (-vga qxl). v2 has a bunch of updates according to Laszlo's review comments. It is also available from github: git://githu

[edk2] [PATCH v2 3/3] QemuVideo: stdvga mmio bar support

From: Gerd Hoffmann The qemu standard vga has a MMIO bar in qemu 1.3+. Use it if available. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gerd Hoffmann --- OvmfPkg/QemuVideoDxe/Driver.c | 115 +--- OvmfPkg/QemuVideoDxe

[edk2] [PATCH v2 1/3] QemuVideo: prepare to support more hardware

From: Gerd Hoffmann Move to a table-driven hardware detection. Add a table with PCI IDs, card name and variant enum. Use the table for hardware detection and initialization. Rename Cirrus-specific data and code to carry "cirrus" in the name. Contributed-under: TianoCore Co

Re: [edk2] can OVMF boot an OS in qemu?

Hi, > 2) could not display in spice (-vga qxl -spice > port=5900,addr=127.0.0.1,disable-ticketing), spicec is blank. That requires qemu 1.3.0 (and a recent ovmf too) to work. cheers, Gerd -- LogMeIn Rescue: Anywher

[edk2] ovmf + SECURE_BOOT_ENABLE

Hi, Trying to build ovmf with secure boot enabled gives me this: GenFv: ERROR 3000: Invalid the required fv image size 0xe96b0 exceeds the set fv image size 0xe6000 Ideas anyone? cheers, Gerd -- LogMeIn Rescue: A

[edk2] [announce] qemu firmware repo

Hi, yum repository with fresh qemu firmware builds is available now: http://www.kraxel.org/repos/ Provides rpms with seabios, tianocore (efi), coreboot and ipxe binaries. enjoy, Gerd PS: /me will disappear into xmas season shortly, so any issues will have to wait 'til next year. je

[edk2] the required fv image size 0x655948 exceeds the set fv image size 0x600000

Hi, See $subject, triggered by: OvmfPkg/build.sh -t GCC44 \ -D SECURE_BOOT_ENABLE \ -D NETWORK_ENABLE \ -D FD_SIZE_2MB \ -a X64 -p OvmfPkg/OvmfPkgX64.dsc Do we need FD_SIZE_4MB? Other suggestions? cheers, Gerd - [ more complete log ] ---

[edk2] ovmf pxeboot

Hi, I'm running ovmf with networking enabled and ipxe efi roms. Network driver seems to work properly. In efi shell I can ifconfig the interface with a static ip address and ping the default gateway. dhcp autoconfigutation doesn't work though. looks like ovmf doesn't like the replies it gets

Re: [edk2] SeaBIOS as CSM

Hi, > The implementation of this would be horrid, and it's made even more > horrid by the fact that it would then have to do the platform-specific > unlocking in its Legacy16Boot method, before re-enabling the normal > stack-swapping code. And the CSM isn't really supposed to do that kind > of p

Re: [edk2] CSM and keyboard handling

Hi, > And we only invoke the iPXE ROM on the network card *after* the user has > seen the boot menu (without that option), so the user never gets to > choose that. You can build ipxe efi roms and use those, then netboot will show up in the efi boot menu (although I didn't got that actually work

Re: [edk2] CSM and keyboard handling

On 01/22/13 14:46, David Woodhouse wrote: > On Tue, 2013-01-22 at 09:51 +0100, Gerd Hoffmann wrote: >> >>> And we only invoke the iPXE ROM on the network card *after* the user has >>> seen the boot menu (without that option), so the user never gets to >>> choos

Re: [edk2] CSM and keyboard handling

On 01/23/13 00:03, David Woodhouse wrote: > Without CSM support, I can reproduce the problem with the 'Press any key > to boot from CD or DVD...' message not being displayed, but *only* if I > start qemu with '-vga vmware'. With std, qxl or cirrus options, OVMF now > works fine. I think it has nati

[edk2] combined roms (Re: Secure Boot - PCI device driver (NIC))

Hi, > When you refer to .ROM file … is this just the EFI driver or is this > the combined EFI+Legacy Option ROM? You should not sign the entire > Option ROM (EFI+legacy) … that will break the format of the PCI > Option ROM. You only need to sign the EFI driver before creating the > combined Opti

Re: [edk2] [PATCH 2/2] LegacyBbs: add boot entries for virtio-blk devices

Hi, > ... BTW why can't SeaBIOS grab the bootorder fw_cfg file just the same > in the CSM build? (Commit 60258aa4 in David's repo.) Because you want only one boot menu. When you pick 'legacy boot from this cdrom' in the ovmf boot menu you want seabios boot straight from the specified cdrom. c

Re: [edk2] [PATCH 00/15] OvmfPkg: introduce virtio-net driver

On 05/03/13 08:09, Laszlo Ersek wrote: > Both testing and review are greatly appreciated! How does it compare to the ipxe driver? cheers, Gerd -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a fr

Re: [edk2] [PATCH 00/15] OvmfPkg: introduce virtio-net driver

On 05/06/13 08:37, Jordan Justen wrote: > I would say general networking + VirtioNetDxe can be enabled by the > current switch, and Intel drivers could be enabled by E1000_ENABLE. I think there should be switches for each of the three: general networking, e1000 driver + virtio driver. Yes, genera

Re: [edk2] [PATCH 00/15] OvmfPkg: introduce virtio-net driver

On 05/06/13 09:04, Jordan Justen wrote: > On Sun, May 5, 2013 at 11:50 PM, Gerd Hoffmann wrote: >> On 05/06/13 08:37, Jordan Justen wrote: >>> I would say general networking + VirtioNetDxe can be enabled by the >>> current switch, and Intel drivers could be enabled by

Re: [edk2] [PATCH 00/15] OvmfPkg: introduce virtio-net driver

Hi, > The -D NETWORK_ENABLE build switch enables and embeds the following > drivers in the firmware image (not mentioning VirtioNetDxe now): > This is the generic edk2 network stack. The only missing link is the > lowest level, hardware NIC driver. Yes. > Currently, -D NETWORK_ENABLE also add

Re: [edk2] [PATCH 00/15] OvmfPkg: introduce virtio-net driver

Hi, > That should be the case, following Gerd's upstream qemu commit > c45e5b5b30ac1f5505725a7b36e68cedfce4f01f (from Feb 2013). Starting with > qemu-1.5.0, these should work out of the box, I believe. Unless you switch qemu into backward compatibility mode using 'qemu -M pc-${oldversion}'. >