From owner-freebsd-arch Mon Feb 24 13:42: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3304F37B430 for ; Mon, 24 Feb 2003 13:42:00 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1014843FBF for ; Mon, 24 Feb 2003 13:41:59 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h1OLfq3Y091273; Mon, 24 Feb 2003 14:41:53 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 24 Feb 2003 14:39:57 -0700 (MST) Message-Id: <20030224.143957.17279856.imp@bsdimp.com> To: marcel@xcllnt.net Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES From: "M. Warner Losh" In-Reply-To: <20030224204113.GC661@athlon.pn.xcllnt.net> References: <20030224094856.GA21088@athlon.pn.xcllnt.net> <20030224.060315.63039059.imp@bsdimp.com> <20030224204113.GC661@athlon.pn.xcllnt.net> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20030224204113.GC661@athlon.pn.xcllnt.net> Marcel Moolenaar writes: : The tricky part still is that there's a lot of assumptions about : the BIOS and the BIOS data area that, if I understand correctly, : goes beyond plain ISA and is best described as PC specific. I think : this is more a driver issue than anything else. Well, I'm not sure I understand what you are getting at here, so I'll take a stab at guessing (dangerous I know): There's a PC standard for ROMs that live in the ISA hole. One can identify them by scanning this area. This applies to motherboard ROMs as well as ROMs on expansion cards. The ISA hole is memory between 0xa0000 and 0xfffff. The ISA hole is ISA bus specifc, even if the 'hole' is mapped into a different memory range. The ISA cards cannot decode addresses higher than 16MB, and some can only decode them in the first 1MB. This is why, for example, the OLDCARD pccard code tries to allocate things in the above range (well, 0xc0000 to 0xdfffff by default since that tends to be more free). Bus space is supposed to hide these differences by adding or subtracting the "CPU SIDE" offset from the "BUS SPACE" side of the address. So if a machine had a ISA bus mapped at 0x800000000, say, the driver would do a bus space read of location 0xc0000, but the bus_space layer would translate that to an actual read of 0x8000c0000. There are parts of the BIOS RAM that are in segment 0x40 that describe the machine, but most drivers don't deal with that. I agree that ACPI is a bus, but it is only applicable on i386 and ia64. There are no other architectures that use it. pc98 never will, alpha doesn't (and likely never will given its EOL), sparc64 doesn't (but in theory could). While arm, powerpc and mips could, in theory use it, I'm not aware of any that actually do use it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message