Date: Thu, 15 Jun 2000 19:24:28 -0700 From: Mike Smith <msmith@freebsd.org> To: Parag Patel <parag@cgt.com> Cc: Ronald G Minnich <rminnich@lanl.gov>, hackers@FreeBSD.ORG Subject: Re: freebsd bios. Message-ID: <200006160224.TAA01524@mass.osd.bsdi.com> In-Reply-To: Your message of "Thu, 15 Jun 2000 18:58:07 PDT." <77249.961120687@pinhead.parag.codegen.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, 15 Jun 2000 18:49:23 PDT, Mike Smith wrote:
> >
> >8) Actually, the things that really bother me are eg. interrupt routing
> >and the ACPI GPIO bits, since the former is board-specific and you *must*
> >know about it to set PCI up, and the latter is often necessary to do
> >important things like, eg. turn the CPU fan on.
>
> Shouldn't be too bad to figure out actually. I've got register dumps
> when booting using the BIOS so simply setting most of the them back that
> way should handle the intr routing, or at least decode the intr routing.
Uh. You're kidding me, right?
You need to know the interrupt routing to do PCI resource allocation. You
need the MP table to program the I/O APIC.
Both of these are specific to the actual, physical layout of the PCB. The
data is encoded in the BIOS - you will need to extract this information so
that your startup code can do resource allocation. Without this data,
you're completely screwed. You can't probe it, there are no conventions
at all on how it's laid out - just Have To Know it.
> GPIO bits are going to be a problem if we can't read the settings. The
> boards I'm using always turn on the CPU fan at power-on. Which board
> doesn't do this? Seems like a disaster waitng to happen...
Lots of them do; go looking at the _PTS() ACPI method for example. Here's
one from an ASUS P2B - a *very* common single-CPU board:
Method(\_PTS, 1) {
If(LNot(LEqual(Arg0, 0x5))) {
Store(0x0, FANM)
Store(0x0, PLED)
}
If(LEqual(Arg0, 0x1)) {
Store(One, TO12)
}
If(LEqual(Arg0, 0x2)) {
}
Store(One, TO12)
Or(Arg0, 0xf0, Local2)
Store(Local2, DBG1)
}
Note that it's turning off the power LED and the CPU fan. Here's the
_WAK method:
Method(\_WAK, 1) {
Notify(\_SB.PWRB, 0x2)
Store(0x1, FANM)
Store(One, PLED)
Store(0xff, DBG1)
}
Now, you'll want to know where this is, right?
OperationRegion(GPOB, SystemIO, 0xe42c, 0x10)
Field(GPOB, ByteAcc, NoLock, Preserve) {
Offset(0x18),
TO12, 1,
Offset(0x40),
FANM, 1,
Offset(0x48),
PLED, 1,
Offset(0x4c),
Offset(0x4e),
Offset(0x5e),
MSG0, 1
}
So basically, unless your BIOS *specifically* knows that for this board
you need to set that bit in what turns out to be the ACPI GPIO registers
in the PIIX4 (the AML above is actually bogus - the OperationRegion()
should actually be a child of the PIIX4 which is declared elsewhere, but
it's easier to read like this), you're never going to get the CPU fan to
turn on and you'll toast.
You won't get the power LED either. You may not get eg. the SuperIO chip
either, especially if it's powered down (who knows what the TO12 bit
does?).
You can save yourself _some_ grief by stealing the AML from the board
that you're trying to convert, but there's not enough information in
there to initialise it properly either.
> Still, there's so much else to do in both LinuxBIOS and SmartFirmware...
Sisyphean.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org
\\ and he'll hate you for a lifetime. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006160224.TAA01524>