SeaBIOS May 2013

seabios@seabios.org

29 participants
56 discussions

[SeaBIOS PATCH] boot: fix fw_dev_path pattern for q35-pcihost
by Amos Kong 02 Jun '13

02 Jun '13

Bootindex string passed from qemu: /q35-pcihost@i0cf8/ethernet@2/ethernet-phy@0 We match pci domain by "/pci@i0cf8" in SeaBIOS, but fw_dev_path prefix of q35 is "/q35-pcihost@i0cf8". So bootindex in qemu commandline doesn't work if it uses q35 machine type. This patch fixes the pattern to match both original pc-i440fx & q35 Signed-off-by: Amos Kong <akong(a)redhat.com> --- src/boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/boot.c b/src/boot.c index cd9d784..f30d47e 100644 --- a/src/boot.c +++ b/src/boot.c @@ -97,7 +97,7 @@ find_prio(const char *glob) return -1; } -#define FW_PCI_DOMAIN "/pci@i0cf8" +#define FW_PCI_DOMAIN "/*pci*@i0cf8" static char * build_pci_path(char *buf, int max, const char *devname, struct pci_device *pci) -- 1.8.1.4

5 7

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

01 Jun '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 01 Jun '13

01 Jun '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

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
by Laszlo Ersek 01 Jun '13

01 Jun '13

On 05/30/13 18:20, Jordan Justen wrote: > I think ACPI table generation lives in firmware on real products, > because on real products the firmware is the point that best > understands the actual hardware layout for the machine. In qemu, I > would say that qemu best knows the hardware layout, given that the > firmware is generally a slightly separate project from qemu. > > I don't think adding a coreboot layer into the picture helps, if it > brings along the coreboot payload boot interface as a requirement. > > Then again, I don't really understand how firmware could be swapped > out in this case. What would -bios do? How would the coreboot ACPI > shim layer be specified to qemu? I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project. I guess. Laszlo

4 4

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

31 May '13

Jordan Justen <jljusten(a)gmail.com> writes: > On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori <anthony(a)codemonkey.ws> wrote: >> As I think more about it, I think forking edk2 is inevitable. We need a >> clean repo that doesn't include the proprietary binaries. I doubt >> upstream edk2 is willing to remove the binaries. > > No, probably not unless a BSD licensed alternative was available. :) > > But, in thinking about what might make sense for EDK II with git, one > option that should be considered is breaking the top-level 'packages' > into separate sub-modules. I had gone so far as to start pushing repos > as sub-modules. > > But, as the effort to convert EDK II to git has stalled (actually > never even thought about leaving the ground), I abandoned that > approach and went back to just mirroring one EDK II. > > I could fairly easily re-enable mirror the sub-set of packages needed > for OVMF. So, in that case, the FatBinPkg sub-module could easily be > dropped from a tree. > >> But this can be quite simple using a combination of git-svn and a >> rewriting script. We did exactly this to pull out the VGABios from >> Bochs and remove the binaries associated with it. It's 100% automated >> and can be kept in sync via a script on qemu.org. > > I would love to mirror the BaseTools as a sub-package without all the > silly windows binaries... What script did you guys use? We did this in git pre-history, now git has a fancy git-filter-branch command that makes it a breeze: http://git-scm.com/book/ch6-4.html Regards, Anthony Liguori > > -Jordan

1 0

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
by David Woodhouse 31 May '13

31 May '13

On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote: > On Thu, May 30, 2013 at 5:19 AM, David Woodhouse <dwmw2(a)infradead.org> > wrote: > > On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote: > >> Where is CorebootPkg available from? > > > > https://github.com/pgeorgi/edk2/tree/coreboot-pkg > > Is the license on this actually BSD as the License.txt indicates? > > Is this planned to be upstreamed? > > Does this support UEFI variables? > > Does this support UEFI IA32 / X64? Those are questions for Patrick. -- dwmw2

2 1

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: Saturday, May 25, 2013 10:47:42 AM > Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one > > On Fri, May 24, 2013 at 09:06:54AM -0500, Dave Frodin wrote: > > 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. > > Why not just place the rom in "vgaroms/" directory where it will > always be run? That is an option but I was hoping to reduce the number of configuration differences between having coreboot vs seabios load/run the vga option rom. Currently, coreboot has vendor/device ID mapping functions for the family14, family15tn northbridges. > Also, I think we could avoid the binary structure in CBFS. Something > like the below (totally untested). > > -Kevin > > > --- 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. Thanks again, Dave

2 1

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

30 May '13

