Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!cs.utexas.edu!sun-barr!olivea!uunet!mcsun!sun4nl!eur.nl!pk From: pk@cs.few.eur.nl (Paul Kranenburg) Newsgroups: comp.os.386bsd.development Subject: Re: Boot ROM standardization urged Message-ID: <1993Mar24.091422.4284@cs.few.eur.nl> Date: 24 Mar 93 09:14:22 GMT References: <f0Vqgtl@quack.kfu.com> Sender: news@cs.few.eur.nl Reply-To: pk@cs.few.eur.nl Organization: Erasmus University Rotterdam Lines: 50 In <f0Vqgtl@quack.kfu.com> mrapple@quack.kfu.com (Nick Sayer) writes: >From reading this group I get the idea that at least one person is >developing boot ROMs for 386BSD. Before we come up with a system >specific one, wouldn't it be a good idea to come up with a standard one? >One that would RARP, then use TFTP to load a file at a standard address, >then provide standardized service routines for that TFTP file to >use as it sees fit? What I'm suggesting is a setup where the ROMs are >card specific (as they must be), and the TFTP file is OS specific (as it >must be), but the two can be fit together in a standard way. If we >adopt such a standard, I suggest that it won't be long before the OS >vendors join us. Won't it be nice being able to switch OSs without >switching boot ROMs? We are working on ROM code that is intended to be able to boot different OS's as well as to provide a mechanism for passing parameters to the loaded program (in case a BSD kernel is loaded, this would allow to boot in single- user or in ask- mode). Currently, this implemented as an (at least) three stage process: 1) The Boot PROM code (which is constrained to fit in a 16K EPROM) uses BOOTP and TFTP to load a monitor program. 2) The monitor program allows you to specify a particular boot method to be invoked (say "boot net <server> <file>" or "boot disk <partition>"). We are thinking about stuffing any parameters at some "well known" location in memory (which third stage boot programs will have to know about). The monitor also provides for some sort of authentication by querying a home-made server. The outcome of this determines what boot program can loaded next. 3) Whatever is loaded by the monitor program is executed. This can be a disk bootblock loaded from a local disk or floppy or a boot file loaded by TFTP. In the latter case, you would be able to load BSD boot program that knows, for example, how to setup a kernel for diskless operation. As of this moment, the PROM code is mostly written in C and is a mix of several code fragments which have been floating around the net: the hardware driver is a heavily hacked version of the Crnwr packet driver (only WD800x support at the moment), the IP/UDP/TFTP code contains routines from NET/2 and Phil Karn's KA9Q. The monitor code is based on the same collection of networking routines. Code like the TFTP client can almost be thrown in "as is" by virtue of a "poor man's" UDP-only socket level (`sendto', `recvfrom', `bind', and all that) interface. -pk