| 00:11.47 | *** join/#maemo-ssu kerio (~kerio@Maemo/community/contributor/kerio) |
| 00:25.16 | *** join/#maemo-ssu Martix (~martix@158.195.156.162) |
| 01:19.52 | *** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:ec9f:d21:9ba5:7bc) |
| 02:06.58 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 02:08.38 | *** join/#maemo-ssu sv (~discopig@modemcable140.167-130-66.mc.videotron.ca) |
| 02:08.39 | *** join/#maemo-ssu sv (~discopig@unaffiliated/discopig) |
| 02:26.13 | *** join/#maemo-ssu jon_y_ (~enforcer@2002:3c35:9d87::3c35:9d87) |
| 03:04.26 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 05:01.26 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 05:12.10 | *** join/#maemo-ssu luf (~luf@ip-94-112-59-161.net.upcbroadband.cz) |
| 07:21.50 | *** join/#maemo-ssu M4rtinK (~M4rtinK@158.195.156.165) |
| 07:42.56 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 08:03.52 | *** join/#maemo-ssu kolp (~quassel@212.255.227.127) |
| 08:42.34 | *** join/#maemo-ssu futpib (~futpib@89.106.197.42) |
| 09:04.34 | *** join/#maemo-ssu NIN101 (~NIN@p5DD284C0.dip0.t-ipconnect.de) |
| 09:08.38 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 09:24.23 | *** join/#maemo-ssu M4rtinK (~M4rtinK@147.175.116.232) |
| 09:27.45 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 10:29.51 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-195-168-252-233.static.nextra.sk) |
| 10:48.49 | *** join/#maemo-ssu arcean (~arcean@aael136.neoplus.adsl.tpnet.pl) |
| 10:56.53 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-195-168-252-233.static.nextra.sk) |
| 10:59.53 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 11:21.00 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-195-168-252-233.static.nextra.sk) |
| 11:23.54 | *** join/#maemo-ssu Martix (~martix@147.175.116.232) |
| 11:44.00 | *** join/#maemo-ssu Martix (~martix@147.175.116.232) |
| 11:47.52 | *** join/#maemo-ssu M4rtinK (~M4rtinK@147.175.116.232) |
| 11:54.34 | *** join/#maemo-ssu arcean_ (~arcean@aaen184.neoplus.adsl.tpnet.pl) |
| 12:27.37 | *** join/#maemo-ssu M4rtinK (~M4rtinK@147.175.116.232) |
| 12:33.58 | *** join/#maemo-ssu Martix (~martix@147.175.116.232) |
| 13:07.13 | *** join/#maemo-ssu Martix (~martix@147.175.116.232) |
| 13:17.26 | *** join/#maemo-ssu Martix_ (~martix@147.175.116.232) |
| 14:03.34 | *** join/#maemo-ssu arcean (~arcean@aaen184.neoplus.adsl.tpnet.pl) |
| 14:15.04 | kerio | DocScrutinizer05: my bq27k.py is becoming more and more clever :D |
| 14:15.11 | kerio | now i have a factory function that makes classes |
| 14:15.33 | DocScrutinizer05 | ducks and covers |
| 14:16.21 | DocScrutinizer05 | anybody a short noob summary about /etc/postfix/aliases for me? |
| 14:17.23 | DocScrutinizer05 | there's also a ./aliases.db, does it need special treatment or does it sync to ./aliases 'automagically' ? |
| 14:17.34 | DocScrutinizer05 | or are they unrelated? |
| 14:22.53 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 14:46.46 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
| 15:44.20 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 15:44.39 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 15:48.39 | *** join/#maemo-ssu arcean (~arcean@aaen184.neoplus.adsl.tpnet.pl) |
| 15:59.17 | merlin1991 | is does need treatment |
| 15:59.23 | merlin1991 | either postfix restart or some command |
| 16:01.11 | gregoa | newaliases? (which I used the last time for sendmail, in the last millenium) |
| 16:52.00 | *** join/#maemo-ssu NIN101 (~NIN@p5DD284C0.dip0.t-ipconnect.de) |
| 17:04.15 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 17:10.10 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 17:45.35 | *** join/#maemo-ssu Mihanizat0r (~MirandaLS@170.133-224-87.telenet.ru) |
| 17:55.06 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-86-49-81-87.net.upcbroadband.cz) |
| 18:19.15 | *** join/#maemo-ssu Martix_ (martix@nat/redhat/x-lkdrzaprnyzjjyqd) |
| 18:30.52 | *** join/#maemo-ssu Martix (martix@nat/redhat/x-jrnirdbgbcqkcgpd) |
| 18:38.17 | DocScrutinizer05 | yeah, jacekowski also suggested newaliases |
| 18:38.24 | DocScrutinizer05 | thanks |
| 19:05.38 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 19:20.51 | discopig | hi |
| 19:22.50 | *** join/#maemo-ssu gregoa_ (~gregoa@colleen.colgarra.priv.at) |
| 19:46.29 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 19:50.05 | freemangordon | merlin1991: dammit, fix that repo at last, even I am unable to upgrade to cssu, package system-services=0.3.8-68+0cssu1 is nowhere to be found :( |
| 19:55.09 | *** join/#maemo-ssu arcean_ (~arcean@aacu54.neoplus.adsl.tpnet.pl) |
| 20:55.24 | *** join/#maemo-ssu NIN101 (~NIN@p5DD284C0.dip0.t-ipconnect.de) |
| 21:20.02 | *** join/#maemo-ssu Estel_ (~Estel@d56-215.icpnet.pl) |
| 21:20.02 | *** join/#maemo-ssu Estel_ (~Estel@Maemo/community/contributor/Estel-) |
| 21:24.35 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 21:28.03 | *** join/#maemo-ssu arcean_ (~arcean@aacu54.neoplus.adsl.tpnet.pl) |
| 21:31.18 | 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? |
| 21:31.39 | 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 |
| 21:32.18 | 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 |
| 21:32.34 | Estel_ | now, where to modprobe bq2415x_battery, to get earliest charging possible? |
| 21:32.42 | Estel_ | /sbin/preinit sounds ok, but... |
| 21:33.06 | Estel_ | what about act_dead mode or emergency charging? anyone know what else should i edit to put charging module there? |
| 21:33.16 | Estel_ | device uses u-boot, if that matters |
| 21:34.14 | 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 |
| 21:34.47 | Estel_ | ShadowJK, any ideas, how to force device into *really* charging in emergency mode (charger plugged in and battery under 3000 mV) |
| 21:35.14 | 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) |
| 21:39.51 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 21:46.34 | DocScrutinizer05 | amber LED is hardwired to bq24150 STAT output that indicates chip is in charging mode |
| 21:47.28 | 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 |
| 21:47.49 | kerio | so Estel_'s stuck doing emergency charge at 100mA? |
| 21:48.03 | DocScrutinizer05 | bottom line: when steady amber LED, bq24150 *is* charging battery, at least with 100mA |
| 21:48.44 | Estel_ | DocScrutinizer05, strange, as with this device, it doesn't work in emergency mode at all, while in normal mode it charger pefectly |
| 21:48.48 | *** join/#maemo-ssu entitled (e@lodju.net) |
| 21:48.59 | Estel_ | standard 1200 mA battery went from 2900 mV to 2600 mV |
| 21:49.11 | Estel_ | during 10+ hours of "emergency charging" |
| 21:49.12 | 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 |
| 21:49.18 | Estel_ | in that particular device |
| 21:49.26 | Estel_ | i would be happy with 100 mA too |
| 21:49.55 | 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 |
| 21:50.18 | DocScrutinizer05 | I don't know how much the system will consume when in pre-boot state at low voltage |
| 21:50.20 | Estel_ | but that battery definitelly should get charged above 3000 mV pretty fast, @100mA |
| 21:50.50 | Estel_ | just assumption - it shouldn't consume as much as 100mA, methinks |
| 21:50.54 | DocScrutinizer05 | it *should* be really low power consumption |
| 21:51.01 | Estel_ | nods |
| 21:51.37 | 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 |
| 21:51.38 | Estel_ | ah |
| 21:51.53 | Estel_ | from time to time, bme replacement detect this device as "boost mode", if not forced |
| 21:51.57 | Estel_ | when connected to charger |
| 21:52.10 | Estel_ | I wonder why, and how it can affect emergency charging? |
| 21:52.30 | Estel_ | (btw, during non-charging, idle consumption is absolutely normal, so no power leaking) |
| 21:52.46 | DocScrutinizer05 | maybe whatever damaged PHY (extreme overvoltage on USB?) also smoked up bq24150 |
| 21:52.54 | Estel_ | anyway, it seems that I can't affect the way emergency charging is happening via any means? |
| 21:53.20 | Estel_ | DocScrutinizer05, shouldn't be the case, as it's charging fine when device is booted using bq2415x_charger module :P |
| 21:54.00 | 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) |
| 21:54.47 | 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) |
| 21:54.49 | Estel_ | I see |
| 21:54.57 | Estel_ | hm, I wonder what could trigger other state... |
| 21:55.04 | DocScrutinizer05 | twl4030 might become sticky on some weird settings regarding power/usb |
| 21:55.35 | DocScrutinizer05 | ~full-reset |
| 21:55.44 | DocScrutinizer05 | or somesuch |
| 21:56.01 | 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? |
| 21:56.24 | Estel_ | DocScrutinizer05, if full reset is that thing including removing battery for extended period of time, sadly, I tried it |
| 21:56.56 | DocScrutinizer05 | ~listkeys #maemo |
| 21:57.14 | DocScrutinizer05 | ~listkeys reset |
| 21:57.39 | DocScrutinizer05 | ~full reset |
| 21:57.39 | 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 |
| 21:57.44 | 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 |
| 21:57.53 | DocScrutinizer05 | meh! |
| 21:58.08 | Estel_ | I just started to think I've missed some little button on N900 :P |
| 21:58.38 | Estel_ | thanks for taking your time to explain emergency charger and searching for that factoid, btw |
| 21:59.10 | *** join/#maemo-ssu gregoa (~gregoa@colleen.colgarra.priv.at) |
| 21:59.51 | 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? |
| 22:01.30 | DocScrutinizer05 | full reset for twl4030 is done by holding powerbutton for 15s while inserting battery, or somesuch |
| 22:04.10 | DocScrutinizer05 | ~listkeys reset |
| 22:04.20 | merlin1991 | freemangordon: use http://community-testing.merlin1991.at/ ;) |
| 22:04.48 | freemangordon | merlin1991: it is missing there too |
| 22:04.55 | merlin1991 | dafuq |
| 22:05.02 | freemangordon | and in all of the mirrors |
| 22:05.04 | Estel_ | DocScrutinizer05, thanks |
| 22:05.27 | freemangordon | merlin1991: oh, wait |
| 22:05.34 | Estel_ | one should hold it for at least 15 seconds and then enter battery, or hold and insert, then keep holding? |
| 22:05.42 | freemangordon | merlin1991: it is in upstart, WTF? |
| 22:05.44 | merlin1991 | http://community-testing.merlin1991.at/pool/free/u/upstart/system-services_0.3.8-68%2b0cssu1_armel.deb |
| 22:05.53 | merlin1991 | yeah silly upstart package |
| 22:06.17 | freemangordon | yeah, my bad, I was looking in s directory |
| 22:06.25 | merlin1991 | I did aswell |
| 22:06.37 | freemangordon | merlin1991: however, repo should be fixed |
| 22:06.46 | 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 |
| 22:06.59 | freemangordon | Estel_: run sdboot |
| 22:07.05 | Estel_ | (when one enters u-boot console, it informs about it, but none of them works) |
| 22:07.08 | freemangordon | or run mmcboot |
| 22:07.13 | Estel_ | freemangrdon, it gives shitload of errors |
| 22:07.13 | DocScrutinizer05 | I think it been like "hold for 12s at most 12s after inserting battery" or whatever |
| 22:07.15 | Estel_ | any of them |
| 22:07.45 | kerio | Estel_: manual parameters |
| 22:07.46 | freemangordon | Estel_: then you don't have fat first partition. afaik |
| 22:08.11 | Estel_ | freemangordon, I have fat as first partition on emmc and it works from u-boot menu entries |
| 22:08.18 | Estel_ | *just* mmcboot command doesn't work |
| 22:08.47 | merlin1991 | DocScrutinizer05: are you planning on staying up longer today? |
| 22:08.59 | Estel_ | it complains something about ext4, maybe it get confused by mmcblk0p2 being eext4? but why it cares, it should look at mmcblk0p1 only |
| 22:09.13 | freemangordon | Estel_: no idea then |
| 22:09.40 | 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... |
| 22:10.03 | 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 |
| 22:10.34 | 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 |
| 22:10.58 | 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 |
| 22:11.12 | Estel_ | s/fuck in/fucking/ |
| 22:16.11 | DocScrutinizer05 | merlin1991: probably |
| 22:16.14 | DocScrutinizer05 | merlin1991: why? |
| 22:16.25 | merlin1991 | might need some sudo on garage/repo later on |
| 22:16.31 | DocScrutinizer05 | np |
| 22:31.50 | 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? |
| 22:32.10 | Estel_ | or holy low voltage, like < 3000mV but > than 2500 mV |
| 22:32.48 | 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? |
| 22:38.27 | Estel_ | "from different barrel" - I have 4 packages ready, but no time to polish packaging and release into repositories, ffs :P |
| 22:38.49 | Estel_ | irony hits - all of them are for non-free section (kon-boot, and 3 games) |
| 22:39.36 | Estel_ | especially funny, considering, how I used to ignore annoucements for non-open source things for Maemo |
| 22:39.58 | Estel_ | especially for non-FOSS game projects, heh |
| 22:53.59 | *** join/#maemo-ssu arcean_ (~arcean@aacu54.neoplus.adsl.tpnet.pl) |
| 23:14.31 | 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 |
| 23:17.13 | DocScrutinizer05 | ShadowJK: according to schematics and bq24150 datasheet it's forced into 500mA mode on OTG=1 in POR mode |
| 23:20.00 | DocScrutinizer05 | OTG D4 I |
| 23:20.02 | 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 |
| 23:20.03 | DocScrutinizer05 | = Low, Iin – limit = 100mA, see the Control Register for details. |
| 23:22.49 | DocScrutinizer05 | while |
| 23:23.04 | 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. |
| 23:26.56 | ShadowJK | DocScrutinizer05; current balance and the time I had to start charge indicated 100mA |
| 23:27.26 | ShadowJK | I didn't always manage to start charging before voltage dropped too low |
| 23:31.01 | DocScrutinizer05 | sorry, I can't follow |
| 23:31.28 | DocScrutinizer05 | NB the OTG function is defined for POR (non I2C) mode only |
| 23:31.50 | DocScrutinizer05 | in I2C mode you can configure OTG input to anything you like |
| 23:32.48 | DocScrutinizer05 | btw difference of 1704 and 1707 is in level of charge output, so it matches what bq24150 needs for emergency fastcharging to work |
| 23:32.51 | DocScrutinizer05 | iirc |