From owner-freebsd-hackers Fri Apr 25 00:14:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA29024 for hackers-outgoing; Fri, 25 Apr 1997 00:14:03 -0700 (PDT) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA29019 for ; Fri, 25 Apr 1997 00:14:01 -0700 (PDT) Received: from ant.us.dell.com (ant.us.dell.com [198.64.66.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id CAA03546; Fri, 25 Apr 1997 02:11:44 -0500 Message-Id: <3.0.1.32.19970425021142.007bb100@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 25 Apr 1997 02:11:42 -0500 To: Robert Withrow , hackers@FreeBSD.org From: Tony Overfield Subject: Re: Can't put 512MB ram in box ... Extended memory question. In-Reply-To: <199704250001.UAA02252@spooky.rwwa.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk At 08:01 PM 4/24/97 -0400, Robert Withrow wrote: >Can someone tell my why WIN95 can figure out I have 128M in this machine >(with no special help from me) and FreeBSD can't? I don't like the idea >of WIN95 being smarter than FreeBSD.... ;-) The short answer is that Windows 95 calls the BIOS to ask how much memory is installed, but FreeBSD doesn't. One reason for this is that it requires a few dozen bytes of new code and the code space in the 7.5 KB boot-block is very short and is tightly guarded. What follows is strictly IMHO. >From what I can tell, whenever this subject comes up, the discussion usually follows two paths. The first path involves the idea of a three-stage boot, which effectively removes the size restrictions from the portion of code that runs (or can run) in real-mode prior to the kernel being loaded. While this approach is a rather simple and logical extension of the current implementation, it always seems to bog down due to the extraordinary number things people want to add into the extra stage. Perhaps this speaks to the potential of this approach. The second path involves making the kernel generally capable of calling real-mode BIOS functions using a vm86() virtual machine. While this more difficult approach has great power, there doesn't seem to be anyone willing to do the work. This approach also seems to bog down due to the large amount of work which would be required to fully exploit the added capability (for example, running SCSI option ROM's when a native driver is not available). A third, perhaps unseemly, possibility, that I haven't seen mentioned before, is to make the real-mode BIOS call from the kernel init code in the same way that the APM initilization BIOS call is made, by temporarily returning the CPU to real-mode after the kernel is loaded.