Date: Mon, 30 Oct 1995 12:00:49 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, lenzi@cwbone.bsi.com.br, hackers@FreeBSD.ORG Subject: Re: boot disk.... Message-ID: <199510300130.MAA00303@genesis.atrad.adelaide.edu.au> In-Reply-To: <199510271832.LAA23625@phaeton.artisoft.com> from "Terry Lambert" at Oct 27, 95 11:32:28 am
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > Here are some scribbles wrt. what I'm trying to work out... > > > > Bootmanager (MBR) looks up first sector of FreeBSD slice. > > Have to assume (for now) that it knows how to reach beyond the 1024 cyl. > > mark. > > It doesn't. It can't. Then we're not going to get much further in support of big stupid disks. 8( > This is useless because the BSD BIOS-based second stage boot doesn't > know about non-standard-about-to-be-stomped-on-by-boot-selector-replacement > LBA-type addressing. It only knows about standard INT 21. Who's using 21 at the BIOS level? Confuse me if I'm wrong, but my recollection has 21 as the DOS entrypoint. > > Stage 1 boostrap (lives in first track(s) of FreeBSD slice) (code that > > currently gives the Boot: prompt) should search all FreeBSD slices > > and partitions looking for an 'a' filesystem containing a file called > > 'boot2' (or whatever - it's the stage 2 bootstrap code). > > This should be read in (version checks? checksums? fallbacks?) and called. > > (Still in real mode) > > This is the "boot program without the 8k limit" idea. This would in > fact be a third stage bootstrap. > > I find it really questionable that this much work would be put into > what is basically a kludge to get around the lack of firmware access > in the protected mode code. It's really a much less general soloution > than the implementation of a VM86() mode, considering there are three > working examples (1) Linux, (2) NetBSD, and (3) CMU Mach, on how to > implement a VM86() mode. It's more that this much work be put in to maintain compatability with the existing scheme. If I Were To Have My Way (tm), I'd have another partition in the FreeBSD slice for holding kernels and bootstrap tools, stuck at the front of the slice. (Reminiscent of the SVR4 /stand (?) concept). I can see right now the fracas this would cause 8( > I believe that we could benefit from discarding the segments containing > the code after boot (ie: code/data/boot code/boot data/etc.), but I > think doing the BIOS thing in a third stage boot is unnecessary. What I'm trying to do is come up with a semi-rational way of getting around the problems that we currently face with large IDE disks, and with the currently too-squashed bootstrap code. It's quite likely that I'm trying to hit too many things and consequently visualising too large a hammer. > That would make me a purist. 8-). You weren't aware of this? 8) > Not me, at least not right now. 8-(. Oh, you have a job too? 8) > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510300130.MAA00303>