----- Original Message -----
> From: "Kevin O'Connor" <[email protected]>
> To: "Dave Frodin" <[email protected]>
> Cc: "seabios" <[email protected]>
> 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
_______________________________________________
SeaBIOS mailing list
[email protected]
http://www.seabios.org/mailman/listinfo/seabios
