Please be aware that this is cross-posted to both the SeaBIOS and coreboot mailing lists. I know this is generally frowned upon, but I believe the subject is valid for discussion in both forums.
I have a coreboot/SeaBIOS image containing an option ROM that works for multiple graphics devices (seven or eight of them). These graphics devices come from the same vendor but each device has its own (unique) PCI Device ID. If I'm going to load the driver from SeaBIOS, I need to have a copy of the option ROM file, each with the name of the target PCI device (e.g. "pci1234,5678.rom"). Having seven or eight copies in the BIOS image file is a waste of space.
Stefan R. submitted a solution to coreboot to enable mapping one ROM's vendor/device ID to another and this solution has worked well for coreboot-centric uses.
Unfortunately, this does not address the problem in SeaBIOS. I have started working on a solution that extends what Stefan has done, but moves the data into a single "translate" file in CBFS. This file contains simple data to allow coreboot and/or SeaBIOS to take a PCI device's vendor/device info and retrieve alternate vendor/device values.
Since both coreboot and SeaBIOS understand CBFS, the basic translation code would be identical.
The data file consists of sets of four 16-bit binary values: u16 vendor1, device1; // translate FROM this PCI v/d u16 vendor2, device2; // translate TO this PCI v/d
If you have a single ROM which could support three devices, you would have two sets of data: 0x1234, 0x0001, 0x1234, 0x0002 0x1234, 0x0001, 0x1234, 0x0003 This data would let the ROM for vendor 0x1234, device 0x0001 support devices 0x0002 and 0x0003. NOTE: there is no data for device 0x0001, since it would be handled without translation.
The code would work something like this: sprintf(name, "pci%04x,%04x.rom", pci->vendor, pci->device); rom = cbfs_findfile(name); // load the file if (!rom) { // ROM not found... try translation ven = pci->vendor; dev = pci->device; if (translate_findFirst(&ven, &dev)) { do { sprintf(name, "pci%04x,%04x.rom", ven, dev); rom = cbfs_findfile(name); // load the file while ((rom == null) && translate_findNext(&ven, &dev)); } }
I'm not tied to the findFirst/findNext mechanism nor to the specific format of the data. What I would like to see is some mechanism in both coreboot and SeaBIOS that would allow a given ROM to be used for multiple devices.
In coreboot this would affect the map_oprom_vendev() function. In SeaBIOS this would affect both lookup_hardcode() and map_pcirom().
Since this problem exists in both codebases, is it reasonable to come up with a solution that will work in both codebases?
Thoughts? -- Steve G.
On 06/13/12 01:06, Steve Goodrich wrote:
Please be aware that this is cross-posted to both the SeaBIOS and coreboot mailing lists. I know this is generally frowned upon, but I believe the subject is valid for discussion in both forums.
I have a coreboot/SeaBIOS image containing an option ROM that works for multiple graphics devices (seven or eight of them). These graphics devices come from the same vendor but each device has its own (unique) PCI Device ID. If I'm going to load the driver from SeaBIOS, I need to have a copy of the option ROM file, each with the name of the target PCI device (e.g. "pci1234,5678.rom"). Having seven or eight copies in the BIOS image file is a waste of space.
Stefan R. submitted a solution to coreboot to enable mapping one ROM's vendor/device ID to another and this solution has worked well for coreboot-centric uses.
Unfortunately, this does not address the problem in SeaBIOS. I have started working on a solution that extends what Stefan has done, but moves the data into a single "translate" file in CBFS. This file contains simple data to allow coreboot and/or SeaBIOS to take a PCI device's vendor/device info and retrieve alternate vendor/device values.
Since both coreboot and SeaBIOS understand CBFS, the basic translation code would be identical.
The data file consists of sets of four 16-bit binary values: u16 vendor1, device1; // translate FROM this PCI v/d u16 vendor2, device2; // translate TO this PCI v/d
Another possible solution would be to add support for symbolic links to cbfs.
How do you get around the limitation of a single pci id in the rom header? Or does seabios skip the pci id verification for rom files loaded from cbfs?
cheers, Gerd
On Wed, Jun 13, 2012 at 12:50 AM, Gerd Hoffmann kraxel@redhat.com wrote:
On 06/13/12 01:06, Steve Goodrich wrote:
Please be aware that this is cross-posted to both the SeaBIOS and coreboot mailing lists. I know this is generally frowned upon, but I believe the subject is valid for discussion in both forums.
I have a coreboot/SeaBIOS image containing an option ROM that works for multiple graphics devices (seven or eight of them). These graphics devices come from the same vendor but each device has its own (unique) PCI Device ID. If I'm going to load the driver from SeaBIOS, I need to have a copy of the option ROM file, each with the name of the target PCI device (e.g. "pci1234,5678.rom"). Having seven or eight copies in the BIOS image file is a waste of space.
Stefan R. submitted a solution to coreboot to enable mapping one ROM's vendor/device ID to another and this solution has worked well for coreboot-centric uses.
Unfortunately, this does not address the problem in SeaBIOS. I have started working on a solution that extends what Stefan has done, but moves the data into a single "translate" file in CBFS. This file contains simple data to allow coreboot and/or SeaBIOS to take a PCI device's vendor/device info and retrieve alternate vendor/device values.
Since both coreboot and SeaBIOS understand CBFS, the basic translation code would be identical.
The data file consists of sets of four 16-bit binary values: u16 vendor1, device1; // translate FROM this PCI v/d u16 vendor2, device2; // translate TO this PCI v/d
Another possible solution would be to add support for symbolic links to cbfs.
How do you get around the limitation of a single pci id in the rom header? Or does seabios skip the pci id verification for rom files loaded from cbfs?
This is why I think it should not be part of cbfs, The problem is not a file handling issue. It is a function of the PCI ROM handling that has a special case for onboard ROMs. The PCI rom routine needs to understand that it is using a compatible ID and skip the ROM header checking (Seabios doesn't check but coreboot does). VGA ROMs are the most common case, but happens with ethernet and ahci/raid ROMs as well.
Marc