Contribute
Register

<< Solved >> OpenCore battery patch

Status
Not open for further replies.
@yoannez Take a look at IOReg if batterymanager is correctly attached to BAT1 or BAT0. In my case. I'm use VirtualSMC + ACPIBatteryManager, because its correctly attached and SMCBatteryManager don't.
 
@yoannez

I am very happy that it works for you, would've never thought I could make that work xD. Are you sure it does everything a battery has to offer? Charging (percentage going up), draining (percentage going down) and status (charging-bolt)?

I could imagine that there are still bugs, so please check said features. BTW, why are you using the Count field? For example on _OSI to XOSI it seems kinda weird, since you'd want to replace every occurance. Also, on my patches, you don't really need them. Default is 0, replace everything.
 
@kecinzer

Do you mean something along the lines of my image would be "wrong" then? I don't quite know about that, my battery is running fine, I just think VirtualSMC works different. Why do you need that attached? Any disadvantages without it?

Screenshot 2020-04-29 at 13.13.36.png
 
@kecinzer

Do you mean something along the lines of my image would be "wrong" then? I don't quite know about that, my battery is running fine, I just think VirtualSMC works different. Why do you need that attached? Any disadvantages without it?

View attachment 465827
Yes, this is wrong. You probably can't see battery cycle count.
It should looks like this - https://user-images.githubusercontent.com/1541555/80473092-f090ed80-8945-11ea-82d8-bdc1b348921b.png

It's not VirtualSMC thing, bat SMCBatteryManager problem. I have VirtualSMC + ACPIBatteryManager.

May be we will see how it goes on Github :).
 
@kecinzer

Oh, wow! You're right, sorry for my misbelieve xD. I switched to ACPIBatteryManager and finally: "This battery needs replacing" is away, probably because of the missing cycle count. Would've never thought that the guys from VirtualSMC would make a mistake in that kext, I think it's more likely that just something in my patch is not properly done.

So, gotta say: ACPIBatteryManager + VirtualSMC is the better solution.

Screenshot 2020-04-29 at 13.26.06.png
 
@kecinzer

Oh, wow! You're right, sorry for my misbelieve xD. I switched to ACPIBatteryManager and finally: "This battery needs replacing" is away, probably because of the missing cycle count. Would've never thought that the guys from VirtualSMC would make a mistake in that kext, I think it's more likely that just something in my patch is not properly done.

So, gotta say: ACPIBatteryManager + VirtualSMC is the better solution.

View attachment 465833
Great to see it works for you. But I thing stays with ACPIBatteryManager is no way to go, because it's already unsupported.
It will be much better when we can switch to SMCBatteryManager.
I thing that is because I have BATC instead of BAT0, but you have BAT0 and the same problem.

May I ask you to write into GITHUB bug, that you have same issue as me? May be then they will pay more attention on it :))
 
@kecinzer

Right, that's what I've thought about it too, it seems kinda old (2018ish), and is probably no proper solution. But I think I haven't had 0 cycles, some cycles were displayed, but a lot of other fields were undefined in System Profiler.

I'm not on my laptop rn, as soon as I'm back I'll switch to SMCBatteryManager once again, document the differences and post in your issue too :).
 
I can help you with hotpatching the best I can, I've invested a few hours by now (more like days, lol). I know the basics and understand a bit of ASL. Why do you think the trackpad needs patching? Do you have a patch active right now? If so, could you post that?

I'm just now starting to read the opencore laptop guide by dortania to get into it.

For my trackpad I need to patch my dsdt. Firstly I need to move two methods named SSCN and FMCN to a different place, insert the correct gpio pin and change the _CRS method.

Come to think of it, I just had a look at my DSDT again and there might be a better way. The problem is that while SSCN and FMCN should belong to my trackpad, they are defined somewhere else and the definition is wrapped in an If statement like so:

