On Sat, Jul 31, 2010 at 3:08 AM, Stefan Hajnoczi <stefanha at gmail.com> wrote: > Josh: I have CCed you explicitly because I think you had ideas on this > some time ago. > > The question of multiple PCI IDs for a single gPXE ROM came up > recently on IRC. ?It can be useful to have a single gPXE ROM file that > works on multiple PCI devices that have different IDs. > > I reviewed the PnP, BBS, and PCI 3.0 Firmware specifications to check > whether it is possible or not. ?The constraints end up making > general-purpose multiple PCI ID ROMs infeasible. ?I think it is not > worth pursuing this unless these ROMs can be widely used.
Have we gotten a lot of requests for this feature? I'm under the impression that most cases of "I want to make a single ROM and flash it on every machine in my cluster" involve fairly homogeneous setups. > The approaches I found are: > 1. PCI 3.0 device ID list. ?The PCI 3.0 Data Structure includes a > Device List pointer allowing a ROM to advertise support for additional > *device* IDs. ?Two limitations here: only additional device IDs may be > used, not vendor IDs, and the BIOS needs to have PCI 3.0 Firmware > support. This could work well in the "fairly homogeneous" case I mentioned. We could extend the build system such that "make bin/8086.rom" would make a ROM with support for all the e1000 variants (though that particular case would also pull in e1000e and e1000igb and generally be infeasibly large). > 2. Using multiple ROM headers. ?This means providing multiple > expansion ROM headers within the ROM so the BIOS can pick an > applicable one. ?However, each header must start on a 512-byte > boundary and I don't see a reasonable way to share the compressed gPXE > image between multiple ROM headers. ?There will not be enough space to > accommodate multiple (duplicate) images, and the alternative is a more > complex loader that tries to fetch gPXE as a second stage payload from > the PCI expansion ROM (which is known to be tricky). Using the .mrom facility that Michael contributed, this would be feasible for small sets of ROMs from a size perspective. > Thoughts? I actually haven't thought about this use case that much. I think both possibilities are tractable, but like you suggest, probably not worth the effort unless someone would use them extensively. A much simpler alternative that would cover many of the same use cases would be to restore the functionality that used to be in modrom.pl of "rebranding" the ROM device:vendor IDs post-build. -- Josh