<< Solved >> OpenCore battery patch

[BlvckBytes]

@Cimmerian

Cleaned up the SSDT, I think you should try again in OC and tell me the exact errors. First off, do you need a fake EC, or could we just rename H_EC to EC? Also, rename BAT1 to BAT0, like you said, it'll probably help.

The SSDT needs the following now:
* Add config.plist rename _BIF to XBIF ( 5F424946 to 58424946 )
* Add config.plist rename _BST to XBST ( 5F425354 to 58425354 )
* Add config.plist rename _BIX to XBIX ( 5F424958 to 58424958 )
* Add config.plist rename H_EC to EC ( 485F4543 to 45435F5F )
* Add config.plist rename BAT1 to BAT0 ( 42415431 to 42415430 )

If the H_EC to EC doesn't work for you, change EC to H_EC in the SSDT with MaciASL again. I use my EC natively, without fake EC, so I would recommend trying at least.

 

[takki]

@takki

Yeah, I guess that is also a pretty good way to control the variable's value, if it works - it's awesome. The skip and count is pretty nice, but I don't know how futureproof they are, probably a lot and I'm thinking too far here again. I used hexfiend and just got XXXX with like 3 more bytes, I think those also specify the scope, type, and so on. I sadly haven't had the time to look how ASL is translated to assembled machine code.

If the battery patch really works, that would suprise me a lot... The OperationRegion overrides are byte-offset specific, and I've heard the 2019's ACPI differs quite a lot. But I could help you out on that if it doesn't work - if you'd like.

Skip and count sadly is a requirement for the trackpad fix. I couldn't get any accurate match for the _CRS method, no matter how large of a range I selected in HexFiend. Keep in mind if you're using HexFiend to open the .aml file and not the .lst file. That's what I did and that doesn't work for finding patterns, because all the extra stuff in .lst that is added for debugging.

I'll give your pattery patch a try. If it works, great, if it doesn't, it probably won't explode (fingers crossed haha).

I completed the dGPU patch for the early 2019 model. If you still have trouble with the dGPU waking from sleep you could try it as well, just leave out the RTEC patches and SSDT. It disables the gpu on boot, activates it before going to sleep and re-enables it when waking up.

So 2018 model: SSDT-DDGPU.aml and SSDT-PTSWAK.aml + _PTS to ZPTS patch + _WAK to ZWAK patch
Early 2019 model: additionally add RTEC to XTEC patch + SSDT-RTEC.aml (confirmed works on my machine)

 

[vettz500]

Skip and count sadly is a requirement for the trackpad fix. I couldn't get any accurate match for the _CRS method, no matter how large of a range I selected in HexFiend. Keep in mind if you're using HexFiend to open the .aml file and not the .lst file. That's what I did and that doesn't work for finding patterns, because all the extra stuff in .lst that is added for debugging.

I'll give your pattery patch a try. If it works, great, if it doesn't, it probably won't explode (fingers crossed haha).

I completed the dGPU patch for the early 2019 model. If you still have trouble with the dGPU waking from sleep you could try it as well, just leave out the RTEC patches and SSDT. It disables the gpu on boot, activates it before going to sleep and re-enables it when waking up.

So 2018 model: SSDT-DDGPU.aml and SSDT-PTSWAK.aml + _PTS to ZPTS patch + _WAK to ZWAK patch
Early 2019 model: additionally add RTEC to XTEC patch + SSDT-RTEC.aml (confirmed works on my machine)

Added everything to my set up. Sleep and everything seems to still work just fine.

What are you using to monitor power consumption and heat? Last time I tried the HWMonitor App I got a kernel panic on boot and have been hesitant to try again. Right now I'm just monitoring with Intel Power Gadget

 

[Cimmerian]

@Cimmerian

Cleaned up the SSDT, I think you should try again in OC and tell me the exact errors. First off, do you need a fake EC, or could we just rename H_EC to EC? Also, rename BAT1 to BAT0, like you said, it'll probably help.

