**** BEGIN LOGGING AT Sat Sep 11 02:59:57 2010 Sep 11 04:23:43 lindi-: have you actually achieved what you wrote here about modifying the GPS firmware? http://lists.openmoko.org/pipermail/community/2010-September/062993.html Sep 11 04:25:03 pabs3: you can find some nice scripts of him that allow to dump a firmware to a file Sep 11 04:25:42 wow, got a link? Sep 11 04:26:18 doesn't seem to be documented on User:Lindi Sep 11 04:26:21 pabs3: but i'm not sure if he's actually implemented the proposed idea, it feel like it's fairly complex considering one would need to do all the necessary hooking into the arm binary without the sources. Sep 11 04:27:13 PaulF, hey, i have something i'd like you to look at Sep 11 04:27:30 rooly: hey :) Sep 11 04:27:34 pabs3: a moment Sep 11 04:28:07 qtmoko has a problem with it's displayed signal quality Sep 11 04:28:12 pabs3: http://lindi.iki.fi/lindi/git/ubx.git/ Sep 11 04:28:35 i checked the source and mapped out the values, along with a proposed change for it Sep 11 04:28:58 radekp isn't very informed about it, self-admitedly, and wanted me to get a second opinion Sep 11 04:29:01 http://irrlichtirc.g0dsoft.com/rooly/NewMapProposal.png Sep 11 04:29:21 thats the iphone / android mappings, and the current and proposed qtmoko mappings Sep 11 04:31:20 rooly: is calypso functional at ~-105dBm ? Sep 11 04:31:40 rooly: i mean can it be that the modern phones require less power for the same service? Sep 11 04:32:42 PaulF: thanks Sep 11 04:32:44 PaulF, i don't really have any accurate readings for calypso, all i have is whats visible in the source and what are more sane mappings for bar-signal ratios Sep 11 04:33:09 rooly: i know comparing expected service quality is harder than energy but you might do some empirical tests. Sep 11 04:34:18 pabs3: one of the scripts in there enables raw readings that allowed him to get high differential precision. Have you seen his report about it? Sep 11 04:35:40 PaulF: I have not, haven't had time to read lists recently, nor do anything with the FR except use intone Sep 11 04:36:38 * pabs3 wonders what FixNow is Sep 11 04:40:04 pabs3: (differential) http://lists.osgeo.org/pipermail/foss-gps/2010-August/000407.html Sep 11 09:51:14 pabs3: nope but I saw enough to say that's it's only hard, not impossible :) Sep 11 12:37:54 I just reinstalled SHR-u and deleted my ~/.e to try and fix my system. now I get a really tiny and crap top bar with no way to close apps Sep 11 12:38:09 anyone know how to get the old one back? Sep 11 12:38:57 pabs3: why do people need to constantly delete ~/.e? Sep 11 12:40:40 in my case the screen was white due to some module not being loadable and thus preventing it from displaying the home screen and other UI bits Sep 11 12:41:27 another reason to rm -rf ~/.e is to see what the new UI defaults are Sep 11 12:44:03 bye Sep 11 12:46:18 lindi-: suckiest thing about ~/.e is that it is all binary files Sep 11 12:46:39 I here GNOME is moving that way with dconf too :( Sep 11 12:48:55 hmm, the new SHR web browser is pretty Sep 11 13:07:11 gena2x: lindi-: i did another 3 measurements, but i am not clever at all from it, you can see results here http://activationrecord.net/radekp/pub/suspend_power2/results.txt Sep 11 13:07:28 radekp: wel really need to get you an account Sep 11 13:07:48 lindi-: do you know some openmoko admin who could take a look at it? Sep 11 13:08:21 roh Sep 11 13:08:37 btw here are also patches and dmesgs with currents http://activationrecord.net/radekp/pub/suspend_power2/ Sep 11 13:08:42 I'm thinking we should move the bugs somewhere else Sep 11 13:09:03 maybe alioth, launchpad, sourceforge Sep 11 13:10:02 i quite like github for source code... but that's just idea Sep 11 13:11:52 it's quite strange that now in this devices which affect power during suspend are quite different Sep 11 13:12:25 radekp: yes but for bugs Sep 11 13:12:39 only soc-audio is same with 5mA Sep 11 13:36:03 radekp: this time inital value is different Sep 11 13:36:42 radekp: lis patch is not in .34 at all Sep 11 13:36:56 radekp: no, stop Sep 11 13:37:14 gena2x: it's in my git, backported from 2.6.29 Sep 11 13:37:51 gena2x: i doubt it causes any problem - i tried also plain openmoko 2.6.34 git and had the same results Sep 11 13:38:09 radekp: i am just reading line-by line Sep 11 13:38:39 gena2x: this time i measured it really carefully - double checked every change Sep 11 13:39:34 gena2x: i have also powered down bt, gsm (with AT@POFF) and set brightness to 0 Sep 11 13:43:27 gena2x: question is - why is 2.6.29 eating 14mA more then 2.6.32 after boot... Sep 11 13:43:35 erm 2.6.34 Sep 11 13:43:51 radekp: original idea were to dump from boot Sep 11 13:44:09 radekp: this way we are starting from common thing - bootloader Sep 11 13:44:23 oki, i think i will do this for boot now Sep 11 13:45:29 radekp: i tried this yesterday for .29... but this damn thing hangs and corrupts my fs. Sep 11 13:45:41 i though measuring suspend will show something obvious... but it looks we need same starting values Sep 11 13:46:14 previous measurement were starting with same values Sep 11 13:46:18 * radekp is doing it on jffs2 - SD card would be probably dead by now Sep 11 13:48:01 i am going to see what is usb-gadget Sep 11 13:56:16 gena2x: i tried compiling 2.6.34 without usb but current in suspend was still high :( Sep 11 13:56:21 radekp: notice that (72.9-69.4)+3.2=6.7 (both usb things) and 15.3-9.5=5.8. Sep 11 13:56:44 radekp: compiling without something do not mean something is off Sep 11 13:57:04 gena2x: oki Sep 11 13:57:10 is there really no easy way to measure consumption of individual regulators? Sep 11 13:57:11 radekp: because it can be enable on bootloader Sep 11 13:57:32 gena2x: ahh oki Sep 11 13:57:32 radekp: and in fact, at least in u-boot, seem _tons_ of stuff enabled Sep 11 13:59:31 lindi-: best way in described here i think: http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBIQFjAA&url=http%3A%2F%2Fertos.nicta.com.au%2Fpublications%2Fpapers%2FCarroll_Heiser_10.pdf&rct=j&q=consumption%20pdf%20freerunner&ei=XYqLTKeWIOCgOLaMtJcL&usg=AFQjCNGjOiokWXMTdKf6W32q_clcVb0T7A&cad=rja Sep 11 13:59:35 ops Sep 11 13:59:43 sorry, damn google Sep 11 13:59:56 i hope i will be able to measure boot - my ammeter is only up to 200 mA then it disconnect Sep 11 14:00:03 lindi-: http://ertos.nicta.com.au/publications/papers/Carroll_Heiser_10.pdf Sep 11 14:00:48 radekp: strange, most of them are 2A Sep 11 14:01:03 not really strange, ok Sep 11 14:01:37 mine can do 2A too but very imprecise Sep 11 14:02:37 strange. i were suprosed to see your data even with 1 digit after decimal point Sep 11 14:02:50 s/suprosed/surprised/ Sep 11 14:02:50 gena2x meant: strange. i were surprised to see your data even with 1 digit after decimal point Sep 11 14:04:02 gena2x: i can switch between 2A and 200mA Sep 11 14:04:40 ok. i am diving into usb sources. Sep 11 14:07:32 gena2x: i wonder how they got cpufreq working in that paper on fr Sep 11 14:07:57 lindi-: may be this were author of cpu-freq patch? :) Sep 11 14:08:31 lindi-: but most of exaclt data seem not really correct Sep 11 14:08:57 lindi-: but lets not dive into it atm Sep 11 14:09:58 gena2x: well i'd be very interested in cpufreq :) Sep 11 14:11:09 lindi-: why? cpu is anyway idle then doing nothing. Sep 11 14:11:45 hmmm, is the FR ram really split between in-soc and on-bus? Sep 11 14:12:10 pabs3: split? it has 2 ram modules Sep 11 14:12:28 pabs3: i inside cpu one away Sep 11 14:12:32 s/i/1/ Sep 11 14:12:33 I didn't know about that Sep 11 14:12:34 gena2x meant: pabs3: 1 inside cpu one away Sep 11 14:12:45 gena2x: because 100 MHz saves energy Sep 11 14:13:06 gena2x: see my email 'cpufreq patches seem to save ~30 mA (Re: [RFC 0/3] CPU frequency scaling for GTA02)' Sep 11 14:13:37 neat! Sep 11 14:13:43 lindi-: i bet we can save much much more if we'll do proper review of power subsystem Sep 11 14:13:54 i was playing with uboot aaaaaaaaaaaaaaaaaages ago. Locking at 60MHz Sep 11 14:13:55 gena2x: possibly Sep 11 14:14:09 Did cesarb's patches ever get finished? Sep 11 14:14:17 gena2x: but we know that cpufreq saves save energy for a fact Sep 11 14:15:25 pabs3: btw, this division is reason why we can't have 128+64Mb ram. 256mb sdram is supported by cpu, but modules must be of same size. Sep 11 14:16:10 can the audio stuff play music during CPU suspend? Sep 11 14:16:14 lindi-: need more data to see how much really saved. my guess is that in idle mode consumption should be same Sep 11 14:16:18 pabs3: no Sep 11 14:16:24 gena2x: i measured idle mode consumption Sep 11 14:16:47 lindi-: for 400mhz and 100mhz mode? on nodebug kernel? Sep 11 14:16:48 pabs3: I vaguely recall that the glamo can do mp3 - but not in the configuration it's in. Sep 11 14:16:56 gena2x: nobody talked about nodebug back then Sep 11 14:17:15 gena2x: but nodebug has not changed idle mode consumption for me Sep 11 14:17:16 lindi-: i bet it significanlty reduces power consumption Sep 11 14:17:31 SpeedEvil: glamo? not the wolfson? Sep 11 14:17:39 yes. Sep 11 14:17:43 lindi-: ok. not significantly Sep 11 14:17:44 But it can't. Sep 11 14:17:52 The wolfson is just an AC97 - IIRC codec Sep 11 14:17:57 lindi-: but timer interrupt still happens in idle mode Sep 11 14:18:04 gena2x: yep Sep 11 14:18:14 It has no buffering, and relies on the SoC to keep feeding it samples. Sep 11 14:18:23 lindi-: so debugging interrupts will still influence it Sep 11 14:18:32 gena2x: sure Sep 11 14:18:58 lindi-: btw, i propose anarsoul's 100mhz patch to same few power :) Sep 11 14:19:14 DEbugging interrupts only influence stuff if it keeps the CPU awake, or awakes it. Unless they use lots of CPU Sep 11 14:19:15 *save Sep 11 14:19:17 gena2x: where's that patch? Sep 11 14:21:28 lindi-: http://downloads.tuxfamily.org/linuxrx1950/patches/random/0001-Use-100-as-HZ-value-on-S3C24XX.patch Sep 11 14:22:07 gena2x: but may be i am wrong - he reported no diff in power consumption. but i found +2% in other benchmarks. Sep 11 14:22:36 gena2x: 2% is not much compared to what I got with the cpufreq stuff Sep 11 14:22:58 'other benchmarks' is not power-related stuff Sep 11 14:23:16 i didn't measure power at all Sep 11 14:24:15 ok. this still open question :) Sep 11 14:24:26 * gena2x back to usb Sep 11 14:24:51 * pabs3 wonders if those printks on suspend/resume will be removed at some point Sep 11 14:25:36 pabs3: which one? they _all_ are controlled by kernel config. Sep 11 14:25:42 may almost all Sep 11 14:28:56 gena2x: looks like some modesetting stuff. Power on sequence About to set power.. Setting JBT power... 2 Setting mode! Setting base! entering (old_state=normal, new_state=normal) Setting previous mode Sep 11 14:51:41 radekp: hm... s3c2440-usbgadget is platform-specific implementation of usb-slave mode. things like cdc ether working on top of this api. Sep 11 14:53:15 lindi-: btw, about power consumption. is gsm put to deep-sleep constantly? i mean why not to put it into deep-sleep while idle? Sep 11 14:53:45 gena2x: deep sleep does not work without fix for #1024? Sep 11 14:54:08 lets assume we know only phones with #1024 for simplicity. Sep 11 14:54:16 then of coures yes Sep 11 14:54:39 so it deep-sleeps between calls? Sep 11 14:55:01 gena2x: i don't see why not Sep 11 15:04:48 can anyone tell me why E17 insists on creating xterm and mplayer desktop entries, even though such .desktop files are not in /usr/share/applications and xterm isn't even installed in SHR? Sep 11 16:24:44 hi Sep 11 20:16:38 hi all Sep 11 20:16:42 anyone here? Sep 11 20:17:35 id' like to have some info about usb controller of the Freerunner and if is it possible to port psfreedom to the FR ... can you help me? :) Sep 11 20:20:10 usb controller is the onboard controller of the SC2440 Sep 11 20:20:25 It has - IIRC - no phy - it's just directly connected. Sep 11 20:20:50 s3c2440 Sep 11 20:21:12 SpeedEvil, thanks a lot Sep 11 20:21:22 i think this is a good point to start Sep 11 20:28:06 i noticed right now that there is someone working on psfreedom porting for FR Sep 11 20:28:09 :) Sep 11 21:58:00 . Sep 11 23:07:50 hey Sep 11 23:08:26 so i have a freerunner, and i've not done anything with it for about a year.... i'd like to get it going again... is there anyway to get it charged up using the usb cable? Sep 11 23:10:07 mattl: just connecting the wall charger has worked for me Sep 11 23:10:34 i don't know where the wall charger is. hm. Sep 11 23:12:04 lindi-: haha thank you Sep 11 23:12:07 plug it in, leave it 6hours Sep 11 23:12:10 i just decided to look for it, and found it Sep 11 23:14:15 I think I used something like http://paste.debian.net/89367/ to speed up charging without wall charger Sep 11 23:18:11 i'm not sure what to do with that. Sep 11 23:24:26 mattl: it's just a patch to u-boot to force charging at 500 mA. normally it only charges at 100 mA **** ENDING LOGGING AT Sun Sep 12 02:59:57 2010