[Solved] EC _Qxx keys not working on cold boot

[the-braveknight]

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

The strange thing is that I already have my original _OFF method renamed to XOFF in my config.plist, and I verified the bin-patch is being applied, and _OFF method is being replaced with what I have in my SSDT-NVDA, but the _REG related code in the same SSDT-NVDA is somehow broken, so calls to SSDT-NVDA/_OFF are already happening and I confirmed they're working, but not the _REG... I tried declaring full scope like what I have done in the SSDT-NVDA I attached in post #19, and it's still not working... I MUST use another SSDT for the _REG... can this really be a bug?
Any ideas?

 

[RehabMan]

The strange thing is that I already have my original _OFF method renamed to XOFF in my config.plist, and I verified the bin-patch is being applied, and _OFF method is being replaced with what I have in my SSDT-NVDA, but the _REG related code in the same SSDT-NVDA is somehow broken, so calls to SSDT-NVDA/_OFF are already happening and I confirmed they're working, but not the _REG... I tried declaring full scope like what I have done in the SSDT-NVDA I attached in post #19, and it's still not working... I MUST use another SSDT for the _REG... can this really be a bug?
Any ideas?

Something in the file is wrong and is causing AppleACPIPlatform to ignore the code you have for _REG.
Use process of elimination to determine your mistake.

 

[the-braveknight]

Something in the file is wrong and is causing AppleACPIPlatform to ignore the code you have for _REG.
Use process of elimination to determine your mistake.

I never really found any mistake in the code... I wish you could point out to what I might be missing.
Meanwhile, I created a new SSDT (SSDT-NVDA-REG) for the _REG code until I find a better solution.

 

[RehabMan]

I never really found any mistake in the code... I wish you could point out to what I might be missing.
Meanwhile, I created a new SSDT (SSDT-NVDA-REG) for the _REG code until I find a better solution.

Use "process of elimination" to find your mistake.

 

[the-braveknight]

Use "process of elimination" to find your mistake.

Well I'm not sure I understand what that means, but if you mean by eliminating parts of code, I tried that already... _REG code cannot seem to work when in same SSDT with Method(_OFF), otherwise, they work perfectly each on its own SSDT...

 

[RehabMan]

Well I'm not sure I understand what that means, but if you mean by eliminating parts of code, I tried that already... _REG code cannot seem to work when in same SSDT with Method(_OFF), otherwise, they work perfectly each on its own SSDT...

Eliminate code from SSDT-NVDA until the problem goes away. Then you will know where your mistake is.

 

[the-braveknight]

Eliminate code from SSDT-NVDA until the problem goes away. Then you will know where your mistake is.

Wow! I started doing just as you told me, I started commenting the code until I reached P8XH line, I commented the two lines, restarted, and the problem disappeared so I knew it had something to do with P8XH, I moved its declaration back a scope and that fixed the problem somehow! @.@

EDIT: I am unable to reproduce the problem anymore so I don't really know...

 

[the-braveknight]

Marked solved anyway

Thanks @RehabMan

 

[the-braveknight]

Hello @RehabMan,

After more and more testing... the issue is still there. I noticed it's still here after I performed an EC reset so I don't really think this is anyhow fixable, the issue goes away completely only when I remove _REG code permanently and remove the _REG -> XREG bin patch from config.plist, but then the code that was in the _OFF method is never executable, it seems like _REG method is irreplaceable... Would that be a problem?
Also, is there anyway I can execute that code without messing around with the original _REG method in the DSDT?
Btw, can this warning give us some clues?

_REG has no corresponding Operation Region

EDIT:
Well... After playing around with ACPIDebug.kext and looking at Clover logs I could tell the problem is not in the SSDT-NVDA code, and probably has no relation to _REG... But I could notice that the problem only existed if Clover loaded SSDT-BATT before SSDT-NVDA, that MUST be the where the problem is, so I went on and used SortedOrder to make sure SSDT-NVDA is loaded before SSDT-BATT, tried a few times and the problem never occurred again!
Now I only need an explanation, why is it that the problem is happening and _REG code is not being reachable when Clover loads SSDT-BATT before SSDT-NVDA? if you could provide one I would be thankful.

 

[RehabMan]

Hello @RehabMan,

After more and more testing... the issue is still there. I noticed it's still here after I performed an EC reset so I don't really think this is anyhow fixable, the issue goes away completely only when I remove _REG code permanently and remove the _REG -> XREG bin patch from config.plist, but then the code that was in the _OFF method is never executable, it seems like _REG method is irreplaceable... Would that be a problem?
Also, is there anyway I can execute that code without messing around with the original _REG method in the DSDT?
Btw, can this warning give us some clues?

Start by replacing _REG with a version that just calls XREG only.
And verify your _REG is being called by using ACPIDebug.

_REG has no corresponding Operation Region

It means your _REG method has been placed in the wrong scope.

EDIT:
Well... After playing around with ACPIDebug.kext and looking at Clover logs I could tell the problem is not in the SSDT-NVDA code, and probably has no relation to _REG... But I could notice that the problem only existed if Clover loaded SSDT-BATT before SSDT-NVDA, that MUST be the where the problem is, so I went on and used SortedOrder to make sure SSDT-NVDA is loaded before SSDT-BATT, tried a few times and the problem never occurred again!

It implies you have coded an order dependency between those two SSDTs.