SeaBIOS May 2013

seabios@seabios.org

29 participants
56 discussions

[PATCH] qdev: don't add typename to fw_dev_path when get_fw_dev_path isn't implemented
by Amos Kong 28 May '13

28 May '13

Currently we add typename to fw_dev_path if virtio-bus doesn't have get_fw_dev_path implementation, the fw_dev_path passed to seabios is not expected, the typename is redundant. It causes that bootindex parameter of scsi device doesn't work. This patch changes the qdev_get_fw_dev_path_helper() to add nothing if device doesn't have get_fw_dev_path implementation. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Amos Kong <akong(a)redhat.com> --- hw/core/qdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/core/qdev.c b/hw/core/qdev.c index 6985ad8..150255d 100644 --- a/hw/core/qdev.c +++ b/hw/core/qdev.c @@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size) l += snprintf(p + l, size - l, "%s", d); g_free(d); } else { - l += snprintf(p + l, size - l, "%s", object_get_typename(OBJECT(dev))); + return l; } } l += snprintf(p + l , size - l, "/"); -- 1.8.1.4

2 1

seabios for qemu 1.5
by Gerd Hoffmann 27 May '13

27 May '13

Hi, > b44a7be17bdd270ea029a8e2ec0c2e80c6cd0444 virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd} > 5a7730db57ab0715223421e65b54fb50d6fefe5c virtio-scsi: Set _DRIVER_OK flag before scsi target scanning > Anthony + Gerd, can we expect an rev to pc-bios/bios.bin soon to pick up > these seabios changes for vhost-scsi..? I don't feel like placing a seabios git snapshot into qemu. I think we should just cherry-pick everything we need for qemu 1.5 into the 1.7.2-stable branch, roll out a 1.7.2.2 release and put that into qemu 1.5. So, what will be needed? (1) The two commits listed above. (2) The patch for the pvpanic device (assuming it gets merged for 1.5). Anything else? Hard freeze for qemu 1.5 is next Wednesday. cheers, Gerd PS: For qemu 1.6 (which will hopefully include the acpi table reorganization) we will need a new release from the master branch and thus a bit more careful release planning.

3 4

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
by Dave Frodin 25 May '13

25 May '13

