Date: Mon, 09 Feb 1998 17:47:23 -0800 From: Mike Smith <mike@smith.net.au> To: ade@demon.net Cc: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: boot floppy banner Message-ID: <199802100147.RAA06071@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 07 Feb 1998 16:56:52 CST." <E0y1JB7-0000Cg-00@sphinx.lovett.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.. :) Feh. There is only one place to start. > 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, Almost. Loads boot1, executes. Boot2 locates & loads boot2. > 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.. All the code for parsing kernel options goes. The code for loading the kernel is simplified. The splash code goes. The VESA code goes. The NEXTBOOT code goes. The protected mode/real mode switch code may be simplified (depending on where boot3 is actually loaded). More importantly, adding more features doesn't involve more boot2 bloat. (Sorry for the delay here). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802100147.RAA06071>