Contribute
Register

[Solved] EC _Qxx keys not working on cold boot

Status
Not open for further replies.
RehabMan said:
You will need to decide for yourself whether you need the EC related code to execute or not...
It could be that the code you moved is somehow dependent on being executed within the context of the original _OFF.
Click to expand...
I think I'll just try adding it to a patched _REG and see if I still get that problem.

I have 2 final questions:
1- How will I call original _REG (XREG) code from the new patched _REG?
2- What would be the code to be added to the new/to-be-patched _REG?

This way:
Code: 
Method (_REG, 2, NotSerialized)
{
...
    If (\ECON)
    {
        Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
    }
}

Or:
Code: 
Method (_REG, 2, NotSerialized)
{
...
    If (Arg0 == 3 && Arg1 == 1)
    {
        Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
    }
}

Or:
Code: 
Method (_REG, 2, NotSerialized)
{
...
    If (\ECON && (Arg0 == 3 && Arg1 == 1))
    {
        Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
    }
}

Provided the original code removed from the _OFF method is:
Code: 
...
If (\ECON)
{
    Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
}
...
 
Well, I tried doing it the normal way and copied all original _REG code to the SSDT, and got the same results, still no working _Q11, _Q12 with the _REG code in my SSDT.
I'm attaching my SSDT-NVDA for you to take a look.

EDIT:
So weird... I copied the exact same _REG method into the SSDT and I did not add that code to make the _REG identical to the original one, rebooted, still the same issue...

So I guess the problem is that the modified _REG in the SSDT is not being reached for some reason, that's why when I leave it unrenamed (original _REG==_REG) the problem disappears, any ideas why?

EDIT 2:
Confirmed. The issue turns out to be that the _REG in the SSDT is not being reached or called at all. It's just like renaming the original _REG to XREG and leave it unreplaced in any other SSDT. This is really intereting... Any ideas? xD
 

Attachments

  • SSDT-NVDA.dsl
    3 KB · Views: 89
Last edited:
the-braveknight said:
I think I'll just try adding it to a patched _REG and see if I still get that problem.

I have 2 final questions:
1- How will I call original _REG (XREG) code from the new patched _REG?
2- What would be the code to be added to the new/to-be-patched _REG?

This way:
Code: 
Method (_REG, 2, NotSerialized)
{
...
    If (\ECON)
    {
        Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
    }
}

Or:
Code: 
Method (_REG, 2, NotSerialized)
{
...
    If (Arg0 == 3 && Arg1 == 1)
    {
        Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
    }
}

Or:
Code: 
Method (_REG, 2, NotSerialized)
{
...
    If (\ECON && (Arg0 == 3 && Arg1 == 1))
    {
        Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
    }
}

Provided the original code removed from the _OFF method is:
Code: 
...
If (\ECON)
{
    Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
}
...
Click to expand...

ECON is likely non-zero (you can check with ACPIDebug.kext), so checking for it probably has no effect.
But since _REG can be called multiple times (read ACPI spec), it is important to check for Arg0--3 && Arg1==1.
 
RehabMan said:
ECON is likely non-zero (you can check with ACPIDebug.kext), so checking for it probably has no effect.
But since _REG can be called multiple times (read ACPI spec), it is important to check for Arg0--3 && Arg1==1.
Click to expand...
But my problem is that the patched _REG in the SSDT is never being reached or Calle don't at all, and that's what has been causing the problem.
That's really confusing...
 
the-braveknight said:
But my problem is that the patched _REG in the SSDT is never being reached or Calle don't at all, and that's what has been causing the problem.
That's really confusing...
Click to expand...

Attach current "Problem Reporting" files (including patchmatic output).
 
RehabMan said:
Attach current "Problem Reporting" files (including patchmatic output).
Click to expand...
Problem Reporting files are already attached in post #1 with patchmatic output. I'm afraid I'm traveling now and can't provide updated files, but I'm sure the files attached in post #1 haven't changed.
I believe _REG method in SSDT-NVDA is not being reached or called for some reason... I'd be thankful if you take a look.
 
the-braveknight said:
Problem Reporting files are already attached in post #1 with patchmatic output. I'm afraid I'm traveling now and can't provide updated files, but I'm sure the files attached in post #1 haven't changed.
I believe _REG method in SSDT-NVDA is not being reached or called for some reason... I'd be thankful if you take a look.
Click to expand...

Previously you stated the _REG was not being called.
Now you say "I believe _REG ... is not being called"... which sounds more like a guess than a verified fact.
Use ACPIDebug.kext to verify your theory.
 
RehabMan said:
Previously you stated the _REG was not being called.
Now you say "I believe _REG ... is not being called"... which sounds more like a guess than a verified fact.
Use ACPIDebug.kext to verify your theory.
Click to expand...
That's corrected. I haven't checked it (yet). I'll try to see what I can do with ACPIDebug.kext or I'll simply remove the _REG related code...
Thanks :$
 
After more testing, I think it's likely a bug in IASL, or Clover, or somewhere else xD
I removed all _REG related code from my SSDT-NVDA and removed the _REG -> XREG bin-patch and booted up without the code removed form _OFF method and it worked well and the issue disappeared (_REG method was accessible again). But then I decided to go back and give it one final try, I created a new SSDT (named it SSDT-_REG) and copied the code removed from _OFF method, and copied back the binary patch to my config.plist, and strangely, the issue disappeared and _REG method from the new SSDT is being reached. ( I made sure the new SSDT was loaded by Clover and the bin-patch was applied).
After that, I copied the exact same code from SSDT-_REG back to SSDT-NVDA, removed the new SSDT-_REG, and the issue appeared again and _REG method was not accessible from my SSDT-NVDA again for some reason... I am 100% sure I'm not doing anything wrong, the issue MUST be somewhere else, not in my SSDT code, nor in my setup...

Here is my new SSDT:

EDIT:
Added the edited SSDT-NVDA that is supposed to work, but strangely, not working.
And by not working I mean, the _REG method in it is not being reached.
 

Attachments

  • SSDT-_REG.dsl
    563 bytes · Views: 68
  • SSDT-NVDA.dsl
    2 KB · Views: 85
Last edited:
the-braveknight said:
After more testing, I think it's likely a bug in IASL, or Clover, or somewhere else xD
I removed all _REG related code from my SSDT-NVDA and removed the _REG -> XREG bin-patch and booted up without the code removed form _OFF method and it worked well and the issue disappeared (_REG method was accessible again). But then I decided to go back and give it one final try, I created a new SSDT (named it SSDT-_REG) and copied the code removed from _OFF method, and copied back the binary patch to my config.plist, and strangely, the issue disappeared and _REG method from the new SSDT is being reached. ( I made sure the new SSDT was loaded by Clover and the bin-patch was applied).
After that, I copied the exact same code from SSDT-_REG back to SSDT-NVDA, removed the new SSDT-_REG, and the issue appeared again and _REG method was not accessible from my SSDT-NVDA again for some reason... I am 100% sure I'm not doing anything wrong, the issue MUST be somewhere else, not in my SSDT code, nor in my setup...

Here is my new SSDT:

EDIT:
Added the edited SSDT-NVDA that is supposed to work, but strangely, not working.
And by not working I mean, the _REG method in it is not being reached.
Click to expand...

In order to use SSDT-NVDA.aml you will need to rename _OFF in the native SSDT so it does not cause conflict.
I'm not sure External declarations are relative to current scope. You should probably declare the full path.
Maybe you have another RMD1 under PCI0 in another SSDT (that would also be a conflict).
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top