[Guide] How to patch DSDT for working battery status

[cwk9852]

How to patch DSDT for working battery status

It is the large cycle count (0x54). That cycle count is estimated by difference between MaxCapacity and DesignCapacity (0x1004 and 0x1aea). If the numbers for MaxCapacity/DesignCapacity are accurate, your battery is significantly degraded

Ive been doing some research, just to see what would happen, I did a full battery discharge earlier, using the smart battery calibration in the UEFI. Then I did an EC clear (reset?). The message is gone, seems like everything OK for now, but I suspect it will just pop up again... There are deep EC problems.. according to this recent discovery regarding Linux http://www.phoronix.com/scan.php?px=MTYyMjU&page=news_item ...

The root cause of all these issues come down to the embedded controller on several Samsung laptops -- when the EC receives too many events, the embedded controller decides to no longer interrupt the OS with any more events until they have been queried. Linux, on the other hand, isn't proactively querying the controller since it receives no interrupts that there are new events to handle. These EC events are generated while the laptop is in its S3 sleep state, which end up being useless when the system resumes, and aren't queried by Linux when they occur with the laptop being asleep.

Essentially the embedded controller is getting stuffed with too many queries, the buffer is full, and is not emptying these events, even after reboots. The fix to the reported bug is removing the battery and hitting the reset button (on laptops with removable batteries and a reset button hidden behind there), flashing the BIOS to ultimately reset the EC, or a simple debug user-space utility was written that forces queries of the embedded controller. When that utility is run, the Samsung performance is fixed.

Besides performance, this bug was tracked down to issues of AC power not being detected, lid closures not triggering suspend, ambient light sensors not triggering the keyboard backlight, and other issues.

I have an NP540, this references the NP530, but my UEFI/BIOS lists my device as a 530, so Im guessing we share a board ... but its a little confusing because this is afaik supposed to be a seven series HM76 yet I see others with six series chipsets, but they share a BIOS, so I think there are some larger firmware issues there so I guess that takes roundabout back to the problem of closed-source UEFI and Firmware. It doesn't seem very good to me I share a UEFI with the 530 who has a different chipset.. but then again maybe I don't know what I'm talking about, and I'm ranting and using run-on sentences, but you get the idea...

The message about servicing the battery returns if I connect the AC Adapter after boot (and I believe persists until EC clear/reset).

 

[cwk9852]

How to patch DSDT for working battery status

Windows isn't affected (hypothesis) because it uses WMI. It's been a long standing issue from the looks of the support threads. I think something like what they come up with for linux kernel patch might be a solution. Its basically an EC poller triggered on initialization. Pretty recent discovery of the true nature of the problem it looks like.. at least for linux kernel.

https://git.kernel.org/cgit/linux/k.../?id=27095111cbafd3212c7e9a4a8cef1099b7520ca8

Would you be open to the possibility of adding a function like this to ACPIBatteryManager.kext? I'm not sure if thats appropriate place for such a function, that is to say if it would work in that kext. The linux one does an OEM check, but I don't think that would necessarily work in our case because Clover patches OEM to Apple. I'm actually just starting to learn C (like the last two weeks), so I barely understand what I'm looking at.

If we can implement something that clears it or polls, I think it will be fix many issues:lid sleep, maybe lid wake, definitely battery fix, probably have benefits to backlight control. Right now I have to press the ACPI power button once to wake and then again to turn the display back on after sleep.

If you want to take a look a current IOReg, the information reported is very different from the one posted in #435. The only change was the EC clear. (I don't think its a reset). The reported data is more accurate than before, but still "behind." Right now its been sitting at 99% with a few minutes until Full for almost two hours. Also, the LED charging indicator that turns green when on AC power and orange when charging. Its currently orange, agreeing with OS X (charging..). ((Actually it just turned green and OS X says Battery is Charged (but 99% not 100%) If I disconnect the AC adapter though everything EC starts jamming up.

 

[RehabMan]

How to patch DSDT for working battery status

Windows isn't affected (hypothesis) because it uses WMI. It's been a long standing issue from the looks of the support threads. I think something like what they come up with for linux kernel patch might be a solution. Its basically an EC poller triggered on initialization. Pretty recent discovery of the true nature of the problem it looks like.. at least for linux kernel.

https://git.kernel.org/cgit/linux/k.../?id=27095111cbafd3212c7e9a4a8cef1099b7520ca8

Would you be open to the possibility of adding a function like this to ACPIBatteryManager.kext? I'm not sure if thats appropriate place for such a function, that is to say if it would work in that kext. The linux one does an OEM check, but I don't think that would necessarily work in our case because Clover patches OEM to Apple. I'm actually just starting to learn C (like the last two weeks), so I barely understand what I'm looking at.

If we can implement something that clears it or polls, I think it will be fix many issues:lid sleep, maybe lid wake, definitely battery fix, probably have benefits to backlight control. Right now I have to press the ACPI power button once to wake and then again to turn the display back on after sleep.

If you want to take a look a current IOReg, the information reported is very different from the one posted in #435. The only change was the EC clear. (I don't think its a reset). The reported data is more accurate than before, but still "behind." Right now its been sitting at 99% with a few minutes until Full for almost two hours. Also, the LED charging indicator that turns green when on AC power and orange when charging. Its currently orange, agreeing with OS X (charging..). ((Actually it just turned green and OS X says Battery is Charged (but 99% not 100%) If I disconnect the AC adapter though everything EC starts jamming up.

