Date: Mon, 30 Oct 1995 12:09:15 -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: <199510301909.MAA06141@phaeton.artisoft.com> In-Reply-To: <199510300130.MAA00303@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 30, 95 12:00:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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( Why? We don't *have* to insist that we be able to boot from an 'a' slice after 1024, do we? That's a requirement you've tacked on. > > 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. INT 21 extension, INT 13 extension to support INT 21 extension. Same difference. > > 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 personally have no problem with a /stand. It resolves the issue with the location of the bad sector replacements in a more than 1024 cylinder drive. That's something that bad144 craps out on now. The entire BSD partition must be below 1024 so that bad144 table is below 1024 right now. This is an issue of where a drive media perfection layer belongs, and how it can be implemented. I believe bad144 is in the wrong abstract location -- which make bad144 an invalid counter argument. > > 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. I think the issues you are addressing are more "old disk" than "new disk" related. The IDE problems that we are seeing are more the result of translation to something other than the max bounds, which is an issue than can be resolved by using the LBA for the parittion start and size in the DOS partition table instead of the C/H/S values. Unfortunately, there is no guarantee of correctness of this at present, and the only guarantee you can make is based on filling out the values using the BIOS based boot code to rewrite them from the C/H/S values before going into protected mode. If you couple this with the final puzzle piece of detecting the OnTrack manager and offsetting by 64 to get the actual DOS partition table and using that as a logical sector bias for the DOS partition tables LBA addresses, then you've resolved the majority of the issues, including the ability to mount DOS extended partitions but not including the bad144 issues of media perfection (that will have to wait for devfs to be the default and a device bias reexport mechanism to be in place). 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?199510301909.MAA06141>