Kevin, Thanks. The new patch that I've attached no longer alters the pci device struct. I also no longer repeatedly read the file in from CBFS, but keep the pointer to it around for the next time the function is called. As far as the use case is concerned. We (or a client) will often have several of the same mainboard (e.g. persimmon), but the graphics ID will vary depending on which version of the cpu is installed. Previously, we would have to figure out what the PCI ID of the graphics devices was, adjust the ID in coreboot's config, build/flash the new rom image. This seabios change along with a change to coreboot to set the ID and stuff the correct vendev mapping file into CBFS will allow a single coreboot/seabios image to be used on any particular mainboard independent of what cpu was installed. This change won't be useful to someone who is using a single board who's graphics ID would never change. For that case they wouldn't need to do anything. If the vendev mapping file doesn't get added they would see no difference. Thanks again, Dave ----- Original Message ----- > From: "Kevin O'Connor" <kevin(a)koconnor.net> > To: "Dave Frodin" <dave.frodin(a)se-eng.com> > Cc: "seabios" <seabios(a)seabios.org> > Sent: Thursday, May 23, 2013 9:01:00 PM > Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one > > On Thu, May 23, 2013 at 05:25:42PM -0500, Dave Frodin wrote: > > Kevin, > > I've attached a patch that I hope is more along the lines > > of where you wanted me to go with this change. In my testing > > of the patch I'm currently just stuffing the vendev-map.bin file > > into my coreboot image. > > Thanks. > > [...] > > + for (i=0; i < filesize/(sizeof (u32)); i+=2) { > > + if ( filedata[i] == ((pci->vendor << 16) | pci->device)) { > > + dprintf(1, "Mapping PCI device 0x%8x to 0x%8x\n", > > + ((pci->vendor << 16) | pci->device), filedata[i+1]); > > + pci->vendor = filedata[i+1] >> 16; > > + pci->device = filedata[i+1] & 0xFFFF; > > + return; > > I don't understand why struct pci_device is being modified. Maybe you > could further explain the use case. After modifying struct > pci_device, where does the video rom actually come from? > > -Kevin >

2 1

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
by Dave Frodin 24 May '13

24 May '13

Kevin, I've attached a patch that I hope is more along the lines of where you wanted me to go with this change. In my testing of the patch I'm currently just stuffing the vendev-map.bin file into my coreboot image. Thanks, Dave ----- Original Message ----- > From: "Kevin O'Connor" <kevin(a)koconnor.net> > To: "Dave Frodin" <dave.frodin(a)se-eng.com> > Cc: "seabios" <seabios(a)seabios.org> > Sent: Wednesday, May 22, 2013 6:45:34 AM > Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one > > On Tue, May 21, 2013 at 02:47:18PM -0500, Dave Frodin wrote: > > All, > > This is a patch that reproduces the vendor ID mapping that is done in > > coreboot in the various AMD northbridge's. The coreboot mapping is only > > useful if coreboot is used to run the vga bios. If seabios is the payload > > then most coreboot configs leave the vga bios init for it. > > Thanks. See my comments below. > > [...] > > --- a/src/optionroms.c > > +++ b/src/optionroms.c > > @@ -154,7 +154,6 @@ getRomPriority(u64 *sources, struct rom_header *rom, > > int instance) > > return bootprio_find_named_rom(file->name, instance); > > } > > Looks like whitespace got corrupted in your email. > > [...] > > +static u32 > > +map_oprom_vendev(u32 vendev) > > +{ > > + u32 new_vendev = vendev; > > + > > + switch (vendev) { > > + case 0x10029803: // Family14 > > + case 0x10029804: > > If we're going to have a mapping, I think it has to be read from > CBFS. I don't think we should hardcode a list into seabios. > > [...] > > static struct rom_header * > > lookup_hardcode(struct pci_device *pci) > > { > > char fname[17]; > > + u32 vendev_mapped; > > + > > + vendev_mapped = map_oprom_vendev((pci->vendor << 16) | pci->device); > > + pci->vendor = vendev_mapped >> 16; > > + pci->device = vendev_mapped & 0xFFFF; > > Modifying struct pci_device doesn't look right. > > -Kevin >

2 1

Re: [SeaBIOS] [Qemu-devel] [PATCH 4/4][seabios] ec: add ASL for ACPI Embedded Controller
by li guang 23 May '13

23 May '13

Add seabios mail-list 在 2013-05-22三的 11:46 +0800，liguang写道： > Signed-off-by: liguang <lig.fnst(a)cn.fujitsu.com> > --- > src/acpi-dsdt.dsl | 1 + > src/ec.dsl | 51 +++++++++++++++++++++++++++++++++++++++++++++++++ > src/q35-acpi-dsdt.dsl | 1 + > 3 files changed, 53 insertions(+), 0 deletions(-) > create mode 100644 src/ec.dsl > > diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl > index 158f6b4..4fa2b9a 100644 > --- a/src/acpi-dsdt.dsl > +++ b/src/acpi-dsdt.dsl > @@ -112,6 +112,7 @@ DefinitionBlock ( > } > Name(FDEN, 1) > } > +#include "ec.dsl" > } > > #include "acpi-dsdt-isa.dsl" > diff --git a/src/ec.dsl b/src/ec.dsl > new file mode 100644 > index 0000000..c8be420 > --- /dev/null > +++ b/src/ec.dsl > @@ -0,0 +1,51 @@ > +/* > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; version 2 of the License. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +Device (EC0) > +{ > + Name(_HID, EISAID ("PNP0C09")) > + Name(_UID, 1) > + > + Method(_CRS, 0) > + { > + Name(BFFR, ResourceTemplate() > + { > + IO(Decode16, 0x62, 0x62, 0, 1) // ACPI DATA IN/OUT > + IO(Decode16, 0x66, 0x66, 0, 1) // CMD/STS > + }) > + Return(BFFR) > + } > + > + OperationRegion(ECFD, EmbeddedControl, 0, 0xFF) > + Field(ECFD, ByteAcc, Lock, Preserve) > + { Offset(1), > + CPUS, 8, // 1, CPU status > + CPUN, 8, // 2, CPU index > + } > + > + Name(_GPE, 17) > + > + Method(_Q01) > + { > + If(LEqual(1, CPUS)) > + { > + Store(0, CPUS) > + } > + Else > + { > + Store(1, CPUS) > + } > + } > +} > diff --git a/src/q35-acpi-dsdt.dsl b/src/q35-acpi-dsdt.dsl > index c031d83..056b4f8 100644 > --- a/src/q35-acpi-dsdt.dsl > +++ b/src/q35-acpi-dsdt.dsl > @@ -167,6 +167,7 @@ DefinitionBlock ( > FDEN, 1 > } > } > +#include "ec.dsl" > } > > #include "acpi-dsdt-isa.dsl"

1 0

[PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
by Dave Frodin 22 May '13

22 May '13

All, This is a patch that reproduces the vendor ID mapping that is done in coreboot in the various AMD northbridge's. The coreboot mapping is only useful if coreboot is used to run the vga bios. If seabios is the payload then most coreboot configs leave the vga bios init for it. >From 5b7f2ba9f43fbc67a81a2449d8bbd3d2f6e530aa Mon Sep 17 00:00:00 2001 From: Dave Frodin <dave.frodin(a)se-eng.com> Date: Tue, 7 May 2013 13:51:56 -0600 Subject: [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one This feature was added to allow mapping multiple different PCI graphics vendor/device IDs to a single ID. The intent is to have the coreboot mainboard define its VGA_BIOS_ID as the ID that is present in the actual VGA BIOS. The PCI ID of the graphics device would then be mapped to that ID. Change-Id: Id06a1c9730546070146932a4dc8ab8229c4a59b9 Signed-off-by: Dave Frodin <dave.frodin(a)se-eng.com> --- src/optionroms.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 68 insertions(+), 1 deletions(-) diff --git a/src/optionroms.c b/src/optionroms.c index 00697b2..bf1e977 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -154,7 +154,6 @@ getRomPriority(u64 *sources, struct rom_header *rom, int instance) return bootprio_find_named_rom(file->name, instance); } - /**************************************************************** * Roms in CBFS ****************************************************************/ @@ -174,11 +173,79 @@ deploy_romfile(struct romfile_s *file) return rom; } +/* Allow mapping of multiple different PCI IDs to a single ID. A single AMD + * VGA BIOS will quite often be used on hardware that reports different + * PCI graphics IDs. This allows a mainboard to have a single definition + * (which would match the ID in the VGA BIOS) yet would support multiple + * CPU IDs. + */ +static u32 +map_oprom_vendev(u32 vendev) +{ + u32 new_vendev = vendev; + + switch (vendev) { + case 0x10029803: // Family14 + case 0x10029804: + case 0x10029805: + case 0x10029806: + case 0x10029807: + case 0x10029808: + case 0x10029809: + new_vendev = 0x10029802; + break; + case 0x10029901: // Family15tn + case 0x10029903: + case 0x10029904: + case 0x10029906: + case 0x10029907: + case 0x10029908: + case 0x1002990A: + case 0x10029910: + case 0x10029913: + case 0x10029917: + case 0x10029918: + case 0x10029919: + case 0x10029990: + case 0x10029991: + case 0x10029992: + case 0x10029993: + case 0x10029994: + case 0x100299A0: + case 0x100299A2: + case 0x100299A4: + new_vendev = 0x10029900; + break; + case 0x10029831: // Family16kb + case 0x10029832: + case 0x10029833: + case 0x10029834: + case 0x10029835: + case 0x10029836: + case 0x10029837: + case 0x10029839: + case 0x1002983D: + new_vendev = 0x10029830; + break; + default: + break; + } + if (vendev != new_vendev) + dprintf(1, "Mapping PCI device %8x to %8x\n",vendev, new_vendev); + return new_vendev; +} + // Check if an option rom is at a hardcoded location or in CBFS. static struct rom_header * lookup_hardcode(struct pci_device *pci) { char fname[17]; + u32 vendev_mapped; + + vendev_mapped = map_oprom_vendev((pci->vendor << 16) | pci->device); + pci->vendor = vendev_mapped >> 16; + pci->device = vendev_mapped & 0xFFFF; + snprintf(fname, sizeof(fname), "pci%04x,%04x.rom" , pci->vendor, pci->device); struct romfile_s *file = romfile_find(fname); -- 1.7.9

2 1

Re: [SeaBIOS] KVM call agenda for 2013-05-21
by Michael S. Tsirkin 21 May '13

21 May '13

On Mon, May 20, 2013 at 12:57:47PM +0200, Juan Quintela wrote: > > Hi > > Please, send any topic that you are interested in covering. > > Thanks, Juan. Generating acpi tables. Cc'd a bunch of people who might be interested in this topic. Kevin - could you join on Tuesday? There appears a disconnect between the seabios and qemu that a conf call might help resolve. -- MST

4 8

DMI based quirks?
by Christian Gmeiner 21 May '13

21 May '13

Hi all. Would it be possible to add some DMI based quirks? I have a device and in coreboot I have some detection code for it: http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/mainboard/bac… Now it takes quite some time to load Grub in PIO mode even the device could use DMA. For the linux kernel I have added this patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=… What would be the best solution in seabios to use PIO for broken devices and DMA for the others? The biggest problem is that the device supports DMA but due a missing resister I breaks in DMA. thanks -- Christian Gmeiner, MSc

1 0

seabios-1.7.2 stable changes
by Kevin O'Connor 21 May '13

21 May '13

Hi Gerd, I just pulled your git branch at "git://git.kraxel.org/seabios 1.7.2-kraxel" into the seabios 1.7.2-stable branch. (I know my timing isn't great.) I did not pull the pvpanic changes as I'm reluctant to put a new feature and change the acpi tables in a stable release. If there are no other pressing changes, I'll tag 1.7.2.2. -Kevin

1 0

2013 Linux Plumbers Virtualization Microconference proposal call for participation
by Alex Williamson 17 May '13

17 May '13

Hey folks, We'd like to hold another virtualization microconference as part of this year's Linux Plumbers Conference. To do so, we need to show that there's enough interest, materials, and people willing to attend. Anthony and Amit have already started a wiki page for the microconference: http://wiki.linuxplumbersconf.org/2013:virtualization Please help to fill it out and add topics you're interested in discussing or presenting, or relevant topics to current development that you'd like others to present. We don't need full abstracts or proposals at this time, just enough to show that we have things to discuss and enough people interested in attending to allocate space in the program. If approved by the program committee we'll give precedence to proposals that address current issues needing attention, help, or resolution. This is also an excellent opportunity for cross-project discussions. We're not sure when the LPC program committee will make a decision, so please don't hesitate to add things to the wiki as soon as possible. There's no commitment at this point though we obviously hope that many of you will follow through with participation if this microconference is approved. Please feel free to forward to anyone I've missed. Thanks, Alex

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS May 2013