From owner-freebsd-questions Fri Apr 5 15:52:56 2002 Delivered-To: freebsd-questions@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 09F3B37B41E; Fri, 5 Apr 2002 15:52:50 -0800 (PST) Received: from pool0399.cvx21-bradley.dialup.earthlink.net ([209.179.193.144] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16tdVg-0003hD-00; Fri, 05 Apr 2002 15:52:49 -0800 Message-ID: <3CAE38B8.B161CAD2@mindspring.com> Date: Fri, 05 Apr 2002 15:52:24 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: "Kreider, Carl" , freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: read a file from a driver References: <200204051848.g35ImZS05537@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > For drivers which must be active in the boot path, it is > > generally necessary to embed the firmware in the driver as > > data. This is what FreeBSD does for the Adaptec SCSI > > drivers. > > > > For drivers that need to be active after boot time, but before > > the mi_startup() is complete, you can load the data in a module > > that contains the data. THis is similar to compiling the data > > into the kernel, but puts it at a minor level of abstraction. > > These two are the same case. See eg. the isp_fw module. I made the distinction because I could make up a situation where they were different, or where you could replace low performance firmware with higher performance firmware. The Adaptec firmware that comes from the POST is good enough to load enough of the OS for the OS driver to take over, and the OS driver replaces the firmware. You could also consider the case where the firmware module was loaded, the firmware shoved down to the card by the driver, and then the module containing it was unloaded (recovering the data space). This is a tiny amount of space for modern systems, but it's a possibility. You could also think about booting with one set of Tigon II firmware, replacing it, and then resetting the driver, which would result in the replacement firmware being shoved down. There's also the possibility of updating the firmware for a driver using a module that's loaded at boot time, but having firmware compiled into it. These are all really border cases, and the distinction is really slight, though... just trying to dot the I's and cross the T's. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message