| *** NIN101 has quit IRC | 00:00 | |
| *** Estel_ has joined #maemo-ssu | 00:20 | |
| *** Estel_ has quit IRC | 00:20 | |
| *** Estel_ has joined #maemo-ssu | 00:20 | |
| *** xes has joined #maemo-ssu | 00:24 | |
| *** arcean_ has quit IRC | 00:27 | |
| *** arcean_ has joined #maemo-ssu | 00:28 | |
| Estel_ | kerio, do you remember one of my devices that can't charge normally due to treating usb data pins as non-existent, so it require forcing dedicated mode in bme replacement? | 00:31 |
|---|---|---|
| Estel_ | I did as suggested, i.e. forced it in /etc/event.d/bme, but it turned out, that it's too late for some situations | 00:31 |
| Estel_ | for example, if battery get discharged completely (to the point of under 3000 mV), device doesnt event want to start booting, and when connected to charger, only *pretends* that it is emergency charging, by yellow diode | 00:32 |
| Estel_ | now, where to modprobe bq2415x_battery, to get earliest charging possible? | 00:32 |
| Estel_ | /sbin/preinit sounds ok, but... | 00:32 |
| Estel_ | what about act_dead mode or emergency charging? anyone know what else should i edit to put charging module there? | 00:33 |
| Estel_ | device uses u-boot, if that matters | 00:33 |
| Estel_ | normally no problems, but if device user, accidentally, let it discharge too much, no way to charge it without using external charger, even if for 5 minutes (to allow device boot normally, at plug-in charger during boot). If possible, I would like to achieve emergency charging, too | 00:34 |
| Estel_ | ShadowJK, any ideas, how to force device into *really* charging in emergency mode (charger plugged in and battery under 3000 mV) | 00:34 |
| *** Vlad_on_the_road has quit IRC | 00:34 | |
| Estel_ | or is it all hardcoded so without chip detecting crossed data, it will just light yellow diode, but do nothing? (as it does now) | 00:35 |
| *** Martix has quit IRC | 00:37 | |
| *** xes has quit IRC | 00:39 | |
| *** xes has joined #maemo-ssu | 00:39 | |
| DocScrutinizer05 | amber LED is hardwired to bq24150 STAT output that indicates chip is in charging mode | 00:46 |
| DocScrutinizer05 | D+/- detection by PHY is hardwired to bq24150 OTG input, that in POR state of schip determines whether chip is doing 500mA or 100mA charging | 00:47 |
| kerio | so Estel_'s stuck doing emergency charge at 100mA? | 00:47 |
| DocScrutinizer05 | bottom line: when steady amber LED, bq24150 *is* charging battery, at least with 100mA | 00:48 |
| Estel_ | DocScrutinizer05, strange, as with this device, it doesn't work in emergency mode at all, while in normal mode it charger pefectly | 00:48 |
| *** entitled has joined #maemo-ssu | 00:48 | |
| Estel_ | standard 1200 mA battery went from 2900 mV to 2600 mV | 00:48 |
| Estel_ | during 10+ hours of "emergency charging" | 00:49 |
| DocScrutinizer05 | a broken PHY will cause no D+/- short detection, so charging doesn't get forced to 500mA or even more, but stays at 100mA | 00:49 |
| Estel_ | in that particular device | 00:49 |
| Estel_ | i would be happy with 100 mA too | 00:49 |
| Estel_ | I wonder why it doesn't charge at all. I'm not sure if it isn't even eating power due to that bright diode, lol | 00:49 |
| DocScrutinizer05 | I don't know how much the system will consume when in pre-boot state at low voltage | 00:50 |
| Estel_ | but that battery definitelly should get charged above 3000 mV pretty fast, @100mA | 00:50 |
| Estel_ | just assumption - it shouldn't consume as much as 100mA, methinks | 00:50 |
| DocScrutinizer05 | it *should* be really low power consumption | 00:50 |
| * Estel_ nods | 00:51 | |
| Estel_ | btw on other devices I was able to emergency charge from dumb charger (100 mA), so something doesn't work as intended with broken phy | 00:51 |
| Estel_ | ah | 00:51 |
| Estel_ | from time to time, bme replacement detect this device as "boost mode", if not forced | 00:51 |
| Estel_ | when connected to charger | 00:51 |
| Estel_ | I wonder why, and how it can affect emergency charging? | 00:52 |
| Estel_ | (btw, during non-charging, idle consumption is absolutely normal, so no power leaking) | 00:52 |
| DocScrutinizer05 | maybe whatever damaged PHY (extreme overvoltage on USB?) also smoked up bq24150 | 00:52 |
| Estel_ | anyway, it seems that I can't affect the way emergency charging is happening via any means? | 00:52 |
| Estel_ | DocScrutinizer05, shouldn't be the case, as it's charging fine when device is booted using bq2415x_charger module :P | 00:53 |
| DocScrutinizer05 | emergency charging is a purely hw-defined thing, as long as bq24150 is in POR state (hard to keep it in any other state) | 00:54 |
| *** kolp has quit IRC | 00:54 | |
| Estel_ | although unknown reason for device being damaged (I got it in this state, for free, as un-repairable, revived it by preparing working backup to restore, that used modules for kernel matching one in-device) | 00:54 |
| Estel_ | I see | 00:54 |
| Estel_ | hm, I wonder what could trigger other state... | 00:54 |
| DocScrutinizer05 | twl4030 might become sticky on some weird settings regarding power/usb | 00:55 |
| DocScrutinizer05 | ~full-reset | 00:55 |
| DocScrutinizer05 | or somesuch | 00:55 |
| Estel_ | anyway, leaving emergency mode - when battery is above 3000 mV and device boots into act_dead when charger plugged in, modprobing charging module in /sbin/preinit is enough? | 00:56 |
| Estel_ | DocScrutinizer05, if full reset is that thing including removing battery for extended period of time, sadly, I tried it | 00:56 |
| DocScrutinizer05 | ~listkeys #maemo | 00:56 |
| infobot | Factoid search of '#maemo' by key (16 of 44): #maemo bme-replacement ;; #maemo bmo ;; #maemo bnf ;; #maemo closed ;; #maemo closed_packages ;; #maemo db ;; #maemo ek ;; #maemo expired-key ;; #maemo fam ;; #maemo gmo ;; #maemo interim-dns ;; #maemo kp ;; #maemo mirror ;; #maemo mirrors ;; #maemo mo/* ;; #maemo multiboot. | 00:56 |
| DocScrutinizer05 | ~listkeys reset | 00:57 |
| infobot | Factoid search of 'reset' by key (15 of 19): password reset #DEL# ;; looks like the reset ;; hard reset ;; password reset ;; reset ;; firm reset ;; eq.preset ;; jargon 120 reset ;; jargon reset ;; only reason you absolutely must reset, ;; warm reset ;; trackerreset ;; connection reset by peer ;; soft reset ;; full reset. | 00:57 |
| DocScrutinizer05 | ~full reset | 00:57 |
| infobot | from memory, full reset is flip the battery switch to "replace" open the cover, press the little button with the stylus, close cover, flip the switch to normal, power on. Warning: data in ram storage will be lost by doing a full reset | 00:57 |
| Estel_ | For me it isn't problem, but device is used by my son on trips and somesuch, when LiPo charger or other N900's are not around. I'll wind up bancruting and buying external charger for 5$, probably. And modding it, cause ones sold here have risk of killing people by idiotic design, where *battery" pins have possibility to bend into touching 220V | 00:57 |
| DocScrutinizer05 | meh! | 00:57 |
| Estel_ | I just started to think I've missed some little button on N900 :P | 00:58 |
| Estel_ | thanks for taking your time to explain emergency charger and searching for that factoid, btw | 00:58 |
| *** gregoa has quit IRC | 00:58 | |
| *** gregoa has joined #maemo-ssu | 00:59 | |
| Estel_ | so, anyone remember how fckn act_dead is called? it doesn't skip /sbin/preinit in actdead mode, I hope? actually, it should be called from /sbin/preinit if certain conditions are meet? | 00:59 |
| DocScrutinizer05 | full reset for twl4030 is done by holding powerbutton for 15s while inserting battery, or somesuch | 01:01 |
| DocScrutinizer05 | ~listkeys reset | 01:04 |
| infobot | Factoid search of 'reset' by key (15 of 19): trackerreset ;; password reset ;; looks like the reset ;; spa2000_factory_reset ;; jargon 120 reset ;; full reset ;; eq.preset ;; connection reset by peer ;; hard reset ;; soft reset ;; jargon reset ;; reset switch ;; warm reset ;; only reason you absolutely must reset, ;; firm reset. | 01:04 |
| merlin1991 | freemangordon: use http://community-testing.merlin1991.at/ ;) | 01:04 |
| freemangordon | merlin1991: it is missing there too | 01:04 |
| merlin1991 | dafuq | 01:04 |
| freemangordon | and in all of the mirrors | 01:05 |
| Estel_ | DocScrutinizer05, thanks | 01:05 |
| freemangordon | merlin1991: oh, wait | 01:05 |
| Estel_ | one should hold it for at least 15 seconds and then enter battery, or hold and insert, then keep holding? | 01:05 |
| freemangordon | merlin1991: it is in upstart, WTF? | 01:05 |
| merlin1991 | http://community-testing.merlin1991.at/pool/free/u/upstart/system-services_0.3.8-68%2b0cssu1_armel.deb | 01:05 |
| merlin1991 | yeah silly upstart package | 01:05 |
| freemangordon | yeah, my bad, I was looking in s directory | 01:06 |
| merlin1991 | I did aswell | 01:06 |
| freemangordon | merlin1991: however, repo should be fixed | 01:06 |
| Estel_ | kerio, how one force u-boot to boot from sd, from u-boot terminal? it proposes some scripts like sdboot or emmcboot, but none of them works | 01:06 |
| freemangordon | Estel_: run sdboot | 01:06 |
| Estel_ | (when one enters u-boot console, it informs about it, but none of them works) | 01:07 |
| freemangordon | or run mmcboot | 01:07 |
| Estel_ | freemangrdon, it gives shitload of errors | 01:07 |
| DocScrutinizer05 | I think it been like "hold for 12s at most 12s after inserting battery" or whatever | 01:07 |
| Estel_ | any of them | 01:07 |
| kerio | Estel_: manual parameters | 01:07 |
| freemangordon | Estel_: then you don't have fat first partition. afaik | 01:07 |
| Estel_ | freemangordon, I have fat as first partition on emmc and it works from u-boot menu entries | 01:08 |
| Estel_ | *just* mmcboot command doesn't work | 01:08 |
| merlin1991 | DocScrutinizer05: are you planning on staying up longer today? | 01:08 |
| Estel_ | it complains something about ext4, maybe it get confused by mmcblk0p2 being eext4? but why it cares, it should look at mmcblk0p1 only | 01:08 |
| freemangordon | Estel_: no idea then | 01:09 |
| Estel_ | freemangordon, considering that I have only one partition on sd and that partition is vfat, and using sdboot command result in same ext4 errors... | 01:09 |
| Estel_ | I assume u-boot browse through all partitions and get pissed off by finding something that it doesn't like, even when he shouldn't care | 01:10 |
| Estel_ | need to pester Pali, probably, but if he is going to say "won't fix, try to push upstream patch", I'm stopping to report anything to Pali :P | 01:10 |
| Estel_ | if I would be able to push upstream patch, I wouldm fuck in fix it myself, instead of asking here or reporting anything to him | 01:10 |
| Estel_ | s/fuck in/fucking/ | 01:11 |
| infobot | Estel_ meant: if I would be able to push upstream patch, I wouldm fucking fix it myself, instead of asking here or reporting anything to him | 01:11 |
| DocScrutinizer05 | merlin1991: probably | 01:16 |
| DocScrutinizer05 | merlin1991: why? | 01:16 |
| merlin1991 | might need some sudo on garage/repo later on | 01:16 |
| DocScrutinizer05 | np | 01:16 |
| Estel_ | DocScrutinizer05, now the question is, does hard reset of charging chip work if battery inserted during performing hard reset is on unholy low voltage? | 01:31 |
| Estel_ | or holy low voltage, like < 3000mV but > than 2500 mV | 01:32 |
| Estel_ | (or unholy, like something like 2200 mV - never happened, but thinking theoretically). I wonder what kind fo voltage from battery is required to perform full_reset? | 01:32 |
| Estel_ | "from different barrel" - I have 4 packages ready, but no time to polish packaging and release into repositories, ffs :P | 01:38 |
| Estel_ | irony hits - all of them are for non-free section (kon-boot, and 3 games) | 01:38 |
| Estel_ | especially funny, considering, how I used to ignore annoucements for non-open source things for Maemo | 01:39 |
| Estel_ | especially for non-FOSS game projects, heh | 01:39 |
| *** arcean_ has quit IRC | 01:51 | |
| *** arcean_ has joined #maemo-ssu | 01:53 | |
| *** M4rtinK has quit IRC | 02:01 | |
| ShadowJK | Estel_; afaik it's always limited to 100mA hardware-only. When I had uBoot+meego on spare device, bme would not start charging empty battery (nolo charging missing), but there was still enough time for me to launch xterm and launch meegocharge21.sh | 02:14 |
| DocScrutinizer05 | ShadowJK: according to schematics and bq24150 datasheet it's forced into 500mA mode on OTG=1 in POR mode | 02:17 |
| DocScrutinizer05 | OTG D4 I | 02:20 |
| DocScrutinizer05 | Boost mode enable control or input current limiting selection pin. When OTG is in active status, bq24150/1 is forced to operate in boost mode. It has higher priority over I2C control and can be disabled through control register. The logic voltage level at OTG active status can also be controlled. At POR, the OTG pin is default to be used as the input current limiting selection pin. When OTG = High, Iin – limit = 500mA and when OTG | 02:20 |
| DocScrutinizer05 | = Low, Iin – limit = 100mA, see the Control Register for details. | 02:20 |
| DocScrutinizer05 | while | 02:22 |
| DocScrutinizer05 | STA TC 4 O Charge status pin. Pull low when charge in progress. Open drain for other conditions. During faults, a128-mS pulse is sent out. STAT pin can be disabled by the EN_STAT bit in control register. STAT ca nbe used to drive a LED or communicate with a host processor. | 02:23 |
| *** arcean_ has quit IRC | 02:26 | |
| ShadowJK | DocScrutinizer05; current balance and the time I had to start charge indicated 100mA | 02:26 |
| ShadowJK | I didn't always manage to start charging before voltage dropped too low | 02:27 |
| DocScrutinizer05 | sorry, I can't follow | 02:31 |
| DocScrutinizer05 | NB the OTG function is defined for POR (non I2C) mode only | 02:31 |
| DocScrutinizer05 | in I2C mode you can configure OTG input to anything you like | 02:31 |
| DocScrutinizer05 | btw difference of 1704 and 1707 is in level of charge output, so it matches what bq24150 needs for emergency fastcharging to work | 02:32 |
| DocScrutinizer05 | iirc | 02:32 |
| *** nox- has quit IRC | 02:49 | |
| *** xes has quit IRC | 03:31 | |
| Estel_ | thanks ShadowJK and DocScrutinizer05. ShadowJK, I don't get from where you've run meegocharge21.sh - I'm talking about situation, when device doesn't boot into anything system-related (for example, 2900 mV battery inserted) | 03:40 |
| Estel_ | DocScrutinizer05, tried reset of chip, haven't helped. I wonder if it may be related to some fubar with OTG pin? | 03:40 |
| Estel_ | physically, that pin is ok, but who knows what happened inside broken phy (or whatever is broken there) | 03:41 |
| Estel_ | anyway the result is, that while emergency "charging", that particular device is, in fact, discharging, at natural or even a little increased level | 03:42 |
| Estel_ | another interesting thing - if device connected to charger *without* battery, led is yellow/orange the same way, like emergency charging in progress | 03:42 |
| Estel_ | for now, I've ditched LiIon charging pcb from small bluetooth headphones, that take 5V as input, into inside of backcover... | 03:45 |
| Estel_ | with wires attached to battery cell and wires from that charging PCB attached to battery wires via mini clips, + charging pcb attached via cables to device 5V input (charger port aka microUSB), with hardware switch in between | 03:47 |
| Estel_ | = when emergency charging needed on that device, I plug in charger like normal, then close switch, resulting in recycled charging circuit being powered and charging cell. After few minutes I open switch, de-attach nokia charger, boot device, and attach charger again, quickly - bq2415x_battery module takes care of normal maemo charging, then (bme repl.) | 03:49 |
| *** LauRoman has quit IRC | 04:08 | |
| ShadowJK | Estel_; with uboot + meego, actdead did not exist, it booted into meego straight | 04:51 |
| *** amiconn has quit IRC | 05:05 | |
| *** amiconn_ has joined #maemo-ssu | 05:05 | |
| *** amiconn_ is now known as amiconn | 05:05 | |
| *** BCMM has quit IRC | 05:43 | |
| *** DocScrutinizer05 has quit IRC | 06:03 | |
| *** DocScrutinizer05 has joined #maemo-ssu | 06:03 | |
| *** Phuzzed has joined #maemo-ssu | 06:42 | |
| *** Phuzzed has quit IRC | 06:43 | |
| *** M13 has joined #maemo-ssu | 06:47 | |
| *** M13 has quit IRC | 07:20 | |
| *** luf has joined #maemo-ssu | 08:13 | |
| *** dhbiker has joined #maemo-ssu | 09:02 | |
| *** unclouded has joined #maemo-ssu | 09:17 | |
| *** Mihanizat0r has joined #maemo-ssu | 10:01 | |
| *** LauRoman has joined #maemo-ssu | 10:09 | |
| *** M4rtinK has joined #maemo-ssu | 10:27 | |
| *** M4rtinK has quit IRC | 11:10 | |
| *** futpib has joined #maemo-ssu | 11:42 | |
| *** LauRoman has quit IRC | 13:22 | |
| *** Martix has joined #maemo-ssu | 13:40 | |
| *** futpib has quit IRC | 14:03 | |
| *** futpib has joined #maemo-ssu | 14:05 | |
| *** unclouded has quit IRC | 14:22 | |
| *** Mihanizat0r has quit IRC | 14:25 | |
| *** Martix has quit IRC | 15:09 | |
| *** M13 has joined #maemo-ssu | 15:22 | |
| *** andre__ has joined #maemo-ssu | 15:32 | |
| *** andre__ has joined #maemo-ssu | 15:32 | |
| *** BCMM has joined #maemo-ssu | 15:39 | |
| *** DocAvalanche has joined #maemo-ssu | 15:50 | |
| *** DocScrutinizer51 has quit IRC | 15:51 | |
| *** futpib has quit IRC | 15:51 | |
| *** DocAvalanche is now known as DocScrutinizer51 | 15:51 | |
| *** futpib has joined #maemo-ssu | 15:52 | |
| *** lizardo has joined #maemo-ssu | 15:53 | |
| *** kolp has joined #maemo-ssu | 16:17 | |
| *** MohammadAG has quit IRC | 17:04 | |
| *** arcean has joined #maemo-ssu | 17:17 | |
| Estel_ | ShadowJK, I see | 17:20 |
| *** M4rtinK has joined #maemo-ssu | 18:24 | |
| *** NIN101 has joined #maemo-ssu | 18:53 | |
| *** dafox has joined #maemo-ssu | 19:35 | |
| *** sunny_s has quit IRC | 20:02 | |
| *** sunny_s has joined #maemo-ssu | 20:06 | |
| *** dafox has quit IRC | 20:21 | |
| *** xes has joined #maemo-ssu | 20:53 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 21:22 | |
| *** dafox has joined #maemo-ssu | 21:26 | |
| *** dafox is now known as Guest70244 | 21:26 | |
| *** Mihanizat0r has joined #maemo-ssu | 21:39 | |
| *** M13 has quit IRC | 21:42 | |
| *** Mihanizat0r has quit IRC | 21:44 | |
| *** BCMM has quit IRC | 22:06 | |
| *** Guest70244 has quit IRC | 22:11 | |
| *** Guest70244 has joined #maemo-ssu | 22:11 | |
| *** sunny_s has quit IRC | 22:46 | |
| *** NIN101 has quit IRC | 22:52 | |
| *** futpib has quit IRC | 23:17 | |
| *** andre__ has quit IRC | 23:20 | |
| *** andre__ has joined #maemo-ssu | 23:20 | |
| *** andre__ has joined #maemo-ssu | 23:20 | |
| *** LauRoman has joined #maemo-ssu | 23:41 | |
| *** dhbiker has quit IRC | 23:42 | |
| *** Martix has joined #maemo-ssu | 23:48 | |
| *** nox- has joined #maemo-ssu | 23:51 | |
| *** Martix has quit IRC | 23:52 | |
| *** Martix has joined #maemo-ssu | 23:53 | |
| *** lizardo has quit IRC | 23:56 | |
| Estel_ | DocScrutinizer05, I got interesting thing to discuss with you. That device wit borked usb phy started to act strangely - after boot, it uses ~ 500 mA, idle. Powertop and CPU usage are fine. When I try booston and boostoff from HEN, it becomes OK | 23:57 |
| Estel_ | same happens when I plug in charger and unplug | 23:57 |
| Estel_ | it started when I did hard reset of chip, btw | 23:57 |
| Estel_ | I assume that resetting bq24150 by i2c commands from booston and it's trap, are fixing that | 23:58 |
| Estel_ | so, it seems, that device start a day, after boot, in boost mode | 23:58 |
| Estel_ | ironically, if I disable charging at all, plugging in charger result in *increase* of power usage (until I unplug it, then, everything is normal, and next plug-ins doesn't affect power usage) | 23:59 |
| Estel_ | I wonder, what sits in that usb chip/phy? | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!