Date: Wed, 29 May 1996 18:34:37 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: three stage boot again Message-ID: <199605290904.SAA07784@genesis.atrad.adelaide.edu.au> In-Reply-To: <199605271809.OAA03085@skynet.ctr.columbia.edu> from "Bill Paul" at May 27, 96 02:09:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Paul stands accused of saying: > > > I think you're on the money here; the third stage shouldn't care how it > > got into memory, it should be able to derive _everything_ by examining the > > environment that it finds itself in on startup. > > Well, it turns out that it can read the disklabel by itself. The problem > I had was that I initially just declared a struct disklabel as a buffer, > but that didn't work. Later I just left space in start.S for the disklabel > buffer, just like the original start.S does, and that worked fine. Without initialising it, it probably ended up in the BSS. No idea where you put that 8) > > (I know this means two bootp requests if it's come in from a netboot > > environment, but that shouldn't hurt). > > Unfortunately, I'm not making much headway with integrating netboot. I don't think you _want_ to integrate it, per se. You should at some level have a set of functions that are the interface to the reading/finding of files, and bolt one or more bottom ends under that. The current netboot would load a network-aware third stage, which would use bootp/tftp/nfs as required in place of the BIOS disk calls that the disk-aware version would. Perhaps it would be possible to integrate the two functions together, but it's not something you'd do straight away. > Another problem, which could be tough to overcome, is that the biosboot > program's bss section is actually quite large. This is because it delcares > a lot of large buffers for disk I/O. One of them is a read-ahead buffer > which takes up 9K, then there are several 8K buffers for some of the > ufs support code. The first image that I linked with the netboot > code included had text, data and bss sections that added up to over 70K. > This easily exceeds the 64K limit. If you're running in protected mode and just thunking back to real mode to talk to the BIOS this shouldn't be an issue. I'll have to leave it to Bruce to confirm/deny that though. > Curiously, even when I got rid of the read ahead buffer and its associated > code, which brought the total just under 64K, it still didn't work. It Hmm. Removing the buffer didn't screw some implicit offset somewhere else? (I'm not familiar with the code, and not enough of a guru to keep up with you there...) > Of course, I also tried to link netboot as a standalone program all > by itself, and that blew up too. I found netboot to be _very_ touchy in general, although once I got a .com version working for our systems here I stopped thinking about it. > *sigh* What I wouldn't give for a 386 simulator with memory and register > dump capabilities. :) Heh. You've got one - it's called a spare PC 8( > -Bill Paul (212) 854-6020 | System Manager -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605290904.SAA07784>