On Sat, Jul 31, 2010 at 7:07 PM, Joshua Oreman <orem...@rwcr.net> wrote: > On Sat, Jul 31, 2010 at 3:08 AM, Stefan Hajnoczi <stefa...@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 question was about making one gPXE ROM that VirtualBox could use regardless of the emulated NIC type (pcnet32 or e1000). > >> 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 > _______________________________________________ gPXE-devel mailing list gPXE-devel@etherboot.org http://etherboot.org/mailman/listinfo/gpxe-devel
