SeaBIOS

seabios@seabios.org

5 participants
3802 discussions

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

[QEMU PATCH v2] pci: set firmware name of q35 to pci
by Amos Kong 30 May '13

30 May '13

In QEMU, we set the firmware name of pc-i440fx to 'pci', and the typename 'q35-pcihost' is set to the firmware name of q35 by default. The seabios matches pci devices by "/pci/@i0cf8", so q35 device could not be identified, seabios fails to adjust the boot priority of q35 devices. This patch sets firmware name of q35 to 'pci'. Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Amos Kong <akong(a)redhat.com> --- v2: just set the fw_name, no need to change seabios --- hw/pci-host/q35.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c index 8467f86..24df6b5 100644 --- a/hw/pci-host/q35.c +++ b/hw/pci-host/q35.c @@ -76,6 +76,7 @@ static void q35_host_class_init(ObjectClass *klass, void *data) k->init = q35_host_init; dc->props = mch_props; + dc->fw_name = "pci"; } static void q35_host_initfn(Object *obj) -- 1.8.1.4

2 2

[PATCH] pci: change typename of q35 to pci-q35
by Amos Kong 30 May '13

30 May '13

In QEMU, we set the firmware name of pc-i440fx is 'pci', and set the firmware name of q35 is 'q35-pcihost'. The seabios pattern matching code isn't sophisticated, and we want to match those two devices with exact pattern. This patch changes the typename of q35 to 'pci-q35', all pci devices use same prefix 'pci' in fireware name. And I will change pattern in seabios to "/pci*@i0cf8". Signed-off-by: Amos Kong <akong(a)redhat.com> --- include/hw/pci-host/q35.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h index e182c82..3579fb0 100644 --- a/include/hw/pci-host/q35.h +++ b/include/hw/pci-host/q35.h @@ -34,7 +34,7 @@ #include "hw/acpi/ich9.h" #include "hw/pci-host/pam.h" -#define TYPE_Q35_HOST_DEVICE "q35-pcihost" +#define TYPE_Q35_HOST_DEVICE "pci-q35" #define Q35_HOST_DEVICE(obj) \ OBJECT_CHECK(Q35PCIHost, (obj), TYPE_Q35_HOST_DEVICE) -- 1.8.1.4

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS