Date: Wed, 15 May 1996 10:35:34 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@freebsd.org Subject: Re: Making a three-stage boot Message-ID: <199605150105.KAA24644@genesis.atrad.adelaide.edu.au> In-Reply-To: <199605141608.MAA02641@skynet.ctr.columbia.edu> from "Bill Paul" at May 14, 96 12:08:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Paul stands accused of saying: > > Well, for a couple of reasons. First, generating real mode executables > is hard (we have assembly that starts off in real mode and changes to > protected mode now). Second, the kernel is loaded above 1MB, and you > have to be in protected mode to do that. The second stage bootstrap > accomplishes this by running in protected mode and then switching to > real mode to do BIOS stuff, which is in itself a third reason, namely > don't re-invent the wheel if you can avoid it. :) Not unreasonable. If we can thunk to the BIOS hooks, then I guess it's probably going to be easier to do it that way. > > > - The /boot program is loaded by a second stage bootstrap, which is > > > by design very dumb and limited in function. It has a compiled-in > > > array of disk blocks which tell it where the the /boot program resides > > > on disk. It also has a compiled-in value for the filesystem blocksize, > > > and possibly some other magic values. In essence, this second stage > > > > I think this hardcoding is a Very Bad Idea. > > Well, SunOS has used this scheme successfully for a long time. I happen > to like the idea. *sigh*. If all you're thinking about is dedicated FreeBSD machines, then sure, it's probably OK. But you're not going to sell a scheme that requires that sort of arrangement. There are just too many problems that it causes. > But I don't want the code that groks the filesystem in the second > stage bootstrap. The second stage can't be made big enough to have any > fun, which is why we need the third stage. If we're making a third > stage anyway, then it should be the one with all the brains. Also, > ripping out as much non-essential code as possible leaves more room for > the block number array: the more block numbers you can cram in, the > larger a third stage bootstrap you can load. But if you don't _need_ the array in the first place, why put it there? I think the code to handle the filesystem reading is likely to be smaller than the array for anything other than a really small third-stage bootstrap anyway. > The installboot program can patch in block numbers for /boot no matter > where it's located (well, unless it's past the 1024th cylinder, of > course). Also, I seem to recall people clamoring for a way to stamp disks > in such a way as to be able to relate the DOS/BIOS drive ID to FreeBSD's > notion of drive IDs (controller/unit). You could use installboot to patch > this info into the bootstrap. # installboot Please list all disk devices from which you might ever want to boot: No thanks. > Yes you have to change it if you change your machine configuration. > Well, hey: life is tough. Great. I don't see you on -questions everyday 8( This sort of deal would generate an absolute plethora of support issues. > > Alternatively, put the block information in the first part of the 'boot' > > program. If you were to use the first 512 bytes, and allow 32 bits per > > physical block, you could map a 64K file. This means that any bootstrap > > can use the boot program, not just one written to explicitly know where > > it is. (Think using a second-stage bootstrap off a floppy). > > In my current prototype, I have an array of 768 unsigned ints reserved > for block numbers. With a blocksize of 4K, this allows me to reference > something like 3 MB of data, which is more than you could fit on a > floppy anyway. With an 8K blocksize (the default for disk partitions) > this goes up to 6 MB. You're not handling bad144 forwarding then I presume? If you want to get around that, you'll need to list individual physical block numbers, not FS block numbers. (You can save space by listing start blocks and run lengths...) And using FS block numbers means you need to have slice and partition intelligence in the bootstrap. Why not the minimal extra to read filesystem data as well? Or go to the other extreme and not bother? > I plan to leave the 'twiddle' function in so that you can see it > trying to load sectors. The only errors it can signal are disk read > failures: remember that it isn't searching for anything -- it knows > exactly where /boot is. I don't buy that scheme. And it _still_ should report where it's loading from, given that it will have to know the slice and partition. > > Obviously then we move userconfig() into 'boot', and have it be able to > > read configurations out of kernels. > > Argh. No. Please. One catastrophe at a time, okay? Next you'll be telling > me to add devfs support to it, and then I'll be forced to shoot you. What's the point of a third-stage bootstrap then? You hardcode its location into the second-stage bootstrap, so that if anything at all changes the system can't be booted at all, and then you move all the functionality that the second-stage bootstrap had into the third stage. How about we add a few more stages just to stretch the whole thing out longer? The only real justification for a third-stage bootstrap is to move some of the boot-time cruft out of the kernel and the interactive stuff out of the second stage. userconfig(), kzip and the 'which kernel' selection are all obvious candidates. We'll talk about boot-time linking the kernel some other day; you could use it to do the boot-time driver probe/load stuff that Terry and I were musing about a while back. > > It probably wants to be PIC or possibly loaded somewhere lowish like > > 2000:0. You'll want to consider whether 'boot' will be loaded by the > > 'fbsdboot.exe' program, or whether 'boot's functionality will be > > incorporated into it. Also consider those that use the Linix 'lilo' > > tool. > > PIC? Hm... the existing bootstrap isn't compiled PIC. That would > imply runtime relocation hackery, no? No, PIC is Position Independent Code. ie. it doesn't give a damn where it is. You'd have to provide it with a suitable stack and bss perhaps, depending on whether we outlawed uninitialised globals. (Not sure if you can do that with gcc). The current second-stage bootstrap is actually two parts, boot1 and boot2. boot1 is loaded by the MBR bootstrap at 0x0:0x7c00 (see comment at the top of start.s). It loads boot2 at 0x1000:0 (see commend in the Makefile). It'd probably be reasonable to load 'boot' at 0x2000:0, given this. > To have it loaded by fbsdboot.exe, it would have to be similar to a > stripped down kernel. This is not a bad idea, but again I haven't > the slightest idea how to do it. The fbsdboot code is built by (ugh) MSVC--. > > If it's in real mode, you just do a far jump to it. You'll need to work > > out who's responsible for ss and ds, and get this clear with the compiler > > too. > > But it isn't going to be in real mode. But it _will_ be entered in real mode. Look at boot2.S (ignore for now the BDE_DEBUGGER stuff) for how to manage this. > -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?199605150105.KAA24644>