New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SMCBatteryManager show 0 cycle count project:vsmc #892
Comments
Issue #879 was marked as invalid and closed for write. I corrected my ACPI patch as suggested. That mean this issue can't be fixed? |
@kecinzer it is basically unjustified that your patch is correct and we are not ready to investigate every not working configuration. I am afraid a more technical report will be needed for us to look at this issue. |
OK, I understand. More technical report you mean EFI folder with OpenCore and Lilu DEBUG log? I'm so sorry to being so annoying, I'm just trying to understand what is wrong and fix it. |
More technical is the explanation of what values comes from ACPI, why are they correct, and what SMCBatteryManager does wrong. So far we received many similar reports like yours, and they always were due to incorrect ACPI. CC @usr-sse2 |
It shows both design capacity and current capacity 0x12c6 = 4806 mA•h, so the battery has 100% capacity and so we report 0 cycles. How old is your battery? |
In fact I don’t use it so much, but I tought that cycle is one discharge from 100 to 0% or 2 discharges from 100 to 50%. |
@kecinzer Then your battery doesn’t report cycle count, so the driver approximates it from loss of capacity, like I said before. Does ACPIBatteryManager report different max and current capacity? We took the formula for cycle count from ACPIBatteryManager, so it should get the same value. Besides, which ACPIBatteryManager are you comparing with? Sent with GitHawk |
No, ACPIBatteryManager report same max and current capacity as "0x12c6" . |
We based on Slice's ACPIBatteryManager. RehabMan's one may have different formula. |
Ah, great. So it looks like SMCBatteryManager works perfectly, just have different count methods. Thank you a lot for this explanation! What about consider to change formula to RehabMan's one? For me it's more accurate. I have almost new battery, but some usage there was and when I compare to my MacBook Pro, where I replaced battery about 1 year ago (now it has 10 cycle count), counts increases very similarly... According this - https://github.com/RehabMan/OS-X-ACPI-Battery-Driver/blob/master/AppleSmartBatteryManager/AppleSmartBattery.cpp#L1291 |
• About expanding _BIF to include cycle count: this line of code only gets cycle count if _BIF size is larger than defined by ACPI specification, e. g. you wrote some code in DSDT to calculate cycle count and provide it as additional field. I doubt that laptop manufacturers do such hacks, but I can check it if you upload your DSDT. Please upload the DSDT and something that shows capacity (IOReg, iStat, System Profiler) with RehabMan's ACPIBatteryManager. |
@usr-sse2 thank you so much for this investigation with me. Here are all needed stuff. |
RehabMan´s method implements a possible ACPI custom cycle count parameter. Is a good idea to take a look here: https://github.com/RehabMan/OS-X-ACPI-Battery-Driver/blob/master/SSDT-ACPIBATT.dsl#L12 |
Yes, its only formula constant like @usr-sse2 already mentioned earlier. |
as you refer to constant, you did not understand that this is precisely so that the formula is not based on a "constant" but on a parameterized variable |
In my case, is no matter what this variable is, 0 / variable is always zero, but its 8 for me. |
@kecinzer From your DSDT I see that BTIF method is implemented in SSDT. Please upload all (patched) tables from running system with MaciASL's File->Export Tableset. |
Ok, here. |
So, your battery reports cycle count (in BCC field, which is split as BCC0 and BCC1), but doesn't implement _BIX method and instead does it in GBTI method which seems to be proprietary. Your battery patch in one of SSDTs adds this field to _BIF (this is that zprood's technique). It violates the ACPI specification, and we don't want to support it. Instead, an ACPI 4.0 _BIX method should be implemented in your SSDT that would report the same info but in different structure, like here: https://github.com/gsly/OS-X-ACPI-Battery-Driver/wiki/_BIX-Method |
Thank you a lot for you findings. |
Try these two (separately, of course). |
Thanks a lot. I tried SSDT-08-BATT-BIX and cycle count is now 8. So it works great! Full capacity is now different - it shows full capacity as current capacity, as you said. |
Ah, ok :). In IOREG is now bigger design capacity and iStatMenus shows 99% health of battery. With ACPIBatteryManager there was DesignCapacity=MaxCapacity=CurrentCapacity = 0x12c6 |
Thank you so much @usr-sse2 for his work on this issue acidanthera/bugtracker#892. He prepares new SSDT file that fully working with SMCBatteryManager with cycle count and correct display of full designed capacity. Signed-off-by: kecinzer <1541555+kecinzer@users.noreply.github.com>
Thank you so much @usr-sse2 for his work on this issue acidanthera/bugtracker#892. He prepares new SSDT file that fully working with SMCBatteryManager with cycle count and correct display of full designed capacity. Signed-off-by: kecinzer <1541555+kecinzer@users.noreply.github.com>
@usr-sse2 , can you help me with battery also? |
@Mateo1234454545, kecinzer's laptop exposes cycle count through EC register but didn't implement _BIX, so we were able to do it (the register was guessed by name). Look at your DSDT: Method (_BIF, 0, NotSerialized) // _BIF: Battery Information
{
Name (BIF0, Package (0x0D){})
ECG9 (One, BIF0)
Return (BIF0) /* \_SB_.BAT0._BIF.BIF0 */
} Method (ECG9, 2, NotSerialized)
{
Acquire (ECM1, 0xFFFF)
ECWB (0x03, Arg0)
Arg1 [Zero] = One
Local0 = ECRW (0x20)
Arg1 [One] = Local0
Local1 = ECRW (0x1E)
Arg1 [0x02] = Local1
Arg1 [0x03] = One
Local2 = ECRW (0x22)
Arg1 [0x04] = Local2
Divide (Local0, 0x0A, Local5, Local3)
Arg1 [0x05] = Local3
Divide (Local0, 0x21, Local5, Local3)
Arg1 [0x06] = Local3
Divide (Local0, 0x64, Local5, Local3)
Arg1 [0x07] = Local3
Arg1 [0x08] = Local3
Local3 = ECU0 (BS01, Zero)
Arg1 [0x09] = Local3
Local3 = ECRW (0x26)
Local3 = XPTS (Local3)
Arg1 [0x0A] = Local3
Local3 = ECRB (0x29)
Local3 = ECU0 (BS03, Local3)
Arg1 [0x0B] = Local3
Local3 = ECRB (0x28)
Local3 = ECU0 (BS02, Local3)
Arg1 [0x0C] = Local3
Release (ECM1)
} It's obfuscated by getting registers by numeric offsets using ECRW method. There's nothing that we can do here. The approximation that we have is best that we can if the hardware doesn't count cycles or doesn't expose the counter. |
NEVERMIND, I found solution by myself :). Dear @usr-sse2 HP released new BIOS with changes into battery. They added BTIX method. Now your modified SSDT hotfix didn't work - battery can't be seen. I tried to fix it by additional ACPI renames for BTIX method and some edit of SSDT. Now I can see battery, but it shows only 1% charged. I can also see cycle count etc. But current battery level isn't reported. Here is my new DSDT (without renames) and my new SSDT-BATT.aml try. Can you please help me with this? |
I'm so sorry for opening another issue, but I have still this issue (#879.).
I removed my combined battery hack, so now I have correct ACPI patch, but result is still same.
Should be Kext attached to battery like with ACPIBatteryManager?
The text was updated successfully, but these errors were encountered: