On Wed, 17 Apr 2002, Ken Yap wrote:
> >All now in CVS, including the multi-driver ROM stuff. All builds fine on
> >my system, if anyone hits compile errors with my code please let me know.
> Sorry Michael, I've redesigned the format of the NIC spec file so your
> diffs have not been propagated because I haven't thought up of a
> replacement syntax for your multi-driver build specs. Suggest something.
> Maybe a section like:
> multi
> name=driver1,driver2,driver3 PCI-IDs Comment
> You will find the revamped genrules.pl and NIC in CVS now.
OK, I finally got around to doing something about this.
I've taken a different approach: rather than having to list multi-driver
ROMs in the NIC file, I thought it would be more elegant if it were
possible to type, for example:
make bin32/dfe538--prism2_pci.rom
to generate a BootROM for the dfe538 card (RTL8139-based) that would
include both the RTL8139 and Prism2_PCI drivers.
I have modifed genrules.pl to produce pattern rules alongside the "normal"
rules. The upshot is that it is now possible to type
make bin32/PCI_NIC--ADDITIONAL_DRIVER.{rom,lzrom,etc.}
for any combination of PCI_NIC and ADDITIONAL_DRIVER. No multi-driver
ROMs will be built by default (i.e. "make" will produce only single-driver
ROMs).
I should probably document this somewhere - any suggestions for an
appropriate place?
For those interested: the build procedure for a multi-driver ROM is
identical to that of a single-driver ROM except that:
1) the config-*.o file must have -DINCLUDE_XXX defined for all the
required drivers, and must also have -DTRY_ALL_DEVICES defined
2) when generating the .img, .tmp or .elf file, the additional driver must
also be linked in
The current multi-driver solution is not particularly elegant in its
implementation and has three known bugs:
1) It only works with PCI Roms at the moment - I don't know enough about
the ISA build process to be confident of modifying it.
2) It only works for dual-driver Roms - there is no way of even specifying
three or more drivers. This is irritatingly inelegant but not likely
to cause practical problems; if you try to squeeze in three or more
drivers then Etherboot will die horribly through RAM starvation anyway.
It is probably possible to fix this using some of the more esoteric
features of make - patsubst, wildcard etc.
3) The Roms makefile is too long and could probably be shortened
considerably by judicious use of pattern rules.
This feature meshes nicely with the option-175 patch I put in yesterday:
the multi-driver NIC will send the currently-in-use driver as option 175
to the DHCP server and this means that the server can send back a
single-driver kernel - no need to maintain multi-driver kernels as well.
As always, if these changes break anything, please let me know.
Michael
|