From owner-freebsd-hackers Thu Dec 6 8:44:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 2974037B416 for ; Thu, 6 Dec 2001 08:44:55 -0800 (PST) Received: from dialup-209.245.132.144.dial1.sanjose1.level3.net ([209.245.132.144] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16C1dV-0001OP-00; Thu, 06 Dec 2001 08:44:37 -0800 Message-ID: <3C0FA075.A3C405DF@mindspring.com> Date: Thu, 06 Dec 2001 08:44:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dmitry Konyshev Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: switching to real mode References: <3972603197.20011206170402@agava.com> <3C0F89FC.EA91E6A1@mindspring.com> <1080523636.20011206191602@agava.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dmitry Konyshev wrote: [ ... reboot with new active partition ... ] > I thought of this way, but it might seem "strange" for a user if her > computer would want to reboot without any obvious reason. I'll keep > this way in mind for the case I fail to implement it in more user-friendly > manner. :) > > I saw an example of switching in real mode in linux' sources (it looks > pretty clear) and thouhgt it is possible to do the same under FreeBSD. During the boot process, we swithc back and forth. Once the IDT is replaced in low memory, though, we pretty much have to use VM86() to access that space. If the OS you want to boot is "DOS" or some other that runs in 8086 "real mode", then you could run it via a VM86() call, and trap the BIOS reset vector to return you to FreeBSD by exiting the VM86() call. For this to work, you will probably want to be able to save and restore a "pristine" VM86() environment (I'm not sure we template this; you could ask Mike Smith, as he did a lot of that code). > The problem is I'm absolutely lost in FreeBSD's physical memory management > implementation (page tables and directory and so on). Ugh. FreeBSD's physical memory management... yet another series of articles I have drafted, but haven't yet had time to complete (I think it is a 2 or 3 part thing). Right now, I have sent one "Embedded BSD" article off to "Dameon News", and have another "Embedded BSD" article (about "Rebadging FreeBSD") pending later completion. The answer is "you could do it, but putting the code in the low 16M so that it would be addressible and resetting the segment registers, IDT, etc., and disabling paging would be pretty hard". > Devices states shouldn't be a problem because version of FreeBSD I'm > going to use will have minimal option. Anyway I could reset such > devices (if any) manually before loading other OS. Device states are incredibly ugly. I'm pretty sure that there is not a Linux program that can successfully boot Linux from Windows NT/95, since most of the IDT vectors in the VM86() get moved over to point to thunks into Windows protected mode code, so the initial VM86() calls in the Linux startup break, just like the FreeBSD ones, since they try to thunk into an OS that isn't there any more to service them. You basically need to get the system back to the POST state, after IO.SYS (and potentially, the LBA disk INT patch) have been loaded, before Windows takes them all over. That's basically what you are asking "How do I do this?" for FreeBSD. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message