Skip to contentSkip to conversation

Aspire 1511LMI - Aspire 1513LMI DSDT

DISCUSSION giupil 2 participants 4 messages Nov 19, 2004 – Nov 22, 2004 3 messages not in the archive ACPI

lore
Share & tools
lore

giupil

author
#0 lore raw

Hi,

I've an Acer Aspire 1513lmi; this notebook is a 1511lmi + AMD Athlon 64 Processor 3400+ and their DSDTs are identical. I've followed the threads about the 1511lmi and I found the Christian Casteyde DSDT and his suggestions in:

http://casteyde.christian.free.fr/laptop/LinuxOnAspire1511LMi.html

and the DSDT in:

http://acpi.sourceforge.net/dsdt/tables/ACER/Aspire_1513LMi/ACER-Aspire_1513LMi-unknown_bios-custom.asl.gz

and these work fine on my system.

My system is a dual boot system Gentoo-64 + Freebsd-64 (5.3 installation) and then the DSDT problem is also a Freebsd problem.
In Freebsd the better way to obtain the DSDT is the acpidump solution and this DSDT is just like the DSDT that I obtained by my Linux system, except for some initial notes, for the file tail, and a error that the Freebsd iasl and
http://acpi.sourceforge.net/dsdt/tables/ACER/Aspire_1513LMi/ACER-Aspire_1513LMi-unknown_bios-custom.asl.gz signal but the iasl in Linux doesn't signal.

The Linux DSDT tail is:

.
.
.
Name (FWSO, "FWSO")
}

The Freebsd DSDT tail is:

.
.
.
Name (FWSO, "FWSO")
Scope (\_PR.CPU0)

   {
       Name (_PCT, Package (0x02)
       {
           ResourceTemplate ()
           {
               Register (FFixedHW, 0x00, 0x00, 0x0000000000000000)
           },

           ResourceTemplate ()
           {
               Register (FFixedHW, 0x00, 0x00, 0x0000000000000000)
           }
       })
       Name (_PSS, Package (0x04)
       {
           Package (0x06)
           {
               0x00000898,
               0x00013E5C,
               0x00000064,
               0x00000009,
               0xE020288E,
               0x0000008E
           },

           Package (0x06)
           {
               0x000007D0,
               0x0000FA00,
               0x00000064,
               0x00000009,
               0xE020298C,
               0x0000018C
           },

           Package (0x06)
           {
               0x00000708,
               0x0000B798,
               0x00000064,
               0x00000009,
               0xE0202A8A,
               0x0000028A
           },

           Package (0x06)
           {
               0x00000320,
               0x00004A38,
               0x00000064,
               0x00000009,
               0xE0202C80,
               0x00000480
           }
       })
       Name (_PPC, 0x00)

}
}

I'm not a acpi-asl expert, but this excerpt, I think, defines the cpu object. There are three subobjects:

the _PCT interface, the _PSS declaration about the performance states and the _PPC method, and they make clear the file part:

   Scope (\_PR)
   {
       Processor (CPU0, 0x00, 0x00008010, 0x06) {}
   }

The only part that, I think, is strange in this excerpt is "Name (_PPC, 0x00)", because _PPC is a method and its definition form, in general, is:

Method (_PPC, ...)

{
.
.
}

but here, _PPC has an objectname form.

Anyway in the Freebsd DSDT, the only necessary changes are:

3975,3980d3974
<
< Return (Package (0x02) <------ #### This additional lines are absent in the Casteyde DSDT
< {
#### and I obtained its solution by
the DSDT for
< Zero,

                             #### 1513lmi in:
<                             Zero           
                              #### 
http://acpi.sourceforge.net/dsdt/tables/ACER/-
<                         })               
                                  #### 

ACER-Aspire_1513LMi-unknown_bios-custom.asl.gz
5163,5164c5157,5158 #### at the line 3893.
< 0x00,
#### Note that the iasl decompiler,
in Linux, doesn't
< 0x00,
#### signals this error, but the
Freebsd one signals it.
--- > Z005,

Quoted 1 line
                Z005,

5456d5449
< Return(Package(0x02){0x00, 0x00})

Note that the Freebsd DSDT is longer that the Linux DSDT because the first one has some initial notes. The Freebsd DSDT tail can't be added to the Linux DSDT, because the Linux system doesn't boot with this.

