Contribute
Register

Battery Manager with Fix for Boot without Batteries

Status
Not open for further replies.
dpg12 said:
For what it's worth, your patch (I didn't apply all of it) allows for the retrieval of the battery's serial number and other extended information correctly (it's much cleaner than what I had taken previously). Thanks, RehabMan!
Click to expand...

So, I take it the patch works for you...
 
I'm using a mix of battery patches (probably a contributing factor as why I have to call the "charger removed/inserted" method in _WAK so that the laptop realises that I did actually take out the charger while it was sleeping...), so, really, the only thing I can say that works for sure is the serial number retrieval etc. as I'm not seeing "M3n" and the other default values but I'll apply your patch to this laptop's original DSDT, inject graphics and AR9285 properties and reply again with the results... :)
 
dpg12 said:
I'm using a mix of battery patches (probably a contributing factor as why I have to call the "charger removed/inserted" method in _WAK so that the laptop realises that I did actually take out the charger while it was sleeping...), so, really, the only thing I can say that works for sure is the serial number retrieval etc. as I'm not seeing "M3n" and the other default values but I'll apply your patch to this laptop's original DSDT, inject graphics and AR9285 properties and reply again with the results... :)
Click to expand...

If a patch works, it would be nice if people could respond with their complete model# of laptop (BIOS version too), such that I can add that information to the comments. It might help others find such a patch and would help if I ever contemplate putting together a patch repository...
 
Success!!! Well kinda.
I patched using MaciASL, but it wouldn't compile with ACPI 5.0 so I used ACPI 4.0.
Then added new DSDT and BAM!!! Battery METER WORKS!!!
but it killed trackpad and keyboard!

Booted -v and saw some problems with my added kexts (ElanTouchPad.kext and ApplePS2Controller.kext)
So I booted -f and track/key came back...

I wondered if you know a way to fix? Is it my KernelCache or kexts or DSDT or what? I've Rebuilt Cache and Reset Permissions with Kext Wizard.
I also have a 2nd Partition without a DSDT or added kexts, and Track/Keyboard work flawlessly. Is that strange??? (oh but no Fn Keys)

I use v2.7.5 of ElanTouchPad.kext and ApplePS2Controller.kext found at http://forum.osxlatitude.com/index.php?/topic/1948-elan-touchpad-driver-mac-os-x/
I really want Fn keys to work also!

I want to say thank you again for your help already!
 
jesselid said:
Success!!! Well kinda.
I patched using MaciASL, but it wouldn't compile with ACPI 5.0 so I used ACPI 4.0.
Then added new DSDT and BAM!!! Battery METER WORKS!!!
but it killed trackpad and keyboard!
Click to expand...

I don't think the DSDT edits were related to your trackpad/keyboard loss... Probably a different issue.

BTW, I use ACPI 4.0 for everything generally. There is no reason to use ACPI 5.0. Even Apple's own DSDTs are only 4.0 compliant.

Booted -v and saw some problems with my added kexts (ElanTouchPad.kext and ApplePS2Controller.kext)
So I booted -f and track/key came back...

I wondered if you know a way to fix? Is it my KernelCache or kexts or DSDT or what? I've Rebuilt Cache and Reset Permissions with Kext Wizard.
I also have a 2nd Partition without a DSDT or added kexts, and Track/Keyboard work flawlessly. Is that strange??? (oh but no Fn Keys)
Click to expand...

Take a look at the output from bdmesg (in Terminal). You may be surprised what you see with multiple partitions (partititons are sometimes not as separate as you would like).

Also, monitor output in system.log during kext cache rebuild. You could have a problem with the mix of kexts you have installed, especially if you've been installing lots of replacement/patched kexts for the ones provided by the system.

Usually a system that works with "-f" but doesn't work otherwise, points to a problem of mismatched, incorrect, or otherwise corrupt kexts, and that problem (errors) will usually show during a cache rebuild.

I use v2.7.5 of ElanTouchPad.kext and ApplePS2Controller.kext found at http://forum.osxlatitude.com/index.php?/topic/1948-elan-touchpad-driver-mac-os-x/
I really want Fn keys to work also!
Click to expand...

No experience with ELAN here, so I'm not aware of any issues those kexts linked may cause...
 
RehabMan said:
If a patch works, it would be nice if people could respond with their complete model# of laptop (BIOS version too), such that I can add that information to the comments. It might help others find such a patch and would help if I ever contemplate putting together a patch repository...
Click to expand...

Your patch does seem to work! The battery meter is present and the percentage is going down steadily. The laptop isn't detecting when I've put the charger in but that's most likely due to the fact that I forgot to apply the AppleACAdapter kext from your ProBook repository or the laptop itself isn't reporting the charger has been inserted (at 95%, the battery LED on the front of the laptop is reporting the battery is full).

