cvs commit: src/sys/dev/cxgb bin2h.pl cxgb_main.c cxgb_t3fw.c cxgb_t3fw.h t3fw-5.0.0.bin.gz.uu src/sys/modules/cxgb Makefile src/sys/modules/cxgb/cxgb Makefile src/sys/modules/cxgb/cxgb_t3fw Makefile src/sys/conf NOTES files

[Andrew Gallatin]

Sam Leffler writes:
 > Andrew Gallatin wrote:
 > > Sam Leffler [sam at errno.com] wrote:
 > >   
 > >> Huh?  What does "static linking" mean?  If you're looking for an example 
 > >> of a firmware image being embedded in a kernel look at the npe firmware 
 > >> used by xscale.
 > >>     
 > >
 > > Kip,
 > >
 > > Before spending time on this, be warned that I tried this for mxge
 > > last year, and I gave up because it was such a headache.  The final
 > > straw was that building the firmware into a .fwo file via a files file
 > > rule doesn't work on platforms like ia64 due some toolchain problems.
 > > Specifically, there was no way to get the constant-gp flag set on an
 > > ld -b binary image, which caused the final kernel link command to
 > > explode. 
 > >
 > > Rather than use the .fwo method, I committed some .c shims (see
 > > dev/mxge/mxge_eth_z8e.c) which just #include my firmware header files.
 > > This avoids the linking problems, and turns out to be much, much
 > > easier to work with than the fw_stub files file method.
 > >   
 > 
 > My recollection from working with you on this was that the issue was 
 > ia64, not that it was hard.  Given working examples to cut&paste I find 
 > this argument weak.  As to ia64, if it doesn't support our build 
 > mechanisms then it should not be part of make universe.

ia64 was the only example I knew of, but nobody seemed interested/able
to fix it at the time.   I don't think it deserves demotion for this
issue. 

 > When Kip and I talked about why he did stuff w/o using fw_stub.awk it 
 > turned out he wasn't aware of existing examples.  This technique is 
 > documented in firmware(9) and has worked fine for me (but of course I 
 > came up with it).

I was just trying to prevent Kip from butting up against the same
issue that I had with firmware(9), and pointing him at what I
think is the only example of a driver which can compile in firmware
and survive a make universe.

For what its worth, I actually prefer my small shim files to the files
file rules for the .fwo objects and I would resist going to the files
file rules for mxge even if the ia64 issue is fixed.  With the shim
files, it is quite easy to understand what is going on.  To my
admittedly uneducated eyes, the files file magic looks almost like
line noise.

 > The bottom line however is that I don't particularly care how firmware 
 > images get built so long as drivers use firmware(9) to load them.  I've 
 > dealt with firmware loading on a variety of non-freebsd systems and 
 > always miss it.

I agree.  It is much nicer than the alternatives on other systems.

Drew