On Thu, May 30, 2013 at 09:57:10AM -0700, Jordan Justen wrote: > On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek <lersek(a)redhat.com> wrote: > > On 05/30/13 18:20, Jordan Justen wrote: > >> I think ACPI table generation lives in firmware on real products, > >> because on real products the firmware is the point that best > >> understands the actual hardware layout for the machine. In qemu, I > >> would say that qemu best knows the hardware layout, given that the > >> firmware is generally a slightly separate project from qemu. > >> > >> I don't think adding a coreboot layer into the picture helps, if it > >> brings along the coreboot payload boot interface as a requirement. > >> > >> Then again, I don't really understand how firmware could be swapped > >> out in this case. What would -bios do? How would the coreboot ACPI > >> shim layer be specified to qemu? > > > > I guess -bios would load coreboot. Coreboot would siphon the data > > necessary for ACPI table building through the current (same) fw_cfg > > bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or > > something else -- not sure how to configure that), and pass down the > > tables to the firmware (through a now unspecified interface -- perhaps > > the tables could even be installed at this point). This could introduce > > another interface (fw_cfg+something rather than just fw_cfg), but ACPI > > table preparation would be concentrated in one project. > > > > I guess. > > For reference, I believe that both Xen and virtualbox build ACPI table > in the VMM rather than firmware. They both dump the tables into the > 0xe000 segment (yuck) where firmware finds and publishes it to the OS. > I think fw-cfg would be a reasonable alternative to this for > communicating the tables. > > -Jordan Want to review/ack the patches I sent? That's exactly what they do. -- MST

1 0

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

30 May '13

On Thu, May 30, 2013 at 09:20:42AM -0700, Jordan Justen wrote: > On Thu, May 30, 2013 at 5:19 AM, David Woodhouse <dwmw2(a)infradead.org> wrote: > > On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote: > >> Where is CorebootPkg available from? > > > > https://github.com/pgeorgi/edk2/tree/coreboot-pkg > > Is the license on this actually BSD as the License.txt indicates? > > Is this planned to be upstreamed? > > Does this support UEFI variables? > > Does this support UEFI IA32 / X64? > > >> > And it helps to dispel the stupid misconception in some quarters that > >> > Coreboot *competes* with UEFI and thus cannot possibly be supported > >> > because helping something that competes with UEFI would be bad. > > Coreboot and EDK II both provide a good infrastructure for > initializing hardware. So, they compete on that point. > > Coreboot then focuses on booting coreboot payloads, while EDK II > focuses on UEFI support. On that point they don't compete, but the > focus is different. > > Of course, you can build a layer of EDK II => Coreboot payload > support, or Coreboot => EDK II (CorebootPkg, I guess?), but the match > will not be perfect. (That is not to say it can't work.) > > >> I'm not sure who do you mean by "some quarters", but for some > >> distributions Coreboot would be yet another component (package) to > >> support, for no obvious benefit. > >> > >> (Gerd said it better than I possibly could: > >> <http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705>.) > > > > Yeah, but if we're shoving a lot of hardware-specific ACPI table > > generation into the guest's firmware, instead of just doing it on the > > qemu side where a number of us seem to think it belongs, then there *is* > > a benefit to using Coreboot. When stuff changes on the qemu side and we > > have to update the table generation to match, you end up having to > > update just the Coreboot package, and *not* having to patch both SeaBIOS > > and OVMF. > > I think ACPI table generation lives in firmware on real products, > because on real products the firmware is the point that best > understands the actual hardware layout for the machine. In qemu, I > would say that qemu best knows the hardware layout, given that the > firmware is generally a slightly separate project from qemu. Of course ACPI tables are firmware. Please note that what my patches do is simply supply templates for ACPI tables on a ROM device separate from where bios code resides. bios still tweaks them in minor ways. I am guessing this is what happens on real hardware too: most tables pre-generated in ROM, firmware shadows them and tweaks them in minor ways. > I don't think adding a coreboot layer into the picture helps, if it > brings along the coreboot payload boot interface as a requirement. > > Then again, I don't really understand how firmware could be swapped > out in this case. What would -bios do? How would the coreboot ACPI > shim layer be specified to qemu? > > -Jordan

1 0

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
by Laszlo Ersek 30 May '13

30 May '13

On 05/30/13 18:57, Jordan Justen wrote: > On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek <lersek(a)redhat.com> wrote: >> On 05/30/13 18:20, Jordan Justen wrote: >>> I think ACPI table generation lives in firmware on real products, >>> because on real products the firmware is the point that best >>> understands the actual hardware layout for the machine. In qemu, I >>> would say that qemu best knows the hardware layout, given that the >>> firmware is generally a slightly separate project from qemu. >>> >>> I don't think adding a coreboot layer into the picture helps, if it >>> brings along the coreboot payload boot interface as a requirement. >>> >>> Then again, I don't really understand how firmware could be swapped >>> out in this case. What would -bios do? How would the coreboot ACPI >>> shim layer be specified to qemu? >> >> I guess -bios would load coreboot. Coreboot would siphon the data >> necessary for ACPI table building through the current (same) fw_cfg >> bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or >> something else -- not sure how to configure that), and pass down the >> tables to the firmware (through a now unspecified interface -- perhaps >> the tables could even be installed at this point). This could introduce >> another interface (fw_cfg+something rather than just fw_cfg), but ACPI >> table preparation would be concentrated in one project. >> >> I guess. > > For reference, I believe that both Xen and virtualbox build ACPI table > in the VMM rather than firmware. They both dump the tables into the > 0xe000 segment (yuck) where firmware finds and publishes it to the OS. > I think fw-cfg would be a reasonable alternative to this for > communicating the tables. I think Xen uses a separate utility called "hvmloader" that runs in the domU. - http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5453/focus=5668 - http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=tools/firmware/hvmloader - http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/6255/focus=110562 Laszlo

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS May 2013