Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Feb 2003 14:39:57 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        marcel@xcllnt.net
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: [RFC] splitting of conf/NOTES
Message-ID:  <20030224.143957.17279856.imp@bsdimp.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20030224204113.GC661@athlon.pn.xcllnt.net>
            Marcel Moolenaar <marcel@xcllnt.net> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030224.143957.17279856.imp>