Date: Wed, 15 May 1996 00:16:40 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: freebsd-hackers@freebsd.org, wpaul@skynet.ctr.columbia.edu Subject: Re: Making a three-stage boot Message-ID: <199605141446.AAA23535@genesis.atrad.adelaide.edu.au> In-Reply-To: <199605131546.LAA01112@skynet.ctr.columbia.edu> from "Bill Paul" at May 13, 96 11:46:36 am
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Paul stands accused of saying: > > Lately I've been experimenting with creating a three-sgate bootstrap > program. (No, I don't know why. It isn't as if I don't have enough to > do already.) Unfortunately, much as I expected, I've hit a wall. That's OK; I've been thinking about this too 8) > - There is a standalong program called /boot. This program should run > in protected mode, but have the same ability to perform real mode > BIOS operations as the existing second-stage bootstrap. I believe it Hmm. I'm not convinced that it should run in protected mode. Why not run in real mode and avoid having to switch back and forth until the time comes to load the kernel? > has to be limited to having at most 64K of text and data, though I > may be mistaken about this. This is the program which will ultimately > read the kernel image from the filesystem and run it. The issue here is which compiler is used to generate the 'boot' program. If we stick with gcc (a wise idea), and use the same approach as the current second-stage bootstrap, then yes, I believe we're limited to 64K in real mode. If 'boot' were running in protected mode, we could go larger without any trouble. > - The /boot program is loaded by a second stage bootstrap, which is > by design very dumb and limited in function. It has a compiled-in > array of disk blocks which tell it where the the /boot program resides > on disk. It also has a compiled-in value for the filesystem blocksize, > and possibly some other magic values. In essence, this second stage I think this hardcoding is a Very Bad Idea. The code to find and read filesystems is already in the second-stage bootstrap, so it fits already. You should search all possible FreeBSD partitions, not just the first one. Alternatively, put the block information in the first part of the 'boot' program. If you were to use the first 512 bytes, and allow 32 bits per physical block, you could map a 64K file. This means that any bootstrap can use the boot program, not just one written to explicitly know where it is. (Think using a second-stage bootstrap off a floppy). > need any code to grok a UFS filesystem; it doesn't need any keyboard or > serial port I/O code since it doesn't have to interact with the user. It should be able to report on its progress searching for a 'boot' program. > arrays populated with magic numbers. The installboot program reads in > the second stage image and stops when it reaches the magic numbers, then > overwrites them with the proper disk block values. (This is ugly, but > it's the only way I could find to do it without a symbol table.) It's the 'traditional method'. 8) > to load it. Also, by patching values into the bootstrap, we can save > other information, such as the proper disk geometry of the boot drive, > or anything else that it would be useful to save. The one restriction > here is that /boot must remain where it is. If it is moved, the installboot > program must be run again in order to install a new second stage boot > with a new set of physical block numbers. Better still, never mind about all these other parameters. Because 'boot' is using the BIOS and is much larger, it can nut these out itself. It can also read and maybe write UFS filesystems, so it can maintain a seperate configuration file. Obviously then we move userconfig() into 'boot', and have it be able to read configurations out of kernels. > - The standalone image obviously needs some sort of assembly language > startup routine, only I'm not adept enough at 386 protected-mode > assembly language to write it myself. (What would really help is if > we had some sort of 'libsa' standalone library. 4.4BSD-Lite had one > for the i386 architecture, but it relied on special protected-mode > drivers. It would be terrific if we had one that used the BIOS > instead.) Stick to real mode. Calling the BIOS out of real mode is Relatively Easy. In real mode, about all you'll have to do is setup ds and ss. If you're determined to do the protected-mode thing, have a look at how the DJGPP stuff works. (The go32 DOS extender etc.) Note that this is serious overkill for this application. 8) > - Assuming I had a startup routine (and the right code to do the real-mode > BIOS operations), how exactly do I link the image? > > o Should it be a ZMAGIC binary like the kernel? Or should it > be OMAGIC like the existing bootstrap? It probably wants to be PIC or possibly loaded somewhere lowish like 2000:0. You'll want to consider whether 'boot' will be loaded by the 'fbsdboot.exe' program, or whether 'boot's functionality will be incorporated into it. Also consider those that use the Linix 'lilo' tool. > - How do I hand off control to the standalone image from the second > stage bootstrap? Can I use the same startprog() routine that the > existing bootstrap uses to kick off the kernel? If not, what do I > use instead? If it's in real mode, you just do a far jump to it. You'll need to work out who's responsible for ss and ds, and get this clear with the compiler too. > Basically, this is deep magic, and I'm not yet a clever enough magician > to make it all work. I _want_ to learn how to do this, but I'm not making > much progress. If anyone can shed some light on this subject, either > by pointing me at some in-depth documentation (that preferably doesn't > need to be viewed with a stinking web browser) or answering some of the > above questions, I'd greatly appreciate it. Hmm. I'm not all that much of a magician either 8( If any of the above is helpful, great! There are lots of wonderful things that could be done with such an approach. > -Bill -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605141446.AAA23535>