SeaBIOS

seabios@seabios.org

5 participants
3802 discussions

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

[PATCH v17] Add pvpanic device driver
by Hu Tao 15 May '13

15 May '13

pvpanic device is used to notify host(qemu) when guest panic happens. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Hu Tao <hutao(a)cn.fujitsu.com> --- No change from v16. qemu patches at: http://lists.nongnu.org/archive/html/qemu-devel/2013-04/msg01028.html src/acpi.c | 3 +++ src/ssdt-misc.dsl | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+) diff --git a/src/acpi.c b/src/acpi.c index bc4d8ea..fe504f0 100644 --- a/src/acpi.c +++ b/src/acpi.c @@ -534,6 +534,9 @@ build_ssdt(void) ssdt_ptr[acpi_pci64_valid[0]] = 0; } + int pvpanic_port = romfile_loadint("etc/pvpanic-port", 0x0); + *(u16 *)(ssdt_ptr + *ssdt_isa_pest) = pvpanic_port; + ssdt_ptr += sizeof(ssdp_misc_aml); // build Scope(_SB_) header diff --git a/src/ssdt-misc.dsl b/src/ssdt-misc.dsl index 679422b..acc850e 100644 --- a/src/ssdt-misc.dsl +++ b/src/ssdt-misc.dsl @@ -55,4 +55,50 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1) Zero /* reserved */ }) } + + External(\_SB.PCI0, DeviceObj) + External(\_SB.PCI0.ISA, DeviceObj) + + Scope(\_SB.PCI0.ISA) { + Device(PEVT) { + Name(_HID, "QEMU0001") + /* PEST will be patched to be Zero if no such device */ + ACPI_EXTRACT_NAME_WORD_CONST ssdt_isa_pest + Name(PEST, 0xFFFF) + OperationRegion(PEOR, SystemIO, PEST, 0x01) + Field(PEOR, ByteAcc, NoLock, Preserve) { + PEPT, 8, + } + + Method(_STA, 0, NotSerialized) { + Store(PEST, Local0) + If (LEqual(Local0, Zero)) { + Return (0x00) + } Else { + Return (0x0F) + } + } + + Method(RDPT, 0, NotSerialized) { + Store(PEPT, Local0) + Return (Local0) + } + + Method(WRPT, 1, NotSerialized) { + Store(Arg0, PEPT) + } + + Name(_CRS, ResourceTemplate() { + IO(Decode16, 0x00, 0x00, 0x01, 0x01, IO) + }) + + CreateWordField(_CRS, IO._MIN, IOMN) + CreateWordField(_CRS, IO._MAX, IOMX) + + Method(_INI, 0, NotSerialized) { + Store(PEST, IOMN) + Store(PEST, IOMX) + } + } + } } -- 1.8.1.4

5 11

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
by David Woodhouse 14 May '13

14 May '13

On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote: > > It depends. For ARM we insist that the user provides the > device tree that corresponds to the kernel they're going to > run, and then we just tweak it a bit. Um... device trees describe hardware, and should not be at all kernel-specific. Did you mean to say "the device tree that corresponds to the machine they're going to emulate"? And I suppose you do have a kernel that corresponds to the machine it's going to run on, so what you say isn't *entirely* bogus. But it's just written in a way which makes it scary :) -- dwmw2

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS