Date: Tue, 18 Nov 1997 04:43:30 -0600 From: Tony Overfield <tony@dell.com> To: Jonathan Mini <j_mini@efn.org> Cc: hackers@freebsd.org Subject: Re: >64MB Message-ID: <3.0.3.32.19971118044330.0071582c@bugs.us.dell.com> In-Reply-To: <19971110022540.34863@micron.mini.net> References: <3.0.3.32.19971110034509.0069e370@bugs.us.dell.com> <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
At 02:25 AM 11/10/97 -0800, Jonathan Mini wrote: >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. The nominal term "lowest 640K" is often used to refer to this real-mode accessible user memory. In the context of this discussion, he could have meant either the "lowest 640K" or the lower 64K of the second MB. I guessed that he probably just dropped a zero from the 640K, when in fact he was talking about the other. It makes no difference, the important point was that the address needs to be real-mode compatible. >(calculate the linear adress for >FFFF:FFFF - it's (64K - 1) above 1M) "THat's not true." To be correct, you should have said "(64K - 16)." Yes, that's picky, but I though you were being picky too. ;-) >> 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. Of course I can't fault the simple logic of this answer, but if you had read my questions more carefully, you should have realized that I'm talking strictly about the time _before_ FreeBSD touches the devices. Once again, there's a certain time before the devices are touched and after the bootloader jumps into the kernel where it would be advantageous to make a few BIOS calls. I simply suggested doing so then, while it's still easy to do and while it can't possibly conflict with anything that FreeBSD has done up to that point. As an added bonus, when it is done at this certain time, it doesn't increase space consumption by the bootloader, which is a very important consideration. That's my last attempt. I apologize for not giving up sooner. I simply can't tolerate the unusual level of effort that seems to be required to be properly understood around here. - Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19971118044330.0071582c>