Messages in this thread |  | | From | "Kimon Berlin" <> | Date | Mon, 23 Dec 1996 10:22:23 +0100 | Subject | Re: detecting > 64M on x86 |
| |
"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.
"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 think e801h would be enough for our purposes, it can still report a memory hole below 16 MB and only has to be called once.
Would there be a point in reporting the amount of cachable memory? I don't know if any other part of the kernel is designed to have a use for that (i.e. "fast pages" and "slow pages").
> No, I don't know the difference between local and system memory, and I
"Local" would be on the motherboard, "system" on another board. Before memory modules (SIPPs and SIMMs), when you wanted more memory, you added an ISA (or MCA?) card with memory chips on it. Bandwidth was, um, suboptimal.
> 1. Assign a 42 byte block in the PARAM page to return the entire > data structure. We would still need a way to return the memory > for systems that do not support the memory map bios call - probably > use the existing PARAM+2 location. > 2. Change the PARAM+2 location to return the amount of memory in MB instead > of 1K chunks. Currently this location is only a 16-bit word and > returns memory on 1K chunks.
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?
Cheers, Kimon. -- Kimon Berlin - Hewlett-Packard Performance Desktop Computing Operation R&D (BIOS), a spinoff of the Division Formerly Known as GPCD "You can tune a filesystem, but you can't tune a fish" [HP/UX tunefs(1M)]
|  |