<< Solved >> OpenCore battery patch

[takki]

@BlvckBytes

Believe it or not, there is an app for that lol

williambj1/GenI2C

Generate SSDT hotpatches for your Touchable Device and get ready for VoodooI2C! - williambj1/GenI2C

github.com

This thing can generate all the SSDTs and hotpatches and even took care of my USTP situation, which I imagine is an edge case. I still don't understand why my stuff didn't work but now it does. The app can even do some diagnostics and tells you wether you're in polling or interrupt mode. Wow.

Attached are the patches and SSDTs for the early 2019 Blade 15 trackpad.

Edit: Okay nevermind, those patches need TgtBridge and OC doesn't implement that. It's prossible to do it with something called count/skip but it seems like you're not supposed to use that either. **** me.

 

[BlvckBytes]

@takki

Directly patching the if on those byte levels is something I’d only do if *nothing* else is possible. BTW, the <> brackets get added on their own, they just signal hex data, don’t type them in yourself.

I don’t quite know if your SSDT would work like that, first of - did you check that USTP is in root scope? You wrote the External like that. Also, _SB probably already has an _INI, I don’t think it will be able to call that. I’ve never needed to override a variable, but I think just writing the If statement without the method should execute on runtime, and since the SSDT gets put on the stack after the DSDT, that change should work.

Maybe going to look into that app later, could you quickly explain what TgtBridge is?

Also, just for clarification: If you load up the patched DSDT on OC, it works? So if I diff native and patched, I see what needs to be done with SSDTs now, right? Then I can start looking into it.

 

[BlvckBytes]

@Cimmerian

If _STA returns 0xF, it also means it's on. I don't quite know if there is a range of valid values for ON state, but 0xF is definitely fine. Please check out why OpenCore can't boot, and send an image. Since you want to boot with OC, I'd focus on that.

Battery always reports 0? Had a lot of those issues on my battery aswell, this needs debugging... If you are running it on OC, I will try to repair that for you. Just one thing at a time, I don't see a reason why Clover would take it and OC wouldn't.

BTW, if _STA is off, the battery would be gone. _BIF is Information, _BST is Status, so those probably have issues, I screwed up somewhere in there.

 

[Cimmerian]

What i did on clover was to rename the batterie device BAT0 instead of BAT1. It has fixed the kernel panic so i'll try the same on OC

 

[BlvckBytes]

@Cimmerian

Could you provide me with your current EFI/ and your origin DSDT?

 

[takki]

@takki

Directly patching the if on those byte levels is something I’d only do if *nothing* else is possible. BTW, the <> brackets get added on their own, they just signal hex data, don’t type them in yourself.

I don’t quite know if your SSDT would work like that, first of - did you check that USTP is in root scope? You wrote the External like that. Also, _SB probably already has an _INI, I don’t think it will be able to call that. I’ve never needed to override a variable, but I think just writing the If statement without the method should execute on runtime, and since the SSDT gets put on the stack after the DSDT, that change should work.

Maybe going to look into that app later, could you quickly explain what TgtBridge is?

Also, just for clarification: If you load up the patched DSDT on OC, it works? So if I diff native and patched, I see what needs to be done with SSDTs now, right? Then I can start looking into it.

The program did a pretty good job with the USTP situation. It's renaming it to XSTP and then creates a new variable in the SSDT. I'm happy with that and that part is compatible with OC as well. I wasn't able to change the value of it anyways and the original variable is part of a Fieldset (which is in the root scope), so no idea how that would actually work.

So as far as I understand, Target Bridge (TgtBridge) lets you limit the scope of the binary patch. Some method names are very common (_CRS, _INI for example) and with Target Bridge you can limit the scope of a patch to a specific device. So im my case the patch would be:

Rename the method _CRS to XCRS but only inside of TPD0.

The only proper guide for skip/count in opencore is in Chinese, but google translate worked surprisingly well haha. Skip count works like this: You count all the _CRS methods that come BEFORE the one you want to patch, thats your skip. Count is how many occurrences starting after the count you want to patch. So in my case skip 75, count 1. I can't test it as I don't actually have an OC install but I've attached all the files. Both OC and clover versions are in there (clover works, OC should work).

Next up is RTEC and battery. RTEC should be easy and I think the battery patch is the same as yours, so I'll try that if you don't mind

Edit: whoops seems like I counted only method names, but you need all occurrences. Updated the patch accordingly.

 

[BlvckBytes]

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

 

[Cimmerian]

here you go

 

[vettz500]

@vettz500

I've removed a lot of redundant path-prefixes and changed the Externals to the actual right types, had some issues there. Windows battery is still screwed up on my end, everything works the same, but it's easier to maintain for the future. You can replace it, if you want to, I definitely recommend, tho.

I'm just getting to this now. I've been so busy since I've been called back to work, I just haven't had time to invest into this. Hoping to have a day or so this weekend to look into the debugging the DSDT stuff.

I replaced the original with this. Battery indicator still works just fine in OSX and Windows with it. Thank you for it!

 

[BlvckBytes]

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