Date: Sun, 15 Dec 1996 10:09:23 -0500 From: Tony Overfield <tony@dell.com> To: Bruce Evans <bde@zeta.org.au>, freebsd-hackers@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: MAXMEM was: Re: 2.1.6 on Compaq Prosignia 500 (2.1.5 worked) Message-ID: <3.0.1.32.19961215100920.00678040@bugs.us.dell.com>
next in thread | raw e-mail | index | archive | help
Sorry about this long answer! My genuine respect for you guys compels me to offer the best information I can. At 10:13 PM 12/15/96 +1100, Bruce Evans wrote: >>What BIOS calls? My old notebook is probably the oldest machine that >>somebody would be willing and able to run FreeBSD on (386/16, 5 MB >>RAM, approx. 1990/91), so i could test its BIOS for the existance of >>that call. > >You don't have >= 64MB extended memory, so the existence of the calls >doesn't matter. What matters is that they fail correctly if they are >not supported. Right. >The Interrupt List version 46 (June 1995) gives the at least the >following calls: > >--- >INT 15h/AH=88h The standard call, used in our boot blocks. Limited to > 64MB. Said to be unreliable because some BIOSes don't set the > carry flag if they don't support it. They didn't get this quite right. This call isn't optional and it cannot fail on 286+ systems. They may be confused by the fact that the carry flag is not even returned by this call, since, for compatibility, it must exit with IRET. If you feel compelled to check carry after this call, make sure it's cleared before you call it. Bonus: Since there could be 86xxh KB of extended memory, don't use AH=86h as a fail code for this function either. (I know, it's not likely.) >INT 15h/AX=DA88h. Works on AMI PCI BIOS. Returns size in K in CL:BX. This is a private, non-standard call. > >INT 15h/AX=E801h. Works on some Compaqs and Dells. Details not all > known. Limited to 64M. Not quite right. The values returned by this call are not limited to 64 MB. The details at http://www.uruk.org/grub/mem64mb.html are essentially correct for this function. Here's some of the missing info: The difference between the "configured" and "extended" values is that the "configured" represents the CMOS Setup values and "extended" represents the amount detected by POST. The word "extended", as used here, is usually called "installed" or "detected" by others. In the old days, when we had separate diskette-based Setup programs, these could actually differ until the user corrected the mismatch. The AX=E801h function works in real mode and 16-bit protected mode. There is also a 32-bit protected mode variant that is called with EAX=E881h, but don't expect that one to be supported. In more complete docs, the < 16 MB return values (in KB) are defined to be equal to the RTC-memory values. In effect, this limits the RTC-memory values to 15 MB extended. Windows NT codified this interpretation since NT will not use the E801h function unless the INT 15 AH=88h function returns no more than 15 MB. This limitation was later ignored to support rogue DOS-extenders and the like, but that, in turn, rendered the function useless for Windows NT and it drove Microsoft (and Intel) to create the considerably more powerful AX=0E820h function. See http://www.microsoft.com/kb/articles/q117/3/73.htm or search Microsoft for "e820" if this link was one of those short-term search temp things. > >INT 15h/AX=E802h. Works on some Compaqs. Details not known. > >INT 15h/AX=E802h. Works on some Dells. More details given than for > Compaq, but not enough to actually use it. It can apparently > report any number of discontiguous regions. They got this partly wrong too. The call is INT 15h/AX=0E820h. This call works on Compaq, Dell and a large number of other systems. The documentation at http://www.uruk.org/grub/mem64mb.html appears to be complete, although the official spec has been slightly revised for ACPI. The best version that I'm aware of is chapter 14 of the ACPI specification (ver. 0.9) which is located at: http://www.teleport.com/~acpi/ This function can indeed return arbitrarily detailed system memory maps. This function is called repeatedly until it "dries up." > >There is probably a standard way now, but it may not work on the old >Compaqs and Dells. Some have a stupid 15 or 16MB limit, so they hit >the limit a couple of years before other systems. > >Bruce That limit may indeed seem stupid now, but Dell and Compaq have been shipping systems that support greater than 64 MB of memory for more than six years. For most people, thank goodness, that "stupid limit" disappeared many years ago. The INT 15 AH=88h function hasn't, strictly speaking, worked correctly since about 1990. It seems petty to brag that "My BIOS discards less memory than yours does!" -- To help bolster my point, I'm conveniently ignoring the fact that a fair number of systems have more than 16 MB and not more than 64 MB of memory. ;-) I also think it's bad to use the RTC-memory values, since they are nominally BIOS-private values. In fact, in some systems, the oft-groped extended memory values are just the lower two bytes of an extended width value. Thus a 96 MB system may appear to be a 32 MB system, if the two RTC-memory bytes are used directly. However, in these cases the AH=88h value is wrong too, so some other solution is required anyway. In any case, for the last few years, all Dell systems have returned up to 0FC00h for INT 15h AH=88h, and they have supported at least one of INT 15h AX=E801h or AX=E820h. So, why does anything still use the AH=88h function (or the RTC-memory values) when it has been known for so many years that it is unable to support large memory systems? Of course, the answer is that the current solution works pretty well in most cases, so there's always been more deserving things to work on. Please believe me, I'm not trying to change that. I'm merely trying to offer whatever bits of wisdom I might have accumulated over the years on this topic. - p.s. -- Warning! Boring historical chronicle follows! -- There was a point in time (about 1990/1991) when Dell and Compaq were making EISA systems that supported over 100 MB of system memory. At that time, there were 286 protected-mode programs and operating systems that would horribly malfunction (descriptor overflows, etc.) when they queried system memory using AH=88h and got values greater than 15 MB. This is why some BIOS's in those days limited AH=88h to 15 MB. Besides, the AH=88h function was "defined" as part of a lowly 286 16 MB AT BIOS. Newer 386 and 486 EISA systems provided a way (via EISA BIOS calls, real- and protected-mode) to obtain the actual memory configuration in great detail. EISA was the wave of the future and all large memory systems would, of course, be EISA and therefore have the fancy EISA memory query functions. That was the theory anyway. There were some Dell and Compaq systems produced at this time that only supported AH=88h up to 15 MB and had only the weird EISA calls to obtain the extra extended memory. After a while, when large memory non-EISA systems were developed, the E801h function was created to report the extra memory above 16 MB. Oblivious to these things, other BIOS's were appearing that were returning values greater than 15 MB for AH=88h. This worked for systems with small memory (< 64 MB) and with most software. The simplicity of this short-sighted approach caused the DOS-extender writers (and others) to ignore the fancy new EISA BIOS calls and the new extended BIOS calls used by Dell, Compaq and others. The old 286 programs were quickly being upgraded or were being replaced by their superior competitors. By now, DOS, Windows, Windows NT, and OS/2 were using the new BIOS calls. But many new programs (some based on the 'rogue' DOS-extenders) were still relying on the AH=88h call to return all installed memory. It was at this point that the Dell BIOS was changed to return as much as 63 MB of extended memory from INT 15 AH=88h. Well that's a long story, but I think I got it mostly right. - Tony - not speaking in any official capacity.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.19961215100920.00678040>