maemo.org - Talk - [Announce] kernel-power stable v51 in Extras-Devel

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - [Announce] kernel-power stable v51 in Extras-Devel (https://talk.maemo.org/showthread.php?t=85665)

Re: [Announce] kernel-power stable v51 in Extras-Devel

Quote:

Originally Posted by nisheet (Post 1289297)

@pali----bro,when the kernel power 52 will be in devel????

When it is ready?

Re: [Announce] kernel-power stable v51 in Extras-Devel

Waiting for dfries patches...

Re: [Announce] kernel-power stable v51 in Extras-Devel

I find it odd that ever since having this kernel installed on my phone, that my phone has been sending premium rate text messages to egypt and romania...:mad:

11/04/12 04:24 PM SMOINT EGYPT
(S)
0000000000l
11/04/12 04:23 PM SMOINT ROMANIA
(S)
0000000000l

There are no records of these text messages being logged in my el-v1.db file stored in the .rtcom-eventlogger folder.

Has this package been compromised?

Would some one like to share with me their sha1 hashes of the deb files?

If it is not the kernel which is tainted, then does anyone have any suggestions for finding which package that I have installed that may be rogue?

Re: [Announce] kernel-power stable v51 in Extras-Devel

please search for (not-)my-nokia and cherry
/j

Re: [Announce] kernel-power stable v51 in Extras-Devel

N900 101: Before activating gsm for the first time - apt-get remove cherry

Re: [Announce] kernel-power stable v51 in Extras-Devel

Forgive me for my ignorance but it was this cherry application that is sending premium rate text messages to egypt and romania?

Thank you for the responses btw! :)

(I did read this: http://wiki.maemo.org/PR1.2_compulso...nical_analysis)

That would make sense of it was the program because the number that is being texted appears to be a number that is associated with interfacing between sms and e-mail.

Re: [Announce] kernel-power stable v51 in Extras-Devel

Quote:

Originally Posted by pali (Post 1279757)

Packages are updated and here is changelog:

kernel-power (1:2.6.28-10power52) fremantle; urgency=low

* Backport upstream patch: udf-use-hw-sector-size.diff (This fix UDF FS support on SD cards and USB disks)
* Update bq2415x_charger patch: (use kstrtol, use dev_dbg, call sysfs_notify, rename N900 charger to bq24150a, fix reporting bad values, disable charging when charger disconnected)
* Added patch kstrtol.diff which define macro kstrtol as strict_strtol
* Update into about kernel-power-bootimg package
* Package kernel-power-bootimg does not provide any features
* Enable more netfilter and ipv6 modules
* Added driver rx51_battery which export battery temperature, design capacity and voltage to sysfs, provides: kernel-feature-rx51-battery
* Added patch tif_restore_sigmask-syscalls-arm.patch which fix pselect bug, added provides: kernel-feature-sigmask
* Enable bridge module, provides kernel-feature-bridge

-- Pali Rohár <hidden> Fri, 12 Oct 2012 14:59:09 +0200

Few questions which I'm gonna ask here, in order not to spam http://talk.maemo.org/showthread.php...07#post1291607 .

1. You said that the time reported by bq27200 is in seconds, while I see in http://www.ti.com/lit/ds/symlink/bq27200.pdf , page 12, "Minutes". Any explanation?
2. I've seen https://garage.maemo.org/plugins/ggi...587175;hb=HEAD , lines 43-70. And other patches in https://garage.maemo.org/plugins/ggi...d34322;hb=HEAD . Question:

Code:

#define BQ27x00_REG_TTECP              0x26

...

cache.time_to_empty_avg = bq27x00_battery_read_time(di, BQ27x00_REG_TTECP);

while the pdf on the same page 12 states for 0x26

Quote:

Time-to-Empty At Constant Power High - Low Byte

- does the "avg" suffix mean that and I'm just mistakingly taking it for something like "time to empty based on average from last few charges"?

Thank you for taking your time to respond.

Re: [Announce] kernel-power stable v51 in Extras-Devel

@misiak,

1) Each power_supply kernel driver must report time in seconds, so bq27x00_battery too (it convert it).

@joerg_rw, you know bq27200 chip better. Time code was not written by me and now I see from datasheet that chip can report more "time to empty" values (TTECP, MLTTE, STTE, TTE, ARTTE). Which should be reported as "average value" and which as "now value"?

Re: [Announce] kernel-power stable v51 in Extras-Devel

Quote:

Originally Posted by pali (Post 1291750)

1) Each power_supply kernel driver must report time in seconds, so bq27x00_battery too (it convert it).

Is it possible that there's an error somewhere in this conversion? After all, the values in my N900 are always a multiply of 3600 (60*60)... Unless the value reported by chip is a rough estimation in hours converted to minutes...

I found out your conversion in bq27x00_battery_read_time(struct bq27x00_device_info *di, u8 reg), and following the code, in bq27x00_update(struct bq27x00_device_info *di) I found out you use:

0x16 (TTE, Time-to-Empty) for setting time_to_empty (which is used as POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW - the "now value")
0x26 (TTECP, Time-to-Empty At Constant Power) for setting time_to_empty_avg (which is used as POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG - the "average value")

