Contribute
Register

Native DSDT/AML IDE & Compiler: MaciASL Open Beta

Status
Not open for further replies.
This could easily have been posted as an issue months ago, considering I already perform this for DSDTs. See below for the resolution.

I mentioned this previously. Not on this thread, but elsewhere (modhouse).

Tablesets are immutable by design, and I can see no point in recompiling a patched AML originally taken from a one. Surely users requesting patches send their tablesets to a patcher, who then examines and tries patching the tables? What would someone do afterwards with a patched AML while not on the machine it came from?

It is often necessary to apply additional patches to a patched AML to make further corrections for issues not originally contemplated. As mentioned, in AMLs with complex relationships, this is not possible because of the inaccuracy of standalone disassembly. The only way to deal with this using tablesets is to always go back to the original tableset and apply all patches previously used to each file in addition to the new ones (cumbersome). Saving the .dsl files and treating them as source code (which they are) is a better strategy.

With my own setups, I use an automated process, arguably more developer oriented, using patchmatic and make. For an example, see: https://github.com/RehabMan/Lenovo-U430-Touch-DSDT-Patch

This is bad practice for several reasons, which I mentioned.

We have a difference of opinion here. I'll leave it at that.
 
Hey sj_underwater !

First of all thanks for the fast patching!
Now I am able to apply any patch but my DSDT gives much more errors then before.

Even my fixed DSDT has about 48 errors of the same type "object does not exist" which weren´t there before!

Is this still a bug of maciasl or is my dsdt pretty messed up?

Ciao
 

Attachments

  • Untitled.tiff
    284.2 KB · Views: 166
Hey sj_underwater !

First of all thanks for the fast patching!
Now I am able to apply any patch but my DSDT gives much more errors then before.

Even my fixed DSDT has about 48 errors of the same type "object does not exist" which weren´t there before!

Is this still a bug of maciasl or is my dsdt pretty messed up?

Ciao

Use the previous version of MaciASL, but remove the comment pointed out in post #249 (and all others like it).
 
Since the patch does not apply to MaciASL, it has been moved to http://www.tonymacx86.com/mavericks...-7x37-clover-install-guide-26.html#post832916 Please keep this thread on-topic, that includes issues which only affect MaciASL as-shipped.

