Contribute
Register

<< Solved >> OpenCore battery patch

Status
Not open for further replies.
Connected to a charger.
Cycle count "test" is confirmed i guess. - CoconutBattery fully empty.
 
@DaveJ1

Hey, that's awesome tho! This means the code gets executed and I understand how this stuff works now. Just need to fiddle around with serial number and other things.

Please try the attached file once more, maybe it'll now display proper cycle count. In the mean time, I'll try to figure out the other things.
 

Attachments

  • SSDT-BATT.aml
    1.3 KB · Views: 65
Okay, that was weird.
1st boot plug in. Sys Report showing the correct Cycle count. Coconut empty
2nd boot unplug. Hang on boot.
3rd boot unplug. booting up, on lock screen no battery icon and Sys Report correct CC. Coconut empty.
4th plug in. No CC and Hello world and Coconut is showing values but the Design Capacity is wrong i guess.

*Recheck, i attached wrongly.
 
@DaveJ1

Okay, this is weird... I mean, it's nice that the cycles are correct now, but this whole dependency on whether or not the plug is active or not kinda weirds me out.

Already getting pretty late over here, I need to go to bed soon. Will continue on this with you tomorrow, okay?
 
@DaveJ1

Okay, this is weird... I mean, it's nice that the cycles are correct now, but this whole dependency on whether or not the plug is active or not kinda weirds me out.

Already getting pretty late over here, I need to go to bed soon. Will continue on this with you tomorrow, okay?
I agree.
Late in here too, thanks for your effort! I'll be here.
 
You don't need ACPIDebug if you add "acpi_layer=0x08" and "acpi_level=0x02" to your boot-args. To print, you then do something like:
Code:
Name (XORG, One)

Method (_INI, 0, Serialized)
{
    Debug = "INI Called"
    Debug = Concatenate ("XORG is: ", XORG)
}

Easier to use compared to ACPIDebug imo, and doesn't require any ACPI aside from what is already supported in the ACPI spec.

Edit: If you do this, you may want to also add "msgbuf=1048576" or use DebugEnhancer.kext, then use "sudo dmesg". The log command is a bit of a pain and often won't get data from early in the boot process. msgbuf will expand the dmesg buffer, though DebugEnhancer expands it even further. If you use msgbuf, you probably want to get the log ASAP after boot.
 
You don't need ACPIDebug if you add "acpi_layer=0x08" and "acpi_level=0x02" to your boot-args. To print, you then do something like:
Code:
Name (XORG, One)

Method (_INI, 0, Serialized)
{
    Debug = "INI Called"
    Debug = Concatenate ("XORG is: ", XORG)
}

Easier to use compared to ACPIDebug imo, and doesn't require any ACPI aside from what is already supported in the ACPI spec.

Edit: If you do this, you may want to also add "msgbuf=1048576" or use DebugEnhancer.kext, then use "sudo dmesg". The log command is a bit of a pain and often won't get data from early in the boot process. msgbuf will expand the dmesg buffer, though DebugEnhancer expands it even further. If you use msgbuf, you probably want to get the log ASAP after boot.
That was a good shot.
I thought it could only be possible with the Debug OC version.
i added all 3 boot-args and i edited the SSDT-BATT with the code and without.
 
Last edited:
After battery patch with SSDT.BATT am getting these firmware errors
Screen Shot 2021-08-07 at 3.59.55 PM.png
 
After battery patch with SSDT.BATT am getting these firmware errors View attachment 526488
you should be able to use the hotpatch files from:

and adapt the config.plist renames to your config.plist
 
you should be able to use the hotpatch files from:

and adapt the config.plist renames to your config.plist
sorry forgot to say am using OpenCore ,thanks
 
Status
Not open for further replies.
Back
Top