| 01:06.49 | DocScrutinizer05 | musb core tries to talk to phy via ULPI. If phy is defect, the staemachine in musb core might go mad and spam phy with commands and gets IRQ as answer and resends commands |
| 01:07.20 | DocScrutinizer05 | almost a "hardware only" thing |
| 01:10.32 | DocScrutinizer05 | or just maybe KP has "newest leete patches" and now tries to enable boost chargepump in twl4030 ;-P |
| 01:11.31 | DocScrutinizer05 | just mere luck that this chargepump is missing a capacitor, or we'd burn the N900 by one chip in boostmode while other chip in chargemode |
| 01:12.14 | DocScrutinizer05 | on beaglebord somebody smoked up his hw this way |
| 01:14.26 | DocScrutinizer05 | OOOH HAHA |
| 01:15.11 | DocScrutinizer05 | OTG pin of bq24150 actually switches the chip into boost mode when in I2C mode |
| 01:16.15 | DocScrutinizer05 | and the OTG pin on bq24150 is connected to... PHY |
| 01:20.47 | DocScrutinizer05 | so if kernel sends "keep alive" aka watchdog tickling to bq24150 via I2C but forgets to properly initialize the chip (configure OTG pin so it will not force boost mode), you most likely will see nasty behaviour |
| 01:21.33 | DocScrutinizer05 | particularly with broken PHY chip that obviously doesn't obey to what musb core tells it to do |
| 01:28.41 | DocScrutinizer05 | when PHY isn't connected to battery anymore, it might even cause wild oscillation between boost (PHY now gets voltage from boostmode via USB, and thus starts to work correctly, disasserting CHARGER/OTG) and proper "normal mode" (PHY works properly from VBUS voltage by boost, and thus doesn't provide OTG pulldown anymore, so bq24150 stops boost) |
| 01:30.13 | DocScrutinizer05 | this wild oscillation would for sure cause arbitrary power burning, by charging up buffer capacitors on VBUS, then using same enery stored in those buffer capacitors to charge battery, then starting with boostmode again a millisecond later |
| 01:31.12 | DocScrutinizer05 | obviously attaching a charger will fix it since VBUS always present so PHY won't stop working and thus never asserts OTG erratically |
| 01:31.54 | DocScrutinizer05 | funny bug |
| 01:33.13 | DocScrutinizer05 | so funny I even like to check back in schematics now if it's a real possibility, or if I missed sth |
| 01:40.57 | DocScrutinizer05 | nope, i made a logical mistake, OTG pin needs HIGH voltage to force chip into boost mode, NOT GND level. And the line from PHY to bq24150 (CHRG_DET -> OTG) has even a pulldown R4281 |
| 01:46.28 | DocScrutinizer05 | anyway PHY depends on GAIA HFCLKOUT, and GAIA is the chip that gets reset by full-reset procedure |
| 01:47.54 | DocScrutinizer05 | HFCLKOUT is a (iirc) 32768Hz clock derived from RTC |
| 01:48.31 | DocScrutinizer05 | and it's configurable in sticky GAIA (aka TWL4030) config registers |
| 01:48.55 | *** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:ec9f:d21:9ba5:7bc) |
| 01:49.18 | DocScrutinizer05 | without that clock, ULPI communication to musbcore for sure is flawed |
| 01:58.04 | DocScrutinizer05 | anywy, PHY is conected to quite a number of other subsystems, and it could provide enough material for a master thesis to try and analyze all possible failure modes whith this chip going south in various strange ways |
| 01:59.43 | DocScrutinizer05 | not even complete removal of that PHY 1707 chip will yield predictable results |
| 02:04.49 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 03:03.48 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 04:18.18 | *** join/#maemo-ssu M13 (~Miranda@83.149.37.32) |
| 04:42.20 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 06:03.03 | *** join/#maemo-ssu M13 (~Miranda@83.149.37.32) |
| 06:31.27 | *** join/#maemo-ssu amiconn (amiconn@rockbox/developer/amiconn) |
| 06:37.14 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-86-49-81-87.net.upcbroadband.cz) |
| 06:59.06 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 07:07.12 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 09:17.29 | *** join/#maemo-ssu sv (~discopig@70.26.211.6) |
| 09:17.29 | *** join/#maemo-ssu sv (~discopig@unaffiliated/discopig) |
| 09:20.54 | *** join/#maemo-ssu kolp (~quassel@108.Red-83-33-70.dynamicIP.rima-tde.net) |
| 09:34.56 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 09:55.48 | *** join/#maemo-ssu futpib (~futpib@89.106.197.127) |
| 11:03.17 | *** join/#maemo-ssu FReaper (~assassin@203.106.65.1) |
| 11:41.41 | *** join/#maemo-ssu sv (~discopig@unaffiliated/discopig) |
| 12:21.26 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-okpjzyhxbfhalbmy) |
| 13:00.22 | *** join/#maemo-ssu kolp (~quassel@108.Red-83-33-70.dynamicIP.rima-tde.net) |
| 13:11.09 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 13:11.44 | jonwil | hi |
| 13:20.18 | *** join/#maemo-ssu arcean (~arcean@apn-77-114-33-87.dynamic.gprs.plus.pl) |
| 14:40.11 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 15:41.05 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28D3A.dip0.t-ipconnect.de) |
| 15:43.24 | DocScrutinizer05 | hi jonwil |
| 15:49.30 | *** join/#maemo-ssu andre__ (~andre@ip-62-24-76-119.net.upcbroadband.cz) |
| 15:49.30 | *** join/#maemo-ssu andre__ (~andre@wikimedia/aklapper) |
| 15:49.43 | jonwil | wonders if all the issues relating to maemo infrastructure were ever solved |
| 15:49.56 | jonwil | like the problems with the signature on the repositories |
| 15:53.22 | *** join/#maemo-ssu NIN102 (~NIN@p5DD296A8.dip0.t-ipconnect.de) |
| 16:17.01 | DocScrutinizer05 | no, those signature problems are still pending, the nokia-ext guy seems has no pressure to do sth about it |
| 16:17.45 | DocScrutinizer05 | otoh siganture problem is not related to maemo infra |
| 16:18.43 | DocScrutinizer05 | right now we have another problem that's actually related to maemo.org: SSL certs, they are expiring by the day now |
| 16:18.52 | DocScrutinizer05 | and we still don't own the domain |
| 16:21.01 | *** join/#maemo-ssu DocScrutinizer51 (~lagrange@openmoko/engineers/joerg) |
| 16:29.05 | jonwil | So because the domain and stuff are still owned/controlled by Nokia only Nokia can legally obtain SSL certs for it? |
| 16:42.53 | kerio | DocScrutinizer05: startssl will allow you to get free certs if you control the matching webserver iirc |
| 16:42.57 | kerio | either that, or the DNS |
| 16:50.56 | DocScrutinizer05 | yes, but only lowest "level" of cert. We'd prefer a wildcard cert, and those are only available address-validated not domain-validated, and they cost a few bucks |
| 16:52.52 | DocScrutinizer05 | anyway warfare seems has opted for startssl for now |
| 17:03.13 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-86-49-81-87.net.upcbroadband.cz) |
| 17:15.39 | kerio | of course he did |
| 17:15.40 | kerio | it's /free/ |
| 17:16.01 | kerio | and it requires barely more than no effort |
| 17:36.41 | *** join/#maemo-ssu arcean_ (~arcean@apn-77-112-169-170.dynamic.gprs.plus.pl) |
| 17:49.54 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 18:00.48 | *** join/#maemo-ssu luf (~luf@ip-94-112-59-161.net.upcbroadband.cz) |
| 18:42.46 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
| 18:51.01 | *** join/#maemo-ssu andre__ (~andre@wikimedia/aklapper) |
| 18:53.52 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 19:29.51 | Estel_ | DocScrutinizer05, when I reset chip, and then enable boost via i2cset like in booston from HEN, I got exact same power usage as just after boot, on that device with broken smth |
| 19:30.35 | Estel_ | I workarounded it by modifying /etc/event.d/bme to unload module touching bq24150, enabling boost via i2cset, reseting bq24150 via i2c set, loading module again, and forcing dedicated charging |
| 19:30.59 | Estel_ | strangely, skipping "enable boostmode" step, sticking to only reset command, doesnt work |
| 19:31.11 | Estel_ | despite that all other symptoms seems to idnicate device is in boostmode since boot |
| 19:31.53 | Estel_ | fortunatelly, trick with enabling boost and resetting chip in next command works, so no need to put charger in after every boot |
| 19:32.27 | Estel_ | for sure this device wasn't presenting that behavior from beginning, it seems that usage made this problem appear |
| 19:32.42 | Estel_ | so I wonder what will come next :P |
| 20:47.56 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 21:26.28 | *** join/#maemo-ssu merlin_1991 (~merlin@merlin1991.at) |
| 21:27.31 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
| 21:28.34 | *** join/#maemo-ssu g3kk3r (torrkull@lehtori.cc.tut.fi) |
| 21:28.55 | *** join/#maemo-ssu ShadowJK_ (jk@terminus.enivax.net) |
| 21:32.32 | *** join/#maemo-ssu merlin1991 (~merlin@Maemo/community/cssu/merlin1991) |
| 21:36.29 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 23:53.37 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@120.85.133.181) |
| 23:56.05 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |