From owner-freebsd-hackers Mon Dec 16 13:05:07 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02778 for hackers-outgoing; Mon, 16 Dec 1996 13:05:07 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA02755 for ; Mon, 16 Dec 1996 13:04:59 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02010; Mon, 16 Dec 1996 14:01:47 -0700 From: Terry Lambert Message-Id: <199612162101.OAA02010@phaeton.artisoft.com> Subject: Re: Boot loader hacks was: Re: MAXMEM To: jonny@mailhost.coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Mon, 16 Dec 1996 14:01:47 -0700 (MST) Cc: tony@dell.com, terry@lambert.org, eivind@dimaga.com, hackers@freebsd.org In-Reply-To: <199612161833.QAA25314@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Dec 16, 96 04:33:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Just a stupid question: Why does the boot loader should know if > there's more than 64M or not on the system ? So it can tell the kernel. > Why couldn't it simply detect 64M at most, and let the kernel > find the rest by itself ? Anyway, is what's done with the > MAXMEM option, isn't it ? No; the kernel assumes what you tell it is true. If you use the MAXMEM option, you are eternally stuck with that memory for that particular kernel. Take it to a machine with more memory, and you don't use the extra; take it to a machine with less, and you are screwed. > Moreover: Is there any STRONG reason to ask the BIOS for the > memory amount ? Couldn't it search for the memory ? You ask the BIOS because it's the only part of the system that *knows*, without a doubt, how much RAM there is. That's because it has POST code to search for the memory in a motherboard specific way which is known to work. You can't search it from protected mode because: 1) You don't know the correct algorithm for the particular motherboard 2) The correct algorithm for the particular motherboard which is in the BIOS can not be called from protected mode, and there's not even an entry point for it to be "magically" converted so it can run in protected mode. What *is* true is that you can add memory to the KVA space later, so there should be no problem in knowing about up to 16M reliably from the CMOS value, then making the BIOS calls to find out the real amount from protected mode, using a VM86 virtual machine to make virtual real mode BIOS calls. At that point, there's no limit on the amount of resource detection code you could put in the kernel. Note that once segment tagging and kernel paging is supported, the resource detection code space could be marked "run once"... meaning all space used for it could be recovered after it had been run. That is, I think, the correct long-term soloution to the problem; anything else is band-aid. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.