The development branch has been pushed, from work completed last weekend. Any new issues should be tracked against that branch, and reported here. development will eventually merge on to master as v1.4
I mentioned this previously. Not on this thread, but elsewhere.
If you're talking about your mention ~20 days ago, that's not what I mean, considering you were unaware of external resolution in MaciASL until I pointed it out, instead running iASL directly. There is a huge gap developing whereby you're maintaining a diverging downstream product while not contributing upstream or notifying me proactively of issues, sending users my way without explanation. If you're counseling users against my advice to use DSLs, generated with a version of iASL I don't ship (and therefore don't support, at least implicitly), on a downstream product (which I certainly don't support), but still apply my commits to your source, you have a responsibility to keep track of those changes. If you identify an issue which exists in MaciASL, then post it here.
It is often necessary to apply additional patches to a patched AML to make further corrections for issues not originally contemplated. As mentioned, in AMLs with complex relationships, this is not possible because of the inaccuracy of standalone disassembly. The only way to deal with this using tablesets is to always go back to the original tableset and apply all patches previously used to each file in addition to the new ones (cumbersome). Saving the .dsl files and treating them as source code (which they are) is a better strategy.
I noticed you didn't answer my question. Why is this happening, why are you re-patching a patched file? If you're using a "source code" strategy, that strongly implies exactly what I was saying: the tableset and patches are the "source", the patched AML is the "binary".
With my own setups, I use an automated process, arguably more developer oriented, using patchmatic and make. For an example, see: https://github.com/RehabMan/Lenovo-U430-Touch-DSDT-Patch
Developers use IDEs, consumers use automated solutions.
 
Since the patch does not apply to MaciASL, it has been moved to http://www.tonymacx86.com/mavericks...-7x37-clover-install-guide-26.html#post832916 Please keep this thread on-topic, that includes issues which only affect MaciASL as-shipped.

It was clearly directly related to the use of MaciASL with newer iasl, but whatever, this is your thread.

The development branch has been pushed, from work completed last weekend. Any new issues should be tracked against that branch, and reported here. development will eventually merge on to master as v1.4

I had issues with this version, in particular the isInjected code, which crashed when opening standalone files. I replaced it with:
Code:
+(NSString *)isInjected:(NSURL *)url {
    //return [[self.tableset allKeysForObject:[NSData dataWithContentsOfURL:url]] objectAtIndex:0];
    if (!self.tableset)
        return nil;
    NSArray* allkeys = [self.tableset allKeysForObject:[NSData dataWithContentsOfURL:url]];
    if (!allkeys || ![allkeys count])
        return nil;
    return [allkeys objectAtIndex:0];
}

I'm sure the above can be "simplified" somewhat by taking advantage of the fact that you can send messages to nil, but I'm no Obj-C expert so I didn't attempt any such "optimization."

BTW, is there anything in particular you'd like testing to focus on with this new version in the 'development' branch?

If you're talking about your mention ~20 days ago, that's not what I mean, considering you were unaware of external resolution in MaciASL until I pointed it out, instead running iASL directly.

You said I never notified you of the deficiency with regard to external resolution with SSDTs. I was just pointing out that, in fact, I had notified you and therefore your characterization that I'm not reporting issues as discovered is incorrect.

I'm still running iasl directly and have no plans to start using MaciASL tablesets instead.

There is a huge gap developing whereby you're maintaining a diverging downstream product while not contributing upstream or notifying me proactively of issues, sending users my way without explanation.

There is no "huge gap." Look at a diffmerge of the projects and you'll see the differences are almost entirely a result of PATCHMATIC ifdef.

I do not feel it is my responsibility to report bugs to you that other users experience while using MaciASL. That responsibility falls squarely on them and becomes an issue between you and that user, including whether they provide adequate explanation of the problem.

When I report issues to you, I usually spend considerable time investigating and reducing the repro case. Evidently you do not appreciate this. I do not have the time to do that for every issue each user might discover. It is unreasonable for you to expect me to serve as conduit for all bugs discovered by users that I might come in contact with during the process of helping them.

If you're counseling users against my advice to use DSLs, generated with a version of iASL I don't ship (and therefore don't support, at least implicitly), on a downstream product (which I certainly don't support), but still apply my commits to your source, you have a responsibility to keep track of those changes. If you identify an issue which exists in MaciASL, then post it here.

Since MaciASL provides a file association for .DSL, it should be able to open and manipulate any DSL file regardless of how the file was generated. This includes new versions of iasl, as you can't be certain users of MaciASL are not using the tool in ways not according to your personal preferences/practices.

I regularly update my fork of the Intel iasl repo, as there are useful fixes there.

I noticed you didn't answer my question. Why is this happening, why are you re-patching a patched file?

Your question was not relevant to the issue being discussed. As I tried to explain, it is common to apply one patch during the development of a "patch set" for a given computer, only to discover additional patches to the same file are later required. It is for this reason that I use a "source code" strategy where such patches are applied only DSL files and built into AML for testing. This avoids later secondary disassembly, which as you know, is not reliable without the other files in the table set as reference.

If you're using a "source code" strategy, that strongly implies exactly what I was saying: the tableset and patches are the "source", the patched AML is the "binary".

Using the tableset requires all patches to be applied at once. This is cumbersome, time consuming, and error prone. It is why I use patchmatic and make to automate the process. I would never consider using MaciASL tablesets during the the development process.

Developers use IDEs, consumers use automated solutions.

I'm a developer. I use a combination of IDEs *and* automated solutions such as make or shell scripts. IDEs are not the best tools for all development tasks. I use the most appropriate tools to accomplish the given task. I suspect you do too.

MaciASL is a great tool but I don't find it adequate, by itself, for end-to-end development of complex ACPI patches and prefer to use a mix-n-match approach as it fits my needs.
 
Hey everyone!

It seems I came across a bug in MaciASL (or rather the patcher part of it) that prevents applying a patch to my extracted DSDT. When the decompiler adds comments for buffers and the hex-values correspond to the character "}" it can cause trouble. You can replicate the issue with the following two snippets:

The B1B2 and B1B4 method patches from the battery status guide:
Code:
into method label B1B2 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B2, 2, NotSerialized) { Return(Or(Arg0, ShiftLeft(Arg1, 8))) }\n
end;

