Battery Manager with Fix for Boot without Batteries

[tegezee]

Attached you will find what I believe to be the final release of the battery manager kexts. In theory, this is applicable to ML and Lion, although I've only tested it on ML. I don't currently have a Lion partition to test with. It is built with Xcode Version 4.4.1 (4F1003), host OS is ML 10.8.1.

This is the same as zprood's version from this link: http://www.insanlynac.com/forum/index.php?showtopic=272459 (note you will have to fix that URL because of disagreements between tonymac & Insanely Mac), except for a fix for the case where the computer is started without any batteries installed. With my fix here it will correctly show running "Source: Power Adapter" and will of course use the "Power Adapter" power profile in energy preferences. It was simple two line change and is documented in the source code, attached. As per APLS open source license, I include the source and documented my changes along with date of modification.

I have built a 'Release' version and bumped the Version to "1.1" to make it easier to identify. Both AppleACPIBatteryManager.kext and AppleSmartBatteryManager.kext are included and both contain the fix. Please note that generally AppleSmartBatteryManager.kext is the kext that loads, and I believe that AppleACPIBatteryManager.kext is not needed (I usually remove it after the HP ProBook Installer installs it). I include it here just because zprood included it in his version.

Tegezee has tried it and he was one of the folks that had trouble with my version a couple of weeks ago... this time it is good. Several others have downloaded my test version above and I've heard nothing. I'm assuming no news is good news.

Please test and report any issues here.

Tegezee -- Assuming it is good, this is ready to be integrated in the Installer.

Why are you replacing AppleACPIBatteryManager.kext? I'm using the one in the installer & your AppleSmartBatteryManager.kext and it's working fine. Plus the file sizes are dramatically different, what did you do different with AppleACPIBatteryManager.kext?

 

[RehabMan]

Can you please verify my DSDT battery section to be compatible with your kexts?

It definitely doesn't have the extension in _BTIF to add cycle count for System Report, because there is no Store at index 0xD, but that information really isn't that important anyway. I wish I understood a little more about these DSDT patches, but the fact is I don't totally understand how to do a complete DSDT patch from beginning to end.

For reasons that I just don't understand, the patches for the 4x30 series DSDTs break most of the EC fields from their original 16 bits into two 8 bit parts. Then the code in the actual DSDT methods combine them back by calling a B1B2 method when a 16-bit result is required. I don't really understand why this process was required, so I'm not sure if the same thing has to be done with your DSDT. Maybe someone who is aware as to why this was done, can chime in...

If all these 8 to 16 bit changes aren't necessary, then you could add cycle count pretty easy with only a few changes. I have attached a changed file, so you can see what might work. Obviously, I don't have gen3 ProBook like yours, so I can't really test. One thing for sure... the battery section of the DSDTs are very similar. Here's the diff:

localhost:Downloads Admin$ diff dsdt4340s_patched.dsl dsdt4340s_patched_cc.dsl
6576a6577
>                             Store (BCC, Index (DerefOf (Index (NBTI, Arg0)), 0x0D))
12097c12098
<             Package (0x0D)
---
>             Package (0x0E)
12111c12112,12113
<                 "Hewlett-Packard"
---
>                 "Hewlett-Packard",
>                 Zero,
12113c12115
<             Package (0x0D)
---
>             Package (0x0E)
12127c12129,12130
<                 "Hewlett-Packard"
---
>                 "Hewlett-Packard",
>                 Zero,
localhost:Downloads Admin$

Have you tried the kext ... and if so, what did you discover?

 

[RehabMan]

Why are you replacing AppleACPIBatteryManager.kext? I'm using the one in the installer & your AppleSmartBatteryManager.kext and it's working fine. Plus the file sizes are dramatically different, what did you do different with AppleACPIBatteryManager.kext?

As I stated in the post you replied to, AppleACPIBatteryManager.kext isn't even loading when you have AppleSmartBatteryManager.kext present. This is because the OS is only going to load one driver for device PNP0C0A. How it decides to load AppleSmartBatteryManager.kext as a preference to AppleACPIBatteryManager.kext, I don't really know -- but that is what it does.

