Messages in this thread | | | Date | Mon, 23 Dec 1996 11:20:56 -0800 | From | "Larry M. Augustin" <> | Subject | Re: detecting > 64M on x86 |
| |
>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
| |