Just realised I omitted to CC the list.
On Mon, Jun 8, 2009 at 09:12, Stefan Reinauerstepan@coresystems.de wrote:
We've been using the following script to dump ACPI information from a running system.
#!/bin/bash
rm -rf out mkdir out
# walk through all ACPI tables with their addresses # example: # RSDT @ 0xcf6794ba # we can not just dump the tables by their names because some # machines have double ACPI tables
acpidump | grep "@ 0x" | while read line do NAME=$( echo `echo $line|cut -f1 -d@` ) FNAME=$( echo $NAME | sed s/\ /_/g |sed s/!/b/g ) ADDR=$( echo `echo $line|cut -f2 -d@` ) if [ "${!FNAME}" == "" ]; then eval $FNAME=0 else eval $FNAME=$(( ${!FNAME} + 1 )) fi printf "Processing table "$NAME" at $ADDR ... " printf "${!FNAME} tables of that kind found before.\n"
# acpidump -s ${!FNAME} --table "$NAME" > out/$FNAME-$ADDR-${!FNAME}.txt acpidump -b -s ${!FNAME} --table "$NAME" > out/$FNAME-$ADDR-${!FNAME}.bin if [ "`file -b out/$FNAME-$ADDR-${!FNAME}.bin`" != "ASCII text" ]; then iasl -d out/$FNAME-$ADDR-${!FNAME}.bin &>/dev/null else printf "Skipping $NAME because it was not dumped correctly.\n\n" fi
done
I'll try that out.
Yes. You should not use the vendor BIOS acpi tables. There might be legal reasons against doing that, but more so technical reasons. These tables will not do the right thing if you just plug them into coreboot, even if you fix the compilation issues (that happen due to compiler differences between the Microsoft and Intel ASL compiler). There are very good ACPI implementations for some boards in the coreboot tree, and they should give you enough hints on what to do and how.
Hmm, I'll have a poke around, any particular boards you suggest looking at?
I'd be interested though which parts you are actually missing in the ACPI implementation of coreboot on the Epia-M, or why you are looking at the vendor ACPI?
According to the tutorial at http://www.coreboot.org/VIA_EPIA-M#Advanced_ACPI (and the comments in via/epia-m/dsdt.asl) the only ACPI functionality in the epia-m tree is very basic, supporting only the power button, interrupt routing and basic power management (doesn't support all sleep states).
EDIT: further, soft power-off doesn't work, the system halts, the drives spin down but the board does not power off.
Although now that I re-read some of the information it looks like the article contradicts itself, down further it says that the dsdt.c provided in the tree is ripped directly from the original BIOS although it would seem that maybe the comment about it being extracted from the BIOS only applies to the EPIA-M (not the EPIA-MII referenced earlier).
FWIW my board is an EPIA-MII not an EPIA-M.