How I understand the registry names (but that's only my understanding, I rarely read datasheets):

0x16 (TTE, Time-to-Empty) - the average value (calculated by i-have-no-idea-what-maybe-some-balanced-weighted-formula-or-something)
0x20 (MLTTE, Max Load Time-to-Empty) - the value for "busy" state, "active" state or however we call it - the time to empty under max load, as name says (so maybe this is the "busy" value reported by bme signal)
0x1C (STTE, Standby Time-to-Empty High - Low Byte) - as the name states, time to empty at standby (maybe the "idle" value reported by bme signal)
0x26 (TTECP, Time-to-Empty At Constant Power) - the value of time IF the current (="at the moment") power usage would not change (and that would explain why this value can change so dramaically often and jump from 3600 to 18000 or drop from 18000 to 3600 in just a second)
0x04 (ARTTE, At-Rate Time-to-Empty) - ??? I don't know this one... Maybe the time to empty at power usage from 0x02 - AR, At-Rate?
0x18 (TTF, Time-to-Full) - while charging, time to charge battery to full capacity

TL;DR: The names of most are pretty explanatory, I would suspect 0x1C to be time to empty battery on idle and 0x20 to be time to empty on heavy load... so instead of reporting 0x16 for both values I would report these two, what do you think about that? I would check that by myself, but I'm very busy lately, only time I can write here on TMO is from my N900 while I'm on the train or a bus...

Any comments on that from you, joerg_rw, if you (as pali wrote) know this chip?

Re: [Announce] kernel-power stable v51 in Extras-Devel

Ok, i solved the puzzle by reading other pages - Pali, please take a look at pages 12-18 of http://www.ti.com/lit/ds/symlink/bq27200.pdf (sorry for very long quote, I'm quoting here only battery-relevant parts, there are information about more registers and values, maybe you will find that useful):

Quote:

At-Rate Registers (ARL/ARH) — Address 0x02/0x03
The host can write the current in units of 3.57 μV per bit to this register for predictive calculation time-to-empty.
The part uses this value to predict the time-to-empty at any desired current; it does not affect the time-to-empty
calculation based on the actual current. The value in AR is always assumed to be a discharge current.
This register is also used during pack manufacturing to input a nominal available charge value to set NAC to the
approximate initial pack capacity value.
At Rate Time-to-Empty Registers (ARTTEL/ARTTEH) — Address 0x04/0x05
This is predicted time-to-empty in minutes at user-entered discharge rate. The discharge current used in the
calculation is entered by the host system in the AR registers. The at-rate capacity (ARCAP) value used can be
larger or smaller than CACT. It is computed using the same formulas as CACT, except the discharge
compensation is computed using AR, instead of AI, for the discharge rate. The equation used to compute at-rate
time-to-empty is:
ARTTE = 60 * ARCAP / AR
The host system has read-only access to this register pair.
Time-to-Empty Registers (TTEL/TTEH) — Address 0x16/0x17
This register pair reports calculated time-to-empty at the measured discharge rate. This value is based on the
temperature and discharge rate compensated available charge and the average current. The equation to
calculate TTE is:
TTE = 60 * CACT/AI
TTE is reported in minutes. The host system has read-only access to this register pair.
Time-to-Full Registers (TTFL/TTFH) — Address 0x18/0x19
This register pair reports calculated time-to-full at the measured charge rate. The time computed at the average
current charge rate is extended by 50% to estimate the effect of the current taper. TTF is reported in minutes.
The equation for TTF is:
TTF = 60 * 1.50 * (LMD-NAC)/AI
The host system has read-only access to this register pair.
Standby Time-to-Empty Registers (STTEL/STTEH) — Address 0x1C/0x1D
This register pair reports calculated time-to-empty at the measured standby current value. This value is based on
the nominal available charge and the standby current. STTE is reported in minutes. STTE is calculated by:
STTE = 60 * NAC/SI
The host system has read-only access to this register pair.
Max Load Time to Empty Registers (MLTTEL/MLTTEH) — Address 0x20/0x21
This register pair reports calculated time-to-empty in minutes at the maximum measured discharge rate. The Max
Load Capacity (MLCAP) value is based on the temperature and discharge rate compensated available capacity
computed using MLI, instead of AI, for the discharge rate. MLTTE is calculated by:
MLTTE = 60 * MLCAP/MLI
The host system has read-only access to this register pair.
Time-to-Empty at Constant Power Registers (TTECPL/TTECPH) — Address 0x26/0x27
TTECP is the time-to-empty in minutes with a constant power load. Because SAE is already scaled for the
average discharge voltage, the result is simply the ratio of SAE to AP:
TTECP = 60 * SAE/AP
The host system has read-only access to this register pair.

So, basically, in addition to some pre-calculated battery time values, we also have an interactive hardware calculator here which we can "feed" with voltage value to 0x02 and read remaining time value from 0x04 :D

edit: Now I officially propose to edit battery driver module and add at least:

Code:

#define BQ27x00_REG_STTE                        0x1c

#define BQ27x00_REG_MLTTE                        0x20

and change from:

Code:

cache.time_to_empty = bq27x00_battery_read_time(di, BQ27x00_REG_TTE);

cache.time_to_empty_avg = bq27x00_battery_read_time(di, BQ27x00_REG_TTECP);

to (note there's a swap in already present values and addition of two lines):

Code:

cache.time_to_empty = bq27x00_battery_read_time(di, BQ27x00_REG_TTECP);

cache.time_to_empty_avg = bq27x00_battery_read_time(di, BQ27x00_REG_TTE);

cache.time_to_empty_standby = bq27x00_battery_read_time(di, BQ27x00_REG_STTE);

cache.time_to_empty_maxload = bq27x00_battery_read_time(di, BQ27x00_REG_MTTE);

which would also require to change bq27x00_reg_cache struct and few other places in code of course, that's only the concept...