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
Makefile src/sys/modules/cxgb/cxgb_t3fw Makefile src/sys/conf NOTES files
sam at errno.com
Wed Feb 27 16:01:24 UTC 2008
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.
> 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
> 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.
More information about the cvs-src