Code:
If (USTP)
    {
        Scope (_SB.PCI0.I2C0)
        {
            Method (SSCN, 0, NotSerialized)
            {
                Return (PKG3 (SSH0, SSL0, SSD0))
            }

            Method (FMCN, 0, NotSerialized)
            {
                Return (PKG3 (FMH0, FML0, FMD0))
            }
        ... a lot of other stuff follows

USTP is defined at the top of my DSDT inside a field and it value is 8:

Code:
    Field (GNVS, AnyAcc, Lock, Preserve)
    {
        USTP,   8,
        ...

I doubt that will ever be evaluated.. so it might be better to just patch out that if statement if that's possible but I need more testing. There is a guide on how to patch things for this laptop over on github. Some of the stuff is not needed anymore, like the backlight patch and the guide is a little outdated. The ACPI for the early 2019 blade is a real mess anyways. I doesn't even compile without errors after extracting and decompiling and you have to manually remove duplicate case statements and stuff.

Edit: Removing the if statement also works and makes the trackpad work without any other patching. I can't tell if it's running in polling or interrupt mode though, do we still need to patch the _CRS method and add the correct gpio pin or is that just outdated now?
 
Last edited:
@BlvckBytes
@yoannez

I am very happy that it works for you, would've never thought I could make that work xD. Are you sure it does everything a battery has to offer? Charging (percentage going up), draining (percentage going down) and status (charging-bolt)?

I could imagine that there are still bugs, so please check said features. BTW, why are you using the Count field? For example on _OSI to XOSI it seems kinda weird, since you'd want to replace every occurance. Also, on my patches, you don't really need them. Default is 0, replace everything.

I have no words to thank you, it works flawlessly. Charge/discharge, Time to full charge,

And BTW I'm not sure I have the same issue that @kecinzer mentions with SMCBattery manager, IOReg does look like yours but I can see the cycle count in System Profile:

Battery Information:
Model Information:
Serial Number: 7659
Manufacturer: SMP
Device Name: 00HW029
Pack Lot Code: 0
PCB Lot Code: 0
Firmware Version: 0
Hardware Revision: 0
Cell Revision: 0
Charge Information:
Charge Remaining (mAh): 3034
Fully Charged: No
Charging: Yes
Full Charge Capacity (mAh): 3200
Health Information:
Cycle Count: 65
Condition: Normal
Battery Installed: Yes
Amperage (mA): 655
Voltage (mV): 17145

System Power Settings:
AC Power:
System Sleep Timer (Minutes): 60
Disk Sleep Timer (Minutes): 10
Display Sleep Timer (Minutes): 15
Wake on Clamshell Open: Yes
AutoPowerOff Delay: 28800
AutoPowerOff Enabled: 1
Current Power Source: Yes
DarkWakeBackgroundTasks: 0
Display Sleep Uses Dim: Yes
GPUSwitch: 2
Hibernate Mode: 3
High Standby Delay: 86400
ProximityDarkWake: 1
Standby Battery Threshold: 50
Standby Delay: 10800
Standby Enabled: 1
TCPKeepAlivePref: 1
Battery Power:
System Sleep Timer (Minutes): 15
Disk Sleep Timer (Minutes): 10
Display Sleep Timer (Minutes): 5
Wake on Clamshell Open: Yes
AutoPowerOff Delay: 28800
AutoPowerOff Enabled: 1
DarkWakeBackgroundTasks: 0
Display Sleep Uses Dim: Yes
GPUSwitch: 2
Hibernate Mode: 3
High Standby Delay: 86400
ProximityDarkWake: 0
Reduce Brightness: Yes
Standby Battery Threshold: 50
Standby Delay: 10800
Standby Enabled: 1
TCPKeepAlivePref: 1


Hardware Configuration:
UPS Installed: No

AC Charger Information:
Connected: Yes
ID: 0x0100
Wattage (W): 60
Revision: 0x0000
Family: 0x00ba
Serial Number: 0x00453cbe
Charging: Yes
 

Attachments

  • Joao’s MacBook Pro.ioreg
    5.2 MB · Views: 78
@yoannez @kecinzer

The thank you is more than enough, no worries! :) It makes me happy that I helped out someone, that boosts my "f*** apple" mentality xD. I am learning new things, also through your patch, and since I plan to keep on hackintoshing for the next few years, this is only an advantage for me.

I tried switching back to SMCBatteryManager, and that error is gone. I really don't get how stuff like this just disappears, either I missed out on something or this is just getting more weird over time, LOL. So, currently, both kexts work for me. Did a diff on the system profiler's power entry, that's the outcome:

Screenshot 2020-04-29 at 16.33.26.png


No really critical changes, as far as I can see. I can't really make that github issue post @kecinzer, I'm sorry, because I don't have much evidence right now... :(
 
Status
Not open for further replies.
Back
Top