Re: detecting > 64M on x86

Kimon Berlin (kimon_berlin@hpgnd.grenoble.hp.com)
Tue, 24 Dec 1996 10:45:29 +0100


"Larry M. Augustin" <lma@varesearch.com> wrote:
(...regarding which BIOS function to use)
> >"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.

NT uses e820h, or e801h if e820h does not exist.
Win95 and OS/2 use 88h, then e801h if 88h returned a certain value (15MB for
win95, 64MB-4KB for OS/2, I think).
win 3.1 (ha!) only uses 88h, so there is no way to beyond 64MB.
Once upon a time, certain unices used 8ah.

> 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.

The current detection is a simple three-line affair. When I overhaul stuff like
that in a BIOS, there is always the risk that I'll end up breaking something
else in an apparently unrelated piece of code. But it's probably just me,
ensuring faultless compatibility with legacy DOS code is not Linux's primary
concern.

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