[ipxe-devel] One ROM, multiple PCI IDs

[Joshua Oreman]

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