Date: Fri, 27 Oct 1995 11:32:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, lenzi@cwbone.bsi.com.br, hackers@FreeBSD.ORG Subject: Re: boot disk.... Message-ID: <199510271832.LAA23625@phaeton.artisoft.com> In-Reply-To: <199510270246.MAA12415@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 27, 95 12:16:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510271832.LAA23625>