Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Dave Frodin]

----- Original Message -----
> From: "Kevin O'Connor" 
> To: "Dave Frodin" 
> Cc: "seabios" 
> 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" 
> > > --- 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

[PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Kevin O'Connor]

On Fri, May 31, 2013 at 08:32:16AM -0500, Dave Frodin wrote:
> 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.

[...]
> And all of these files for a family15 mainboard

[...]
> 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.

Yes, but it would be quite difficult to inspect vendev-map.bin.  I
think an ascii interface is preferable.

One could go a level up and make a "symbolic link" type in cbfs (this
is effectively what my patch did).  The advantage would be that
cbfstool could display it in a nicer format.

-Kevin