Contribute
Register

<< Solved >> OpenCore battery patch

Status
Not open for further replies.
@ganthore

So you're saying that the kext does work as it should? Why would you like to use an SSDT then? I could help you, but it's like... wasted effort, I guess?
Hey,

So my boot process is lagging and I thought that battery related ACPI errors were the root cause base off some older data I collected earlier today, but after some more reading, learning, crying, etc... it turns out that I'm wrong because my current boot logs no longer mention any errors after I switched to ECEnabler.

My problem seems related to an AppleIntelLpssI2CController thing that the default apple driver is trying to load which is triggering multiple timeouts. So I'm going to say my past comment is unrelated now. Sorry for the confusion! :)
 
Last edited:
@ganthore

Have you already opened a thread for this issue? Would need to know what I2C-devices you are trying to use.
 
Hi BlvckBytes!

I have a guide for an HP 8470p and I saw your post, so i was wondering if you could help me.
With the SMCBatteryManager and ECEnabler working the Battery Percentage, notification for low battery, AC/DC status, Capacity(mAh).
IOREG shows Bat0, Bat1 and BatZ.
So “only” missing is the cycle count and the thermal display, as far as I can tell.(I'm not familiar with this patch yet.)

Cheers!
 
This is a new install. Apparently my bios was set to favor battery health over performance, so that 20% cut is normal.

In any case, I still prefer to use a SSDT patch if it were possible.
not needed if it works with kexts
 
@DaveJ1

It could be that those two informations you're after aren't even stored in the EC, and it needs a lot of debugging right on the device itself. Only ACPI-Tables are not sufficient, as I would need to know what values the EC-fields hold at runtime, perform experiments, and then diff. Quite hard to figure all of that out without the device...
 
@DaveJ1

It could be that those two informations you're after aren't even stored in the EC, and it needs a lot of debugging right on the device itself. Only ACPI-Tables are not sufficient, as I would need to know what values the EC-fields hold at runtime, perform experiments, and then diff. Quite hard to figure all of that out without the device...
That sounds difficult.
Can i do furthermore information, or may be do by myself with your help?
It would be useful if i upload the one, what i used with Clover? A generated DSDT with the old PBI-CE.(Working cycle count, no thermal display)
- or a Similar 8470p EFI(OC) from Github, where is patched maybe the right way?
I’m just thinking, but i get it, without the exact device...

Anyway, thank you for your time!
 
@DaveJ1

I think it would be helpful if you attach the Clover-Patch with working cycle-count, I can take a look at it and maybe help to transfer the responsible section. No idea about thermal stuff tho, never even seen it on any of my machines.
 
@DaveJ1

I think it would be helpful if you attach the Clover-Patch with working cycle-count, I can take a look at it and maybe help to transfer the responsible section. No idea about thermal stuff tho, never even seen it on any of my machines.
Under ACPI/Patched. Don't worry about thermal.
Thanks!
 
Last edited:
@DaveJ1

Okay, I had a quick look at the source and can now share my opinion on it with you. When the patched and original DSDTs are diffed, I noticed an important addition the patch made:

Screen Shot 2021-08-05 at 18.04.57.png


BTIF gathers the needed battery information values and stores them at a known location (in this case package array NBTI, where [0] is the primary battery and [1] got called "travel"). The patched DSDT also writes BCC (possibly battery cycle-count) and TEMP to this package, which will then be read by macOS. Your native DSDT doesn't, other OS probably have another way of acquiring this data.

I'm not 100% sure on how to integrate this to your current setup, since I have *never* worked with ECEnabler. Had a gander at it's source, seems like it just reroutes AppleACPIEC's ecSpaceHandler to some custom implementations that are able to handle fields > 8b. So I *guess* that we no longer need to care about B1B2, B1B4, RECB, WECB, and so on, and just directly implement changes.

Would you be okay if I create a small SSDT for this fix, which may not work? You'd need to create a safe backup so you don't lock yourself out of your system. If it doesn't work, we need to fully convert this DSDT to a battery SSDT.
 
@DaveJ1

Okay, I had a quick look at the source and can now share my opinion on it with you. When the patched and original DSDTs are diffed, I noticed an important addition the patch made:

View attachment 526323

BTIF gathers the needed battery information values and stores them at a known location (in this case package array NBTI, where [0] is the primary battery and [1] got called "travel"). The patched DSDT also writes BCC (possibly battery cycle-count) and TEMP to this package, which will then be read by macOS. Your native DSDT doesn't, other OS probably have another way of acquiring this data.

I'm not 100% sure on how to integrate this to your current setup, since I have *never* worked with ECEnabler. Had a gander at it's source, seems like it just reroutes AppleACPIEC's ecSpaceHandler to some custom implementations that are able to handle fields > 8b. So I *guess* that we no longer need to care about B1B2, B1B4, RECB, WECB, and so on, and just directly implement changes.

Would you be okay if I create a small SSDT for this fix, which may not work? You'd need to create a safe backup so you don't lock yourself out of your system. If it doesn't work, we need to fully convert this DSDT to a battery SSDT.
Sure, Let's do this.
 
Last edited:
Status
Not open for further replies.
Back
Top