Jump to content

DSDT disass+compile: newest iASLme / IASL :, Juli 11th 2012

mitch_de

By mitch_de,
in Guides

 Share
265 posts in this topic

Recommended Posts

Monkey D. Luffy
Monkey D. Luffy
Posted
Posted

Thanks mitch_de for the update. My dsdt was already clean and fixed before trying the updated version of your iasl. I just tried it because I'm not doing anything right now and decided to give it a shot. To my surprise, I got 19 errors using your iasl manually. So I tried iaslme and it still had 19 errors. I tried DSDTSE 1.4.3 and there are no errors or warnings. Does this mean that the newer version of iaslme reports errors more accurately? BTW, I always try your new iasl/iaslme versions and the older ones never gives me errors. Its just this new one that gave me these errors. I just need clarification before fixing these 19 errors.

 

Thanks! :)

 

Updated to newest version ;)
Link to comment
Share on other sites
mitch_de
mitch_de
Posted
  • Author
Posted

Indeed there are some changes in IASL :

/Users/ami/Desktop/dsdt.dsl 2910: Name (_ADR, Zero)

Error 4080 - Invalid object type for reserved name, must be ^ (Integer)

 

/Users/ami/Desktop/dsdt.dsl 2921: Name (_ADR, One)

Error 4080 - Invalid object type for reserved name, must be ^ (Integer)

 

That replacements 0 to ZERO 1 to ONE seems to make problems. I think that before made replacements (by IASL itself, optimised!) are now

against some ACPI definitions / IASL checks code more intensive.

 

After changing premade optimisations back, i get:

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 32 Optimizations

 

All done.

Enjoy ...

 

But using that .aml as source for disassembling , you get back all of that errors when you use that .dsl again for compiling.

 

Perhaps we must use an commandline switch to avoid those opzimisations ( ADR, 0) > (ADR, Zero) .

 

I added last version of iASLme again to the downloads.

Link to comment
Share on other sites
Monkey D. Luffy
Monkey D. Luffy
Posted
Posted

Thanks for the tip, it worked.

 

Now I get:

 

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 51 Optimizations

 

On an interesting side note, I just tried this without thinking of the output, I tried changing ALL occurrences of "One" to "1" and changed ALL occurrences of "Zero" to "0" of my whole dsdt.dsl file, then I compilation reported this:

 

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 498 Optimizations

 

Then I tried using the DSDT.aml of the 498 Optimizations and it seems working, boots fine. Since it is booting fine, and functions seems ok. Is it a bad idea replacing all occurrences of One and Zero? We'll right now I'm still using the DSDT.aml that the 51 Optimization output just to be safe.

 

Thanks you!

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
  • Author
Posted

Yep that works !

But lots of the optimisations (from the 498) are that 0 > Zero , 1 > One.

If you use your (no errors) .aml as input for iASLme (newest) and disassemble it to .dsl and try to recompile you will get again those Zero / One errors :(

Link to comment
Share on other sites
Monkey D. Luffy
Monkey D. Luffy
Posted
Posted

Yup, it still does get the errors after disassembling then recompiling. I then tried this also with my other .aml (51 Optimization) and disassembled, then recompiled the dsl and it still got 19 errors afterward. I noticed that the errors, just like what you said, is about the Zero and One except that it is the other way around.

 

I just used the older version and its now fine :P

 

Thanks for your great work!

 

Yep that works !

But lots of the optimisations (from the 498) are that 0 > Zero , 1 > One.

If you use your (no errors) .aml as input for iASLme (newest) and disassemble it to .dsl and try to recompile you will get again those Zero / One errors :)

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted

@Mitch,

 

Please read this: 

There is a bug in the latest release(20100304).  Would you please apply this patch or use the old release?

diff --git a/compiler/aslpredef.c b/compiler/aslpredef.c
index 04cd2d4..30d33d5 100644
--- a/compiler/aslpredef.c
+++ b/compiler/aslpredef.c
@@ -535,6 +535,9 @@ ApCheckObjectType (
    switch (Op->Asl.ParseOpcode)
    {
    case PARSEOP_INTEGER:
+    case PARSEOP_ZERO:
+    case PARSEOP_ONE:
+    case PARSEOP_ONES:
        ReturnBtype = ACPI_RTYPE_INTEGER;
        break;

---
Lin Ming

Which was addressed to me, but you should know about it so here it is :)

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
  • Author
Posted

THANKS Master Chief for the solution for the new compiler problem with optimzed .dsl code.

I made the changes reported to fix the ONE, Zero .. problems.

 

"Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 11 Optimizations

All done.

Enjoy ...

 

Happy compiling with the newest iASLme again !

Uploaded that fixed march edition !

Link to comment
Share on other sites
Bungo
Bungo
Posted
Posted

Hi mitch_de,

 

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
		})
	}

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
Hi mitch_de,

 

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
		})
	}

And what exactly is FN00? Please attach your DSDT.dsl so that I can have a look at it. Thanks.

Link to comment
Share on other sites
Smith@@™
Smith@@™
Posted
Posted

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

Link to comment
Share on other sites
KariNeko
KariNeko
Posted
Posted

I'm having the same problem

/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
					})

Link to comment
Share on other sites
Guest BuxB
Guest BuxB
Posted
Posted

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.

Link to comment
Share on other sites
THe KiNG
THe KiNG
Posted
Posted

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

Link to comment
Share on other sites
Guest BuxB
Guest BuxB
Posted
Posted

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.

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
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...

This is a regression for which a patch was made available, here even, and thus this should no longer be an issue.

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
  • Author
Posted
Running the new iasl on 10.5.8 gives the error:

dyld: unknown required load command 0x80000022
Trace/BPT trap

Here's a discussion on the problem:

http://discussions.apple.com/thread.jspa?threadID=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

Link to comment
Share on other sites
Onixs
Onixs
Posted
Posted
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

 

Using chocolate kernel, it gives me an error regarding arch.

Can you compile it to be 32Bit compatible...Thanks

Link to comment
Share on other sites
THe KiNG
THe KiNG
Posted
Posted
This is a regression for which a patch was made available, here even, and thus this should no longer be an issue.

Yes I saw that, but Reserved Name bug is not fixed...

 

/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)

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
Yes I saw that, but Reserved Name bug is not fixed...

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.

Link to comment
Share on other sites
tamorgen
tamorgen
Posted
Posted
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.

 

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.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...