[Solved] EC _Qxx keys not working on cold boot

[the-braveknight]

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

I did that too, and verified that _REG is being called.

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

Wrong scope how? My original _REG method is located at _SB.PCI0.LPCB.EC0._REG, and so is the _REG method in SSDT-NVDA.

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

I don't know how that is done, but I'm attaching my SSDTs for you to check.

In conclusion, my SSDT-NVDA which contains a modified _OFF method, and a modified _REG method works just fine. The only problem is that for some unknown reason, the _REG code in SSDT-NVDA does not work (_REG cannot be reached) when the SSDT is loaded after SSDT-BATT, the _OFF related code in SSDT-NVDA still works though, and with the _REG method unreachable, my _Qxx methods are broken too, that's all what's it about.

I don't know if there is an order dependency between my SSDTs and how I could find out, I hope you can take a look and see... Maybe it has something to do with both SSDTs have access to EC? I don't really know... but I don't want to use SortedOrder in my config.plist, I might need to do it though...

I hope you can take a look and give me some clues/info.

Thanks.

 

[RehabMan]

I did that too, and verified that _REG is being called.

Ok... so did having it in the separate SSDT and calling original (via XREG) make any problems?

Wrong scope how? My original _REG method is located at _SB.PCI0.LPCB.EC0._REG, and so is the _REG method in SSDT-NVDA.

Look at your patchmatic -extract output to verify...

I don't know how that is done, but I'm attaching my SSDTs for you to check.

In conclusion, my SSDT-NVDA which contains a modified _OFF method, and a modified _REG method works just fine. The only problem is that for some unknown reason, the _REG code in SSDT-NVDA does not work (_REG cannot be reached) when the SSDT is loaded after SSDT-BATT, the _OFF related code in SSDT-NVDA still works though, and with the _REG method unreachable, my _Qxx methods are broken too, that's all what's it about.

I don't know if there is an order dependency between my SSDTs and how I could find out, I hope you can take a look and see... Maybe it has something to do with both SSDTs have access to EC? I don't really know... but I don't want to use SortedOrder in my config.plist, I might need to do it though...

I hope you can take a look and give me some clues/info.

Thanks.

Consider separating _REG into a different SSDT.

 

[the-braveknight]

Ok... so did having it in the separate SSDT and calling original (via XREG) make any problems?



Look at your patchmatic -extract output to verify...



Consider separating _REG into a different SSDT.

Moving it into a different SSDT can fix the problem, but not always. For example, if SSDT-BATT is loaded before SSDT-REG, the problem will still occur.

The ultimate fix is to make sure that the SSDT that has the _REG related code is loaded BEFORE SSDT-BATT. I can do that only using SortedOrder...

Can you check if that order dependency can be eliminated so I don't have to worry about SortedOrder? If it cannot, I may end up using SortedOrder or moving SSDT-NVDA code into SSDT-BATT...

 

[RehabMan]

Moving it into a different SSDT can fix the problem, but not always. For example, if SSDT-BATT is loaded before SSDT-REG, the problem will still occur.

So it is something that SSDT-BATT is doing...
Note: I'm not certain External is contextual regarding Scope. You might want to check that before making extensive use of such an assumption.

 

[the-braveknight]

So it is something that SSDT-BATT is doing...
Note: I'm not certain External is contextual regarding Scope. You might want to check that before making extensive use of such an assumption.

I don't think it's has anything to do with External... if I decompile SSDT-BATT with the DSDT, the result is SSDT-BATT with External used the regular way (first thing in definition block before the code), when I compile that again, the result is the same...

So I'm pretty much sure it's contextual regarding the scope.

 

[RehabMan]

I don't think it's has anything to do with External... if I decompile SSDT-BATT with the DSDT, the result is SSDT-BATT with External used the regular way (first thing in definition block before the code), when I compile that again, the result is the same...

Declare all Externals with absolute ACPI path to avoid any problems.

So I'm pretty much sure it's contextual regarding the scope.

Declare all Scopes with absolute ACPI path.

eg.... Trying to be clever is not helpful in troubleshooting scenarios...

 

[the-braveknight]

Declare all Externals with absolute ACPI path to avoid any problems.



Declare all Scopes with absolute ACPI path.

Tried that. Same results... I'm attaching the SSDT I used.

eg.... Trying to be clever is not helpful in troubleshooting scenarios...

LOL you're right xD, but I've read about External and scope addresses and used them this way in many places with no problem so far, but you're right, troubleshooting scenarios might require more serious efforts.

I'm attaching the SSDT-BATT and patchmatic output.

 

[RehabMan]

Tried that. Same results... I'm attaching the SSDT I used.


LOL you're right xD, but I've read about External and scope addresses and used them this way in many places with no problem so far, but you're right, troubleshooting scenarios might require more serious efforts.

I'm attaching the SSDT-BATT and patchmatic output.

You will probably need to eliminate parts of SSDT-BATT until you find the part causing the problem...

 

[the-braveknight]

You will probably need to eliminate parts of SSDT-BATT until you find the part causing the problem...

Well, so having to force Clover to load an SSDT before the other is actually a problem that needs to be fixed?

Maybe I'll just use SortedOrder to make sure SSDT-NVDA is loaded before SSDT-BATT so I don't encounter any problems, or I'll simply merge the two SSDTs...

The code in SSDT-BATT is the same code extracted from a battery-patched DSDT, so I don't think it's where the problem is located (or maybe I'm too lazy to start digging into the 456-line SSDT-BATT code xD)... Maybe the _REG code DOES NEED to be loaded before the battery methods (_BIF, _BST... etc). Don't you think?

So I think I should go with one of the two solutions I mentioned earlier and that's it...

Off-topic question: Do I not need the ECON check in the _REG code? Because the _OFF method did have it...

 

[RehabMan]

Well, so having to force Clover to load an SSDT before the other is actually a problem that needs to be fixed?

Personal choice.

The code in SSDT-BATT is the same code extracted from a battery-patched DSDT, so I don't think it's where the problem is located (or maybe I'm too lazy to start digging into the 456-line SSDT-BATT code xD)... Maybe the _REG code DOES NEED to be loaded before the battery methods (_BIF, _BST... etc). Don't you think?

Load order does not affect execution order.

Off-topic question: Do I not need the ECON check in the _REG code? Because the _OFF method did have it...

You could check the value of ECON with ACPIDebug.kext.