From owner-freebsd-hackers Thu Dec 6 7: 9: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 5ED0C37B417 for ; Thu, 6 Dec 2001 07:09:01 -0800 (PST) Received: from dialup-209.245.132.144.dial1.sanjose1.level3.net ([209.245.132.144] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16C08k-0006KA-00; Thu, 06 Dec 2001 07:08:47 -0800 Message-ID: <3C0F89FC.EA91E6A1@mindspring.com> Date: Thu, 06 Dec 2001 07:08:44 -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> 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: > For some odd reason I need to load another OS (no matter which one, > everything that known about it is its boot sector number) > at the end of the reboot syscall. Could someone please explain how to > switch processor to real mode and continue program execution from some > point in low memory? The system is not reset to real mode on reboot. To reset the system to real mode, you should probably copy the VM86 memory area over low core, and switch that way. It will be incredibly difficult. You might also be able to re-POST the low core memory with a software reset in VM86, but I would not rely on this not really resetting the machine. The real problem is the interrupt routing table and the active devices which may result in interrupts during this process; if you take away the FreeBSD IRQ routing and substitute the BIOS routing, things will probably go to hell. At the very least, using BIOS services will be unreliable, unless all devices are returned to POST state (I had a system at one time that did not reset UART state on POST, and the serial ports ceased to work correctly without a power off, since the Xenix I was running enabled the FIFOs, and the BIOS post did not disable them). A better alternative would be to simply mark the target partition as "active" and reboot normally (assuming that you don't want to reboot to FreeBSD on power on, and then switch to another OS on a soft reboot only). Most "multiboot" boot managers will mark the booting partition as active as part of their boot selection process. Without a better understanding of why it is you think you want to do this evil thing, I can only suggest reading: Protected Mode Software Architecture Tom Shanley Mindshare, Inc. Addison-Wesley Publishing Company ISBN 0-201-5447-X -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message