All OS X battery status/alerts are based on what is in ioreg provided by ACPIBatteryManager. Please look at yours in detail. As stated previously, it is likely the large cycle count that triggers the specific message you're seeing.

 

[Mactel]

How to patch DSDT for working battery status

Hi RehabMan,
Thanks for putting together such detailed instructions. I'm trying to get an Acer 5720 to work and don't know which set of DSDT patches to use or if there is just something minor in the DSDT to get it to work. I just get the battery with the X if I install your kext. I've attached my DSDT if you could please give me some direction.

Thanks

 

[RehabMan]

How to patch DSDT for working battery status

Hi RehabMan,
Thanks for putting together such detailed instructions. I'm trying to get an Acer 5720 to work and don't know which set of DSDT patches to use or if there is just something minor in the DSDT to get it to work. I just get the battery with the X if I install your kext. I've attached my DSDT if you could please give me some direction.

Thanks

Did you go through the process with the example DSDT yet?

 

[Mactel]

How to patch DSDT for working battery status

Did you go through the process with the example DSDT yet?

Yes and this is why I wasn't understanding where to go next. From my understanding of the instructions, it looks like there aren't large variables to break down into 8bit pieces? Below is a snippet of the DSDT.

OperationRegion (RAM, EmbeddedControl, Zero, 0xFF)
Field (RAM, ByteAcc, Lock, Preserve)
{
CMD0, 8,
Offset (0x02),
NBID, 8,
Offset (0x08),
DAT0, 8,
DAT1, 8,
, 2,
WLED, 2,
BLED, 2,
Offset (0x51),
BLST, 1,
Offset (0x52),
WDEV, 1,
BDEV, 1,
WEPM, 1,
Offset (0x70),
CRTS, 1,
KLID, 1,
, 3,
KACS, 1,
Offset (0x71),
WSTS, 1,
BSTS, 1,
Offset (0x77),
, 3,
LSTS, 1,
Offset (0x82),
MSTP, 4,
Offset (0x83),
CSTP, 4,
Offset (0x88),
NB0A, 1,

 

[RehabMan]

How to patch DSDT for working battery status

Yes and this is why I wasn't understanding where to go next. From my understanding of the instructions, it looks like there aren't large variables to break down into 8bit pieces? Below is a snippet of the DSDT.

OperationRegion (RAM, EmbeddedControl, Zero, 0xFF)
Field (RAM, ByteAcc, Lock, Preserve)
{
CMD0, 8,
Offset (0x02),
NBID, 8,
Offset (0x08),
DAT0, 8,
DAT1, 8,
, 2,
WLED, 2,
BLED, 2,
Offset (0x51),
BLST, 1,
Offset (0x52),
WDEV, 1,
BDEV, 1,
WEPM, 1,
Offset (0x70),
CRTS, 1,
KLID, 1,
, 3,
KACS, 1,
Offset (0x71),
WSTS, 1,
BSTS, 1,
Offset (0x77),
, 3,
LSTS, 1,
Offset (0x82),
MSTP, 4,
Offset (0x83),
CSTP, 4,
Offset (0x88),
NB0A, 1,

If you search your DSDT, you eventual run into this:

                    Field (RAM, ByteAcc, Lock, Preserve)
                    {
                                Offset (0xE0), 
                        BSRC,   16, 
                        BSFC,   16, 
                        BSPE,   16, 
                        BSAC,   16, 
                        BSVO,   16, 
                            ,   15, 
                        BSCM,   1, 
                        BSCU,   16, 
                        BSTV,   16
                    }

                    Field (RAM, ByteAcc, Lock, Preserve)
                    {
                                Offset (0xE0), 
                        BSDC,   16, 
                        BSDV,   16, 
                        BSSN,   16
                    }

                    Field (RAM, ByteAcc, NoLock, Preserve)
                    {
                                Offset (0xE0), 
                        BSMN,   128
                    }

                    Field (RAM, ByteAcc, NoLock, Preserve)
                    {
                                Offset (0xE0), 
                        BSDN,   128
                    }

                    Field (RAM, ByteAcc, NoLock, Preserve)
                    {
                                Offset (0xE0), 
                        BSCH,   128
                    }

                    Mutex (BATM, 0x07)

Which is a bit more interesting...

 

[Mactel]

How to patch DSDT for working battery status

If you search your DSDT, you eventual run into this:

Which is a bit more interesting...

Thanks for pointing me in the right direction. Its starting to make more sense. The one last issue that I'm having a hard time figuring out is the offsets. Could you please give me some pointers there?

 

[RehabMan]

How to patch DSDT for working battery status

Thanks for pointing me in the right direction. Its starting to make more sense. The one last issue that I'm having a hard time figuring out is the offsets. Could you please give me some pointers there?

Your multibyte registers seem to be all at 0xE0. The offset of any given item is the offset of the prior item + prior item size in bytes, unless an Offset directive is used to change the effective offset.

 

[Mactel]

How to patch DSDT for working battery status

Thanks for pointing me in the right direction. Its starting to make more sense. The one last issue that I'm having a hard time figuring out is the offsets. Could you please give me some pointers there?

Thanks RehabMan for all the help. Its working perfectly now.