Kevin, I've attached a patch that I hope is more along the lines of where you wanted me to go with this change. In my testing of the patch I'm currently just stuffing the vendev-map.bin file into my coreboot image. Thanks, Dave
----- Original Message ----- > From: "Kevin O'Connor" <[email protected]> > To: "Dave Frodin" <[email protected]> > Cc: "seabios" <[email protected]> > Sent: Wednesday, May 22, 2013 6:45:34 AM > Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option > ROMs to one > > On Tue, May 21, 2013 at 02:47:18PM -0500, Dave Frodin wrote: > > All, > > This is a patch that reproduces the vendor ID mapping that is done in > > coreboot in the various AMD northbridge's. The coreboot mapping is only > > useful if coreboot is used to run the vga bios. If seabios is the payload > > then most coreboot configs leave the vga bios init for it. > > Thanks. See my comments below. > > [...] > > --- a/src/optionroms.c > > +++ b/src/optionroms.c > > @@ -154,7 +154,6 @@ getRomPriority(u64 *sources, struct rom_header *rom, > > int instance) > > return bootprio_find_named_rom(file->name, instance); > > } > > Looks like whitespace got corrupted in your email. > > [...] > > +static u32 > > +map_oprom_vendev(u32 vendev) > > +{ > > + u32 new_vendev = vendev; > > + > > + switch (vendev) { > > + case 0x10029803: // Family14 > > + case 0x10029804: > > If we're going to have a mapping, I think it has to be read from > CBFS. I don't think we should hardcode a list into seabios. > > [...] > > static struct rom_header * > > lookup_hardcode(struct pci_device *pci) > > { > > char fname[17]; > > + u32 vendev_mapped; > > + > > + vendev_mapped = map_oprom_vendev((pci->vendor << 16) | pci->device); > > + pci->vendor = vendev_mapped >> 16; > > + pci->device = vendev_mapped & 0xFFFF; > > Modifying struct pci_device doesn't look right. > > -Kevin >
From 7538a044131c12eda885614ad8a0b1fcdd9b9364 Mon Sep 17 00:00:00 2001 From: Dave Frodin <[email protected]> Date: Thu, 23 May 2013 16:07:17 -0600 Subject: [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one This feature was added to allow mapping multiple different PCI graphics vendor/device IDs to a single ID. The intent is to have the coreboot mainboard define its VGA_BIOS_ID as the ID that is present in the actual VGA BIOS. The PCI ID of the graphics device would then be mapped to that ID. Signed-off-by: Dave Frodin <[email protected]> --- src/optionroms.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/src/optionroms.c b/src/optionroms.c index ac92613..6361217 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -177,11 +177,44 @@ deploy_romfile(struct romfile_s *file) return rom; } +/* Allow mapping of multiple different PCI IDs to a single ID. A single AMD + * VGA BIOS will quite often be used on hardware that reports different + * PCI graphics IDs. This allows a mainboard to have a single definition + * (which would match the ID in the VGA BIOS) yet would support multiple + * CPU IDs. + * Example vendev-map.bin format (shown as text) of two AMD (1002) vgabios + * getting mapped from 9803/9804 to 9802 + * From To + * 10029803 10029802 + * 10029804 10029802 + */ +static void +map_oprom_vendev(struct pci_device *pci) +{ + int filesize, i; + + u32 *filedata = romfile_loadfile("vendev-map.bin", &filesize); + if (!filedata) + return; + + for (i=0; i < filesize/(sizeof (u32)); i+=2) { + if ( filedata[i] == ((pci->vendor << 16) | pci->device)) { + dprintf(1, "Mapping PCI device 0x%8x to 0x%8x\n", + ((pci->vendor << 16) | pci->device), filedata[i+1]); + pci->vendor = filedata[i+1] >> 16; + pci->device = filedata[i+1] & 0xFFFF; + return; + } + } + return; +} + // Check if an option rom is at a hardcoded location or in CBFS. static struct rom_header * lookup_hardcode(struct pci_device *pci) { char fname[17]; + map_oprom_vendev(pci); snprintf(fname, sizeof(fname), "pci%04x,%04x.rom" , pci->vendor, pci->device); struct romfile_s *file = romfile_find(fname); -- 1.7.9.5
_______________________________________________ SeaBIOS mailing list [email protected] http://www.seabios.org/mailman/listinfo/seabios
