**** BEGIN LOGGING AT Wed Jul 21 02:59:58 2010 Jul 21 03:13:52 gena2x: yep, no ThibG delay patch there.. Jul 21 05:26:34 DocScrutinizer: moin, PIN is not the reason... it _is_ buffered in userspace Jul 21 05:27:13 DocScrutinizer: apart from releasing GMS/rerequesting GSM not working now... speed might be a reason Jul 21 05:27:35 and I agree that this should be fixed Jul 21 06:07:42 mrmoku: (usb netlink) i seem to remember too that i was somehow involved (less than mwester) yet no idea what exactly to look for. I'll check the sources. Jul 21 06:09:09 PaulFertser: I checked git history... and found the appropriate commits Jul 21 06:09:15 and yes, they are missing in new kernel Jul 21 06:10:23 PaulFertser: 37d2b0bea0314d0947af19152898c1ca7fe736cc and f16c3431a1a7510eb3504ec5d96677dd0fac4cd6 Jul 21 06:12:17 gena2x: Weiss: WS from glamo tuned up Qi were so often, that i had to reflash Qi back to the original SHR version Jul 21 06:12:44 mrmoku: ok Jul 21 06:12:53 mrmoku: so no need for me to do anything, nice :) Jul 21 06:13:04 mrmoku: the most important issue is energy consumption in suspend! Jul 21 06:13:40 gena2x: Weiss: and not being the only one, some other czech fr users are experiencing the same. thus the report :) Jul 21 06:15:19 PaulFertser: yeah... any idea about how to tackle that one? Jul 21 06:15:54 PaulFertser: how to reliably find out what sucks power in suspend? Jul 21 06:28:31 mrmoku: hm... one should have been more careful when porting om-specific patches probably. Jul 21 06:28:50 mrmoku: i think the kernel prints gpios state just before the suspend, does it? Jul 21 06:28:51 PaulFertser: probably, yes... too many things got lost Jul 21 06:29:41 let me check Jul 21 06:30:38 PaulFertser: yep Jul 21 06:32:29 mrmoku: then one has to compare it with old working version. I can provide you with data as i'm still running andy-tracking. Jul 21 06:34:52 mrmoku: i'm not quite sure on which stage those are printed and hence it might be a false lead http://paste.debian.net/81031/ Jul 21 06:35:26 PaulFertser: http://shr.pastebin.com/ArFdzNYw Jul 21 06:35:32 mrmoku: but i think ~40mA looks like some parasiting powering again. Have you checked it yourself? Is it the same with GSM modem turned on and off? Jul 21 06:36:24 E and F differ Jul 21 06:37:33 PaulFertser: I tried with GSM on and off... but not scientifically :) Will have to redo Jul 21 06:38:05 well and G differs too Jul 21 06:39:38 heh... and there is one missing even (in the new kernel) Jul 21 06:40:06 PaulFertser: where can one read up the meaning of the different GPIOs? Jul 21 06:41:34 mrmoku: meaning is from the schematics. Jul 21 06:41:52 mrmoku: actual register interface is either in SoC documentation or by reading the kernel sources. Jul 21 07:35:11 mrmoku: i'm at work atm so i'm feeling uncomfortably digging deep Jul 21 07:37:50 Hi all... anyone noticed GSM deregistering a few seconds after it has registered on SHR-U or is it only me? Jul 21 07:42:19 PaulFertser: sure... I have to do some daywork too Jul 21 07:42:39 PaulFertser: trying the g_ether netlink thing meanwhile Jul 21 07:48:52 someone asked for more modular kernel again (to keep it <2MB) Heinervdm also asked for it a while ago, do we all agree that we need it? :) Jul 21 07:50:24 I don't really care as I'm using Qi and don't see the problem with updating NAND u-boot env Jul 21 07:57:17 * mrmoku feels the same Jul 21 07:57:55 JaMa: if it is as easy as building some parts as module that are not strictly always needed... Jul 21 07:58:55 PaulFertser: just taking those two patches from mwester does not work... causes endless loop of BUG: scheduling while atomic or something like that Jul 21 07:59:30 mrmoku: I can move BT/g_ether/wlan/sound back to modules.. but I'm not sure all users will be happy with this change Jul 21 07:59:51 mrmoku: especially when some module fail to load.. but I can try.. Jul 21 08:01:15 JaMa: g_ether should be a module anyway, no? Jul 21 08:01:25 otherwise you can't use one of the other g_ things Jul 21 08:01:33 yup Jul 21 08:01:59 bt and wlan are fine as module too Jul 21 08:02:02 not sure about sound Jul 21 08:02:08 if might want to have that in the kernel Jul 21 08:02:46 +we Jul 21 08:04:05 DocScrutinizer: there is another reason, why I think using +CFUN instead of just releasing GSM is better... that works even if some other process has GSM requested... like a openbmap-logger running in the background which you forgot about Jul 21 08:05:43 mrmoku: I'll try if bt+wlan+g_ether is enough to remove Jul 21 08:06:10 mrmoku: and also upgrade stablepatch + add ThibG delay/WS patch Jul 21 08:06:19 mrmoku: surely g_ether can't be unbinded to use other gadget modules? Jul 21 08:07:40 PaulFertser: no, not sure... never even tried one of the other g_... Just what I remember to have heard Jul 21 08:09:48 iirc at least some userspace app was written to only replace loaded g_* module Jul 21 08:11:14 xrmx_: build failed for http://annarchy.freedesktop.org/~rm/deb/webkit_1.2.3-2.dsc: /usr/bin/ld: fatal error: out of file descriptors and couldn't close any Jul 21 08:12:01 xrmx_: ulimit -a includes normal 'open files (-n) 1024' Jul 21 08:12:38 xrmx_: rebuild with larger ulimit or try something else? Jul 21 08:13:01 lindi-, ok, np, i'm compiling upstream webkitgtk right now and plan to submit a patch to them if it will work Jul 21 08:14:49 damn arm. who knows, what do i miss?: Jul 21 08:14:50 0x00008844 <+12>: sub r5, r5, #1 Jul 21 08:14:51 => 0x00008848 <+16>: bne 0x8844 <_Z5countPiS_i+12> Jul 21 08:14:51 0x0000884c <+20>: mov r0, #0 Jul 21 08:14:58 (gdb) si Jul 21 08:14:58 0x00008844 in count(int*, int*, int) () Jul 21 08:14:58 3: $cpsr = 16 Jul 21 08:14:58 1: $r5 = 0 Jul 21 08:14:58 (gdb) si Jul 21 08:14:59 0x00008848 in count(int*, int*, int) () Jul 21 08:15:01 3: $cpsr = 16 Jul 21 08:15:03 1: $r5 = 4294967295 Jul 21 08:17:23 and of course it is decreasing from some higher number... Jul 21 08:18:37 gena2x: what's the exact problem? Jul 21 08:19:35 i want it to exit loop :) Jul 21 08:19:54 then r5 becomes zero. Jul 21 08:20:05 but it is still running :( Jul 21 08:20:43 and seem do not setting overflow flag too. so i am stuck a bit... Jul 21 08:21:39 gena2x: want to update cpsr? use subs? Jul 21 08:22:19 gena2x: A4.1.106: 'If S is omitted, the S bit is set to 0 and the CPSR is not changed by the instruction.' Jul 21 08:23:02 mrmoku: set-policy off should do as well Jul 21 08:23:46 DocScrutinizer: right Jul 21 08:29:56 there's exactly 2 valid reasons for switching 'off' modem with at+cfun: 1) you need access to sim contacts/sms 2)more non-obvious but really good reason: you need access via at+csim to e.g run gsm authenticate for hotspots - the thing swisscom was interested in Jul 21 08:31:52 speed as well is not really a reason as most of the time is for scanning networks anyway, no matter if on at+cfun= or on generic power-on Jul 21 08:31:54 lindi-: i am really new to arm assembler (just tired figting with gcc optimizations), and got stuck a bit. s3c manual on arm assembler were misleading for me. thank you much! Jul 21 08:34:44 nota bene that usually SIM stores chan and other details of last cell, so power-on shouldn't be noticeably slower than a mere at+cfun. If however the stored cell isn't reachable, both methods will take considerably longer Jul 21 08:36:21 btw I'm not sure if this storing cell-details maybe only happens on gracefull shutdown of moden, which would strongly suggest not to be too harsh on neglecting @poff Jul 21 08:37:54 DocScrutinizer: ok, then we have to fix fsogsmd regarding re-requesting the resource Jul 21 08:53:06 vanous1231: ok. i'll check Weiss idea about voltage delay, and may be this will fix ws issue. Jul 21 09:05:59 gena2x: added ThibG patch to jbt.. building now Jul 21 09:06:17 hm, which patch? Huge mdelay? Jul 21 09:06:28 yeah :) Jul 21 09:07:10 and "white flash" workaround deletion? Jul 21 09:08:30 Thomas told kms already has no that delayed thing. Jul 21 09:08:43 so may be delay will be enoght? Jul 21 09:09:45 :) Jul 21 09:10:02 JaMa: i can test. Jul 21 09:10:04 where can I find the latest u-boot image ? Jul 21 09:10:17 this one http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel/commit/99ce90618a47cdc8c373838b7ee04348cc21d303 Jul 21 09:11:15 JaMa: ah, it still has dereferred thing. Jul 21 09:11:31 JaMa: and 120 delay may be enought. Jul 21 09:11:38 JaMa: but let's see. Jul 21 09:12:24 gena2x: btw Thomas's simplified jbt driver doesn't have JBT_POWER_MODE_DEEP_STANDBY only JBT_POWER_MODE_OFF Jul 21 09:22:48 Sorry. Where can I find the latest version of u-boot for the gta02 ? I'd like to boot from ext2 and also do large file transfers with it. Jul 21 09:23:53 -rw-r--r-- 1 bitbake bitbake 2.9M Jul 19 13:36 uImage-2.6.32.13-oe3.3+gitr0+a9254be10ac2294ea20165a87c09ea6afcf66d94-r0-om-gta02.bin Jul 21 09:23:56 -rw-r--r-- 1 bitbake bitbake 2.7M Jul 21 11:22 uImage-2.6.32.16-oe3.3+gitr0+a9254be10ac2294ea20165a87c09ea6afcf66d94-r0-om-gta02.bin Jul 21 09:24:00 mrmoku: didn't help much :/ ^^ Jul 21 09:24:54 gena2x: if you want to try it's here http://jama.homelinux.org/org.openembedded.shr.images/om-gta02/ Jul 21 09:26:14 JaMa: hmm Jul 21 09:27:21 mrmoku: I'll move XFS/reiserfs (added yesterday) to modules too (but it's pain if they are used for rootfs.. ) Jul 21 09:27:50 of course. Jul 21 09:27:58 mrmoku: but older image without them had only 2.3M Jul 21 09:28:05 anyone can give a try to this webkit patch on oe and possibly a run on real hw? http://pastebin.com/Z97sseEU Jul 21 09:28:06 JaMa: yeah... maybe we should just have good instructions how to fix uboot for that Jul 21 09:28:23 mrmoku: that wiki page is imho good enough :/ Jul 21 09:28:25 how to correctly configure uboot for kernel > 2m Jul 21 09:28:57 JaMa: does root partition on xfs/reiserfs work anyway? Jul 21 09:29:01 I mean: I don't see how it could be described easier Jul 21 09:29:11 qi won't find those, no? Jul 21 09:29:17 neither u-boot Jul 21 09:29:21 JaMa: ah, wait. xfs module? i can't boot :( Jul 21 09:30:02 JaMa: can you just build kernel temporary for me to test? Jul 21 09:31:19 gena2x: 2.6.32.16 in http://jama.homelinux.org/org.openembedded.shr.images/om-gta02/kernel has xfs included Jul 21 09:31:35 gena2x: now building newer with xfs as module (to see how much space does it take) Jul 21 09:31:59 then I can try to modularize stuff like sound/leds etc Jul 21 09:35:12 JaMa: also _i think_ _may be_ good idea to recheck why all modules loading up on shr boot. Jul 21 09:35:56 JaMa: this may be reason to long uboot delay and unnesesary memory consumption. Jul 21 09:36:41 JaMa: i can't recall whom had this thing, but i remembered issue. Jul 21 09:40:21 of course if this is not know issue :) Jul 21 09:45:24 gena2x: still problems with jbt6k? Jul 21 09:45:50 DocScrutinizer: unknown, just checking possibility. Jul 21 09:46:29 JaMa: your 2.6.32.16 is with patch? Jul 21 09:48:50 JaMa: hey, martin? Jul 21 09:48:53 gena2x: it's from gitorious repo Jul 21 09:49:16 mickey|office: fsodeviced segfaults due to rfkill again Jul 21 09:50:04 JaMa: i don't understand shr's building process. do it have delay patch? Jul 21 09:50:21 JaMa: and xfs module in one pack? Jul 21 09:50:56 mrmoku: "again"? Jul 21 09:51:01 mrmoku: never heard about that Jul 21 09:53:43 JaMa: it boots with 2-4-2 timings in 15% of cases. Jul 21 09:54:13 JaMa: but can't mount rootfs anyway. Jul 21 09:54:36 JaMa: i'll rebuild here to check better, so forget. Jul 21 09:55:34 mickey|office: hmm... IIRC it segfaulted when rfkill plugin was configured, but kernel did not have support for it Jul 21 09:55:38 might remember wrong though Jul 21 09:56:13 anyway... commenting out the rfkill plugin in fsodeviced.conf makes it not segfault Jul 21 09:56:31 last thing in strace is Jul 21 09:56:32 323 11:48:03.954209 read(9, "\0\0\0\0\2\0\0\0", 8) = 8 Jul 21 09:56:37 with 9 being /dev/rfkill Jul 21 09:57:18 hmm Jul 21 09:57:26 perhaps a gift from the new kernel? Jul 21 09:57:33 i didn't touch the rfkill plugin since ages Jul 21 09:57:55 it did already work with the new kernel... would have changed then Jul 21 09:58:25 mickey|office: will try to dig in deeper then Jul 21 09:58:46 mrmoku: ok, thanks. i can try on my laptop again when i'm home Jul 21 09:59:55 what's 8 though Jul 21 10:00:18 err nvm Jul 21 10:05:35 :) Jul 21 10:06:56 is git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable the latest uboot version ? 09-09-2009 is the date on it, and rask lambersten was the contributor. Jul 21 10:07:49 now it looks like this is newer.... http://downloads.openmoko.org/distro/unstable/daily/om-gta02/20100131/ Jul 21 10:08:36 gonzoism: i think, i were just auto-rebuilded for a while Jul 21 10:08:43 gonzoism: no real changes. Jul 21 10:09:11 thanks. when do you think the last real change was ? (if you know) Jul 21 10:09:35 gonzoism: i thinks then git last time changed. Jul 21 10:09:41 *think Jul 21 10:09:47 that makes sense. thanks Jul 21 10:10:43 thanks to everybody for the ongoing development as well. I keep trying to think of nice things to do for everyone, but can't really come up with anything. Jul 21 10:11:36 it is really great that the only open phone is still being developed. Jul 21 10:12:39 and very actively developed (so it seems) Jul 21 10:12:43 true Jul 21 10:12:53 be prepared to hop with us to a more modern platform though -- eventually it's inevitable Jul 21 10:12:57 IMO Jul 21 10:13:42 :) Jul 21 10:13:44 if/when I do, i'll be dragging my freerunner along as well. i noticed the other board Jul 21 10:13:54 what is it called ? Jul 21 10:14:19 there are several contestants around Jul 21 10:14:29 all with their own share of closedness, of course Jul 21 10:14:40 but orders of a magnitude faster and more well-equipped Jul 21 10:15:22 it seems like i read about one that was being added to the freerunner for the extra cpu Jul 21 10:15:33 within the last few months. Jul 21 10:16:14 how many developers are contributing to shr and the gta projects ? Jul 21 10:16:23 not enough :) Jul 21 10:16:26 if you were to estimate. Jul 21 10:18:02 6 Jul 21 10:18:45 I have been wanting to write about the freerunner for a while. It being the only open phone and all. I have been kinda watching hoping shr would release a stable image. I figured that would be a good time to do it. I figured I could quote the price of the phone, talk about ongoing development, and about the portability of the OS shr. Jul 21 10:19:01 "shr" and "gta" is really not the same... as shr people seem working on shr full-time. Jul 21 10:19:02 that it will probably show up on a newer phone, eventually. Jul 21 10:20:05 so 6 working on SHR ? Jul 21 10:20:12 gonzoism: that 'add-on board' in fact is replacing the FR and only uses the display and half the case Jul 21 10:20:33 DocScrutinizer, cool. how much do they cost ? Jul 21 10:20:50 gonzoism: not THAT cool, it's no phone Jul 21 10:21:48 oh. i see. not that cool at all. its turning the freerunner into a handheld pc, i guess. Jul 21 10:22:03 i know few working for qtmoko. may be 3. quite many working on debian... i am sure not less than 4. may people contribure eventually. count me also. this is without shr guys. Jul 21 10:22:17 s/may/many/ Jul 21 10:22:18 gena2x meant: i know few working for qtmoko. many be 3. quite many working on debian... i am sure not less than 4. may people contribure eventually. count me also. this is without shr guys. Jul 21 10:22:37 gonzoism: yes, basically Jul 21 10:22:59 it's going to be a phone Jul 21 10:23:12 there are several add-on board projects Jul 21 10:23:21 nikolaus will announce more stuff later this month i guess Jul 21 10:23:29 mhm Jul 21 10:24:00 hm.. interesting. with new case? Jul 21 10:24:06 think there will be a stable shr release for the freerunner in the near future ? or in the future at all ? Jul 21 10:24:08 anyway there's no addon board feasible that would beef up the SoC Jul 21 10:24:14 i mean with case at all? Jul 21 10:25:25 even a 3G module addon would be much easier than getting rid of glamo and getting a faster CPU - for example Jul 21 10:25:46 DocScrutinizer: why do you want get rid of glamo so much? Jul 21 10:26:06 DocScrutinizer: i understand get rid of calypso :) Jul 21 10:26:10 I want nothing particular Jul 21 10:26:26 DocScrutinizer: but what's wrong with glamo now? and with fr in general? Jul 21 10:26:28 glamo is a gfx decelerator Jul 21 10:26:46 DocScrutinizer: why do you think so? Jul 21 10:26:58 I do not think so, I know Jul 21 10:27:05 ~glamo Jul 21 10:27:06 rumour has it, glamo is http://www.google.com/search?q=site%3Alists.openmoko.org+glamo+raster, or http://lists.openmoko.org/pipermail/gta03/2009-April/000114.html Jul 21 10:27:37 DocScrutinizer: ok. if this is your beleif, i can say nothing more. Jul 21 10:28:41 well, there is 2 types of hardware, the crappy one, and the one that are not open enough to know they are crappy Jul 21 10:28:47 I know it's hard to tweak glamo with its limited bandwidth bus to SoC even up to par with GTA01, for gfx performance Jul 21 10:29:49 DocScrutinizer: it is not limited. it's 1/3 of your memory bandwidth, right now. Jul 21 10:30:06 gena2x: this is a widely wellknown fact, discussed ad nauseum on both ML and here Jul 21 10:30:48 DocScrutinizer: this 'fact' is based on debugging kernel and wrong glamo timings, sorry. Jul 21 10:30:53 a bit closer :/ -rw-r--r-- 1 bitbake bitbake 2.1M Jul 21 11:42 uImage-2.6.32.16-oe3.3+gitr0+a9254be10ac2294ea20165a87c09ea6afcf66d94-r0-om-gta02.bin Jul 21 10:30:58 uhuh Jul 21 10:31:10 ok, me noob, you expert. go on Jul 21 10:31:26 DocScrutinizer: and now i see fact, that fr is not slow anymore. Jul 21 10:31:48 DocScrutinizer: and, notice, i am not talking about personalities ;) Jul 21 10:32:04 DocScrutinizer: only about facts. Jul 21 10:32:40 gena2x: I really doubt you were able to read all hits under Jul 21 10:32:42 ~glamo Jul 21 10:32:43 methinks glamo is http://www.google.com/search?q=site%3Alists.openmoko.org+glamo+raster, or http://lists.openmoko.org/pipermail/gta03/2009-April/000114.html Jul 21 10:32:44 i'm surprised samsung hasn't taken an interest in shr or openmoko. i thought they would have back when they started funding enlightenment. Jul 21 10:32:48 in such short time Jul 21 10:33:57 so, if you don't want to refer to particular statements and results mentioned there, and explain why they are wrong and you know there are better numbers, please don't try to convince me with random rumour Jul 21 10:34:17 gonzoism: shr devs agreed that shr-stable will be released as soon as we'll able to fix all bugs marked as MS1 Jul 21 10:34:27 DocScrutinizer: heh. ok. one: "this made Jul 21 10:34:27 it complicated and added overhead as for fragmented or small memory you'd spend Jul 21 10:34:27 more time scheduling the dma than doing it. the result was hw dma (mem to mem) Jul 21 10:34:27 was at BEST 1/2 the speed of he copy with the cpu." Jul 21 10:34:43 DocScrutinizer: which just plain wrong. Jul 21 10:35:12 gonzoism: and nobody can work on it really full-time because of other paid-daywork restrictions :/ Jul 21 10:35:14 DocScrutinizer: i did dma a week ago, and it had same speed to memcpy. Jul 21 10:36:01 JaMa, thanks. i'm looking up MS1 (mission stopper maybe) I wish I was rich. I'd fund people. :) Jul 21 10:36:10 so still no increase in speed, and no gain on anything, due to fact aiui cpu can't do anything than busy wait until dma finished Jul 21 10:37:15 DocScrutinizer: wrong again. i did lmbench while dma transfer were in progress. Jul 21 10:37:17 where full speed still is a meager 7Mb/s bandwidth on glamo bus Jul 21 10:37:34 DocScrutinizer: 7mb/s is wrong again. Jul 21 10:37:35 iirc Jul 21 10:38:01 gonzoism: milestone, see http://trac.shr-project.org/trac/report/3 Jul 21 10:38:15 DocScrutinizer: even with default settings, it is 12Mb/s. Jul 21 10:38:28 DocScrutinizer: and with better one, 17.5Mb/s Jul 21 10:38:49 incredible, you pushed the thing to speeds none of the hackers that dealed with the shit before for months and years was thinking is possible. Obviously Andy, Werner, Raster all are idiots Jul 21 10:38:51 DocScrutinizer: and it's actually possible that glamo can do more. Jul 21 10:39:09 DocScrutinizer: don't go to personalities. Jul 21 10:39:39 DocScrutinizer: i feared this, instead of say thanks for good work, you told that i am evil. Jul 21 10:40:21 probably you even found a way to realtime compress video ram content, so limitation of glamo of 512*512 is moot now Jul 21 10:40:46 DocScrutinizer: nope. i can't do impossible things. Jul 21 10:41:04 gena2x: thanks for good work. Please make it more visible so I wouldn't have missed it Jul 21 10:42:27 otoh I'm really almost out of FR, so odds are I'd miss it anyway. And I simply thought things with glamo are more or less eaten and finished. Jul 21 10:42:43 JaMa, i feel guilty about not contributing to shr or the freerunner. Whenever I try, I get lost trying to understand the build system. I read the manual to bit bake, and that didn't help. I was more familiar with some of the terms and stuff, but as making changes, and making an image to test it, i would keep failing. How can I get around or past this ? I've considered offering someone to pay me to get me started, but Jul 21 10:42:43 I really don't have much money most of the time. I have so much spare time, though. I have tons of spare time. I want to contribute and shape shr. What do you think about this ? Jul 21 10:43:28 DocScrutinizer: it's nice that you still help developers from time to time. Jul 21 10:44:12 gena2x: sorry for my grumpy mood. It's really much nicer *you* do an awesome job it seems Jul 21 10:44:32 gonzoism: what about non code contribution, like writing documentation, bug triaging, etc, they are important too Jul 21 10:45:23 nevertheless FR *is* obsolete, as in I don't see any add-on cards lifting it to a level where it could compete to other more contemporary platforms. Jul 21 10:45:53 DocScrutinizer: it's pity for me that so few people need and work on GTA in fact. all thinking about shr future, fame in n900, usable devices and so, but fr has much strong sides. Jul 21 10:45:56 gonzoism: Well the problem is that, building whole image from scratch is quite difficult task, OE is saving lot of time by automating everything to level that it usually works as expected, but if it fails, then you need to debug it a bit and provide as much info as possible to allow someone even help you with some build issue Jul 21 10:46:08 DocScrutinizer: depends on what obsolete means :) Jul 21 10:46:49 DocScrutinizer: for example i think it's excellent device to learn. to hack. Jul 21 10:46:50 gonzoism: so from my point of view.. best way to get started is just play with it.. try to solve few build problems and gain knowledge by it.. it can take long but it's worth it Jul 21 10:47:02 DocScrutinizer: it's still a lot better than landline Jul 21 10:47:13 lindi-: sure it's a nice development platform, but I won't go back to it for a daily phone&pocketPC any time, as it's underpowered/underfeatured no matter what you do to it Jul 21 10:47:22 DocScrutinizer: but the free software is the point Jul 21 10:47:49 Jama did shr switch over to OE in the last year ? Jul 21 10:47:52 DocScrutinizer: obviously different people value different things Jul 21 10:47:52 lindi-: maemo is as free as any sw on GTA01 Jul 21 10:47:59 DocScrutinizer: really, all problems should be is just things to trans mind for hackers. Jul 21 10:48:19 DocScrutinizer: fr is not bad too. Jul 21 10:48:20 DocScrutinizer: I didn't buy GTA01 for that reason Jul 21 10:49:01 gonzoism: only from shr specific OE branch to main development branch org.openembedded.dev Jul 21 10:49:09 (that silly binary only GPS daemon) Jul 21 10:49:15 DocScrutinizer: that slowness really, really annoyed me. and i just tried and spend much time in fact on it. but also i think i gained much too. Jul 21 10:49:52 gena2x: so I gather these are amazing results really Jul 21 10:50:11 DocScrutinizer: yes, it's a bit slower than mainstream phones, but now it's very usable, and this is main thing. Jul 21 10:50:29 free software first, usability then :) Jul 21 10:50:33 DocScrutinizer: and all hackers may hack in fact. Jul 21 10:50:41 maybe I should give it a try, just for fun and to keep up to date Jul 21 10:51:02 DocScrutinizer: but I can understand why you feel frustrated by the software Jul 21 10:51:11 DocScrutinizer: check qtmoko, just to seem what were changed. Jul 21 10:51:32 misc. those are good suggestions. I thought about howtos, and writing articles and documentation, and started a little, but nothing really significant enough to contribute. I'm good at fixing silly bugs in scripts, and configuring stuff to run better. I think I could contribute best to the operating system, and I make changes to my own freerunner sometimes, but because it isn't uploaded to dev., i abandon those changes Jul 21 10:51:32 because it isn't worth doing every time. Just makes me sad that I can't contribute what I have done, and that I don't have an avenue to contribute more. Jul 21 10:51:34 I too am quite frustrated about this fso stuff :) Jul 21 10:51:44 lindi-: some things are not free. period. like gsm stack. And sometimes you might consider to live with a blob, e.g for GPS. OR invest manyears to RE Jul 21 10:52:09 DocScrutinizer: of course, it's not black and white Jul 21 10:52:11 JaMa, should I start studying OE ? Jul 21 10:53:21 lindi-: and that's in fact the only two blobs in maemo for n900 I don't know a way around to get it done other way. And for meego it seems there shall be no blobs at all, at least that's the goal Jul 21 10:53:23 DocScrutinizer: but once I have achieved some particular level of freedom I don't fancy giving up anything Jul 21 10:53:41 DocScrutinizer: but your note on being able to charge the battery of n900 may very well change everything Jul 21 10:53:59 JaMa, I'm some kind of farmer/rancher. I've never contributed anything more than bugfixes to developers or anything before. Jul 21 10:54:17 lindi-: seen my note on being able to run N900 without any cell inserted ? :-D Jul 21 10:54:22 DocScrutinizer: yep Jul 21 10:54:34 DocScrutinizer: but I think here was some patent on that :) Jul 21 10:54:37 lindi-: you could help me improving it Jul 21 10:54:39 gonzoism: that would be great... start with http://trac.shr-project.org/trac/wiki/Building%20SHR and as soon as you're able to build your own image then you can easily contribute your fixes Jul 21 10:54:47 mickey|office: fso? Jul 21 10:54:47 WUT? PATENT?? LOL Jul 21 10:54:50 don't ask me how much it sucks that i'm pretty much doing it alone Jul 21 10:55:08 project much too big for one part timer Jul 21 10:55:12 gonzoism: but as misc said, there is more ways to contribute.. just choose whatever makes you happy or you're interested in Jul 21 10:55:13 mickey|office: but i'm scared. fso does way too much Jul 21 10:55:21 mickey|office: all I want is a gsm daemon... Jul 21 10:55:37 well, if you don't even want to take a look at fsogsmd Jul 21 10:55:38 not something to replace init, atd, backlight control, ... Jul 21 10:55:45 you realize FSO is modular? Jul 21 10:56:06 guys, very interesting question. Jul 21 10:56:08 mickey|office: I have some vague idea of that yes Jul 21 10:56:42 mickey|office: what is the point of replicating for example gpsd? Jul 21 10:57:14 gena2x: back then gpsd had neither UBX nor DBus Jul 21 10:57:28 JaMa, so I guess a better question would be, ... ya, the Building SHR is where I get problems. I'll start all over and try again. It's been a while, and maybe I am more familiar or can see something from a new light. Maybe more patience this time. :) And if I get to something I can't get past, I think I'll just try to be a little more demanding for help. Jul 21 10:57:29 that's why we settled on reusing gypsy API Jul 21 10:58:39 mickey|office: ok, no. sorry. forget my question. i didn't research this topic yet, so can't ask meaningful questing in fact. may be later... Jul 21 10:58:53 *questions Jul 21 10:58:59 mickey|office: and re fsogsmd, it's all this dbus and vala stuff that sounds way too bleeding edge for my taste :/ Jul 21 10:59:21 mickey|office: why you didn't choose c++? Jul 21 10:59:42 JaMa, yeah, i think your advice is right. to start there. Jul 21 11:00:16 mickey|office: just bravery? Jul 21 11:00:29 mickey|office: but feel sorry for you, debugging this GSM stuff is very frustrating Jul 21 11:00:31 lindi-: ok. nothing i can do to change that Jul 21 11:00:37 JaMa, thanks Jul 21 11:00:42 gonzoism: yw :) Jul 21 11:00:44 gena2x: we settled on python for rapid development back then Jul 21 11:00:58 gena2x: time frames, as always, where short Jul 21 11:01:12 mickey|office: yes, but were moment to change language. why vala? Jul 21 11:01:26 ah Jul 21 11:01:33 because Vala has massive advantages compared to C++ Jul 21 11:01:33 mickey|office: i understand why python - first implementation and so on. Jul 21 11:02:14 simple syntax, high level control flow constructs directly embedded in the language, C ABI Jul 21 11:02:15 to name three Jul 21 11:02:17 just three Jul 21 11:02:20 there's more Jul 21 11:02:51 and it runs *way* faster than python on the FR Jul 21 11:02:54 :) Jul 21 11:03:12 and uses less memory yes Jul 21 11:03:22 beniwtv: i have no questions about python, it's clean that python is not production thing. Jul 21 11:04:01 gena2x: I wouldn't call it 'not production', we use it very much here at work. But definitively not for the FR. Jul 21 11:04:44 beniwtv: yes. wrong wording... not appropriate for production embedded framework would be better. Jul 21 11:05:03 Agreed. Jul 21 11:05:55 mickey|office: do you have any idea about the current state of fsogsmd packaging in debian btw? Jul 21 11:06:47 mickey|office: ok. i just thought it's better to choose language more standard, easier to attract new developers, better portable. Jul 21 11:07:38 mickey|office: but really, i can be wrong. anyway, i wish only good things to fso project :) Jul 21 11:07:48 gena2x: vala is trying to become a standard in gnome circles but it's hard to predict how soon Jul 21 11:09:09 i have another question now. nand uboot has Boot from microSD (fat+ext2) i want to be able to boot from ext2 on the usd. so my uboot version (jan 8 2010) is not the correct one, is it ? Jul 21 11:09:42 Or is that only a configuration option in /dev/mtdblock1 ? Jul 21 11:09:43 gonzoism: just change u-boot configuration? Jul 21 11:09:55 gotcha. thanks Jul 21 11:10:01 gonzoism: sudo fw_printenv to see all settings Jul 21 11:10:10 gonzoism: and the long u-boot manual :) Jul 21 11:10:17 gonzoism, your u-boot is ok to boot ext2. Jul 21 11:10:39 gonzoism: or just edit text file on host, compile and flash to moko. Jul 21 11:10:40 lindi-: no idea wrt. debian, sorry Jul 21 11:10:56 mickey|office: or fedora or suse? ;) Jul 21 11:11:16 lindi-: neither. i'm not caring about packaging except OE. i have zero jiffies left for distribution work Jul 21 11:11:19 mickey|office: I understood that fso-gsmd wanted to support other modems too Jul 21 11:11:45 gena2x: given the likeliness of attracting more developers, it's more important to please the main developer... Jul 21 11:12:01 lindi-: true, a bunch of modems are supported Jul 21 11:12:20 freescale neptune, cinterion, qualcomm variants, openmoko Jul 21 11:12:23 mickey|office: :) yeah. Jul 21 11:12:30 and probably dozens that just use plain AT Jul 21 11:13:32 gena2x: i realized Vala's potential when i first have seen it. And although it was a tough ride at times, I do not regret it. It is a great technology and without it, FSO2 would not exist Jul 21 11:13:54 mickey|office: it surely has potential yes Jul 21 11:16:18 mickey|office: eh, you increased my todo list... so i'm going to better decrease it than talk :) Jul 21 11:17:27 grr now without sound still >2MB -rw-r--r-- 1 bitbake bitbake 2051848 Jul 21 13:12 uImage-2.6.32.16-oe3.3+gitr0+a9254be10ac2294ea20165a87c09ea6afcf66d94-r0-om-gta02.bin Jul 21 11:17:50 JaMa: why is 2MB so important? Jul 21 11:17:52 JaMa: forget about that 2mb, why you care... Jul 21 11:18:32 I don't care.. but there are people refusing to fix their u-boot env for whatever unknown reason, doh :/ Jul 21 11:18:35 lindi-: maybe, because u-boot read from NAND is slow Jul 21 11:18:53 Martix: ???????? Jul 21 11:18:54 JaMa: they should be educated :) Jul 21 11:19:09 Martix: how slow? Jul 21 11:19:16 when loading kernel Jul 21 11:19:29 lindi-: need to sit and write in wiki how to change u-boot env. Jul 21 11:19:29 250 KB/s Jul 21 11:19:33 Martix: but surely 2.0 MB vs. 2.1 MB is not a huge difference Jul 21 11:19:47 gena2x: there are these commands called "fw_printenv" and "fw_setenv" Jul 21 11:19:52 lindi-: I've included link to wiki page explaining how to update it.. and still people complain Jul 21 11:20:15 JaMa: point them to me :) Jul 21 11:20:18 JaMa: just point em to link Jul 21 11:20:21 damn. Jul 21 11:20:27 * lindi- hides Jul 21 11:20:27 lindi-: ok :) Jul 21 11:20:52 granted I'm stuck in Qi at the moment. should probably migrate back to u-boot Jul 21 11:21:04 no, better i'll hide :) Jul 21 11:22:00 mickey|office: I tried to build fso-gsmd from debian experimetal Jul 21 11:22:06 mickey|office: E: Build-Depends dependency for fso-gsmd cannot be satisfied because no available versions of package libvala-dev can satisfy version requirements Jul 21 11:22:14 gena2x: where you get u-boot sources? from Openmoko git or upstream? I want to compile u-boot myself Jul 21 11:22:32 mickey|office: so apparently not even debian unstable has new enough vala to build fso-gsmd :( Jul 21 11:22:41 Martix: my kernel started in 6 seconds. and it is >3mb i think. Jul 21 11:22:59 Martix: with crc, load and all whistles. Jul 21 11:23:10 gena2x: ok, maybe its 500 KB/s :-) Jul 21 11:23:36 lindi-: yeah, it's sad that noone really cares about packaging Vala in debian. Jul 21 11:23:54 or well, not noone Jul 21 11:23:54 mickey|office: well it is in experimental Jul 21 11:23:59 ah, that's cool Jul 21 11:23:59 Martix: :). sources at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable Jul 21 11:24:08 Martix: as stated in wiki. Jul 21 11:24:09