This is with an Asus N55SL, BIOS rev. 204. I must state that this BIOS is modified, however: more options have been unlocked, the CPU microcode was upgraded, AES-NI enabled and the lock on MSR 0xE2 removed. While I doubt that any of that even makes a remote difference, I'm just stating it now in case it somehow does

EDIT: I know why the charger isn't being detected - I'm dropping SSDT tables and I forgot to fix PNOT()
 
WOW! Thanks again!
I'm learning a lot!
I also updated my signature cause its helpful like you said.
 
dpg12 said:
Your patch does seem to work! The battery meter is present and the percentage is going down steadily. The laptop isn't detecting when I've put the charger in but that's most likely due to the fact that I forgot to apply the AppleACAdapter kext from your ProBook repository or the laptop itself isn't reporting the charger has been inserted (at 95%, the battery LED on the front of the laptop is reporting the battery is full).
Click to expand...

I don't have an AppleACAdapter kext... On the ProBook we simply rename the AC device to ADP1 which loads the native Apple kext.

Tweaked patch for your DSDT:
Code: 
#    Replace all instances of AC with ADP1
into_all all code_regex \(AC0, replaceall_matched begin (ADP1, end;
into all label AC0 set_label begin ADP1 end;

#   Power fix - uses AppleSmartBatteryManager.kext  instead VoodooBattery
into device label ADP1 code_regex Name\s+\(_PRW,[\s\S]*\}\) remove_matched;
into device label ADP1 insert
begin
Name (_PRW, Package() { 0x18, 0x03 })
end;

This is with an Asus N55SL, BIOS rev. 204. I must state that this BIOS is modified, however: more options have been unlocked, the CPU microcode was upgraded, AES-NI enabled and the lock on MSR 0xE2 removed. While I doubt that any of that even makes a remote difference, I'm just stating it now in case it somehow does
Click to expand...

Thanks.
 
RehabMan said:
I don't have an AppleACAdapter kext... On the ProBook we simply rename the AC device to ADP1 which loads the native Apple kext.

Tweaked patch for your DSDT:
Code: 
#    Replace all instances of AC with ADP1
into_all all code_regex \(AC0, replaceall_matched begin (ADP1, end;
into all label AC0 set_label begin ADP1 end;

#   Power fix - uses AppleSmartBatteryManager.kext  instead VoodooBattery
into device label ADP1 code_regex Name\s+\(_PRW,[\s\S]*\}\) remove_matched;
into device label ADP1 insert
begin
Name (_PRW, Package() { 0x18, 0x03 })
end;



Thanks.
Click to expand...

Thanks a lot, but I realised why the charger wasn't being detected (until after a long while) - when the charger is removed/inserted, method _QA0 is called, which in turn calls PNOT() which then blocks looking for PDC* variables which do not exist any more since I'm using DropSSDT. I worked around that the last time by using CondRefOf:

Code: 
Before:
            If (And (PDC0, 0x08))
            {
                Notify (\_PR.CPU0, 0x80)
                If (And (PDC0, 0x10))
                {
                    Sleep (0x64)
                    Notify (\_PR.CPU0, 0x81)
                }
            }

After:
            If (CondRefOf (PDC0))
            {
                If (And (PDC0, 0x08))
                {
                    Notify (\_PR.CPU0, 0x80)
                    If (And (PDC0, 0x10))
                    {
                        Sleep (0x64)
                        Notify (\_PR.CPU0, 0x81)
                    }
                }
            }
            Else
            {
                Notify (\_PR.CPU0, 0x80)
                Sleep (0x64)
                Notify (\_PR.CPU0, 0x81)
            }

(repeated for PDC{1, 2, ...} with the CPU* numbers incrementing)
 
dpg12 said:
Thanks a lot, but I realised why the charger wasn't being detected (until after a long while) - when the charger is removed/inserted, method _QA0 is called, which in turn calls PNOT() which then blocks looking for PDC* variables which do not exist any more since I'm using DropSSDT. I worked around that the last time by using CondRefOf:

Code: 
Before:
            If (And (PDC0, 0x08))
            {
                Notify (\_PR.CPU0, 0x80)
                If (And (PDC0, 0x10))
                {
                    Sleep (0x64)
                    Notify (\_PR.CPU0, 0x81)
                }
            }

After:
            If (CondRefOf (PDC0))
            {
                If (And (PDC0, 0x08))
                {
                    Notify (\_PR.CPU0, 0x80)
                    If (And (PDC0, 0x10))
                    {
                        Sleep (0x64)
                        Notify (\_PR.CPU0, 0x81)
                    }
                }
            }
            Else
            {
                Notify (\_PR.CPU0, 0x80)
                Sleep (0x64)
                Notify (\_PR.CPU0, 0x81)
            }

(repeated for PDC{1, 2, ...} with the CPU* numbers incrementing)
Click to expand...

You could also pull in the portions (into DSDT) of the SSDT that you need, or even place it in a separate SSDT-1.aml (I'm assuming you have SSDT.AML for CPU speedstep).
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top