----- Original Message -----
From: "Kevin O'Connor" kevin@koconnor.net To: "Dave Frodin" dave.frodin@se-eng.com Cc: "seabios" seabios@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@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
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