- Joined
- Jan 6, 2012
- Messages
- 94
- Motherboard
- MSI Z77-G41
- CPU
- i5-2500
- Graphics
- AMD Radeon R7 250X
- Mobile Phone
Sure, here you go.
Tested this on:
Fujitsu Lifebook A555
i3-5005U
Integrated HD5500
8 GB RAM
HDD 1TB
[Guide] How to patch DSDT for working battery status
- Thread starter RehabMan
- Start date
Tested this on:
Fujitsu Lifebook A555
i3-5005U
Integrated HD5500
8 GB RAM
HDD 1TB
RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,011
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
The only thing I can think of to explain the difference would be a difference in timing.
There is a lot more setup code for each read when using RECB/WECB... therefore the time delta between reads is larger than if the EC fields were being accessed directly. It could be that the EC is not setup to handle the faster speed (Windows may have forced timing in its ACPI implementation).
- Joined
- May 28, 2016
- Messages
- 400
- Motherboard
- Gigabyte Z170N-WIFI (ITX)
- CPU
- i7-6700K
- Graphics
- R9 380X
- Mobile Phone
I have looked for embeddedcontorl in my DSDT.aml.
I have found four entries. One
OperationRegion (RAM, EmbeddedControl, Zero, 0xFF)
and three
OperationRegion (ECRM, EmbeddedControl, Arg0, One)
under different methods
Method (XXXX, 2, Serialized)
{
If (ECON)
{
.
The RAM field has a long list with.. stuff. But none of them apparently use bits over 8. They range from 1-8.
The ECRM fields all contains just one line:
ECRB, 8.
Am I in the wrong .aml? Should I try and look in SSDT1.aml?
Is it possible I have my work cut out for me since I had to apply a special BIOS made for Linux for this laptop to install OS X in the first place, a BIOS made by Lenovo?
Edit: 'embeddedcontrol' is only found in DSDT.aml.
.. should I install the .kext and see what happens? There are no bits over 8 and that makes it alright, does it not?
Edit: I installed the kext. It's showing 100%, which should be correct but I'd rather have it show 99%. I don't know if it's really working now or not.
It reads the amount of battery left in hours (accuracy unknown).
It doesn't feel like I deserve this luck but I am very grateful.
I have found four entries. One
OperationRegion (RAM, EmbeddedControl, Zero, 0xFF)
and three
OperationRegion (ECRM, EmbeddedControl, Arg0, One)
under different methods
Method (XXXX, 2, Serialized)
{
If (ECON)
{
.
The RAM field has a long list with.. stuff. But none of them apparently use bits over 8. They range from 1-8.
The ECRM fields all contains just one line:
ECRB, 8.
Am I in the wrong .aml? Should I try and look in SSDT1.aml?
Is it possible I have my work cut out for me since I had to apply a special BIOS made for Linux for this laptop to install OS X in the first place, a BIOS made by Lenovo?
Edit: 'embeddedcontrol' is only found in DSDT.aml.
.. should I install the .kext and see what happens? There are no bits over 8 and that makes it alright, does it not?
Edit: I installed the kext. It's showing 100%, which should be correct but I'd rather have it show 99%. I don't know if it's really working now or not.
It reads the amount of battery left in hours (accuracy unknown).
It doesn't feel like I deserve this luck but I am very grateful.
Last edited:
RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,011
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
There are no multibyte EC fields in your DSDT.
- Joined
- Jan 19, 2013
- Messages
- 21
- Motherboard
- Samsung NP550P7C-T02CA
- CPU
- Intel Core i7
- Graphics
- #1. HD4000 + Optimus GT630M
Awesome guide man, thanks a lot. I learned quite a bit about editing DSDT's and ACPI syntax from this.
Anyway, everything's working except I'm having the same issue as a lot of others in which the AC adapter status doesn't update. It remains at whatever it was during boot and doesn't change. Battery capacity does change, however. Just charging vs. discharging is flawed.
Due to the fact that system logs show this:
Both with/without the AC adapter plugged in, I'm thinking it might be a bug in the BST?
Current status is always 0x2, as well as battery_status 0x1f.
I attached my post-guide DSDT for you to check out. As well as an IOREG taken while the AC adapter was unplugged. Thanks in advance.
Anyway, everything's working except I'm having the same issue as a lot of others in which the AC adapter status doesn't update. It remains at whatever it was during boot and doesn't change. Battery capacity does change, however. Just charging vs. discharging is flawed.
Due to the fact that system logs show this:
Code:
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: pollingTimeOut called
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: pollBatteryState: path = 1
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: getBatterySTA called
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: setBatterySTA: battery_status = 0x1f
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: getBatteryBIF called
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: validateObject return 0x0
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: setBatteryBIF: acpibat_bif size = 13
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fPowerUnit = 0x1
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fDesignCapacityRaw = 5200
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fMaxCapacityRaw = 3900
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fBatteryTech = 0x1
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fDesignVoltage = 11100
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fCapacityWarningRaw = 0
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fLowWarningRaw = 117
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fDeviceName = ''
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fSerialNumber = ''
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fType = 'LION'
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fManufacturer = 'SAMSUNG Electronics'
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: setBatterySerialNumber called
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: getBatteryBST called
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: setBatteryBST: acpibat_bst size = 4
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fPowerUnit = 0x1
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: currentStatus = 0x2
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fCurrentRate = 1852
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fCurrentCapacity = 3315
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fCurrentVoltage = 11246
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: fAverageRate = 2310
2017-02-04 1:03:37.000 PM kernel[0]: ACPIBatteryManager: Battery is charging.Both with/without the AC adapter plugged in, I'm thinking it might be a bug in the BST?
Current status is always 0x2, as well as battery_status 0x1f.
I attached my post-guide DSDT for you to check out. As well as an IOREG taken while the AC adapter was unplugged. Thanks in advance.
RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,011
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
That output looks to be valid... (showing battery charging at 1852 mA).
currentStatus should be 1 when battery is discharging, 2 when charging, and zero when neither charging or discharging (eg. plugged in, fully charged).
If you suspect your DSDT _BST is buggy, use ACPIDebug.kext to debug it...
- Joined
- Jan 19, 2013
- Messages
- 21
- Motherboard
- Samsung NP550P7C-T02CA
- CPU
- Intel Core i7
- Graphics
- #1. HD4000 + Optimus GT630M
Right, however that output is shown when the AC adapter is not plugged in and the battery is discharging. In other words, the output doesn't change regardless of the actual physical state. Whatever state the battery was in at boot is the status it remains at. So possibly my issue is elsewhere because the BST is giving a correct status at boot time?
RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,011
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
Something is wrong with your DSDT...
Use ACPIDebug.kext and debug ACPIBatteryManager.kext to debug it further.
- Joined
- Jan 19, 2013
- Messages
- 21
- Motherboard
- Samsung NP550P7C-T02CA
- CPU
- Intel Core i7
- Graphics
- #1. HD4000 + Optimus GT630M
Gotcha. Just looked over your guide on how to use output method calls. Could you give me a hint as to where I should begin investigating? I assume BST, but if I'm being honest I'm not 100% sure what all of these variables/values represent.
RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,011
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
_BST gives current status. Read the ACPI spec.
And if you need me to look at what you're actually doing (maybe you made a simple mistake), read post #1, "Problem Reporting". Your initial post did not contain the required files.