From owner-cvs-all@FreeBSD.ORG Wed Feb 27 16:43:22 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87293106566B; Wed, 27 Feb 2008 16:43:22 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 71A2F8FC1A; Wed, 27 Feb 2008 16:43:22 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id m1RGfvSl025997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 11:41:57 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id m1RGfSCo048361; Wed, 27 Feb 2008 11:41:28 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18373.37583.482055.929142@grasshopper.cs.duke.edu> Date: Wed, 27 Feb 2008 11:41:28 -0500 (EST) To: Sam Leffler In-Reply-To: <47C5894F.10301@errno.com> References: <200802260302.m1Q32KOT081487@repoman.freebsd.org> <200802261133.00942.jhb@freebsd.org> <47C4A083.2050602@errno.com> <20080227090113.A48182@grasshopper.cs.duke.edu> <47C5894F.10301@errno.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: src-committers@FreeBSD.org, Andrew Gallatin , John Baldwin , Kip Macy , cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 16:43:22 -0000 Sam Leffler writes: > Andrew Gallatin wrote: > > Sam Leffler [sam@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