From owner-freebsd-hackers Fri Oct 27 11:44:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA11410 for hackers-outgoing; Fri, 27 Oct 1995 11:44:02 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA11388 for ; Fri, 27 Oct 1995 11:43:50 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA23625; Fri, 27 Oct 1995 11:32:28 -0700 From: Terry Lambert Message-Id: <199510271832.LAA23625@phaeton.artisoft.com> Subject: Re: boot disk.... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Fri, 27 Oct 1995 11:32:28 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, lenzi@cwbone.bsi.com.br, hackers@FreeBSD.ORG In-Reply-To: <199510270246.MAA12415@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 27, 95 12:16:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4798 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Terry Lambert stands accused of saying: > > Define "work". 8-). > > If I have a disk that claims to be 2000/10/17, and I rewrite it to > 1000/20/17, will the BIOS make the right calculations. It would appear not 8( I should have said "define work right". 8-). IF the BIOS is hooked via INT 13 redirector AND IF the redirector respects the table contents when doing its multiply by the C/H/S value to get an absolute sector offset which it uses internally on the controller (since drives are not addressed by a C/H/S value internally), THEN your INT 21 operations will not fail. BUT since the reason you need INT 21 operations is to translate the C/H/S value in the DOS partition table into an absolute sector offset so that the BSD protected mode driver, which doesn't know anything about C/H/S values except phisical ones to use them to get absolute real disk sectors, THEN your use of the DOS patition table contents will fail AND THEN your attempt to locate the BSD partition on the disk will fail AND THEN your BSD will fail. > 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. What it *MIGHT* be able to do *IF* it's a non-standard MBR replacement (which we will tromp on anyway to put in a boot selector) is use the standard-but-implemented-by-no-programs-because-it's-not-portable LBA INT 21 extensions to do the loading instead of C/H/S values. 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. > Stage 0 bootstrap (first sector of FreeBSD slice) reads Stage 1 bootstrap > from next N sectors of FreeBSD slice. Uses same technique as the MBR code > to reach beyond 1024 cyls. That would be BIOS-based geometry translation (for most SCSI devices) and OnTrack 6.x INT-13-redirector-TSR-based geometry translation for most IDE devices (which are otherwise too stupid to translate the geometry on their own). Currently, this is called the second stage (or OS specific) bootstrap. > 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. Consider that a generlization of the boot process for PPC/Alpha/Sun/etc. will require the ability to make firmware calls from protected mode. The difference is that for those systems, the interface is implemented, and for Intel it (VM86) is not. > Stage 2 boostrap runs in real mode under the BIOS. It should provide > facilities to select the root filesystem and kernel. It should be able > to read the device configuration out of the kernel, and thus inherit > the functionality of userconfig(). It should perform MBR fixup to > guarantee that the absolute offset field in the MBR matches the c/h/s > values for the slice under the BIOS geometry. It should also be buildable > as a DOS program, to allow it to work with Ontrack's Disk Mangler. The > ability to provide the correct major/minor numbers to the kernel > (automatic detection of the wd/hd/sd stuff in the current idiom) would > follow as a matter of course. A lot of work to replace exisiting functionality. 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. > Now, I'm sure that the purists and the serial console people are screaming > here, so there's a need to continue to support the current scheme as well. That would make me a purist. 8-). > Input and, naturally, time are required. Alternatively, if someone wants > to pick this up and play with it, please do! Not me, at least not right now. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.