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 again,
Dave
----- Original Message -----
> From: "Kevin O'Connor" <ke...@koconnor.net>
> To: "Dave Frodin" <dave.fro...@se-eng.com>
> Cc: "seabios" <seabios@seabios.org>
> Sent: Thursday, May 23, 2013 9:01:00 PM
> Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option
> ROMs to one
>
> On Thu, May 23, 2013 at 05:25:42PM -0500, Dave Frodin wrote:
> > 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.
>
> [...]
> > + 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;
>
> I don't understand why struct pci_device is being modified. Maybe you
> could further explain the use case. After modifying struct
> pci_device, where does the video rom actually come from?
>
> -Kevin
>
From f54a6a23e12cb8f76c46248d8effe7b07abfdaf3 Mon Sep 17 00:00:00 2001
From: Dave Frodin <dave.fro...@se-eng.com>
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
vendor/device IDs to a single ID. It allows a coreboot/seabios ROM
image to be used on a mainboard whose graphics ID will vary depending
on which cpu is installed. 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 all possible graphics IDs would then be mapped to that ID.
It may have use for other PCI devices where a single option ROM can be
used with PCI devices with varying IDs.
Signed-off-by: Dave Frodin <dave.fro...@se-eng.com>
---
src/optionroms.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index ac92613..4f37560 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -177,13 +177,59 @@ 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 option ROM) yet would support multiple
+ * CPU IDs.
+ * Example vendev-map.bin format (shown as text) of two AMD (ID=1002) vgabios
+ * getting mapped from 9803/9804 to 9802
+ * From To
+ * 10029803 10029802
+ * 10029804 10029802
+ */
+#define MAP_FILE_STATUS_UNINITED 0
+#define MAP_FILE_STATUS_GOOD 1
+#define MAP_FILE_STATUS_BAD 2
+
+static u32
+map_oprom_vendev(u32 vendev)
+{
+ static u32 *filedata = NULL;
+ static int filesize = 0, map_status = MAP_FILE_STATUS_UNINITED;
+ u32 new_vendev = vendev;
+ int i;
+
+ // On first call see if the file exists and cache it
+ if (map_status == MAP_FILE_STATUS_UNINITED) {
+ filedata = romfile_loadfile("vendev-map.bin", &filesize);
+ if (!filedata)
+ map_status = MAP_FILE_STATUS_BAD;
+ else
+ map_status = MAP_FILE_STATUS_GOOD;
+ }
+
+ if (map_status != MAP_FILE_STATUS_GOOD)
+ return vendev;
+
+ for (i=0; i < filesize/(sizeof (u32)); i+=2) {
+ if ( filedata[i] == vendev) {
+ dprintf(1, "Mapping PCI device 0x%8x to 0x%8x\n",vendev, filedata[i+1]);
+ new_vendev = filedata[i+1];
+ break;
+ }
+ }
+ return new_vendev;
+}
+
// 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];
+ u32 vendev = map_oprom_vendev((pci->vendor << 16) | pci->device);
snprintf(fname, sizeof(fname), "pci%04x,%04x.rom"
- , pci->vendor, pci->device);
+ , vendev >> 16, vendev & 0xFFFF);
struct romfile_s *file = romfile_find(fname);
if (file)
return deploy_romfile(file);
--
1.7.9.5
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
