From owner-freebsd-hackers Mon Mar 20 17:03:49 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA18322 for hackers-outgoing; Mon, 20 Mar 1995 17:03:49 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA18314; Mon, 20 Mar 1995 17:03:46 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03603; Mon, 20 Mar 95 17:04:11 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503210004.AA03603@cs.weber.edu> Subject: Re: SVNET Meeting? To: gibbs@estienne.CS.Berkeley.EDU (Justin T. Gibbs) Date: Mon, 20 Mar 95 17:04:10 MST Cc: peter@bonkers.taronga.com, rgrimes@gndrsh.aac.dev.com, bde@zeta.org.au, gibbs@freefall.cdrom.com, hackers@freefall.cdrom.com, jkh@freefall.cdrom.com In-Reply-To: <199503202253.OAA01706@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Mar 20, 95 02:53:56 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > >How big is this firmware? > >Can it be poked into the boot in a separate operation? > >That would mean the kernel would have to use the BIOS to read it back, > >wouldn't it? > > Oh man.... Hmmm... The firmware is < 2k. Its basically an array of > byte values that the driver dumps to the card. The current setup > is the best setup except that it contaminates the GENERIC kernel > (ie, if someone decides its okay for them to use this driver, it works > without haveing to do anything special on their part except configure > for the controller.) If you can think of a way for the driver to > read in an additional file during boot, then we can distribute the > firmware separately. Probably the easiest approach is to chain-load it into a non-auto initialized area, the load the kernel, and have the kernel dump from that area to the sequencer. Basically this would mean either getting the V86 code working well enough to run a disk driver using IPC to the V86, or chain-loading in real mode. In other words, have the BIOS based boot blocks load a BIOS based loader in real mode instead of the kernel and put the protected mode switch in the kernel itself. Alternately, it may be possible to load a file "preinit" or whatever into < 640k and have the kernel use this as an IPC area between it and the boot blocks. Most of these soloutions are Bad(tm) because they mean more code in the boot blocks. Alternately, the BIOS is able to load the kernel in order to boot; this means that there is default sequencer code on the card, even if it is very ugly. Write a piddly driver to use that code to load the new code into the kernel once the root file system is up, then switch over to the driver that wants new code. For the purposes of binary distribution, it ought to be easier to either get the sequencer code un-GPL'ed, rewrite it, or someone sign a non-disclosure with Adaptec and write a binary driver distributed soley as .o files. 8-|. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.