DSDT/AML/Etc Inspiron 5748

[Larry Rosenman]

On 2016-03-02 20:32, Larry Rosenman wrote:
> On Wed, Mar 02, 2016 at 08:16:16PM -0600, Larry Rosenman wrote:
>> Thanks, David!
>> 
>> I removed the entries from PS2K for 0x66, and now my mouse works.
>> 
>> I'll attach what I loaded.
>> 
>> 
>> On Thu, Mar 03, 2016 at 01:47:50AM +0000, Box, David E wrote:
>> > Concerning the recompiling of disassembled AML code, do heed any warnings that show up at the top of the output file. In any case , 100% correct disassembly of AML code is not guaranteed and you recompile and override your system at your own risk.
>> >
>> > That said, I've attached a "fixed" dsdt.dsl and the accompanying reference file that helped generate it. By "fixed" I mean it will compile without error. I can't speak to the component that you want to change. But this should get you farther along. Be aware that there could be portions that disassembled incorrectly but still produced valid syntax. What follows is a description of the problem and how it was fixed.
>> >
>> > There were a couple of issues with your dump. If you do a diff on the attached tables and the originals, you'll see what was changed. In dsdt.dsl there were two issues preventing recompile. First, the external method MDBG was incorrectly identified as an integer. This was fixed using the attached refs.txt file and the command:
>> >
>> > 	iasl -da -ve -fe refs.txt dsdt.dat ssdt*.dat
>> >
>> > The refs.txt file tells the compiler the correct type (and if applicable argument count) for external objects. The above tables come from the command, acpixtract -a acpidump.txt.
>> >
>> > Secondly, the AML was packed with a bunch of 0's between two Devices. I've seen this before. It's likely an artifact of the way the table is generated on your system (e.g. space reserved for a device that doesn't exist on your particular platform?). I removed those dangling zeroes. After that, it could compile without error.
>> >
>> > Your ssdt2 table also had what was likely a table generation artifact. If you look at _PSS, there is a package of packages list that contained 29 items, but the BIOS only setup information for the first 13 (0xD) of them and set the package length accordingly. The rest were left hanging off the end causing the error. You can see they had what looks like default values. Removing those dangling packages fixed it.
>> >
>> > Hope this helps.
>> >
>> > David
>> 
>> --
>> Larry Rosenman                     http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640                 E-Mail: ler at lerctr.org
>> US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
> 
> I'm now seeing the following:
> 
> cryptosoft0: <software crypto> on motherboard
> aesni0: <AES-CBC,AES-XTS,AES-GCM,AES-ICM> on motherboard
> acpi0: <DELL WN09   > on motherboard
> ACPI Error: [^PCI0.GFX0.DSLP] Namespace lookup failure, AE_NOT_FOUND
> (20150818/psargs-391)
> ACPI Error: Method parse/execution failed [\134_SB._INI] (Node
> 0xfffff80006bef180), AE_NOT_FOUND (20150818/psparse-558)
> acpi0: Power Button (fixed)
> cpu0: <ACPI CPU> on acpi0
> cpu1: <ACPI CPU> on acpi0
> cpu2: <ACPI CPU> on acpi0
> cpu3: <ACPI CPU> on acpi0

Apparently I'm also missing the stuff for the lid.  I'll see if I can 
figure it out, but any help on what I really need
to compile would be appreciated.

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler at lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961