From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 19:41:46 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 192DA16A41F; Mon, 21 Nov 2005 19:41:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A13EE43D78; Mon, 21 Nov 2005 19:41:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALJdnaA045219; Mon, 21 Nov 2005 12:39:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 12:39:48 -0700 (MST) Message-Id: <20051121.123948.39201087.imp@bsdimp.com> To: deischen@freebsd.org From: Warner Losh In-Reply-To: References: <20051121.113052.71133065.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 12:39:49 -0700 (MST) Cc: arch@freebsd.org, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 19:41:46 -0000 > Not taking one side or the other... Can we use a common > tool to convert firmware to a kld? Just pass it the > symbol name or whatever else you need? The answer is 'it depends'... > I guess this makes the assumption that most firmware consists > of just one object file. The object files vary somewhat as to what is in the file. Some are S records in text format, while otherrs are COFF or some other format in binary form. I had assumed that each driver would want to parse things out into a useful form in the conversion program to keep the kernel portion as small as possible. This is inharently driver dependent. However, if we wanted to have a raw bits into the kernel conduit, then we could have a tool, so long as it handled an arbitrary number of files. Many drivers have a 'primary' and a 'secondary' firmware to load. But presenting an array to the driver, or having the driver load multiple files is a way around this. Having the kernel loader be able to load arbitrary files would be even better... Warner