Date: Mon, 27 May 1996 14:09:14 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: hackers@freebsd.org Subject: Re: three stage boot again Message-ID: <199605271809.OAA03085@skynet.ctr.columbia.edu> In-Reply-To: <199605270547.PAA25723@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 27, 96 03:17:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the world, Michael Smith had to walk into mine and say: > Bill Paul stands accused of saying: > > > > Yes, I'm still here. > > Good to know; thanks for doing the hard yards on this! In the end, it turned out not to be that hard. Of course, it took me a while to get to the end. [chop] > I think you're on the money here; the third stage shouldn't care how it > got into memory, it should be able to derive _everything_ by examining the > environment that it finds itself in on startup. Well, it turns out that it can read the disklabel by itself. The problem I had was that I initially just declared a struct disklabel as a buffer, but that didn't work. Later I just left space in start.S for the disklabel buffer, just like the original start.S does, and that worked fine. > (I know this means two bootp requests if it's come in from a netboot > environment, but that shouldn't hurt). Unfortunately, I'm not making much headway with integrating netboot. I _did_ manage to get the original mach_kboot program to work properly, and it has support for loading a kernel over the net. (This was just a matter of taking the startup routine that I'd created for the biosboot program and grafting it onto the mach_kboot program. Mach_kboot also uses a slightly different segment descriptor table layout, so I had to sweak the segment selector values a little, but now that I've figured out how they're supposed to work it was simple to do.) But when I tried grafting the netboot and biosboot programs together, the resulting program would not run correctly. Biosboot works fine as a standalone program. Biosboot+netboot just explodes on entry and the machine reboots. I'm not quite sure why this happens. One problem is that there are some duplicated functions; for example, both programs have their own printf()s, their own real_to_prot()s and print_to_real()s, and a few other things. I may have to tinker a bit more before I find the right mixture. Another problem, which could be tough to overcome, is that the biosboot program's bss section is actually quite large. This is because it delcares a lot of large buffers for disk I/O. One of them is a read-ahead buffer which takes up 9K, then there are several 8K buffers for some of the ufs support code. The first image that I linked with the netboot code included had text, data and bss sections that added up to over 70K. This easily exceeds the 64K limit. Curiously, even when I got rid of the read ahead buffer and its associated code, which brought the total just under 64K, it still didn't work. It looks as though the program is successfully jumping to the restart location in the new boot code segment (protected mode, with an offset of 0x10000), but it blows up as soon as I try to reload the stack and data segment selectors. This would seem to indicate that maybe the descriptor table is getting scrambled somehow, but if that was the case then the intersegment jump (which also reloads the code segment selector) shouldn't have worked either. Of course, I also tried to link netboot as a standalone program all by itself, and that blew up too. *sigh* What I wouldn't give for a 386 simulator with memory and register dump capabilities. :) -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= License error: The license for this .sig file has expired. You must obtain a new license key before any more witty phrases will appear in this space. =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605271809.OAA03085>