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)]