The SSDT needs the following now:
* Add config.plist rename _BIF to XBIF ( 5F424946 to 58424946 )
* Add config.plist rename _BST to XBST ( 5F425354 to 58425354 )
* Add config.plist rename _BIX to XBIX ( 5F424958 to 58424958 )
* Add config.plist rename H_EC to EC ( 485F4543 to 45435F5F )
* Add config.plist rename BAT1 to BAT0 ( 42415431 to 42415430 )

If the H_EC to EC doesn't work for you, change EC to H_EC in the SSDT with MaciASL again. I use my EC natively, without fake EC, so I would recommend trying at least.

I have those change.

Well now it's booting but i dont have any "battery monitoring" (unlike clover where it says 0%)

Also yeah the EC rename works fine

 

[BlvckBytes]

@Cimmerian

Current EFI/ folder please, need to check some stuff. But if the rename is good, and you don't crash, that's a start.

 

[Mr.Crab]

@vettz500

Still very amazed that it works in your windows, it absolutely doesn't for me xD. Right, I understand that - I also got more stuff to do rn. I will try to continue learning about all of this, so I might be able to make more progress...

Don't know if you know, but 1) you can boot trough UEFI menu to avoid OC stuff in Windows; 2) there is a fork of OC that doesn't apply patches to other OSs.

 

[takki]

Added everything to my set up. Sleep and everything seems to still work just fine.

What are you using to monitor power consumption and heat? Last time I tried the HWMonitor App I got a kernel panic on boot and have been hesitant to try again. Right now I'm just monitoring with Intel Power Gadget

I'm just using Intel Power Gadget to monitor my CPU temp. iStat menus is also an option but I haven't used that in a while. If my dGPU is off my CPU idles around 42 degrees @0.8ghz, if my dGPU is active in the background it's rising to 55-60. I'm sure it would go even higher but that's when I stop monitoring usually. For overall power consumption you can go to Activity Monitor -> Energy and look at how much battery life is remaining. It's not very accurate but it can tell you if there is something wasting huge amounts of energy (like the dGPU).

 

[Las_Vegas]

I've been struggling with my SSDT-BATT script for a couple of weeks now. I really am at a loss.

I'm dealing with 3 HP laptops (ProBook 640G2, Probook 450G5 & EliteBook 850G4) and all have the same issue. I'm getting ACPI errors referencing the BTIF and BTST methods. I haven't figured out a way saving the boot logs for reference.

I'm using RehabMan's scripts for these laptops. I did realize last week that he'd written them with the EC rename expected, so I created one changing EC to EC0. I just tried disabling SSDT-EC, adding the EC0 to EC patch and using RehabMan's original aml file. I still get the same errors...

This is the modified SSDT-BATT file I've been trying to use. This is for both of the Kabylake units. All patches are in place. I did modify them a bit to ensure that only the appropriate methods are renamed. This is the config.plist for OC 0.5.8:

 

[BlvckBytes]

@Mr.Crab

Thank you, I know those options alredy. The direct boot through the windows bootloader alone is something I don't want to do (it's only a way to avoid the problems) and the fork is also not something I'd touch, since everything else works, but only the battery doesn't on windows. I need to find out what's causing that, otherwise I won't learn.

@Las_Vegas

I don't quite understand your current situation, do you own a working DSDT patch and just don't get it "translated" into a SSDT, or do you have to come up with everything yourself? If something exists already, any concrete sources of information?

Errors with _BIF (Battery Information) and _BST (Battery Status) are common, if there are fields used which are larger than a byte (8 bit). Only because all three laptops share this "common" issue, it doesn't mean you will be able to apply the same patch on all of them, at least I have a hard time of believing that.

 

[BlvckBytes]

@Mr.Crab @takki @rufus8472 @vettz500

Does the setting "Mission Control > Displays have seperate spaces" work for you guys? I had this issue on clover, where my external monitors would display white menu-bars when they should be transparent (not selected). Now, both displays work with transparent bars, but my built-in display has this bug.

Any ideas? Is this reproducable on some of your machines? I feel like nobody ever had this xD. Images attached!