DSDT Extraction

[Morgan Reed]

Hi all,

As an aside to my earlier question, I'm currently looking at the
Advanced ACPI stuff (i.e. pulling in the DSDT from the original BIOS).

I've extracted the DSDT using the instructions from the wiki, i.e. cat
/proc/acpi/dsdt > dsdt; iasl -d dsdt; iasl -tc dsdt.dsl;

Initially there are a few errors thrown by the compiler which I had to
fix. Now, when I replace coreboot-v2/src/mainboard/via/epia-m/dsdt.c
with it I get linker errors (section <section> [<fromaddr>-<toaddr>]
overlaps section <section> [<fromaddr>-<toaddr>]), I expect this is to
do with the DSDT from coreboot being ~1kB and the one from the dump
being ~12kB.

Anybody have any suggestions?

Oh and a side note, with regards to the DSDT stuff, I believe we can
get around the Intellectual Property issues involved in shipping a
"real" DSDT (rather than the default minimalist version) if we have
one person disassemble the DSDT from the BIOS in question, write a
spec and then give it to somebody else to implement in ASL (Chinese
walls) though I'm unsure of the practicalities/logistics involved in
doing this (That and IANAL).

Thanks,

Morgan

[Stefan Reinauer]

On 07.06.2009 15:47 Uhr, Morgan Reed wrote:
> Hi all,
>  As an aside to my earlier question, I'm currently looking at the
>
> Advanced ACPI stuff (i.e. pulling in the DSDT from the original BIOS).
>
> I've extracted the DSDT using the instructions from the wiki, i.e. cat
> /proc/acpi/dsdt > dsdt; iasl -d dsdt; iasl -tc dsdt.dsl;

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
> Initially there are a few errors thrown by the compiler which I had to
> fix. Now, when I replace coreboot-v2/src/mainboard/via/epia-m/dsdt.c
> with it I get linker errors (section <section> [<fromaddr>-<toaddr>]
> overlaps section <section> [<fromaddr>-<toaddr>]), I expect this is to
> do with the DSDT from coreboot being ~1kB and the one from the dump
> being ~12kB.
>
> Anybody have any suggestions?

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.

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?

Best regards,

Stefan

[Morgan Reed]

Just realised I omitted to CC the list.

On Mon, Jun 8, 2009 at 09:12, Stefan Reinauer 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.