I don't know why the Freebsd DSDT is so different, but peraphs someone can use this excerpt to improve the DSDT corrections.
I can add that these corrections work in the Freebsd system, and the error signals disappear with the corrected DSDT, but
I can't know if the acpi system work fine with Freebsd, because the Freebsd S.O. doesn't implement
the powernow-k8 functionalities.
Peraphs this Freebsd DSDT tail is only an external (this is strange because the AML decompilers don't print the externals), and in fact the powenow-k8 functionalities for the frequencies 2200000 (0x00000898), 2000000 (0x000007D0), 1800000 (0x00000708), 800000 ( 0x00000320) are correctly recognized by Linux, and then this tail isn't
necessary.

About the error that the Freebsd iasl (and the http://acpi.sourceforge.net/dsdt/tables/ACER/Aspire_1513LMi/-
ACER-Aspire_1513LMi-unknown_bios-custom.asl.gz) signals and the Linux iasl (and Casteyde for 1511lmi) doesn't signal, I add this comment that I found in http://www.cpqlinux.com/acpi-howto.html:

.
.
.
Note: It may be possible to use iasl with the -d option to dump your table to .asl as well; however, one guy at the acpica ML who showed me this had the following to say:

"I have not checked actually if iasl is 'good' in order to disable the AML. It is a new feature, so that it has perhaps some bugs. I can not be sure.

Using pacpidump should be OK, but the version you point was updated, debugged, etc. under FreeBSD, and those changes are present only under FBSD, not the one you pointed."
.
.
.

Then I think that the acpidump command and iasl command in Freebsd works better that in Linux and that the freebsd error signals are, peraphs, more correct.

Sorry for my english, it's terrible, I know!

Bye Giuseppe

-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 3 lines · giupil

Then I think that the acpidump command and iasl command in Freebsd works better that in Linux and that the freebsd error signals are, peraphs, more correct.

iasl is the same for both Linux and FreeBSD and is develloped and maintained by Intel people. acpidump from FreeBSD is now a wrapper to iasl.

What produce FreeBSD acpidump is not only the decompiled DSDT, but also the differents SSDTs if those are presents. Under FreeBSD, when a table is overriden, no further SSDT will be loaded by the OS, whereas SSDTs will be loaded under Linux.

If you take the pmtools packages, then :
./acpidmp SSDT > ssdt
iasl -d ssdt

will produce the difference (the objects for the processor) you have.

Signature · 11 lines
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#4 lore raw

Hi Bruno,

I'm sorry for my ignorance, I'm not a expert. I'm very gratefull for your notes. The only problem that still remains in my mind is:

In

http://acpi.sourceforge.net/dsdt/tables/ACER/Aspire_1513LMi/-
ACER-Aspire_1513LMi-unknown_bios-custom.asl.gz

at the line 3893 of the ACER-Aspire_1513LMi-unknown_bios-custom.dsl
decompiled file, I
find:

                   Return (Package (0x02)
                   {
                           Zero,
                           Zero
                    })

but at the
http://casteyde.christian.free.fr/laptop/LinuxOnAspire1511LMi.html in the
dsdt_asp1511.asl at the line 3895, I find:

                   Return (0x00)

These corrections are about the warnig:

mydsdt_orig.dsl 3865: Method (DRUL, 1,
NotSerialized)
Warning 2019 - ^ Not all control paths
return a value (DRUL)

Is there anyone who know the difference between the two solutions and which is the better solution?

Bye Giuseppe

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/

A message that is not in the archive (sent off-list or not yet received): [email protected]

#6 lore raw
Quoted 26 lines · giupil

Hi Bruno,

I'm sorry for my ignorance, I'm not a expert. I'm very gratefull for your notes.
The only problem that still remains in my mind is:

In

http://acpi.sourceforge.net/dsdt/tables/ACER/Aspire_1513LMi/-
ACER-Aspire_1513LMi-unknown_bios-custom.asl.gz

at the line 3893 of the ACER-Aspire_1513LMi-unknown_bios-custom.dsl
decompiled file, I
find:

                   Return (Package (0x02)
                   {
                           Zero,
                           Zero
                    })

but at the
http://casteyde.christian.free.fr/laptop/LinuxOnAspire1511LMi.html in the
dsdt_asp1511.asl at the line 3895, I find:

Quoted 8 lines
                   Return (0x00)

These corrections are about the warnig:

mydsdt_orig.dsl 3865: Method (DRUL, 1,
NotSerialized)
Warning 2019 - ^ Not all control paths
return a value (DRUL)

The other paths return an integer, and this is not a reserved method. So return an integer ;)

I would buy for 'Return (0)', but anyway I will not care for this at all, since it's called only in order to query a VGA change via probably a hotkey at first read (via a _Q?? method), and there is nothing to verify the return values anyway in the AML.

Signature · 11 lines
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/