qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Sebastian Herbszt" <herbszt@gmx.de>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: info@vruppert.de, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: vgabios + qemu: issues and plans.
Date: Wed, 5 May 2010 21:56:56 +0200	[thread overview]
Message-ID: <4855E2D8011C47A797DC2460DC9919F7@FSCPC> (raw)
In-Reply-To: <4BE174CD.9030606@redhat.com>

Gerd Hoffmann wrote:
>   Hi,
> 
> Today we have two vgabios versions in qemu:  The standard one 
> (vgabios.bin) and the cirrus one (vgabios-cirrus.bin).
> 
> The cirrus vgabios is a PCI ROM.  We can (and do) load it into the ROM 
> PCI bar.  The vgabios checks the pci config space to figure where the 
> linear framebuffer (for vesa graphics) is mapped to.  It knows how to 
> program the cirrus.
> 
> The standard bios isn't a PCI ROM.  We have to load it using the seabios 
> firmware interface.  It expects to find the linear framebuffer at the 
> magic address 0xe0000000.  It uses the bochs extentions to implement 
> vesa graphics support.
> 
> So, what is wrong with this?
> 
> First, I'd like to be able to load the vgabios via PCI ROM bar on all 
> pci vga cards (stdvga, vmware, soon qxl).  The PCI ID in the bios has to 
> match the PCI ID of the card, so we'll need a bunch of vga bios 
> binaries, all identical except for the PCI ID.  Or we need some kind of 
> binary patching.  Otherwise seabios will not load them from the PCI ROM bar.

vgabios could be build multiple times with PCIBIOS set and VENDOR_ID and
DEVICE_ID supplied from the Makefile like it's already done with VGABIOS_DATE.

> Second, I want to get rid of the magic address 0xe0000000 (except for 
> isa-vga).  This is basically just a matter of updating to vgabios 
> version 0.6c.  And this needs one vga bios binary per vga card too as 
> the PCI ID is used to lookup the card (and then the framebuffer address) 
> in PCI config space.
> 
> Comments?  Especially on the binary patching?  Worth it?  Or just build 
> a bunch of binaries?  They are not *that* big after all ...

Few more bios binaries should do no harm. This is currently used for eepro100
(gpxe-eepro100-80861209.rom and gpxe-eepro100-80861229.rom). So maybe
define a similar naming convention for the vgabios.

Sebastian
 
> cheers,
>   Gerd
> 
> 
>

  reply	other threads:[~2010-05-05 20:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-05 13:38 [Qemu-devel] vgabios + qemu: issues and plans Gerd Hoffmann
2010-05-05 19:56 ` Sebastian Herbszt [this message]
2010-05-06  9:35   ` [Qemu-devel] " Gerd Hoffmann
2010-05-06 18:09     ` Sebastian Herbszt
2010-05-06 19:37       ` Gerd Hoffmann
2010-05-06 20:19         ` Sebastian Herbszt
2010-05-06 20:27           ` Gerd Hoffmann
2010-05-06 10:03 ` [Qemu-devel] " Isaku Yamahata
2010-05-06 11:08   ` Gerd Hoffmann
2010-05-06 18:23     ` [Qemu-devel] " Sebastian Herbszt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4855E2D8011C47A797DC2460DC9919F7@FSCPC \
    --to=herbszt@gmx.de \
    --cc=info@vruppert.de \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).