Active Topics
-
Porting apps to Leste (40)
to Maemo 7 / Leste by Maemish - 2 days, 11 hrs ago -
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 6 days, 15 hrs ago - more...
| The Following 4 Users Say Thank You to freemangordon For This Useful Post: | ||
|
2012-11-07
, 16:07
|
|
Posts: 24 |
Thanked: 26 times |
Joined on Feb 2011
|
#253
|
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...
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?
Last edited by zitstif; 2012-11-07 at 16:21.
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?
Last edited by zitstif; 2012-11-07 at 16:21.
 |
|
2012-11-07
, 16:50
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#254
|
please search for (not-)my-nokia and cherry
/j
/j
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
| The Following 2 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2012-11-07
, 16:51
|
|
Posts: 1,680 |
Thanked: 3,685 times |
Joined on Jan 2011
|
#255
|
N900 101: Before activating gsm for the first time - apt-get remove cherry
__________________
N900: One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die.
| The Following 5 Users Say Thank You to vi_ For This Useful Post: | ||
|
|
2012-11-07
, 17:40
|
|
Posts: 24 |
Thanked: 26 times |
Joined on Feb 2011
|
#256
|
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.
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.
| The Following User Says Thank You to zitstif For This Useful Post: | ||
|
|
2012-11-07
, 23:11
|
|
Posts: 804 |
Thanked: 1,598 times |
Joined on Feb 2010
@ Gdynia, Poland
|
#257
|
Originally Posted by pali
Few questions which I'm gonna ask here, in order not to spam http://talk.maemo.org/showthread.php...07#post1291607 .
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
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);
Time-to-Empty At Constant Power High - Low Byte
Thank you for taking your time to respond.
| The Following 3 Users Say Thank You to misiak For This Useful Post: | ||
|
|
2012-11-08
, 09:43
|
|
Posts: 2,154 |
Thanked: 8,464 times |
Joined on May 2010
|
#258
|
@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"?
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"?
| The Following 8 Users Say Thank You to pali For This Useful Post: | ||
|
|
2012-11-08
, 17:44
|
|
Posts: 804 |
Thanked: 1,598 times |
Joined on Feb 2010
@ Gdynia, Poland
|
#259
|
Originally Posted by pali
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...
1) Each power_supply kernel driver must report time in seconds, so bq27x00_battery too (it convert it).
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?
Last edited by misiak; 2012-11-08 at 17:50.
| The Following 2 Users Say Thank You to misiak For This Useful Post: | ||
|
|
2012-11-08
, 18:14
|
|
Posts: 804 |
Thanked: 1,598 times |
Joined on Feb 2010
@ Gdynia, Poland
|
#260
|
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):
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 
edit: Now I officially propose to edit battery driver module and add at least:
and change from:
to (note there's a swap in already present values and addition of two lines):
which would also require to change bq27x00_reg_cache struct and few other places in code of course, that's only the concept...
Last edited by misiak; 2012-11-08 at 19:20.
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.
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
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);
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);
Last edited by misiak; 2012-11-08 at 19:20.
| The Following 5 Users Say Thank You to misiak For This Useful Post: | ||
 |
| Tags |
| bq2415x_charger, bq27200, kernel-power |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 09:09.
Never fear. I is here.
720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900
Community SSU developer
kernel-power developer and maintainer