[ sorry about the delay, I had to catch a plane in the middle of my
response. That may also cause it to read a little broken ]
> > (http://microsoft.com/hwdev/desinit/simp_bios.htm)
>
> This one isn't it. This is the fast boot BIOS option. With a CMOS
> register you can set when booting succeeds.
Sure. The BIOS has to save the information somehow in NV memory. But, it
seems that it is this table that allows the OS and the BIOS to communicate
that information back and forth. Windows can set this bit to tell the
BIOS not to initialize hardware when it boots (or you can set it in the
BIOS setup). Then the BIOS will save this information in nvram so it knows
what to do next time it boots up.
Note that there are also bits to set in that same table for when a
successful boot was completed, and to communicate whether or not to run
diagnostic tests. (I'd cut n' paste the text, but all I have is a printed
version).
> I read through it yesterday as part of this conversation to see if there
> was anything worthwhile there. My current impression of ACPI is that
> it sucks less. But that it is overkill for what it is doing. Plus it only
> works on intel architectures. (I.e. I can' describe my alpha IRQ routing).
Funny. The first two were my impression of it as well. It has lots of
potential, but it is way over-engineered. As far other architectures,
heh. Though they asserted architecture and OS-independence, the 1.0 spec
is very x86/win32 centric. The 2.0 spec has smoothed some of those
references to windows, and they talk a lot about IA64, but it's pretty
obvious where it's focus is. A prime example is the widespread use of
explicit byte ordering and bit fields.
Given the number of broken BIOS's in the world, it would behoove the
kernel ACPI subsystem to provide its own ACPI tables in the event that one
presented by the BIOS is incomplete or false. If the kernel was to start
doing this, it could be extended for all architectures. But, that's a
kernel thing, and a pipe dream at this point.
> The ASL & AML are what I really object to in the specification. I
> think the same information can be conveyed with flat data values
> instead of needing an AML interpreter. It's complexity without
> advantage as far as I can see.
>
> Hardware control code buried in AML gives me the shivers.
This is the part that is architecture independent, or is at least meant to
be. While interpeted hardware control methods are a bit frightening and
just plain weird, it does allow you to write processor independent code
for controlling the devices.
>From what I've seen so far, it seems the same data could have been
conveyed much more concisely, but I admit that I have not gotten knee-deep
in the AML yet. It appears to provide for practically every possible case,
which can be good. I'm just glad that I didn't have to try and think of
every corner case for the spec ;)
> If I can I want to break linux of unnecessary BIOS dependencies, and
> ACPI seems to introduce some new ones.
True. There will always be some sort of dependencies involved. The thing
with ACPI, though, is that it is meant as much more than just BIOS
information. It slices, it dices, it describes interrupts, and controls
the power state. It is meant as a very core part of an OS. If Linux goes
that route and implements more and more aspects of ACPI, then all is well,
and the dependency would exist anyway. Whether or not it does is
questionable. I personally think it's cool, and would like to see more of
it in the kernel, and the BIOS.
> > If there are any questions, I'll be happy to field them as best I can.
>
> If you can defend the ACPI works I'd find it interesting.
> Or if you know where I can get an ASL compiler so I can build ACPI
> configuration tables.
I've done my part of defending it. I don't want to take the ACPI pedestal,
since I still have somewhat mixed feelings about it, but I will argue for
it.
As far as the ASL compiler, Intel supposedly has one. There could also be
one in the pmtools package. Look here:
http://developer.intel.com/technology/IAPC/acpi/
-pat