into method label B1B4 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B4, 4, NotSerialized)\n
{\n
    Store(Arg3, Local0)\n
    Or(Arg2, ShiftLeft(Local0, 8), Local0)\n
    Or(Arg1, ShiftLeft(Local0, 8), Local0)\n
    Or(Arg0, ShiftLeft(Local0, 8), Local0)\n
    Return(Local0)\n
}\n
end;

An offending DSDT snippet:
Code:
DefinitionBlock ("DSDT.aml", "DSDT", 2, "OEMID  ", "TableID ", 0x00000000)
{
    Scope (_SC)
    {
        Device (DEV1)
        {
            Name (BUFF, Buffer (0x000A)
            {
                /* 0000 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /* ...}.... */
                /* 0008 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /* ...}.... */
                /* 0010 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00   /* ...}.... */
            })
        }
    }
}

When the patch is applied to the DSDT snippet, you will notice that the methods are inserted into the buffer. When the "}" characters are removed from the comments, the patch works as expected. I also tried to write a workaround-patch, but it seems impossible to match the "}" character inside the comments using the patcher grammar.

Regards
herrritschwumm
 
Hey everyone!

It seems I came across a bug in MaciASL (or rather the patcher part of it) that prevents applying a patch to my extracted DSDT. When the decompiler adds comments for buffers and the hex-values correspond to the character "}" it can cause trouble. You can replicate the issue with the following two snippets:

The B1B2 and B1B4 method patches from the battery status guide:
Code:
into method label B1B2 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B2, 2, NotSerialized) { Return(Or(Arg0, ShiftLeft(Arg1, 8))) }\n
end;

into method label B1B4 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B4, 4, NotSerialized)\n
{\n
    Store(Arg3, Local0)\n
    Or(Arg2, ShiftLeft(Local0, 8), Local0)\n
    Or(Arg1, ShiftLeft(Local0, 8), Local0)\n
    Or(Arg0, ShiftLeft(Local0, 8), Local0)\n
    Return(Local0)\n
}\n
end;

An offending DSDT snippet:
Code:
DefinitionBlock ("DSDT.aml", "DSDT", 2, "OEMID  ", "TableID ", 0x00000000)
{
    Scope (_SC)
    {
        Device (DEV1)
        {
            Name (BUFF, Buffer (0x000A)
            {
                /* 0000 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /* ...}.... */
                /* 0008 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /* ...}.... */
                /* 0010 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00   /* ...}.... */
            })
        }
    }
}

When the patch is applied to the DSDT snippet, you will notice that the methods are inserted into the buffer. When the "}" characters are removed from the comments, the patch works as expected. I also tried to write a workaround-patch, but it seems impossible to match the "}" character inside the comments using the patcher grammar.

Regards
herrritschwumm

Use a version of iasl that doesn't have that "feature"...

See here: http://www.tonymacx86.com/yosemite-laptop-support/152573-guide-patching-laptop-dsdt-ssdts.html
 
Or you can simply do a better job at making that patch.

Not sure what you mean. The bug is in MaciASL, not my patch.
 
I come across bug when patching my dsdt

when i triedto apply GFX rename patch on my dsdt,maciasl could't match anything.
Later I try patchmatic and I got errors.:crazy:
2.jpg

Here are my dsdt and patch from Rehabman.
View attachment files.zip
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top