Re: detecting > 64M on x86

Larry M. Augustin (lma@varesearch.com)
Mon, 23 Dec 1996 11:20:56 -0800


>From: "Kimon Berlin" <kimon_berlin@hpgnd.grenoble.hp.com>
>
>"Larry M. Augustin" <lma@varesearch.com> 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.

Thanks,

Larry