Date: Sat, 07 Feb 1998 16:56:52 -0600 From: Ade Lovett <ade@demon.net> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: boot floppy banner Message-ID: <E0y1JB7-0000Cg-00@sphinx.lovett.com> In-Reply-To: Your message of "Sat, 07 Feb 1998 13:30:15 PST." <199802072130.NAA05630@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith writes: > >What has to happen is that someone has to write the third-stage >bootstrap. The biosboot code will shrink substantially when this >happens. Ok. Forgive my ignorance in any of the below comments - I probably need to hit myself over the head with a clue-by-four as far as i386 booting goes.. :) AIUI, with the two-stage boot process at the moment (MBR and biosboot), the i386 validates the contents of the first few sectors of the disk, loads in biosboot at some low memory location, this code runs, prints up the boot prompt, determines the kernel image to load, blits it in at the 1Mb region, and passes control over and away we go. As far as the end user is concerned, they can either sit and do nothing, or type one line of text to load a different kernel.. Splitting this into three stage process: 1. MBR loads biosboot at <low memory location> 2. biosboot runs and prompts "where do you want to load the next boot program?" 3. biosboot loads <boot3> at <somewhere below 512k> 4. <boot3> runs and prompts "which kernel do you want to load?" 5. <boot3> loads <kernel> at 1Mb 6. kernel runs.. Assuming I haven't messed up anywhere above :), I don't see where the code shrinkage comes from.. biosboot still needs BAD144 etc.. to be able to load the 3rd stage boot, and we still want to give the pilot a choice as to where this code is loaded from.. -aDe [currently confused, as usual..] -- Ade Lovett, Demon Internet, Austin, Texas.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0y1JB7-0000Cg-00>