Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
Kevin,
I talked with Marc Jones about this and he sees value in the method I've
proposed.
He also predicts that this will be an issue in the future on Intel motherboards.
The one major difference is that if you were building coreboot for a Family15
mainboard
you would only need to add one file (vendev_map) rather than 20 alias mapping
files to
CBFS. I agree that the parsing code is more than clunky (what I wouldn't give
for a sscanf()),
perhaps my patch could use some changes rather than throwing it out.
I'll re-attach my patch in case anybody wants to review it.
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: Tuesday, July 2, 2013 10:29:39 PM
Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option
ROMs to one
On Tue, Jul 02, 2013 at 07:40:17AM -0500, Dave Frodin wrote:
Kevin,
Did you ever get a chance to look over this patch?
I don't see the gain in introducing a config file parser for this
task. What was wrong with the approach of creating alias files?
-Kevin
From 907686ae6a41a0cb75d0ff2a565586b6f4e25615 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 | 87 +++-
1 file changed, 86 insertions(+), 1 deletion(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index ac92613..3b86244 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -177,13 +177,98 @@ deploy_romfile(struct romfile_s *file)
return rom;
}
+/* Read up to 8 ascii chars plus one non-convertible character from a
+ * string and convert to binary.
+ */
+static u32
+text_to_binary( char **ptr )
+{
+u32 data = 0;
+u8 loop = 0;
+if (*ptr == NULL)
+return data;
+for ( ; ; (*ptr)++ ) {
+if ((**ptr = '0') ( **ptr = '9'))
+data = (data * 0x10) + (**ptr - '0');
+else if ((**ptr = 'a') (**ptr = 'f'))
+data = (data * 0x10) + (**ptr - 'a' + 0x0A);
+else if ((**ptr = 'A') (**ptr = 'F'))
+data = (data * 0x10) + (**ptr - 'A' + 0x0A);
+else
+break;
+if (++loop = 9)
+break;
+}
+(*ptr)++; /* point to the char after the non-convertible char */
+return data;
+}
+
+/* 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 format for AMD Family14 (ID=1002) vgabios.
+ *10029803-10029802
+ *10029804-10029802
+ *10029805-10029802
+ *10029806-10029802
+ *10029807-10029802
+ *10029808-10029802
+ *10029809-10029802
+ */
+#define MAP_FILE_STATUS_UNINITED 0
+#define MAP_FILE_STATUS_GOOD 1
+#define MAP_FILE_STATUS_NOEXIST 2
+#define MAP_FILE_STATUS_USED 3
+#define MAPPER_BYTES_PER_LINE18 /* U32 src, '-', U32 dst, 0x0A */
+
+static u32
+map_oprom_vendev(u32 vendev)
+{
+static char *filedata = NULL;
+static int filesize = 0, map_status = MAP_FILE_STATUS_UNINITED;
+u32 vendev_src = 0, vendev_dst = 0;
+char *tmp_ptr;
+int i;
+
+if ((map_status == MAP_FILE_STATUS_NOEXIST) ||
+(map_status == MAP_FILE_STATUS_USED))
+return vendev;
+
+if (map_status == MAP_FILE_STATUS_UNINITED) {
+filedata = romfile_loadfile(vendev-map, filesize);
+if (!filedata) {
+map_status = MAP_FILE_STATUS_NOEXIST;
+return vendev;
+}
+else
+map_status = MAP_FILE_STATUS_GOOD;
+}
+
+tmp_ptr = filedata;
+for (i=0; i filesize/MAPPER_BYTES_PER_LINE; i++) {
+vendev_src = text_to_binary( tmp_ptr );
+vendev_dst = text_to_binary( tmp_ptr );
+dprintf(5, map %d: src=%x dst=%x\n, i, vendev_src, vendev_dst);
+if ( vendev_src == vendev) {
+dprintf(1, Mapping PCI device %8x to %8x\n,vendev, vendev_dst);
+map_status = MAP_FILE_STATUS_USED;
+free(filedata);
+return vendev_dst;
+}
+}
+return vendev
Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
Kevin, Did you ever get a chance to look over this patch? Thanks, Dave - Original Message - From: Dave Frodin dave.fro...@se-eng.com To: Kevin O'Connor ke...@koconnor.net Cc: seabios seabios@seabios.org Sent: Wednesday, June 5, 2013 8:45:11 AM Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one Kevin, Attached is the new option rom mapping patch. I was hunting around for an existing SeaBIOS ftn that would convert ascii strings to a binary value (i.e. sscanf) but couldn't find one. If there's already one in the code I can replace the text_to_binary() with it. I tested this on a AMD family14 platform. The vendev-map file I added to CBFS looks like this... 10029803-10029802 10029804-10029802 10029805-10029802 10029806-10029802 10029807-10029802 10029808-10029802 10029809-10029802 Each line ends with a NEWLINE character (0x0A). On my test platform the actual graphics ID of the part is 10029804. The vgabios gets added to CBFS with the name pci1002,9802.rom. Thanks, Dave ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
On Tue, Jul 02, 2013 at 07:40:17AM -0500, Dave Frodin wrote: Kevin, Did you ever get a chance to look over this patch? I don't see the gain in introducing a config file parser for this task. What was wrong with the approach of creating alias files? -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
Kevin,
Attached is the new option rom mapping patch.
I was hunting around for an existing SeaBIOS ftn that would convert
ascii strings to a binary value (i.e. sscanf) but couldn't find one.
If there's already one in the code I can replace the text_to_binary()
with it.
I tested this on a AMD family14 platform. The vendev-map file I added
to CBFS looks like this...
10029803-10029802
10029804-10029802
10029805-10029802
10029806-10029802
10029807-10029802
10029808-10029802
10029809-10029802
Each line ends with a NEWLINE character (0x0A).
On my test platform the actual graphics ID of the part is 10029804.
The vgabios gets added to CBFS with the name pci1002,9802.rom.
Thanks,
DaveFrom 907686ae6a41a0cb75d0ff2a565586b6f4e25615 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 | 87 +++-
1 file changed, 86 insertions(+), 1 deletion(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index ac92613..3b86244 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -177,13 +177,98 @@ deploy_romfile(struct romfile_s *file)
return rom;
}
+/* Read up to 8 ascii chars plus one non-convertible character from a
+ * string and convert to binary.
+ */
+static u32
+text_to_binary( char **ptr )
+{
+u32 data = 0;
+u8 loop = 0;
+if (*ptr == NULL)
+return data;
+for ( ; ; (*ptr)++ ) {
+if ((**ptr = '0') ( **ptr = '9'))
+data = (data * 0x10) + (**ptr - '0');
+else if ((**ptr = 'a') (**ptr = 'f'))
+data = (data * 0x10) + (**ptr - 'a' + 0x0A);
+else if ((**ptr = 'A') (**ptr = 'F'))
+data = (data * 0x10) + (**ptr - 'A' + 0x0A);
+else
+break;
+if (++loop = 9)
+break;
+}
+(*ptr)++; /* point to the char after the non-convertible char */
+return data;
+}
+
+/* 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 format for AMD Family14 (ID=1002) vgabios.
+ *10029803-10029802
+ *10029804-10029802
+ *10029805-10029802
+ *10029806-10029802
+ *10029807-10029802
+ *10029808-10029802
+ *10029809-10029802
+ */
+#define MAP_FILE_STATUS_UNINITED 0
+#define MAP_FILE_STATUS_GOOD 1
+#define MAP_FILE_STATUS_NOEXIST 2
+#define MAP_FILE_STATUS_USED 3
+#define MAPPER_BYTES_PER_LINE18 /* U32 src, '-', U32 dst, 0x0A */
+
+static u32
+map_oprom_vendev(u32 vendev)
+{
+static char *filedata = NULL;
+static int filesize = 0, map_status = MAP_FILE_STATUS_UNINITED;
+u32 vendev_src = 0, vendev_dst = 0;
+char *tmp_ptr;
+int i;
+
+if ((map_status == MAP_FILE_STATUS_NOEXIST) ||
+(map_status == MAP_FILE_STATUS_USED))
+return vendev;
+
+if (map_status == MAP_FILE_STATUS_UNINITED) {
+filedata = romfile_loadfile(vendev-map, filesize);
+if (!filedata) {
+map_status = MAP_FILE_STATUS_NOEXIST;
+return vendev;
+}
+else
+map_status = MAP_FILE_STATUS_GOOD;
+}
+
+tmp_ptr = filedata;
+for (i=0; i filesize/MAPPER_BYTES_PER_LINE; i++) {
+vendev_src = text_to_binary( tmp_ptr );
+vendev_dst = text_to_binary( tmp_ptr );
+dprintf(5, map %d: src=%x dst=%x\n, i, vendev_src, vendev_dst);
+if ( vendev_src == vendev) {
+dprintf(1, Mapping PCI device %8x to %8x\n,vendev, vendev_dst);
+map_status = MAP_FILE_STATUS_USED;
+free(filedata);
+return vendev_dst;
+}
+}
+return 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 0x);
struct romfile_s *file = romfile_find(fname);
if (file)
return deploy_romfile(file
Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
- Original Message - From: Kevin O'Connor ke...@koconnor.net To: Dave Frodin dave.fro...@se-eng.com Cc: seabios seabios@seabios.org Sent: Friday, May 31, 2013 9:18:21 PM Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one 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 I agree with that, and marc made the same suggestion. I'll put together a new patch next week. Dave ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
- 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 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 ke...@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
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
- Original Message -
From: Kevin O'Connor ke...@koconnor.net
To: Dave Frodin dave.fro...@se-eng.com
Cc: seabios seabios@seabios.org
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
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
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 ke...@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
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
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 0x;
Modifying struct pci_device doesn't look right.
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
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.
From 5b7f2ba9f43fbc67a81a2449d8bbd3d2f6e530aa Mon Sep 17 00:00:00 2001
From: Dave Frodin dave.fro...@se-eng.com
Date: Tue, 7 May 2013 13:51:56 -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.
Change-Id: Id06a1c9730546070146932a4dc8ab8229c4a59b9
Signed-off-by: Dave Frodin dave.fro...@se-eng.com
---
src/optionroms.c | 69 +-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index 00697b2..bf1e977 100644
--- 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);
}
-
/
* Roms in CBFS
/
@@ -174,11 +173,79 @@ 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.
+ */
+static u32
+map_oprom_vendev(u32 vendev)
+{
+ u32 new_vendev = vendev;
+
+ switch (vendev) {
+ case 0x10029803: // Family14
+ case 0x10029804:
+ case 0x10029805:
+ case 0x10029806:
+ case 0x10029807:
+ case 0x10029808:
+ case 0x10029809:
+ new_vendev = 0x10029802;
+ break;
+ case 0x10029901: // Family15tn
+ case 0x10029903:
+ case 0x10029904:
+ case 0x10029906:
+ case 0x10029907:
+ case 0x10029908:
+ case 0x1002990A:
+ case 0x10029910:
+ case 0x10029913:
+ case 0x10029917:
+ case 0x10029918:
+ case 0x10029919:
+ case 0x10029990:
+ case 0x10029991:
+ case 0x10029992:
+ case 0x10029993:
+ case 0x10029994:
+ case 0x100299A0:
+ case 0x100299A2:
+ case 0x100299A4:
+ new_vendev = 0x10029900;
+ break;
+ case 0x10029831: // Family16kb
+ case 0x10029832:
+ case 0x10029833:
+ case 0x10029834:
+ case 0x10029835:
+ case 0x10029836:
+ case 0x10029837:
+ case 0x10029839:
+ case 0x1002983D:
+ new_vendev = 0x10029830;
+ break;
+ default:
+ break;
+ }
+ if (vendev != new_vendev)
+ dprintf(1, Mapping PCI device %8x to %8x\n,vendev, new_vendev);
+ 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_mapped;
+
+ vendev_mapped = map_oprom_vendev((pci-vendor 16) | pci-device);
+ pci-vendor = vendev_mapped 16;
+ pci-device = vendev_mapped 0x;
+
snprintf(fname, sizeof(fname), pci%04x,%04x.rom
, pci-vendor, pci-device);
struct romfile_s *file = romfile_find(fname);
--
1.7.9
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
