SeaBIOS June 2013

seabios@seabios.org

22 participants
54 discussions

Start a nNew thread

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

01 Jun '13

1 0

Re: [SeaBIOS] [Qemu-devel] What's the impact of enlarging IDE_TIMEOUT ?
by Kevin O'Connor 01 Jun '13

01 Jun '13

On Fri, May 31, 2013 at 03:18:56AM +0000, Gonglei (Arei) wrote: > IDE_TIMEOUT is defined 32s. But we encountered its timeout in > some cases, and then loading disk failed in VM. In order to > reduce the probability of timeout, we want to enlarge the > IDE_TIMEOUT, such as 120s. We verified this modification worked > for us. But we are wondering if this modification may cause other > potential issues. Why set IDE_TIMEOUT to 32s? Thanks! The ATA specification specifies the maximum response time for many commands to be 30 seconds. The extra 2 seconds were thrown in for safety. -Kevin

2 1

Re: [SeaBIOS] KVM call agenda for 2013-05-28
by Peter Stuge 31 May '13

31 May '13

Kevin O'Connor wrote: > one possible way forward would be to split the current SeaBIOS rom > into two roms: "qvmloader" and "seabios". The "qvmloader" would do > the qemu specific platform init (pci init, smm init, mtrr init, bios > tables) and then load and run the regular seabios rom. qvmloader sounds a lot like coreboot. > qvmloader could be committed into the QEMU repo and maintained there. If QEMU really doesn't want anything besides quacking like a PC with BIOS or UEFI (such as quacking like a PC *without* a particular firmware) it makes perfect sense to me to put the complete firmware code into the QEMU repo and never reuse anything else. After all, that's how the proprietary firmware products are managed. Jordan Justen wrote: > Why is updating the ACPI tables in seabios viewed as such a burden? I don't know about burden but to me it just doesn't make any sense to generate ACPI in one component (SeaBIOS) based on configuration for another component (QEMU). ACPI bytes are obviously a function of QEMU configuration. QEMU configuration can be changed through a great many channels, so it makes sense to me that QEMU itself would take care of generating correct ACPI, rather than exporting it's own data structures and pushing the ACPI problem onto the firmware, especially considering the desire for multiple independent firmware implementations. There's some code for dynamic ACPI generation in coreboot already, maybe that can be reused in QEMU to save some effort.. > On the flip side, why is moving the ACPI tables to QEMU such an issue? Maybe because it is such a steaming pile that even the place where it belongs doesn't really want it.. > I think overall I prefer the tables being built in the firmware, > despite the extra thrash. That doesn't make sense to me. :\ Keep in mind: there is firmware and there is firmware.. > Some things, such as the addresses where devices are configured at > are re-programmable in QEMU, so a firmware can decide to use a > different address, and thus invalidate the address qvmloader had > set in the tables. ..there is now talk about a first-stage firmware (qvmloader) which does only hardware init, and then jumps into a second-stage firmware (SeaBIOS) which starts the operating system. I don't expect that anyone would argue for the second-stage firmware to generate ACPI tables if the first-stage firmware would be shared across different second-stage implementations. The above is by the way *exactly* the model coreboot uses since 14 years. Please make an ernest effort to *look into and try to reuse* what *is already there* .. The fear of coreboot is truly amazing. //Peter

4 3

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

31 May '13

----- 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 30, 2013 7:45:13 PM > Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one > > On Thu, May 30, 2013 at 07:49:36AM -0500, Dave Frodin wrote: > > > From: "Kevin O'Connor" <kevin(a)koconnor.net> > > > --- a/src/optionroms.c > > > +++ b/src/optionroms.c > > > @@ -178,10 +178,19 @@ deploy_romfile(struct romfile_s *file) > > > static struct rom_header * > > > lookup_hardcode(struct pci_device *pci) > > > { > > > - char fname[17]; > > > - snprintf(fname, sizeof(fname), "pci%04x,%04x.rom" > > > + struct romfile_s *file; > > > + char fname[19]; > > > + snprintf(fname, sizeof(fname), "alias%04x,%04x.rom" > > > , pci->vendor, pci->device); > > > - struct romfile_s *file = romfile_find(fname); > > > + char *alias = romfile_loadfile(fname, NULL); > > > + if (alias) { > > > + file = romfile_find(alias); > > > + free(alias); > > > + } else { > > > + snprintf(fname, sizeof(fname), "pci%04x,%04x.rom" > > > + , pci->vendor, pci->device); > > > + file = romfile_find(fname); > > > + } > > > if (file) > > > return deploy_romfile(file); > > > return NULL; > > > > > > > In your sample code above, I don't see where any pci ID translation > > (mapping) occurs. > > As an example we could have a family14 mainboard with a coreboot > > .config that generates a vga option rom with the name > > "pci1002,9802.rom". The actual mainboard could have a graphics chip > > with the id of 1002,9804 (which is 1 of 8 possible IDs). So there > > needs to be some sort of mapping function (in SeaBIOS) that maps the > > ID of 1002,9804 to 1002,9802. > > With the above patch (assuming it works) one should be able to create > a CBFS file named "alias1002,9804.rom" that contains the text > "pci1002,9802.rom". > > -Kevin I see now, that's pretty slick. The problem I see with that approach is that coreboot would need to add all of these files for a family14 mainboard. alias1002,9803.rom alias1002,9804.rom alias1002,9805.rom alias1002,9806.rom alias1002,9807.rom alias1002,9808.rom alias1002,9809.rom And all of these files for a family15 mainboard alias1002,9901.rom alias1002,9903.rom alias1002,9904.rom alias1002,9906.rom alias1002,9907.rom alias1002,9908.rom alias1002,990a.rom alias1002,9910.rom alias1002,9913.rom alias1002,9917.rom alias1002,9918.rom alias1002,9919.rom alias1002,9990.rom alias1002,9991.rom alias1002,9992.rom alias1002,9993.rom alias1002,9994.rom alias1002,99a0.rom alias1002,99a2.rom alias1002,99a4.rom Since at build time we only know what cpu family the rom is being built for and not (necessarily) what the exact graphics ID is. The method I proposed would have one family specific "vendev-map.bin" file. Someone who's building a rom for a mainboard with a single known graphics ID wouldn't need to add any files with either method. Thanks, Dave

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS June 2013