Date: Mon, 10 Nov 1997 02:25:40 -0800 From: Jonathan Mini <j_mini@efn.org> To: Tony Overfield <tony@dell.com> Cc: Mike Smith <mike@smith.net.au>, John-Mark Gurney <gurney_j@resnet.uoregon.edu>, Chuck Robey <chuckr@glue.umd.edu>, Terry Lambert <tlambert@primenet.com>, jamil@trojanhorse.ml.org, hackers@freebsd.org Subject: Re: >64MB Message-ID: <19971110022540.34863@micron.mini.net> In-Reply-To: <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com>; from Tony Overfield on Mon, Nov 10, 1997 at 03:45:09AM -0600 References: <Your <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> <199711070205.MAA00455@word.smith.net.au> <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Overfield <tony@dell.com> stands accused of saying: > At 12:34 PM 11/7/97 +1030, Mike Smith wrote: > >The kernel is loaded above 1M, so you would have to be careful to make > >sure that your BIOS calls came out of the lowest 64K. That could be > >done with a dispatcher in locore.s though. > > I assume you mean the lowest 640K. But yes, a dispatcher would have > to exist down there, with a buffer large enough for your INT 13h calls > and etc. THat's not true, the call needs to come from the lower 1087K, or the lower 1024K (1M) if you want to be really nice. (calculate the linear adress for FFFF:FFFF - it's (64K - 1) above 1M) > >The other reason is that I don't know how to make the change. 8) If I > >did, I'd certainly consider it, although vm86 has a few other uses that > >argue for using it just out of commonality. > > Have you seen this? > > /pub/NetBSD-current/src/sys/arch/i386/bioscall/biostramp.S > > I don't know if it works, but it looks simple enough. I do realize it > offends the sensibilities of some real-mode fearing folks. > > If you can't trust the BIOS after the kernel is in memory, how can you > trust it to load the kernel into memory? While the kernel is still > "booting...", the BIOS should be safe enough to call in real-mode. The reason you can't trust the BIOS always is because once FreeBSD touches a device, the BIOS doesn't know it and might assume that the device is in a different state than it really is. The solution to this is to ensure that the BIOS and FreeBSD never touch the same devices. The only real way to ensure this is if FreeBSD doesn't touch devices, or the BIOS doesn't touch devices. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971110022540.34863>