DSDT disass+compile: newest iASLme / IASL :, Juli 11th 2012
Started by mitch_de, Sep 28 2009 06:15 AM
265 replies to this topic
#61
Posted 09 March 2010 - 09:37 PM
Thanks Master Chief, cVaD & mitch_de for the updated and working version.
#62
Posted 09 March 2010 - 11:50 PM
Thanks Master Chief, Cvad, mitch_de .. new version works like a charm
#63
Posted 12 March 2010 - 02:38 PM
Thanks for the updates. I just tried your iASLMe_fixed_march_2010 version and got this error:
Name (_PR0, Package (One) Invalid object type for reserved name, must be ^ (Package)I never got it before with your previous versions of iASLMe.
Here is original code where error was found:
Device (FAN0)
{
Name (_HID, EisaId ("PNP0C0B"))
Name (_UID, Zero)
Name (_PR0, Package (One)
{
FN00
})
}
#64
Posted 14 March 2010 - 08:59 AM
Running the new iasl on 10.5.8 gives the error:
http://discussions.a...hreadID=2151112
dyld: unknown required load command 0x80000022 Trace/BPT trapHere's a discussion on the problem:
http://discussions.a...hreadID=2151112
#65
Posted 14 March 2010 - 04:46 PM
Bungo, on Mar 12 2010, 03:38 PM, said:
Hi mitch_de,
Thanks for the updates. I just tried your iASLMe_fixed_march_2010 version and got this error:
Thanks for the updates. I just tried your iASLMe_fixed_march_2010 version and got this error:
Name (_PR0, Package (One) Invalid object type for reserved name, must be ^ (Package)I never got it before with your previous versions of iASLMe. Here is original code where error was found:
Device (FAN0)
{
Name (_HID, EisaId ("PNP0C0B"))
Name (_UID, Zero)
Name (_PR0, Package (One)
{
FN00
})
}
#66
Posted 14 March 2010 - 05:23 PM
The last version "destroys" all my dsdt, this error always:
Invalid object type for reserved name, must be ^
I restore now an old version of iasl and ALL works amazing, same dsdt, nothing error. The problem is SURE last version of iasl, i'm sure
Invalid object type for reserved name, must be ^
I restore now an old version of iasl and ALL works amazing, same dsdt, nothing error. The problem is SURE last version of iasl, i'm sure
#67
Posted 14 March 2010 - 07:54 PM
I'm having the same problem
The section on the DSDT where it came from look like this
/DSDT.test.dsl 5227: Name (_PLD, Buffer (0x10) Error 4080 - Invalid object type for reserved name, must be ^ (Package)
The section on the DSDT where it came from look like this
Name (_PLD, Buffer (0x10)
{
/* 0000 */ 0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/* 0008 */ 0x30, 0x1C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
})
#68
Guest: BuxB_*
Posted 15 March 2010 - 09:27 AM
Guest: BuxB_*
yep, it's good to keep older iASLMe's. The latest working for me is 2009-09-03, tested with several DSDTs from different computers. The question is: is this a Mac OS port or a iasl bug also occurring with the binaries of i.e. Windows.
#69
Posted 15 March 2010 - 01:52 PM
New IASL dosen't like optimized DSDT's.
So if you have Zero instead 0x00 or One instead 0x01 or Ones instead 0xFFFFFFFF and so on it will complain.
Funny is that after all are like it ask it does optimize them back on compile LOL.
Another "bug" is on _XYZ Reserved names, if it dosen't know them it will complain again.
Dunno wtf is wrong, or the source is borked or they are going backwards...
BTW if you compile it the decompile and try again you are back with same errors ROFL
So if you have Zero instead 0x00 or One instead 0x01 or Ones instead 0xFFFFFFFF and so on it will complain.
Funny is that after all are like it ask it does optimize them back on compile LOL.
Another "bug" is on _XYZ Reserved names, if it dosen't know them it will complain again.
Dunno wtf is wrong, or the source is borked or they are going backwards...
BTW if you compile it the decompile and try again you are back with same errors ROFL
#70
Guest: BuxB_*
Posted 16 March 2010 - 07:15 AM
Guest: BuxB_*
OK KiNG thx for the analysis! Even @ Intel it's all just human BEANS .. 
it's much more important anyways to manually mod one's DSDT i.e. with the great compendium in EvOSX86 DSDT Simple Editor and compile with it into .aml, no matter which iasl is behind it.
it's much more important anyways to manually mod one's DSDT i.e. with the great compendium in EvOSX86 DSDT Simple Editor and compile with it into .aml, no matter which iasl is behind it.
#71
Posted 16 March 2010 - 02:53 PM
THe KiNG, on Mar 15 2010, 02:52 PM, said:
New IASL dosen't like optimized DSDT's. So if you have Zero instead 0x00 or One instead 0x01 or Ones instead 0xFFFFFFFF and so on it will complain...
#72
Posted 16 March 2010 - 10:35 PM
asstastic, on Mar 14 2010, 09:59 AM, said:
Running the new iasl on 10.5.8 gives the error:
http://discussions.a...hreadID=2151112
dyld: unknown required load command 0x80000022 Trace/BPT trapHere's a discussion on the problem:
http://discussions.a...hreadID=2151112
iasl was compiled as an 64 Bit app.
Can your "Mac" run 64 Bit Apps ?
64 Bit CPU + mosty Intel needed, i dont know if it will run on AMD, even they are 64 Bit
#73
Posted 17 March 2010 - 12:54 AM
mitch_de, on Mar 17 2010, 06:35 AM, said:
iasl was compiled as an 64 Bit app.
Can your "Mac" run 64 Bit Apps ?
64 Bit CPU + mosty Intel needed, i dont know if it will run on AMD, even they are 64 Bit
Can your "Mac" run 64 Bit Apps ?
64 Bit CPU + mosty Intel needed, i dont know if it will run on AMD, even they are 64 Bit
Using chocolate kernel, it gives me an error regarding arch.
Can you compile it to be 32Bit compatible...Thanks
#74
Posted 17 March 2010 - 07:48 AM
Master Chief, on Mar 16 2010, 04:53 PM, said:
This is a regression for which a patch was made available, here even, and thus this should no longer be an issue.
Quote
/Users/Me/Desktop/test.dsl 10235: Name (_WDG, Buffer (0x50)
Warning 1099 - Unknown reserved name ^ (_WDG)
/Users/Me/Desktop/test.dsl 11468: Method (_WED, 1, NotSerialized)
Warning 1099 - Unknown reserved name ^ (_WED)
Warning 1099 - Unknown reserved name ^ (_WDG)
/Users/Me/Desktop/test.dsl 11468: Method (_WED, 1, NotSerialized)
Warning 1099 - Unknown reserved name ^ (_WED)
#75
Posted 17 March 2010 - 12:55 PM
THe KiNG, on Mar 17 2010, 08:48 AM, said:
Yes I saw that, but Reserved Name bug is not fixed...
Do you have any other examples [of reserved names] that should be valid? If not then this is not a bug, but a feature [due to stricter checking for typos and other errors].
Thank you.
#76
Posted 17 March 2010 - 05:55 PM
Master Chief, on Mar 17 2010, 01:55 PM, said:
I am currently looking into it and I will make sure that it get fixes when this 'bug' has been confirmed as bug, but both _WED and _WDG are invalid i.e. unknown to the ACPI 4.0 specification and as such not be used.
Do you have any other examples of reserved names that should be valid? If not then this is not a bug, but a feature [stricter checking for typos and other errors].
Thank you.
Do you have any other examples of reserved names that should be valid? If not then this is not a bug, but a feature [stricter checking for typos and other errors].
Thank you.
Master Chief,
I know you are the DSDT guru, so I'm hoping you can answer some questions. No matter what I do, no matter what i use, I cannot get a DSDT to compile. I've tried iASLme, DSDT_patcher, and DSDTSE, and even if all I do is extract, and try to recompile, I get errors.
I have a DSDT that I got from another user that I've been trying to make an edit to. He has the exact same machine, same kexts, but on his laptop, the screen will auto dim when running on battery, mine will not. I found a possible fix, but I cannot get it to compile. Any advise you can give me? I'm getting really frustrated.
Also, I was wondering if the bootloader can cause this sort of behavior? I'm running Chameleon RC5 v112 now. I'm not entirely sure what the other individual is running. He used SnowX86 3.6 to install and doesn't know what bootloader it installed.
#77
Posted 17 March 2010 - 06:56 PM
tamorgen, on Mar 17 2010, 06:55 PM, said:
Master Chief,
I know you are the DSDT guru, so I'm hoping you can answer some questions. No matter what I do, no matter what i use, I cannot get a DSDT to compile. I've tried iASLme, DSDT_patcher, and DSDTSE, and even if all I do is extract, and try to recompile, I get errors.
I have a DSDT that I got from another user that I've been trying to make an edit to. He has the exact same machine, same kexts, but on his laptop, the screen will auto dim when running on battery, mine will not. I found a possible fix, but I cannot get it to compile. Any advise you can give me? I'm getting really frustrated.
Also, I was wondering if the bootloader can cause this sort of behavior? I'm running Chameleon RC5 v112 now. I'm not entirely sure what the other individual is running. He used SnowX86 3.6 to install and doesn't know what bootloader it installed.
I know you are the DSDT guru, so I'm hoping you can answer some questions. No matter what I do, no matter what i use, I cannot get a DSDT to compile. I've tried iASLme, DSDT_patcher, and DSDTSE, and even if all I do is extract, and try to recompile, I get errors.
I have a DSDT that I got from another user that I've been trying to make an edit to. He has the exact same machine, same kexts, but on his laptop, the screen will auto dim when running on battery, mine will not. I found a possible fix, but I cannot get it to compile. Any advise you can give me? I'm getting really frustrated.
Also, I was wondering if the bootloader can cause this sort of behavior? I'm running Chameleon RC5 v112 now. I'm not entirely sure what the other individual is running. He used SnowX86 3.6 to install and doesn't know what bootloader it installed.
#78
Posted 18 March 2010 - 03:58 AM
Master Chief, on Mar 17 2010, 02:55 PM, said:
I am currently looking into it and I will make sure that it get fixed when this 'bug' has been confirmed as bug, but both _WED and _WDG are invalid i.e. unknown to the ACPI 4.0 specification and as such should not be used.
Do you have any other examples [of reserved names] that should be valid? If not then this is not a bug, but a feature [due to stricter checking for typos and other errors].
Thank you.
Do you have any other examples [of reserved names] that should be valid? If not then this is not a bug, but a feature [due to stricter checking for typos and other errors].
Thank you.
I don't care about it since I'm using previous one till Intel will fix own mess.
#80
Posted 20 March 2010 - 09:24 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users



Sign In
Create Account