At any rate, the code for both is pretty much identical (which is a PITA to maintain, by the way, as changes must be duplicated between the two). If you remove AppleSmartBatteryManager.kext, or vanilla AppleSmartBatteryManager.kext is installed, then AppleACPIBatteryManager.kext will load. The problem with having vanilla or non-existent AppleSmartBatteryManager.kext thus allowing AppleACPIBatteryManager.kext to load is that various third party utilities like to look at the IO registry specifically for AppleSmartBatteryManager because Apple's product doesn't use AppleACPIBatteryManager.kext anymore (thus why the OS doesn't include it), and if you're using AppleACPIBatteryManager.kext, of course, that IO registry is not there, so the third-party apps fail to work.

So, the best configuration is to simply replace AppleSmartBatteryManager.kext with the one I provided here. My suggestion would be to also remove AppleACPIBatteryManager.kext from the Installer as it isn't going to load on a system with a proper AppleSmartBatteryManager.kext and therefore isn't necessary at all. I only included it here as it was part of zprood's project, and I was really just trying to do a surgical fix to just fix the "boot w/ no battery installed" issue, and make as minimal changes as possible. What we want in the installer is just my AppleSmartBatteryManager.kext and AppleACPIBatteryManager.kext should be removed.

My guess on the question of file sizes is that I would say the files you have in the Installer right now are probably debug versions with symbols combined into the binary. And that is why they are much larger. Right now, the version of Xcode I have places the debugging information in separate files, but maybe the version BigDonkey was using was doing something different.

During beta/testing phases of projects developers will build non-optimized binaries that have extra debugging information including symbols and such that are useful in a debugger. A non-optimized binary is also easier to debug as the order of execution generally matches better with the source code (a code optimizer is free to re-arrange the order of execution to increase speed or save space as long as the result is the same -- this confuses us humans when we try to step through code in a debugger). Generally, when you release the final build, you create a compiler optimized binary that is smaller and faster.

 

[corebuilder]

Tegezee has tried it and he was one of the folks that had trouble with my version a couple of weeks ago... this time it is good. Several others have downloaded my test version above and I've heard nothing. I'm assuming no news is good news.

Please test and report any issues here.

Tegezee -- Assuming it is good, this is ready to be integrated in the Installer.

I had tested and its seams good but 98% showing at 100% charge

 

[corebuilder]

Okay people before you install RehabMan's battery kext and expect it to work, there is some things you need to do. You can just install it and if it works great but instead of draining the battery to 4-5% just do this:

Reseting the smc (sort of speak)
*Turn off the laptop
*Take out your battery & ac adapter
*Hold down the power button for 30-60 seconds (just hold it for 60)
*Put the battery back in without the ac adapter
*Turn on the laptop
*(OPTIONAL)boot into bios & reset the defaults
*Now just boot up without ac adapter

Trust me this works, when you get to your desktop plugin your ac adapter.

tested worked for me

 

[RehabMan]

I had tested and its seams good but 98% showing at 100% charge

If what you are saying is that you have percentage showing at 98% on the menu bar, but the system saying "Not charging", that can happen if you just allow the battery to discharge to only 98%. The battery sub-system will not charge at that point just for the 2% extra capacity to help the battery have a longer total lifetime (lessen small discharge/recharge cycles). If you let it run down further, say to 80%, then plug in the power adapter, it will then begin to charge again.

If what you are saying is that you have percentage showing at 98% on the menu bar, but the system saying "Battery is Charged", that can happen if you battery is slightly degraded. That is where the battery can no longer sustain a 100% charge. You can find out about your specific battery health in About This Mac, More Info, System Report, and even more information by running the following in Terminal:

ioreg -n AppleSmartBattery -r AppleSmartBattery

If you see your battery never reach 100% charge, I think it is possible you have MaxCapacity less than DesignCapacity. At least this is what I understand so far.

 

[eleron]

It definitely doesn't have the extension in _BTIF to add cycle count for System Report, because there is no Store at index 0xD, but that information really isn't that important anyway. I wish I understood a little more about these DSDT patches, but the fact is I don't totally understand how to do a complete DSDT patch from beginning to end.

For reasons that I just don't understand, the patches for the 4x30 series DSDTs break most of the EC fields from their original 16 bits into two 8 bit parts. Then the code in the actual DSDT methods combine them back by calling a B1B2 method when a 16-bit result is required. I don't really understand why this process was required, so I'm not sure if the same thing has to be done with your DSDT. Maybe someone who is aware as to why this was done, can chime in...

http://www.insanlynac.com/forum/index.php?showtopic=272459&hl=b1b2&st=0
(change insanlynac to ...)

 

[RehabMan]

http://www.insanlynac.com/forum/index.php?showtopic=272459&hl=b1b2&st=0
(change insanlynac to ...)

Oh, I've seen that thread. And I understand what they did with the B1B2 method and all the conversions of 16-bit fields to 8-bit fields. I just don't understand why.

It seems to me the layout of the EC and the implementation of the various ACPI battery methods are exactly that... private implementation for the DSDT. The only thing that should matter is that the semantics of the ACPI method results are intact (ie. that when called upon, it returns the correct values). Probably tomorrow I will experiment with my DSDT just to see if all these things can be converted back to their native 16-bit. I think it was originally done to get some battery manager working that was reading the EC values directly without going through the various ACPI methods. But with the battery manager code we are using, which is using the ACPI methods, the only dependency should be that the methods work and return the expected data to the battery kext.

There's probably something I don't understand, because it looks like a lot of work to do if it was all unnecessary...

 

[RehabMan]

Oh, I've seen that thread. And I understand what they did with the B1B2 method and all the conversions of 16-bit fields to 8-bit fields. I just don't understand why.

It seems to me the layout of the EC and the implementation of the various ACPI battery methods are exactly that... private implementation for the DSDT. The only thing that should matter is that the semantics of the ACPI method results are intact (ie. that when called upon, it returns the correct values). Probably tomorrow I will experiment with my DSDT just to see if all these things can be converted back to their native 16-bit. I think it was originally done to get some battery manager working that was reading the EC values directly without going through the various ACPI methods. But with the battery manager code we are using, which is using the ACPI methods, the only dependency should be that the methods work and return the expected data to the battery kext.

There's probably something I don't understand, because it looks like a lot of work to do if it was all unnecessary...

Guess what? Some code somewhere (AppleACPIPlatform/AppleACPIFamily maybe) reads these values directly from the EC and, I guess, depends on the specific names used. That's some crazy stuff (to me anyway). I guess Apple doesn't have to worry about encapsulation when they build their own machines... Or I still don't understand...

But I'm pretty sure that for those folks who have DSDT's with a lot of 16-bit battery status/info fields, you gotta do the patches to change them to 8-bit layout and make the appropriate calls to the B1B2 method to do it. There's no way around it, I don't think. I think there is some automated ways to do these patches though. Haven't looked into that yet.

P.S. I'm not just doing this to torture myself. I'd like to really understand what's going on with the DSDT patching stuff (curious person). And all this will likely prepare me for the time I try to hack a different machine... one which isn't so easy with pre-created DSDTs and everything...

 

[Elrom]

Have you tried the kext ... and if so, what did you discover?

Yes, i tried, i install your kexts and edited dsdt, but have no success - only X sign on battery no matter - from battery or from AC adaptor.
In console i see messages:
8/27/12 7:31:13.000 PM kernel[0]: AppleSmartBatteryManager:getBatteryBIF(0xE00002BC) failed
8/27/12 7:31:13.000 PM kernel[0]: AppleSmartBatteryManager:getBatteryBST(0xE00002BC) failed

What can i do next?

Thank you very much!!