Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Apr 1997 02:11:42 -0500
From:      Tony Overfield <tony@dell.com>
To:        Robert Withrow <witr@rwwa.com>, hackers@FreeBSD.org
Subject:   Re: Can't put 512MB ram in box ... Extended memory question. 
Message-ID:  <3.0.1.32.19970425021142.007bb100@bugs.us.dell.com>
In-Reply-To: <199704250001.UAA02252@spooky.rwwa.com>
References:  <Your message of "Wed, 23 Apr 1997 14:38:53 PDT."             <199704232138.OAA06172@root.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.  





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.19970425021142.007bb100>