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

[Sam Leffler]

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.

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).

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.

    Sam