The Following User Says Thank You to Ridd92 For This Useful Post: | ||
|
2018-11-15
, 19:43
|
Community Council |
Posts: 685 |
Thanked: 1,235 times |
Joined on Sep 2010
@ Mbabane
|
#12
|
~ $ lsmod | grep battery bq27x00_battery 7120 0 rx51_battery 2240 0 power_supply 6916 3 bq27x00_battery,bq2415x_charger,rx51_battery
The Following 2 Users Say Thank You to sicelo For This Useful Post: | ||
|
2018-11-15
, 20:30
|
Posts: 188 |
Thanked: 223 times |
Joined on Apr 2013
@ Poland
|
#13
|
The Following 2 Users Say Thank You to Ridd92 For This Useful Post: | ||
|
2019-11-23
, 17:01
|
Posts: 8 |
Thanked: 14 times |
Joined on Sep 2019
|
#14
|
~ $ lsmod | grep battery ~ $
Ironically, reflashing wouldn't help, at all. I think you just had >32 charging cycles since last calibration. For some reasons, device hadn't chance to calibrate itself automaticaly (maybe you were always charging it before it reached very low level/never let it shut itself down due to out of charge?).
To fix, you need to calibrate manually:
1. Charge battery to full, until VDQ flag turns to 1
2.
3. Use your device normally, but don't shut it down, charge, or reboot. Checking battery level manually, from time to time (battery applet *won't* give you correct readings, due to modules being not loaded). Always ensure that VDQ flag is 1, otherwise, you need to start back from scratch. Accidental reboot may or may not turn VDQ to 0, depending on circumstances.Code:modprobe -r bq27x00_battery modprobe -r rx51_battery
4. When voltage drops to ~3300 mV, stop whatever you're doing on device and start monitoring it closely.
5. The goal now is to get under 3248 mV and stay there for at least 15 seconds, without voltage either going above, or too much under (less than ~2900 mV), causing device to "faint" due to low power. The most reliable - although, time consuming - way is to set screen to never dim, and/or enable flashlight - so device will consume steady ammount of current. Monitor voltage and VDQ.
6. When voltage dros below threeshold (3248 mV) and stays there for 15 seconds, VDQ will immediately turn to 0 and chip recalibrate.
7. Power device off via normal way, before it "faints" - if you miss that step, it *won't* spoil calibration, but you may get your /home filesystem corrupted. You better not miss this step, or you will give yourself quite a homework (see next steps). In case of failing it, for some reason, follow step 8. Otherwise, you're finished now - start using device normally.
8. (optional, in case of missing step 7)
This step require you to run latest cssu-thumb or cssu-testing. Precisely, it require updated e2fsprogs&friends, cause Maemo's vanilla ones were ancient and segfaulted mid-way, leaving filesystem in total mess.
Boot into any recovery console (backupmenu's one, Mentalist Traceur's one, Pali's one, etc), and:
a) If it says (amongst other things) "<filesystem name> clean" - with or without "recovering journal" before - and exits, you're good to go. Power off, and you're finished. Start using device normally.Code:fsck /dev/mmcblk0p2 -f -p
b) If it informs about fixing some things, but exits cleanly, see point a.
c) If it ends with something like "Unexpected inconsistency, run FSCK manually", do:
Ensure, that path where you save log isn't any temporary directory (that will get nuked after boot), as you may really need that log later.Code:fsck /dev/mmcblk0p2 -f -y -v >> /path/where/you/want/log/saved/fsck.log
Where to save, depends on the recovery shell you're using. If you have rootfs mounted, /path/where/rootfs/is/mounted/var/log/fsck.log is a good place. Using backupmenu's root console (and *only* after mounting rootfs via 'mountroot' command), it is /tmp/mnt/rootfs/var/log/fsck.log, If I remember correctly (you can use auto-completion via TAB).
When it's finished, repeat this point (8) from the beginning, and follow approriate sub-point.
8.1. After you boot into Maemo, check fsck.log you've create in point 8 - it will contain (amongst other things), pathes to files that were repaired/salvaged (connected to lost+found) during manual fsck repair. Check every file's integrity individually. In case it "vanished", check /home/lost+found, it may be sitting there. In case of problems, determine which package missing file depend to, and reinstall whole package.
---
Appendix:
To check VDQ flag and voltage conveniently, either use bq27200.sh script, or package BNF (the latter is my favorite method, but no surprise here, as I've created it ).
Appendinx 2:
Don't get scared by ammount of text here - I tried to explain everything in details, and half of this (as it turned to be) tutorial is an emergency kit for worst-case scenario of filesystem corruption, due to device fainting of low power. By being at least basically aware of situation, you won't hit it, saving yourself half of this
Cheers,
/Estel
The Following User Says Thank You to bdbogart For This Useful Post: | ||
|
2019-11-23
, 20:53
|
|
Posts: 4,118 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#15
|
|
2019-11-24
, 02:55
|
Posts: 256 |
Thanked: 939 times |
Joined on Jun 2014
@ Finland
|
#16
|
The Following User Says Thank You to Koiruus For This Useful Post: | ||
|
2019-11-24
, 07:27
|
Posts: 1,424 |
Thanked: 2,623 times |
Joined on Jan 2011
@ Touring
|
#17
|
|
2019-12-03
, 03:07
|
Posts: 8 |
Thanked: 14 times |
Joined on Sep 2019
|
#18
|
|
2019-12-03
, 19:55
|
Posts: 256 |
Thanked: 939 times |
Joined on Jun 2014
@ Finland
|
#19
|
|
2019-12-10
, 19:45
|
Posts: 8 |
Thanked: 14 times |
Joined on Sep 2019
|
#20
|
Tags |
battery, bme replacement, cssu thumb2 |
|
This is from rx51_battery:
This is from bq27x00_battery:
And this is from BNf with above modules wirh -r
WT*??