DSDT/AML/Etc Inspiron 5748

[Moore, Robert]

Sounds like a good time to post our summary of the "external control method" problem. (To be solved by the External AML opcode in ACPI 6.0)



Summary of the external control method problem:

When the -e option is used with disassembly, the various SSDTs are simply
loaded into a global namespace for the disassembler to use in order to
resolve control method references (invocations).

The disassembler tracks any such references, and will emit an External()
statement for these types of methods, with the proper number of arguments .

Without the SSDTs, the AML does not contain enough information to properly
disassemble the control method invocation -- because the disassembler does
not know how many arguments to parse.

An example: Assume we have two control methods. ABCD has one argument, and
EFGH has zero arguments. Further, we have two additional control methods
that invoke ABCD and EFGH, named T1 and T2:

    Method (ABCD, 1)
    {
    }
    Method (EFGH, 0)
    {
    }
    Method (T1)
    {
        ABCD (Add (2, 7, Local0))
    }
    Method (T2)
    {
        EFGH ()
        Add (2, 7, Local0)
    }

Here is the AML code that is generated for T1 and T2:

     185:      Method (T1)

0000034C:  14 10 54 31 5F 5F 00 ...    "..T1__."

     186:      {
     187:          ABCD (Add (2, 7, Local0))

00000353:  41 42 43 44 ............    "ABCD"
00000357:  72 0A 02 0A 07 60 ......    "r....`"

     188:      }

     190:      Method (T2)

0000035D:  14 10 54 32 5F 5F 00 ...    "..T2__."

     191:      {
     192:          EFGH ()

00000364:  45 46 47 48 ............    "EFGH"

     193:          Add (2, 7, Local0)

00000368:  72 0A 02 0A 07 60 ......    "r....`"
     194:      }

Note that the AML code for T1 and T2 is essentially identical. When
disassembling this code, the methods ABCD and EFGH must be known to the
disassembler, otherwise it does not know how to handle the method invocations.

In other words, if ABCD and EFGH are actually external control methods
appearing in an SSDT, the disassembler does not know what to do unless
the owning SSDT has been loaded via the -e option.




> -----Original Message-----
> From: Jung-uk Kim [mailto:jkim at FreeBSD.org]
> Sent: Wednesday, March 02, 2016 9:04 AM
> To: Larry Rosenman; freebsd-acpi at freebsd.org
> Cc: Box, David E; Moore, Robert
> Subject: Re: DSDT/AML/Etc Inspiron 5748
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 03/ 2/16 10:11 AM, Moore, Robert wrote:
> > This is probably because of external references that cannot be
> > resolved.
> >
> > Try : iasl -e ssdt* -d dsdt.dat
> 
> Please note it is /usr/local/bin/iasl (i.e., sysutils/acpica-tools from
> the ports tree), not /usr/sbin/iasl from the base.
> 
> Jung-uk Kim
> 
> >> -----Original Message----- From: owner-freebsd-acpi at freebsd.org
> >> [mailto:owner-freebsd- acpi at freebsd.org] On Behalf Of Larry Rosenman
> >> Sent: Tuesday, March 01, 2016 3:57 PM To:
> >> freebsd-acpi at freebsd.org Subject: DSDT/AML/Etc Inspiron 5748
> >>
> >> I have a Dell Inspiron 5748, and it's DSDT has the mouse (0x66) in
> >> the keyboard resources.
> >>
> >> I was trying to recompile it, but even dumping the DSDT and
> >> recompiling it with no changes garners syntax errors from iasl.
> >>
> >> I've posted the DSDT at:
> >> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl
> >>
> >> and the errors:
> >> http://www.lerctr.org/~ler/FreeBSD/acpi/my.asl.err
> >>
> >> Can someone help me?
> >>
> >> System is at:
> >>
> >> FreeBSD trivet 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r296241: Mon Feb
> >> 29 18:02:55 CST 2016 root at trivet:/usr/obj/usr/src/sys/GENERIC  amd64
> >> 1100100
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJW1x0YAAoJEHyflib82/FGERAH+wagXCh2KTFmoTB7UfON1r19
> 6FkMEyZBvJxPG5SPQ/NpUgk/TQvCt7ta911xavVGH5xOgCajPgbjZ1VRJ8Bb6L5h
> sdgBSZSbfELXSKIlPjUJEOuCnSj2/rFVkxrtC7S09khCEdJrsV5diAx/8I+rCqeC
> 8+ZIpOqLWrBcHtdzLusAcglxBQdbuLqo1ZKOgAohRQtq/Z7qt1t0c2IqpcsDfM7+
> 87cuUAt4XUAqIpff54msm13Dpw8cqm2ujXzA7xT30+8jev75T80qabjH2oK3kdml
> fXnULEKql+M4eYLvOnIOLbfo8LXK861uqHQVwTjWQzJNm5cMH+H4e2azrW/DpE8=
> =9HhI
> -----END PGP SIGNATURE-----