Date: Mon, 20 Mar 1995 17:38:49 -0800 From: "Justin T. Gibbs" <gibbs@estienne.CS.Berkeley.EDU> To: terry@cs.weber.edu (Terry Lambert) 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 Subject: Re: SVNET Meeting? Message-ID: <199503210138.RAA02205@estienne.cs.berkeley.edu> In-Reply-To: Your message of "Mon, 20 Mar 1995 17:04:10 MST." <9503210004.AA03603@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >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. I have no interest in disassembling the firmware (which is different on every revision of the cards they have put out) to figure out their sequencer interface and spend time trying to interface with it just so I can go fetch the real code. >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. Yes, the best solution is non-GPLd sequencer code, but the author has stopped responding to my mail so I don't know what the deal is with this issue. My last message to him was a polite note asking him to say either "never" or "yes", but to at least say something... :-( > >8-|. > > > Terry Lambert > terry@cs.weber.edu >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ==============================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503210138.RAA02205>