Date: Wed, 05 Nov 1997 02:06:26 -0600 From: Tony Overfield <tony@dell.com> To: Terry Lambert <tlambert@primenet.com> Cc: jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG Subject: Re: >64MB Message-ID: <3.0.3.32.19971105020626.006da974@bugs.us.dell.com>
next in thread | raw e-mail | index | archive | help
At 07:47 PM 11/3/97 +0000, Terry Lambert wrote: >> FreeBSD simply makes the wrong BIOS call. The particular >> BIOS call made by the boot loader is limited to 16 bits >> worth of Kilobytes. > >That's what I said: the BIOS lies. Ok. I guess this is some kind of a cutesy anthropomorphism. The fact is that the BIOS INT 15h AH=88h function returns the best possible answer. The function is limited, by definition, to 63 MB of memory, and it physically cannot return 64 MB, even if you were willing to violate the API. For systems with more than 63 MB of extended memory, it is simply the wrong function to call, and it has been for many years. moral: If you force the BIOS to lie, it will. >> To make matters worse, the kernel >> eventually ignores that answer in preference to the lower >> 16 bits of the actual value stored in CMOS, which is never >> better and often worse, as it truncates the most >> significant bits. > >Only on machines that are anal about not indicating more than 16M >even though the bits are there for 64M for conformance with some >bogus, antiquated IBM AT hardware document. 8-|. Not correct and not on topic. We're talking about $(subject). Off-topic response... In fact, this 16 MB limit was enforced by some serious software compatibility problems with 286-protected mode software, operating systems and utilities which were prevalent at that time. It seems they couldn't squeeze 26 bits into the 24-bit descriptor's base address fields. ;-) All of that software has now been obsolete for so long that, IMHO, any system built in the last half-dozen years does not restrict any of the memory values to 16 MB. Returning to topic... The main problem I was pointing out here is that the CMOS values are being directly probed by the kernel without any reasonable expectation that it is the correct thing to do. In some cases, these CMOS values are actually 24-bit values, having been extended by the addition of 8 additional higher order bits. This permits the BIOS to record and track up to 16 GB of extended memory. But the kernel only probes the lower 16 bits, tossing high order significance. Unfortunately, this bogosity cannot be easily fixed because there is no standardized storage location for the rest of the bits. The best way to determine the amount of memory is to make the appropriate BIOS calls. The bootloader already makes the "64 MB limited" BIOS call and sends this value to the kernel, but for some strange reason, the kernel tosses that value away in favor of the sometimes bogus CMOS value. Using this BIOS call's result instead of tossing it would resolve my complaint about the CMOS groping. To get past the 64 MB limit requires making other BIOS calls, but that's a well-known problem I won't bother to get into again. I've described all of these problems in detail in -hackers before. Search for variations on "e820h", "E820h", "0E820h" etc. >The problem is that the BIOS call made in the boot code should not >be in the boot code at all, I think you don't understand. It must be there. You cannot load the kernel into memory without knowing whether you have any memory. >not that we should increase the size of >the boot code yet again by calling the "good" BIOS call (quoted >because it exists only on newer hardware, not all hardware), and >falling back to the ignored one if it's not there. > >The problem with increasing the boot code size "just a tiny bit" is >that there is *truly* no room for it (the ELF capable boot blocks >that can still boot an a.out kernel have about 12 bytes left). The lack of room doesn't make it the wrong thing to do, it just makes it hard to do. At *least* the "64 MB limited" BIOS call must be in the bootloader. Since 64 MB is enough to load even the largest kernels (for now at least ;-) ), the "good" BIOS calls don't need to be in the bootloader, but that's where I'd put them. Of course, the bootloader would need to know how to fetch some extra code first. I think an extra stage (or a half-stage) would work fine for this. - Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19971105020626.006da974>