Funny battery values (nx6325)

Ian Smith smithi at nimnet.asn.au
Fri Mar 19 05:18:29 UTC 2010


On Thu, 18 Mar 2010, Alexandre "Sunny" Kovalenko wrote:
 > On Thu, 2010-03-18 at 20:53 +0100, Joerg Wunsch wrote:
 > > As Alexandre Sunny Kovalenko wrote:
 > > 
 > > > You can dump your ASL (see Handbook for instructions) and search for
 > > > something like:
 > > 
 > > ...
 > > 
 > > > and try to track down where the actual values came from. Chapter 10
 > > > of the ACPI specification (http://www.acpi.info/spec.htm) should
 > > > provide you with more information on the subject.
 > > 
 > > OK, the machine's back here now.  Meanwhile, I already tried all that
 > > on all available laptops around, and while I can basically follow the
 > > logic of most of those ASL files, I'm completely confused about the
 > > ASL file I'm getting from the nx6325.  Perhaps that confusion about it
 > > is also what confuses acpiconf -i0... ;-)
 > > 
 > > I'm attaching both, the acpiconf -i0 output as well as the ASL file.
 > > Is anybody able to hint me where the _BIF and _BST methods get their
 > > actual data from?

 > Unfortunately, it looks like values are coming straight from Embedded
 > Controller without any modifications:
 > 
 > Method (C1AC, 1, Serialized)
 > {
 > ...
 >   If (C14C)
 >   {
 >     Store (Arg0, C160)
 >     Store (C164, Local0)
 >     // This is your design capacity
 >     Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x01))
 >     // This is your last full capacity
 >     Store (Local0, Index (DerefOf (Index (C1AF, Arg0)), 0x02))
 >     // And yes they are the same by design of your BIOS ;)
 > ...
 > 
 > and
 > 
 > OperationRegion (C153, EmbeddedControl, 0x00, 0xFF)
 > Field (C153, ByteAcc, NoLock, Preserve)
 > {
 >   Offset (0x86), 
 >   C160,   4, 
 >   Offset (0x87), 
 > ...
 >   Offset (0x8D), 
 >   C164,   16, 
 >   Offset (0x91), 
 > ...
 > 
 > and
 > 
 > Name (C1AF, Package (0x02)
 > {
 >   Package (0x0D)
 >   {
 >     0x01, 
 >     0xFFFFFFFF, 
 >     0xFFFFFFFF, 
 >     0x01, 
 >     0xFFFFFFFF, 
 >     0x00, 
 >     0x00, 
 >     0x64, 
 >     0x64, 
 >     "Primary", 
 >     "100000", 
 >     "LIon", 
 >     "Hewlett-Packard"
 >    }, 
 > ...
 > 
 > Given that you are not getting default values, something is actually
 > being read and returned. Unfortunately you are going to need somebody
 > smarter then myself to tell you whether magic number they store and
 > offsets they use to read the values are indeed valid.

Hardly smarter than yourself :) but I notice there's another Method C1AC 
in the EC section, Scope (C0E3), which appears, perhaps, to be doing 
these calculations around line 2767 of Joerg's file.  It's way too 
complicated with double derefs etc for me to follow, but it does maths 
and refers to C1AF a lot, so might be updating those values?  I notice a 
couple of divide by 100 after adding 99 .. if I'm reading it right ..

   Divide (Add (Local1, 0x63), 0x64, Local3, Local2)

where something may be out by 10 in the manner Peter mentioned earlier?

 > Out of sheer curiosity... what does acpiconf -i1 say?

It should't be there, but .. I wondered about that too :)  

cheers, Ian


More information about the freebsd-acpi mailing list