Date: Mon, 30 Oct 1995 17:05:19 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, hackers@freebsd.org, lenzi@cwbone.bsi.com.br, terry@lambert.org Subject: Re: boot disk.... Message-ID: <199510300635.RAA01084@genesis.atrad.adelaide.edu.au> In-Reply-To: <199510300614.RAA08870@godzilla.zeta.org.au> from "Bruce Evans" at Oct 30, 95 05:14:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans stands accused of saying: > >It's actually intended to remove the need for any driver to need to know > >about any translation. There are issues related to disks not covered by > >a BIOS, but from the point of view of the 'panic: can't mount root' problem > >experienced when an unwitting installer gets the geometry wrong. > > Drivers only need to know about the BIOS translation so that they can > report it to fdisk so installers can get the geometry right. This is The BIOS geometries for all BIOS-recognised disks would theoretically be passed in in the kernel environment block. (the same techniqe would be used for passing in the name of the root device, any userconfig tweaks, the _real_ memory size as determined using the "correct" technique(s), etc.) > remarkably complicated, especially for handling of disks not covered > by the BIOS, and still not handled right. The stage 2 bootstrap If the disk isn't covered by a BIOS, then there's no translation involved, and no need for alternative geometry to be passed in. > shouldn't have to duplicate the complications. Anyway, the stage 2 > bootstrap is far too late to fix the values. The previous stage (stage > 1 of 0, 1, 2, ...) is written at the absolute offset but loaded using > the c/h/s values. Only stage 0 (the MBR) can fix them. Point. SOunds like chicken-and-egg 8( > >Nothing would. "It should be buildable as a DOS program"; in other words, > >it should fit into the fbsdboot tool, to cover all booting scenarios. > > fbsdboot should _be_ a DOS program and be built as a FreeBSD program. > Then it would be easier to add extensions to it. If you have any magic techniqes for converting a FreeBSD binary into DOS EXE format, I'm keen 8) I currently use the GNU toolchain and the DJGPP libraries as a cross-development platform for much of our DOS work. > The new stage should also be buildable as an extension for netboot. Being BIOS-only, it would effectively be loaded by netboot as the kernel currently is. This would strip all of the protected-mode stuff out of the seperate bootstraps and park it all in once place. > Bruce -- ]] 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?199510300635.RAA01084>