[lkml]   [1996]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: detecting > 64M on x86

>From: "Kimon Berlin" <>
>"Larry M. Augustin" <> wrote:
>> Modern x86 BIOSes support detection of memory > 64MB. I have modified
>> arch/i386/boot/setup.S to safely detect the presence of these BIOS
>> features and use them if present to detect more than 64MB RAM.
>> I now need some advice as to how to return this information to the
>> kernel.
>> For example, the int 15h ah=c7 get memory map call returns a 42 byte
>> structure that includes how much memory is installed above and below
>> the 16M boundary.
>Ralf Brown's interrupt list says this is a PS/2 function, i.e. you are not
>likely to see it implemented on a non-IBM system.

I don't know how widely it is implemented, but I have tested it on
about 6 boards, all pentium or pentium pro, the oldest about 3 years
old, and none of them are from IBM. Most of them are Intel boards.

>"Standard" functions are int 15h, ax=e801h and int 15h, ax=e820h. e820h is
>closest to c7h, it returns a detailed memory map, but it has to be called
>several times, this would bloat setup.S .

I will look into these calls.

Is there any reason to be terribly concerned about adding this code to
setup.S? Even Windows NT knows when a system has more than 64M RAM.
Linux ought to also. I added quite a bit of checking and
instrumentation to setup.S.

>Maybye PARAM+2 can be used for memory between 1 and 16/64MB, and we can add
>PARAM+8 for 16/64MB to 4 GB (I think 8 is the first available offset)?
>We wouldn't break anything that way.
>I've been playing with the idea for a while, but I've never found the nerve to
>modify the PARAM table. It also is defined in several places, would it be okay
>to centralize the definitions in a single file?

The biggest obstacle to my just making a sample fix and distributing
the diffs is that I don't have a PARAM table map. If someone will
send me one, I will pick an implementation, distribute, the diffs, and
we can work from there to find the optimal solution.



 \ /
  Last update: 2005-03-22 13:38    [W:0.060 / U:3.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site