Contribute
Register

[Guide] How to patch DSDT for working battery status

windwalker said:
Well, I haven't changed anything outside of ACPIDebug support but OK, I've attached the files.
Click to expand...

Looks like _BIF is failing or returning bad data.
 
RehabMan said:
Looks like _BIF is failing or returning bad data.
Click to expand...
\_SB.BAT0._BIF returns \_SB.BTIF so I've added trace code to that:
Code: 
Method (BTIF, 1, Serialized)
{
    Store (\_SB.PCI0.LPCB.EC0.BTIF (Arg0), Local0)
    \RMDT.P4 (Arg0, "passed to \_SB.PCI0.LPCB.EC0.BTIF which returned", Local0, "LEqual 0xFF follows")
    If (LEqual (Local0, 0xFF))
    {
        \RMDT.P1 ("Preparing constant to return")
        Name (TEMP, Package (0x0D)
        {
            0x00, 
            0xFFFFFFFF, 
            0xFFFFFFFF, 
            0x01, 
            0xFFFFFFFF, 
            0x00, 
            0x00, 
            0x00, 
            0x00, 
            "", 
            "", 
            "", 
            0x00
        })
        \RMDT.P2 ("\_SB.BTIF returning constant", TEMP)
        Return (TEMP)
    }
    Else
    {
        \RMDT.P2 ("Preparing to dereference NBTI[]", Arg0)
        Store(DerefOf (Index (NBTI, Arg0)), Local1)
        \RMDT.P2 ("\_SB.BTIF returning NBTI value", Local1)
        Return (Local1)
    }
}
And the result is
Code: 
(ACPIBatteryManager) ACPIBatteryManager: Version 1.70.3 starting on OS X Darwin 16.6.
(ACPIBatteryManager) ACPIBatteryManager: Using ACPI regular battery information method _BIF
(ACPIDebug) ACPIDebug: Version 0.1.4 starting on OS X Darwin 16.6.
(ACPIDebug) ACPIDebug: { "_SB.PCI0.LPCB.EC0.BSTA (0x01) returned", 0xf, "XOr BT0P follows", 0xf, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.BAT0._STA returning", 0xf, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.LPCB.EC0.BSTA (0x01) returned", 0xf, "XOr BT0P follows", 0xf, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.BAT0._STA returning", 0xf, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.LPCB.EC0.BSTA (0x01) returned", 0xf, "XOr BT0P follows", 0xf, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.BAT0._STA returning", 0xf, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.LPCB.EC0.BSTA (0x01) returned", 0x1f, "XOr BT0P follows", 0xf, }
(ACPIDebug) ACPIDebug: { "Local0", 0x1f, "Local1", 0x1f, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.BAT0._STA returning", 0x1f, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.LPCB.EC0.BSTA (0x01) returned", 0x1f, "XOr BT0P follows", 0x1f, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.BAT0._STA returning", 0x1f, }
(ACPIDebug) ACPIDebug: { 0x0, "passed to _SB.PCI0.LPCB.EC0.BTIF which returned", 0x0, "LEqual 0xFF follows", }
(ACPIDebug) ACPIDebug: { "Preparing to dereference NBTI[]", 0x0, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.LPCB.EC0.BSTA (0x01) returned", 0x1f, "XOr BT0P follows", 0x1f, }
(ACPIDebug) ACPIDebug: { "_SB.PCI0.BAT0._STA returning", 0x1f, }
(ACPIDebug) ACPIDebug: { 0x0, "passed to _SB.PCI0.LPCB.EC0.BTIF which returned", 0x0, "LEqual 0xFF follows", }
(ACPIDebug) ACPIDebug: { "Preparing to dereference NBTI[]", 0x0, }
//Last four lines keep repeating after
It's safe to say that the line
Code: 
Store(DerefOf (Index (NBTI, Arg0)), Local1)
fails. What could be causing this?
 
windwalker said:
It's safe to say that the line
Code: 
Store(DerefOf (Index (NBTI, Arg0)), Local1)
fails.
Click to expand...


Not really.
You should do a simple trace after the store to verify that assumption.
eg.
\rmdt.p1("returned from NBTI deref store")
 
RehabMan said:
Not really.
You should do a simple trace after the store to verify that assumption.
eg.
\rmdt.p1("returned from NBTI deref store")
Click to expand...
Your suspicion was correct. Accessing the Package that was dereferenced was failing probably because its declared size and actual size were not the same.
After undoing this patch
Code: 
# Need to extend size of NBTI packages
into all code_regex \"Hewlett\-Packard\"\s+\},\s+Package\s\(0x0D\) replaceall_matched
begin
        "Hewlett-Packard",\n
        Zero,\n
        //Zero,\n
      },\n
    Package(0x0F)\n
end;

into all code_regex Name\s\(NBTI,\sPackage\s\(0x02\)\s+\{\s+Package\s\(0x0D\) replaceall_matched
begin
    Name (NBTI, Package(0x02)\n
    {\n
        Package(0x0F)\n
end;

into_all all code_regex \"LIon\",\s+\"Hewlett\-Packard\"\n\s+\}\n replaceall_matched
begin
    "LIon",\n
    "Hewlett-Packard",\n
    Zero,\n
    //Zero,\n
}\n
end;
the battery support seems to be working fine.
The patch looks rather suspicious. It clearly changes the size of the Package from 13 to 15, adds two values to compensate but the last one is commented out. I can hardly imagine how this functions for everyone else who is using it.
 
windwalker said:
Your suspicion was correct. Accessing the Package that was dereferenced was failing probably because its declared size and actual size were not the same.
After undoing this patch
Code: 
# Need to extend size of NBTI packages
into all code_regex \"Hewlett\-Packard\"\s+\},\s+Package\s\(0x0D\) replaceall_matched
begin
        "Hewlett-Packard",\n
        Zero,\n
        //Zero,\n
      },\n
    Package(0x0F)\n
end;

into all code_regex Name\s\(NBTI,\sPackage\s\(0x02\)\s+\{\s+Package\s\(0x0D\) replaceall_matched
begin
    Name (NBTI, Package(0x02)\n
    {\n
        Package(0x0F)\n
end;

into_all all code_regex \"LIon\",\s+\"Hewlett\-Packard\"\n\s+\}\n replaceall_matched
begin
    "LIon",\n
    "Hewlett-Packard",\n
    Zero,\n
    //Zero,\n
}\n
end;
the battery support seems to be working fine.
The patch looks rather suspicious. It clearly changes the size of the Package from 13 to 15, adds two values to compensate but the last one is commented out. I can hardly imagine how this functions for everyone else who is using it.
Click to expand...

Nothing wrong with the patch.
It makes the package larger, so as to accommodate additional fields (temperature and cycle count).
Probably you're missing the code which actually populates those additional entries...
 
RehabMan said:
Nothing wrong with the patch.
It makes the package larger, so as to accommodate additional fields (temperature and cycle count).
Click to expand...
That makes sense. But why is only one extra field added in the declaration/initialization and the other one commented out?
RehabMan said:
Probably you're missing the code which actually populates those additional entries...
Click to expand...
I applied the complete battery_HP-ProBook-Generic.txt patch and not cherry-picked only the matching fields specifically to avoid any problems like this.
 
windwalker said:
That makes sense. But why is only one extra field added in the declaration/initialization and the other one commented out?

I applied the complete battery_HP-ProBook-Generic.txt patch and not cherry-picked only the matching fields specifically to avoid any problems like this.
Click to expand...

It may be an oversight in the patch.
Try with package size 0xe and see what happens.
The code looks to be present in the patch to capture/set cycle count, but temperature was commented out...
 
battery_ASUS-N55SL.txt also confirmed to work on Strix FX502VM (so I suspect on any of their GL502VM ones).
 
benspoonder said:
battery_ASUS-N55SL.txt also confirmed to work on Strix FX502VM (so I suspect on any of their GL502VM ones).
Click to expand...

Thanks. Added a comment to that effect.
 
hi sir i applied all battery patches but no luck and i couldn't follow your guide it is very difficult for me even i applied Fujitsu-Lifebook-A555 but no luck please help me

i attached my dsdt.dsl please consider for my compiled dsdt
Screen Shot 2017-07-10 at 4.26.04 AM.png problem look like this I couldn't find patch for battery please patch for me
 

Attachments

  • DSDT-dsl.zip
    29.2 KB · Views: 78
  • SSDT-pm-piker.aml
    1.2 KB · Views: 77
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top