Contribute
Register

[Guide] How to patch DSDT for working battery status

How to patch DSDT for working battery status

Hi, Rehabman, I have met problem again.

I help other people make a battery patch recently. And for this dsdt, I think I have modifed all things that should be modified, but actually battery is always at 0% status, and I have already try the “Fix Mutex with non-zero SyncLevel” patch, but it is always at 0% status.

I wander your help when you have time. I can't find the errors in my patch by myself.

So, here is a original dsdt.dsl and the patch that I made.

View attachment battery_patch_help_check.zip
 
How to patch DSDT for working battery status

Hi, Rehabman, I have met problem again.

I help other people make a battery patch recently. And for this dsdt, I think I have modifed all things that should be modified, but actually battery is always at 0% status, and I have already try the “Fix Mutex with non-zero SyncLevel” patch, but it is always at 0% status.

I wander your help when you have time. I can't find the errors in my patch by myself.

So, here is a original dsdt.dsl and the patch that I made.

View attachment 98770

Apply "Fix Mutex with non-zero SyncLevel" multiple times (until there are no more changes).

It is a bug in MaciASL that I haven't had time to track down.

Note: I added a few extra copies (10x) of the patch in "Fix Mutex..." as a work-around.
 
How to patch DSDT for working battery status

Apply "Fix Mutex with non-zero SyncLevel" multiple times (until there are no more changes).

It is a bug in MaciASL that I haven't had time to track down.

Thanks for your reply.:)
 
How to patch DSDT for working battery status

Hi, Rehabman, I'm sorry for disturbing you again.

I meet a new problem that the Field SMD0 is 100bits in a DSDT. So, I have no idea about how to deal with it.

Here is a original DSDT.dsl and my initial patch for it.

View attachment ThinkPad_E40_With_SMD0_is_100bits.zip
 
How to patch DSDT for working battery status

Hi, Rehabman, I'm sorry for disturbing you again.

I meet a new problem that the Field SMD0 is 100bits in a DSDT. So, I have no idea about how to deal with it.

Here is a original DSDT.dsl and my initial patch for it.

View attachment 99380

My first try would be to treat it as if it is 104 bits (multiple of 8, 13 bytes). That is, call WECB/RECB with 104 instead of 100. Because WECB/RECB will truncate down to 96 bits (12 bytes) if you pass 100, so you want to avoid that and read 13 bytes from the EC. It should be interesting if the system does the right thing when you transfer that result (104 bits) to FW00 (100 bits).

The alternative would be to treat it as two separate items. First item a 96 bit buffer. Second item a 4 bit EC field. Same for both SMD0 and FW00, so SMD0 would look like:
Code:
SMDX, 96
SMD1, 4
...

FWXX, 96
FW01, 4

But then some of the code patching gets a bit tricky...

The other thing to consider is that BFWL is only called from EC.HKEY.BFWL, which sounds like some sort of hotkey processing and therefore probably not battery related and probably not called from OS X. In fact, BFWL is only called from MHPF, which, like SMWR (see below), is not accessed from DSDT.

The other place SMD0 is accessed is from SMWR which is not called from anywhere in the DSDT (could be called from one of the SSDTs).

As you can see:
Code:
            Device (HKEY)
            {
                Name (_HID, EisaId ("IBM0068"))  // _HID: Hardware ID

HKEY is some kind of vendor specific (IBM) device intended to attach to a vendor specific driver on Windows.
 
How to patch DSDT for working battery status

My first try would be to treat it as if it is 104 bits (multiple of 8, 13 bytes). That is, call WECB/RECB with 104 instead of 100. Because WECB/RECB will truncate down to 96 bits (12 bytes) if you pass 100, so you want to avoid that and read 13 bytes from the EC. It should be interesting if the system does the right thing when you transfer that result (104 bits) to FW00 (100 bits).

The alternative would be to treat it as two separate items. First item a 96 bit buffer. Second item a 4 bit EC field. Same for both SMD0 and FW00, so SMD0 would look like:
Code:
SMDX, 96
SMD1, 4
...

FWXX, 96
FW01, 4

But then some of the code patching gets a bit tricky...

The other thing to consider is that BFWL is only called from EC.HKEY.BFWL, which sounds like some sort of hotkey processing and therefore probably not battery related and probably not called from OS X. In fact, BFWL is only called from MHPF, which, like SMWR (see below), is not accessed from DSDT.

The other place SMD0 is accessed is from SMWR which is not called from anywhere in the DSDT (could be called from one of the SSDTs).

As you can see:
Code:
            Device (HKEY)
            {
                Name (_HID, EisaId ("IBM0068"))  // _HID: Hardware ID

HKEY is some kind of vendor specific (IBM) device intended to attach to a vendor specific driver on Windows.

Thanks, thanks! I'll try your method.
:)
 
How to patch DSDT for working battery status

My first try would be to treat it as if it is 104 bits (multiple of 8, 13 bytes). That is, call WECB/RECB with 104 instead of 100. Because WECB/RECB will truncate down to 96 bits (12 bytes) if you pass 100, so you want to avoid that and read 13 bytes from the EC. It should be interesting if the system does the right thing when you transfer that result (104 bits) to FW00 (100 bits).

The alternative would be to treat it as two separate items. First item a 96 bit buffer. Second item a 4 bit EC field. Same for both SMD0 and FW00, so SMD0 would look like:
Code:
SMDX, 96
SMD1, 4
...

FWXX, 96
FW01, 4

But then some of the code patching gets a bit tricky...

The other thing to consider is that BFWL is only called from EC.HKEY.BFWL, which sounds like some sort of hotkey processing and therefore probably not battery related and probably not called from OS X. In fact, BFWL is only called from MHPF, which, like SMWR (see below), is not accessed from DSDT.

The other place SMD0 is accessed is from SMWR which is not called from anywhere in the DSDT (could be called from one of the SSDTs).

As you can see:
Code:
            Device (HKEY)
            {
                Name (_HID, EisaId ("IBM0068"))  // _HID: Hardware ID

HKEY is some kind of vendor specific (IBM) device intended to attach to a vendor specific driver on Windows.

One question. Can I also treat FW00 to 104 bits in 1st method?

So like this:

Store (SMD0,
FW00)
104bit 104bit
 
How to patch DSDT for working battery status

One question. Can I also treat FW00 to 104 bits in 1st method?

So like this:

Store (SMD0,
FW00)
104bit 104bit

I think you can, but I also think that this field doesn't need to be patched.
 
How to patch DSDT for working battery status

Are there any particular downsides to using voodoobattery?
 
How to patch DSDT for working battery status

Are there any particular downsides to using voodoobattery?

VoodooBattery.kext does the same thing as ACPIBatteryManager.kext.

Most versions of VoodooBattery.kext also install AppleACPIPlatform.kext from Snow Leopard (a "rollback"). This breaks a number of things, but most notably is power management for Ivy/Haswell machines.
 
Back
Top