**** BEGIN LOGGING AT Tue Jan 11 02:59:58 2011 Jan 11 04:44:39 lindi-: i added small chapter about booting current version of u-boot without battery/with discharged battery: http://wiki.openmoko.org/wiki/U-boot-gena2x. Actually this is bug, u-boot turns charger on only if... this is not first boot %) Currently anyway it draws 1A kind of always, so you can boot with or without battery without problems. Jan 11 04:49:04 you can also run nor, poweroff it and then run nand. Jan 11 04:49:33 seem PMU is running even if power is off and resets if you remove all sources. Jan 11 04:49:33 lindi-: newer uBoot versions have a rather halfarsed implementation of something that is *supposed* to handle charging when battery too low to bot to linux. That's the red-aux flashing thingy. Ask Werner about the details. Anyway it's known to be buggy, and I'd not be surprised to find it also blows chunks when trying to boot from low battery Jan 11 04:53:54 lindi-: iirc the bug I found in 'new' uBoot was it starts charging the battery and flashing red, but when batery is sufficiently charged it doesn't boot, but rather is switching off charging eventually, while continuing red flashing and of course also keeps CPU running. So eventually you end where you've started -> flat battery :-P Jan 11 04:54:44 also you can't switch down the device even with power button Jan 11 04:55:00 and of course it doesn't notice when you remove the charger Jan 11 04:58:36 lindi-: anyway pcf50633, when bupbat is empty, resets to some sane settings for charging iirc. Sth like 100mA - not enough to power up the system, but should charge the battery to the point where it can power the device for normal boot. The paradox problem is that a working bupbat may keep pcf50633 at fubar settings, if those got messed during previous system uptime Jan 11 05:00:59 lindi-: isn't that nice? meanwhile all FR 'fixed themselves' by bupbat completely dead and empty and PCF50633 resetting on ~2min of main bat removal ;-D Jan 11 05:15:40 lindi-: btw I seem to remember there's a weird way to make FR boot NOR instead of NAND uBoot. The SoC is connected to AUX via GPIO, so asserting low and output on that GPIO makes the adress muxer think the AUX switch got pressed. Of course this would mean you need to do this early during boot, I'm not sure you can do it at all at the right moment. I looked into it to find a way to avoid the inverse situation: segfault on booting Jan 11 05:15:42 NOR, when AUX key gets released too early Jan 11 05:27:27 lindi-: anyway I can't think of a plausible story how FR would boot from NOR without AUX being pressed (or otherwise high level on OM0). AFAIR OM0 does a direct adress level remapping, so if it's GND/low then device definitely will start executing cmds in NAND uBoot area, and somewhere early in both uBoots (which have to be identical up to this instruction) it tests if AUX/GPF6 is low (aux switch pressed), and jumps accordingly to Jan 11 05:27:29 the mirrored address range for the corresponding uBoot - NOR or NAND. Jan 11 05:30:08 err sorry, ...if AUX/GPF6 is low (aux switch *NOT* pressed) Jan 11 06:35:50 wpwrak: any idea why FR would boot NOR uBoot though AUX not pressed? Jan 11 06:39:28 DocScrutinizer: hmm, sounds odd. foreign object ? Jan 11 06:39:28 except of obvious reasons like R1502 missing/broken or SW1501 stuck Jan 11 06:39:53 DocScrutinizer: (other) no, not really Jan 11 06:40:00 I think lindi- should notice all mech things Jan 11 06:44:03 wpwrak: aiui lindi- flashed a custom NAND uBoot. Jan 11 06:44:39 well, you could just jump from NAND into NOR ... Jan 11 06:44:49 yeah, thought as much Jan 11 06:45:36 isn't there a cmd sequence to do exactly that, depending on AUX status (GPF6)? Jan 11 06:46:15 or not exactly but sufficiently similar so it could fail in that way Jan 11 06:46:25 AUX changes the CPU's boot mode. that's hardware. Jan 11 06:46:32 No, i think lindi- was telling that he can boot to NOR (the usual way, holding AUX), but can't boot to NAND, with main battery ~empty. Jan 11 06:46:53 Good morning, DocScrutinizer and wpwrak :) Jan 11 06:46:54 yeah, but eventually it will need to get checked and uBoot branches accordingly Jan 11 06:47:19 aaah, oh sorrry then Jan 11 06:47:20 PaulFertser: ah, so it's NOR-boot or no boot ? Jan 11 06:47:29 wpwrak: yes Jan 11 06:47:32 hm... i think i already answered question which i were asked by lindi- Jan 11 06:47:46 wpwrak: but if he swaps a charged battery, he can boot to nand as well. Jan 11 06:47:49 though that's similarly strange, except for the known flawed lowbat handling in 'new' uBoot Jan 11 06:48:06 how to boot svn u-boot without battery or with depleted battery Jan 11 06:48:24 it works well Jan 11 06:48:33 PaulFertser: that would make sense then. he may be stuck at the low battery wait. not sure if we have it in NOR and if we do which version exactly ended up there. Jan 11 06:48:58 we don't have it in NOR - luckily Jan 11 06:49:30 this is just usual bug and that's all Jan 11 06:49:46 latest u-boot doesn't turn on charger at all on first boot Jan 11 06:49:51 what to talk about? Jan 11 06:50:14 what to rant? Jan 11 06:51:04 gena2x: not charging in u-boot is arguably the right thing to do. i think what's missing is a proper way to make it into the kernel at 100 mA. Jan 11 06:51:35 yes Jan 11 06:51:36 gena2x: the idea was to configure the system into a low-power mode that only drew 100 mA and then proceed with booting Jan 11 06:52:10 gena2x: all the way assuming USB power, of course Jan 11 06:52:10 wpwrak: i didn't really investigate charging (yet), this is that i see in svn u-boot. Jan 11 06:52:38 wpwrak: though you as well can argue it *should* charge/power system at max when fastcharger is detected Jan 11 06:52:39 wpwrak: i also see some patches like 'always enable charger' on top Jan 11 06:53:09 DocScrutinizer: the idea was to keep such decisions out of u-boot. just make it to the kernel, do the fancy stuff there. Jan 11 06:53:50 gena2x: "always enable charger" doesn't sound right. there was a known problem where enabling the charger with the battery absent caused the supplies to collapse Jan 11 06:54:05 hmm, I thought we found it's impossible to have uBoot with menu and video and backlight, on a small 100mA? Jan 11 06:54:16 DocScrutinizer: that sounds plausible, yes Jan 11 06:54:48 so it's a very bad idea to leave something as simple as detecting 47k on ID to kernel Jan 11 06:55:17 DocScrutinizer: the idea was to go into the kernel without enabling all the lights and gimmicks Jan 11 06:55:30 DocScrutinizer: think qi Jan 11 06:55:32 wpwrak: collapse??? Jan 11 06:55:41 so why not keep this act_dead concept to Qi then? Jan 11 06:55:42 wpwrak: can you provide a bit more details? Jan 11 06:56:00 gena2x: inrush current of some capacitors. drop of Vsys. system resets. Jan 11 06:56:07 wpwrak: btw, i am ignoring DocScrutinizer Jan 11 06:56:21 btw who cares? Jan 11 06:56:49 he'll be amazed when channel ignores him Jan 11 06:57:00 +q and bye Jan 11 06:57:01 wpwrak: but nothing pernamently destuctive i hope? just reset? Jan 11 06:57:36 wpwrak: i just were wondering about meaning of 'collapse' :) Jan 11 06:57:44 gena2x: yes, i think it just kept on resetting indefinitely (well, until you fixed the power problem) Jan 11 06:58:10 wpwrak: hm, here it boots without battery Jan 11 06:58:33 wpwrak: this collapse has been fixed on all a7 and most a6 though Jan 11 06:59:45 wpwrak: also enabling charger is not identical to acepting power from USB for Vsys Jan 11 06:59:49 iirc Jan 11 06:59:53 gena2x: part of the situation is that the gta02 battery has a slightly overzealous protection circuit that cuts the battery off if discharged too much, and you need to charge it for a bit before it will switch on again. combine this with the other issues, and you have a nasty problem :) Jan 11 07:00:42 duh, what? This was a problem related to gta02 prot chip?? no, not afaik Jan 11 07:00:57 wpwrak: I am taking that in account. It's like any other adecvate lithium battery i hope, as full discharge destroys them. Jan 11 07:01:12 DocScrutinizer: the charger thing was just caps on one side sucking the ones on the other side dry Jan 11 07:01:26 yes Jan 11 07:01:39 resulting in a brownout of Vsys Jan 11 07:01:49 gena2x: (destroy) no no, the protection circuit in the battery should prevent this Jan 11 07:01:57 there's nothing you can do with it by any uBoot tricks Jan 11 07:02:11 it happens before CPU even starts to execute uBoot Jan 11 07:02:16 wpwrak: ok :) Jan 11 07:02:39 gena2x: what happens is that, if you discharge the battery, the protection cuts its output off. very high impedance, no measurable voltage. like a switch/relay. Jan 11 07:03:07 gena2x: and it will only turn it back on if you add a bit of a charge (charge for a few seconds). until then, the battery looks absent. Jan 11 07:03:21 not for charging Jan 11 07:03:31 gena2x: the gta01 battery didn't have such a violent cut-off mode Jan 11 07:03:36 only for discharging, which is perfectly sane Jan 11 07:03:59 DocScrutinizer: well, it will sink a current. but if you disconnect before it has switched on again, it will go right back to high-Z. Jan 11 07:04:18 yes Jan 11 07:04:35 I still fail to see the problem Jan 11 07:04:37 DocScrutinizer: (nothing you can do) well, don't try to charge :) Jan 11 07:05:04 meh Jan 11 07:05:06 part of the problem is of course that you don't really control the initial state of the PMU Jan 11 07:05:17 exactly Jan 11 07:05:35 at least all the BUBs should be dead by now, so the state space is now smaller ;-) Jan 11 07:05:40 and this initial state aka POR is "charging" Jan 11 07:05:48 and it passed fab QA Jan 11 07:06:37 DocScrutinizer: that's the goal, no ? who cares what happens afterwards ;-) Jan 11 07:07:33 I just fail to understand why we need to disable charging, when it evidently is not persistent and also evidently didn't stop device from powering up correctly at QA Jan 11 07:08:11 DocScrutinizer: dunno the QA configuration Jan 11 07:08:18 wpwrak: hm. so tell me why not turn on charger in u-boot? Jan 11 07:08:31 wpwrak: at 500mA Jan 11 07:08:52 this brownout only happens when you *switch* on charging, it *does not* happen when charger is already enabled when VBUS gets applied Jan 11 07:09:23 wpwrak: except minimalisation ideas Jan 11 07:09:28 DocScrutinizer: also, the Vsys cap changes were gradual. we had unfixed devices, then almost fixed devices (couldn't make the cap bit enough to be 100% sure), then fixed devices, and finally i think they made the cap even a bit larger Jan 11 07:09:45 gena2x: how can you be sure you're allowed to drawn 500 mA ? Jan 11 07:09:51 but again, I don't care about charging in uBoot, I just think uBoot should not mess with charging at all, and better bother about detecting fastcharger Jan 11 07:09:55 s/drawn/draw/ Jan 11 07:09:55 wpwrak meant: gena2x: how can you be sure you're allowed to draw 500 mA ? Jan 11 07:10:49 (caps) yes, as I said: most A6 worked fine with 47uF. A7 with 100uF were ok Jan 11 07:11:06 DocScrutinizer: i think the boot loader should just no know about all these things and simply boot the damn kernel ;-) Jan 11 07:11:29 wpwrak: i don't really gone deep into charging, but question why power provider is not cheching for this always bothered me Jan 11 07:11:33 yes, after showing a legible menu Jan 11 07:11:49 DocScrutinizer: the whole concept of making the boot loader a cosy place to dwell at, with a shell, protocol stacks, menus, persistent state, and what not is just madness Jan 11 07:11:50 s/checking/responsible for limiting/ Jan 11 07:11:52 otherwise user is free to opt for qi Jan 11 07:12:16 DocScrutinizer: qi is the way :) Jan 11 07:12:25 if for example n900 may drain too much from GTA and don't care, why gta should care? Jan 11 07:12:38 is't usb plug and play Jan 11 07:12:54 damn, who's talking about a shell. And you don't suggest to rip out all the cruft of uboot to make it "as sane as qi" - do you? Jan 11 07:13:02 so i should be able to insert anything into it without any chance to fry? Jan 11 07:13:10 DocScrutinizer: well, qi-hw did a better job on the ben - they also chose u-boot but at least nobody is trying to make it "nice". it just boots. end of the story. Jan 11 07:13:47 hooray for another of gena2x's fabulous notions about "why care?" Jan 11 07:14:05 gena2x: a tricky question. most of the time, it's safe. but what do you do when it isn't ? Jan 11 07:15:04 wpwrak: you however tried to make it nice, by implementing all that "don't charge" or/and "don't display, but charge and blink" things Jan 11 07:15:06 wpwrak: my main wonder why burden on checking power limit is on consumer in case of usb? Jan 11 07:15:26 wpwrak: how does it work for unpowered usb hubs? Jan 11 07:15:33 DocScrutinizer: (rip out) no. throw it away. start with a clean slate. you don't buy a PC and start dismantling it if all you need is the "standby power" LED on the mainboard, do you ? :) Jan 11 07:15:52 gena2x: you have to take up that issue with intel and co. ;-) Jan 11 07:16:33 gena2x: unpowered hubs politely ask you to drawn 100 mA (if you're downstream) Jan 11 07:16:42 s/drawn/draw/ Jan 11 07:16:44 wpwrak meant: gena2x: unpowered hubs politely ask you to draw 100 mA (if you're downstream) Jan 11 07:17:13 wpwrak: why it's inpossible to negotiate about power in u-boot? Jan 11 07:17:41 wpwrak: so start with 100mA, then immidiately switch to 500mA if allowed Jan 11 07:17:46 DocScrutinizer: (make it nice) yeah. didn't have the guts to just assassinate it :) Jan 11 07:18:01 wpwrak: sorry I get tired of this debate. You're arguing in circles. You chosen to implement uBoot. You chosen to give it a menu. Then you say it needs to boot without displaying this menu, just to become more like qi. You implemented cruft to deal with all sorts of perceived problems, to uBoot. Then you say it's not worth this effort. Jan 11 07:18:02 gena2x: i think that's what it does Jan 11 07:19:00 DocScrutinizer: i didn't choose u-boot. that decision happened before my time. i did the menu, correct. it took me a while to realize how bad things really were. Jan 11 07:19:51 JaMa|Off: is removing the now upstream patch for libeflvala in your queue? or should I do it? Jan 11 07:20:21 last uBoot I've checked was seriously fsckdup with this red blink thing that never stopped and finally discharged battery to death after a few hours. And it for sure was not better in any respect than the NOR version that didn't come with these additional functions Jan 11 07:20:57 mrmoku: not before efl SRCREV bump Jan 11 07:21:19 JaMa|Off: hmm... I started a build over night Jan 11 07:21:28 wpwrak: heh. ok, seem you just don't follow u-boot svn :) Jan 11 07:21:34 it stopped at libeflvala Jan 11 07:21:39 due to that patch Jan 11 07:21:43 so I assumed efl is bumped Jan 11 07:21:43 mrmoku: do you have autorev? Jan 11 07:21:52 not that I think Jan 11 07:21:59 at least not for efl Jan 11 07:22:07 hmm Jan 11 07:22:16 mrmoku: yesterday I've pushed 56024 to OE, then playya applied it in 56026 Jan 11 07:22:17 DocScrutinizer: i don't really know what the current state is with regard to the red blink mode. a) i lost interest in the issue, because i consider u-boot and the way it is used as flawed per se, and b) more changes i remember not liking were made there later on, but i forgot the details. Jan 11 07:22:22 wpwrak: but really, don't know, may be i am wrong. didn't investigate charging, just know some tricks with it :) Jan 11 07:22:30 JaMa: is libeflvala in fso-autorev.inc? Jan 11 07:22:34 that would explain it ;) Jan 11 07:22:38 wpwrak: but it sets 1A charging now in all cases Jan 11 07:22:40 mrmoku: so in OE it should still apply fine (does apply here and on shr buildhost) Jan 11 07:22:43 wpwrak: and what you're saying now is "make uBoot completely like qi bootloader" and I wonder why you would do that when there's qi already Jan 11 07:22:51 gena2x: i try to stay as far as i can from u-boot ;-) Jan 11 07:22:53 JaMa: ohh, yes it is Jan 11 07:22:59 JaMa: nvm :) Jan 11 07:23:12 hmm maybe it will be better to drop it from there Jan 11 07:23:16 heyho! Jan 11 07:23:16 yeah Jan 11 07:23:23 DocScrutinizer: did i say "make u-boot like qi" ? Jan 11 07:23:24 should be dropped there Jan 11 07:23:28 as efl rev is changed quite often without any libeflvala change Jan 11 07:23:33 hm with webOS 2.0 we have a new modem firmware version on the pre phones ... Jan 11 07:23:49 but looks like they only fixed some bugs :) Jan 11 07:24:03 wpwrak: yes. You said uBoot mustn't enable backlight, and it doesn't need to as we don't want a menu anyway Jan 11 07:24:04 JaMa: and it has nothing to do with fso in the end Jan 11 07:24:32 yes.. it's probably only because first version was in fso repo, before mickey moved it to efl svn Jan 11 07:24:38 wpwrak: heh. sound like it were not simple to cope all issues :) Jan 11 07:24:43 :) Jan 11 07:24:46 wpwrak: if my NOR u-boot had a menu entry for "turn backlight off & charge at 500 mA" I'd be 100% happy :-) Jan 11 07:25:07 wpwrak: since then I could 1) plug in wall charger 2) enter nor u-boot 3) choose that menu entry Jan 11 07:25:12 lindi-: hey, i told you how to boot it even without battery, have you read? Jan 11 07:25:27 DocScrutinizer: well, if you don't switch to qi. then that's your only option, isn't it ? :) but you really ought to abandon u-boot and make the 100 mA boot path work. Jan 11 07:25:40 gena2x: long discussion :-) I don't think my gta02v5 boots without battery unless you meant some lab power supply Jan 11 07:25:49 lindi-: boots Jan 11 07:25:53 lindi-: you can try it Jan 11 07:26:01 lindi-: just see my first answer Jan 11 07:26:03 oh, isn't that already done in qi??? Jan 11 07:26:14 lindi-: you could extend your NOR u-boot ;-) Jan 11 07:26:19 wpwrak: yeah Jan 11 07:26:36 wpwrak: I was just wondering what change in u-boot caused it to not boot in this situation Jan 11 07:26:47 gena2x: hmm, I guess I should scroll down a lot... Jan 11 07:27:07 gena2x: scroll to _my_ answer to your question to _me_ :) Jan 11 07:27:34 sorry, I need to leave this discussion, as I don't see any more point in arguing about enabling charging while there's no problem with that in old uBoots Jan 11 07:27:42 gena2x: I think my gta02v5 emits horrible sound if I connect charger without battery Jan 11 07:28:09 gena2x: but I don't have the wall charger with my at work now to test Jan 11 07:28:25 and there's still no plausible story why FR can boot to NOR but not to NAND, except the one that NAND uBoot is fubar Jan 11 07:28:39 lindi-: i am not telling about wall-charger Jan 11 07:28:46 gena2x: ok, then I can test Jan 11 07:29:12 lindi-: just do following: press power button immediately after plugging usb power Jan 11 07:29:21 DocScrutinizer: you can always change it to do whatever you like :) Jan 11 07:29:45 and I can leave any time I like Jan 11 07:30:53 lindi-: of course, this also works with battery Jan 11 07:31:00 and I'm free to wonder why you bother to argue about fastcharger detection when you don't want to deal with uBoot at all Jan 11 07:31:42 DocScrutinizer: you called me "DocScrutinizer> wpwrak: any idea why FR would boot NOR uBoot though AUX not pressed?" :) Jan 11 07:32:00 so what? did you answer that? Jan 11 07:32:10 was this about fastcharger? Jan 11 07:32:12 DocScrutinizer: it's not as if i would be going around, searching for u-boot discussions ;-) Jan 11 07:33:11 gena2x: I connect usb cable, hold power and then hold aux. I hear a low frequency buzz Jan 11 07:34:00 lindi-: if you can get NOR u-boot without battery Jan 11 07:34:15 gena2x: I can't Jan 11 07:34:25 yes, you can't Jan 11 07:34:38 gena2x: I can get nor u-boot with depleted battery :) Jan 11 07:34:59 lindi-: ok, then try go nor and select power-off Jan 11 07:35:19 and then boot nand Jan 11 07:35:21 ohmy. bye Jan 11 07:35:30 (all with usb connected) Jan 11 07:35:31 gena2x: I tried that yesterday, nand u-boot just didn't do anything Jan 11 07:35:48 gena2x: when I swapped a full battery and repeated the same then nand u-boot menu appeared Jan 11 07:36:27 hm... Jan 11 07:36:51 it is really not always working, but if i insert power cable and immediately press power Jan 11 07:37:00 lindi-: use an older version for NAND uBoot, that does NOT mess around with checking battery level and dis/en-abling charging and blinking AUX and whatnot Jan 11 07:37:01 my nand loads Jan 11 07:37:21 *sigh* Jan 11 07:37:23 may be really, different vesions of hw, only wpwrak knows :) Jan 11 07:37:28 gena2x: probably our batteries have depleted differently? ;) Jan 11 07:37:39 lindi-: it works without battery Jan 11 07:37:46 gena2x: gta02v5 for sure? Jan 11 07:37:49 lindi-: also, i have working bubatt Jan 11 07:38:17 lindi-: as this dude has me on his ignore list, it's up to you to inform him about different behaviour from A5 thru A7 to A7 Jan 11 07:38:48 s/A7/A6/ Jan 11 07:39:24 even A6 have different behavior from device to device Jan 11 07:41:03 gena2x: (working BUB) last man standing, eh ? ;-) Jan 11 07:41:18 wpwrak: ah, you missed it :) Jan 11 07:41:36 wpwrak: someone posted about replacing bubatt with capacitor Jan 11 07:41:59 lindi-: v5 has a relatively high probability of a weak vsys that would break down if trying to charge an absent/cut-off battery Jan 11 07:42:02 wpwrak: i just bought one from some old phone and it now works well :) Jan 11 07:42:28 wpwrak: and my time is kept well too :) Jan 11 07:42:29 gena2x: oh, you replaced it. i was wondering how it could still be alive ;-) Jan 11 07:43:06 wpwrak: but do you know why all batteries from the factory died? Jan 11 07:43:10 wpwrak: really, why openmoko guys did not use such capacitors from beginning? they seem quite popular Jan 11 07:43:39 wpwrak: and yeah, PaulFertser quiestion is also interesting if you able to answer Jan 11 07:44:03 PaulFertser: no, not really. there used to be a problem with the reflow profile once that killed them really quickly, but that was supposedly fixed. after that, it's a mystery. Jan 11 07:44:30 wpwrak: :) Jan 11 07:45:24 gena2x: i think nobody realized just how bad the BUB was (and would continue to be) when it was designed into gta02 Jan 11 07:45:54 mickey|zzZZzz: ping Jan 11 07:46:00 gena2x: another thing that would be nice in u-boot would be the ability to see battery energy and consumption :) Jan 11 07:46:09 PaulFertser: they simply are crap. N900 bupbat does same short life hard death Jan 11 07:46:22 lindi-: adding commands to u-boot is really, super-simple Jan 11 07:46:22 morphis: too early... but that will change someday soon ;) Jan 11 07:46:44 gena2x: yeah, I added this "force 500 mA" command for my own abuse of USB already :P Jan 11 07:46:59 lindi-: where is patches? :) Jan 11 07:47:10 too ugly :) Jan 11 07:47:13 mrmoku: hehe ... I though already about that it is too early for mickey (and his last commit message is only some hours old) but it was a try :) Jan 11 07:47:25 :) Jan 11 07:47:59 moin moin PaulFertser mrmoku btw Jan 11 07:48:18 DocScrutinizer: moin, still awake or up early? :P Jan 11 07:48:25 guess Jan 11 07:48:28 DocScrutinizer: morning Jan 11 07:48:44 DocScrutinizer: the first one would be my guess of course ;) Jan 11 07:48:54 right :) Jan 11 07:49:06 hehe :) Jan 11 07:49:08 lindi-: hehe, just make it better. and in final end working ugly patch is better than nothing Jan 11 07:49:32 lindi-: if it 100% working of course Jan 11 07:50:38 lindi-: anyway there's no hardware reason whatsoever why NAND uBoot can't work while NOR does. Given same code both will act similar. Any rumour about "NAND using too much power" is just BS Jan 11 07:53:10 mrmoku: (change) not really. Just odds are you find Mickey stay up until 7 then go to sleep :-D Jan 11 07:53:29 DocScrutinizer: yeah it's just new version => new bugs :P Jan 11 07:53:44 :nod: Jan 11 07:54:33 DocScrutinizer: well... becoming dad will change things... believe me ;) Jan 11 07:55:25 yeah, but not necessarily in a way you will find Mickey awake @ 8:30 then. More the opposite I guess Jan 11 07:56:11 we'll see :-) Jan 11 07:57:14 bbl Jan 11 07:57:21 o/ Jan 11 08:07:01 PaulFertser: (what kills bupbat) these are LiIon as well - and both FR and N900 keep them at max charge all the time :-P Jan 11 08:08:19 otoh this type of cell is specified for, like, 200 cycles 30% or somesuch. So microcycling isn't an option either Jan 11 08:08:23 DocScrutinizer: btw, i haven't really tested yet but it looks like my main FR battery became kinda weak. Despite using proper charging as we discussed. Jan 11 08:09:31 hmm, they are specified for >500 100% cycles. Might well degrade by now Jan 11 08:10:35 datasheet of bupbat has a gpldcap as alternative, same page just at bottom :-) Jan 11 08:10:45 goldcap* Jan 11 08:11:31 capacity like 1/70 of the LiIon Jan 11 08:11:57 0.1F? Jan 11 08:14:04 anyway, both N900 have dead bupbat. RTC doesn't even survive a battery swapping (some 10 sec) Jan 11 08:26:12 so, my free palm pre plus from palm recieved! Jan 11 08:27:06 nice: http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6304.pdf Jan 11 08:27:47 >> Learn how to port an open source Java™ Platform, Micro Edition (Java ME) implementation to new mobile platforms such as Google Android, iPhone, OpenMoko, LiMO, and more. Jan 11 08:28:36 well, rank 3 after andridiot and whyPhone :-D Jan 11 08:30:39 and no maemo or meego.. hmm 2008 SUN JavaOne Conference. Can't blame them Jan 11 09:31:26 can someone test newer 2.6.34.8 for me on gta02? Jan 11 09:43:30 yes. any specific tests? Jan 11 09:44:24 I've merged larsc's ws fix.. so mostly ws ;) Jan 11 09:44:50 http://jama.dyndns-home.com/org.openembedded.shr.images/om-gta02/uImage-2.6.34-r5-oe15-om-gta02.bin and corresponding modules.*tgz Jan 11 09:47:28 upgrading ... Jan 11 10:00:52 are there any patches to resize the enlightenment SEGV screen to fullscreen? Jan 11 10:22:50 JaMa: so, it really fixed WS for mrmoku? Jan 11 10:23:25 or someone else Jan 11 10:24:07 anything i should do to force a WSOD? Jan 11 10:30:39 it's not WSOD, it's WS, basically do blank/unblank Jan 11 10:34:20 gena2x: no idea, I don't have gta02 to test it myself.. Jan 11 10:35:52 but if it works at least as previous 2.6.34 build I'll push it to OE for everybody to upgrade Jan 11 10:36:51 https://lkml.org/lkml/2011/1/6/587 Jan 11 10:39:51 JaMa: ok, got idea. but would be nice if someone with actual WS problem will test this (like Rui or mrmoku) Jan 11 10:45:21 disabling/enabling screen doesn't give me a WS Jan 11 10:46:32 gena2x: agreed.. I plan to ask mrmoku.. but first I wanted to push it to OE and build it on shr buildhost Jan 11 10:47:02 playya_: thanks for test Jan 11 10:52:39 JaMa: what did you mean by link, we have volunteer now to support v34 in long term or .8 is out? Jan 11 10:55:26 .8 is out and users are encouraged to update, that's why I wanted to push this soon and possible WS fix is just bonus for someone.. Jan 11 10:57:42 ah, ok :) For me were just a bit surprise that .34 has long-term support :) Jan 11 11:00:24 JaMa: hmm... r5 or r6 ? Jan 11 11:01:19 it's the same, PR was bumped just before push Jan 11 11:01:36 ok Jan 11 11:06:56 * mrmoku booting Jan 11 11:10:03 mickey|office: ping Jan 11 11:22:18 gena2x, JaMa: my WS is still there and everything else seems to work as usual Jan 11 11:30:01 mrmoku: ok... btw we still can try to fight WS. but i'll insist on setup bootloader, then dump glamo registers. tell if you interested. Jan 11 11:32:59 gena2x: sure, tell me what to do - and I'll do it :) Jan 11 11:33:47 mrmoku: ok, later today, now i'll be busy for a while Jan 11 11:34:02 good Jan 11 11:40:38 Hi all! Jan 11 11:41:39 JaMa: could you tell me which file on the host build.shr-project.org is the more frquently updated ? I need to test a wget target in a makefile Jan 11 11:43:28 GarthPS: maybe http://build.shr-project.org/tests/shr-unstable/ipk/Packages.gz Jan 11 11:44:04 mrmoku: I thought about this one http://build.shr-project.org/autobuild-tail.log Jan 11 11:45:29 mrmoku: you can try 2.6.37 :) Jan 11 11:46:35 GarthPS: I don't understand what do you need.. why not wget google.com for example? Jan 11 11:48:58 JaMa: hum right. but I wanted to have an idea of the updated rate so.. but it is good I have completed my test thx :) Jan 11 11:49:48 JaMa: you have push the 2.6.37 in OE ? Jan 11 11:50:34 yes it's there for few dayes Jan 11 11:50:45 JaMa: from your host? Jan 11 11:50:52 will do that after lunch :-) Jan 11 11:51:28 mrmoku: shr-kms on buildhost has the same Jan 11 11:51:33 ahh, ok Jan 11 11:51:40 will try that then Jan 11 11:52:54 JaMa: wow! already. does the main stream kernel missing lot of freerunner's hardware support ? or does everything is mainstreame now ? Jan 11 11:54:04 size of openmoko.patch is almost the same, shr.patch is smaller mostly because I didn't include kms patches this time Jan 11 11:54:30 -rw-r--r-- 1 bitbake bitbake 232K Jan 11 10:05 shr.patch.34.20110110 Jan 11 11:54:30 -rw-r--r-- 1 bitbake bitbake 35K Jan 10 15:35 shr.patch.37.20110110 Jan 11 11:55:07 -rw-r--r-- 1 bitbake bitbake 1547845 Jan 11 09:32 openmoko.patch.34.20110111 Jan 11 11:55:10 -rw-r--r-- 1 bitbake bitbake 1561894 Jan 6 09:42 openmoko.patch.37.20110106 Jan 11 11:57:14 JaMa: I don't know If I am able to dertermine myself If that responds to my question... :) Jan 11 11:57:55 hehe, it missing 35kbytes of hardware support Jan 11 12:00:54 GarthPS: it says that there is still >1.5M of patches which are needed and yet not in mainstream kernel Jan 11 12:01:43 GarthPS: you should look at larsc's branches to see what exactly is missing upstream Jan 11 12:01:44 JaMa: how.. sorry I did not take the time to look at the right place :) Jan 11 12:03:03 JaMa: so you tried the 2.6.37 already on the FR ? something to notice ? Jan 11 12:06:35 yes I had it booted for about 2 minutes and then I had to leave home.. so haven't found anything special Jan 11 12:07:06 except TS not working in xorg, but that was probably because of missing tslib patch Jan 11 12:07:15 which is now included Jan 11 13:08:05 JaMa: can't see it in shr-kms ? Jan 11 13:19:18 mrmoku: weird, I was pretty sure I was building it there yesterday.. running build now Jan 11 13:19:35 seems like it built 2.6.34 yesterday not .37 :/ Jan 11 13:27:05 ah it did build it, but only for gta01.. Jan 11 13:35:04 JaMa: Hard weekend? Jan 11 13:36:46 depends on "Hard" definition :) Jan 11 13:38:43 Hehe Jan 11 13:40:21 I've had hard holidays... too many alcohol... too many holidays... Jan 11 13:41:10 I had no alcohol on holidays. Still was surprisingly hard. Jan 11 13:43:08 Hi, small question: I noticed that the feed config filed for opkg have been updated for SHR-t (tests version), do I have to apply the changes (basically just removing the tests directory from the feed config files), or should I keep the files the way they are now? Jan 11 13:43:49 morphis: pong Jan 11 13:45:53 PaulFertser: 8) Jan 11 13:46:03 morphis: hi! Jan 11 13:46:19 mickey|office: I got my free pre plus from palm today :) Jan 11 13:46:33 so it's no dream Jan 11 13:46:56 yamitenshi: did you put tests/ there before yourself? Jan 11 13:46:57 congrats Jan 11 13:47:03 morphis: how to call a target form an other target in makefile not as a dependence but at some point? Jan 11 13:47:06 does it feel better? Jan 11 13:47:15 yamitenshi: if yes.. then new location is http://build.shr-project.org/shr-testing2011.1/ instead of tests/shr-testing Jan 11 13:47:35 morphis: oh cool for the pre plus! how did you do that ? Jan 11 13:47:46 if you want to see upgrades only after "rsync" not live builddir Jan 11 13:47:47 mickey|office: it's at my parents, so I can't try until now Jan 11 13:47:52 ah, k Jan 11 13:48:17 GarthPS: wrote to Palm when they offered a free pre plus for developers Jan 11 13:48:43 so I am off for some hours Jan 11 13:48:44 bye Jan 11 13:48:49 morphis: but ahta was only for us no ? i did asked too :) Jan 11 13:48:52 JaMa: yeah, that's the image I used, I was told I should use the tests directory for the feeds since the images were identical Jan 11 13:49:22 JaMa: so I should change tests/shr-testing to shr-testing2011.1 and that would do the trick? Jan 11 13:49:33 does someone knows how to call a target form an other target in makefile but not as a dependence but at some point? Jan 11 13:50:19 yamitenshi: the new testing image should have shr-testing2011.1 as feed Jan 11 13:50:21 without tests Jan 11 13:50:26 yamitenshi: currently they are the same shr-testing2011.1 is link to tests/shr-testing Jan 11 13:51:23 yamitenshi: but shr-testing2011.1 is what should be in /etc/opkg now http://git.openembedded.org/cgit.cgi/openembedded/commit/?h=shr/testing2011.1&id=3b4316cd5695087d7ceda6ea17eca5b5b53ef3a5 Jan 11 13:52:18 ah, okay. So I should just change tests/shr-testing to shr-testing2011.1 and it should work? Or do I have to install the new image? Jan 11 13:52:34 no just change it Jan 11 13:52:48 strange thing is, the package that was installed points to the normal shr-testing, not to shr-testing2011.1, so that's what made me doubt myself :P Jan 11 13:53:34 yes, that's strange, I've seen Heinervdm asking why his change didn't work.. so maybe he didn't found out yet Jan 11 13:56:05 distro-feed-configs package is right Jan 11 13:56:37 yamitenshi: which package did show you normal shr-testing feed? Jan 11 13:57:21 distro-feed-configs was updated after an opkg upgrade, installing files that pointed to the normal shr-testing feed, but I haven't tried an opkg upgrade since Jan 11 13:57:29 so it might have been changed already Jan 11 13:59:28 by the way, I didn't apply the changes, the files pointing to the normal shr-t feed are now /etc/opkg/*.conf-opkg Jan 11 14:00:32 then ignore them and make another opkg update && opkg upgrade from tests/shr-testing Jan 11 14:01:09 did that, didn't do anything Jan 11 14:01:25 opkg install -force-reinstall distro-feed-configs Jan 11 14:01:30 ok :) Jan 11 14:06:54 mrmoku: changed sync_testing alias to keep it normal rsynced dir Jan 11 14:07:09 mrmoku: with .md5s etc Jan 11 14:07:15 ok Jan 11 14:07:43 ah, I guess the package has been updated, it points to the correct feed now :) Jan 11 14:13:20 And another question: I installed a dutch myspell dictionary to my neo for the illume keyboard, and it recognizes that the file is there (it shows me the option for Dutch when I tap the top left of the keyboard), but it doesn't seem to predict any words when I type. Do I have to change anything in the .dic file? Jan 11 14:15:20 Maybe add a number after every word? Jan 11 14:15:40 probably needs that, yeah Jan 11 14:17:01 it has some foo to show the more probably (more commonly used) words directly and the others (if any) in the flap up list IIRC Jan 11 14:18:59 yeah, just a number after every word. I just noticed that the myspell dictionary has no numbers after the words, but some words have "/c" and such things appended to them. Not sure what that means, but I'm fairly sure illume doesn't do anything with it Jan 11 14:26:16 JaMa: i fixed it yesterday and build new images afterwards Jan 11 14:27:18 * mrmoku booting 2.6.37 Jan 11 14:28:27 HeinervdmWork but PR was bumped just once and only after url change, right? so I'm surprised that yamitenshi reports he had seen upgrade with old url Jan 11 14:30:42 JaMa: yes that was there for 1 day Jan 11 14:30:58 because DISTRO_FEED_URI was set in auto.conf too Jan 11 14:31:25 ah ok.. thanks for explanation, I didn't know about it in auto.conf Jan 11 14:31:46 me either, until google told me Jan 11 14:32:19 hehe :) Jan 11 14:33:03 HeinervdmWork: maybe worth commenting it out in shr-makefile Jan 11 14:37:10 JaMa: boots... and WS is still there Jan 11 14:37:18 in addition touchscreen does still not work Jan 11 14:37:32 and some sysfs boogie Jan 11 14:37:35 2000-01-01T03:23:44.330776Z [WARN] fsogsmd : Can't write-open /sys/bus/platform/devices/gta02-pm-gsm.0/power_on: No such file or directory Jan 11 14:38:15 mrmoku: do you still have booted it? please confirm that /proc/bus/input/devices and xorg.conf has right eventN interfaces Jan 11 14:38:35 mrmoku: I had right.. Jan 11 14:38:57 maybe switching to evdev for test is worth it too (I have evdev-2.6.0 locally Jan 11 14:39:05 S: Sysfs=/devices/virtual/input/input1 Jan 11 14:39:21 Option "Device" "/dev/input/event1" Jan 11 14:39:30 looks good Jan 11 14:40:06 [1804207.910] (II) XINPUT: Adding extended input device "Touchscreen" (type: TOUCHSCREEN) Jan 11 14:40:09 [1804207.911] xf86TslibControlProc Jan 11 14:40:30 there is more fun :P Jan 11 14:40:31 [1804200.127] (EE) Glamo(0): Couldn't open "/sys/bus/spi/devices/spi2.0/state" to save display resolution: No such file or directory Jan 11 14:40:54 * mrmoku downstairs for a cup of tea and a muffin :-) Jan 11 14:41:04 mrmoku: https://github.com/radekp/linux-2.6/commit/84af470fc07070fd5a129bfdcbd7c25978f8e778, maybe I should try to rebuild tslib too Jan 11 14:41:16 this patch is not in OE kernel Jan 11 14:41:37 Bah, it still only predicts half of the words... And interestingly, just the half I don't use :( Oh well, I guess it'll learn in a while :) Jan 11 15:06:46 gtg, bye Jan 11 15:06:51 cu Jan 11 15:40:34 <|x|> hiho Jan 11 15:42:06 <|x|> anyone who knows who built linux-image-2.6.34-openmoko-gta02 (or is involved himself)? Jan 11 15:42:46 from where? Jan 11 15:43:47 <|x|> pkg-fso.alioth.debian.org i guess Jan 11 15:43:50 http://pkg-fso.nomeata.de/sid/linux-image-2.6.34-openmoko-gta02 lists Timo Jyrinki and he also sent few announcements about it to ML.. so I guess it was he Jan 11 15:44:15 <|x|> ah, thanx for the hint Jan 11 15:44:56 http://www.mail-archive.com/community@lists.openmoko.org/msg61222.html Jan 11 16:05:51 N900 users: is its GPS of any good without AGPS? I mean does it make sense to think about adding support to gpsd via libisi? Jan 11 16:06:10 guys I did some advertising for FSO/SHR/ openmoko etc ... http://vimeo.com/18663899 Jan 11 16:06:37 the next to come is pre2(FSO/SHR) vs pre2(WebOS) Jan 11 16:07:13 mickey|office: wow, esr committed my patch for the hook as is, without additional discussion. Jan 11 16:08:19 ~nf Jan 11 16:08:20 The #openmoko-cdevel Newsflash Bulletin Board. (continued at ~NF2. For help see ~NF-help) - - - Recommended URLs and channels(chanlogs etc):see ~RL - - - NEWSFLASH [2010-10-07] wiki is down, see http://lists.openmoko.org/pipermail/community/2010-October/063395.html Jan 11 16:08:34 So now with the help of lindi-'s ubx tools we can fully implement nice handling for the FR. Jan 11 16:19:08 GarthPS: nice, looking forward for next one Jan 11 16:25:29 PaulFertser: can't we add our own agps with mickey|office's location stuff too? Jan 11 16:27:12 mrmoku: agps is discussable. Currently there exists a simple and clean ubx implementation by lindi- that should allow us to do what we need agps-wise, but it probably needs extending if we consider getting agps data from an external source. Jan 11 16:27:45 * mrmoku wants all of it :-) Jan 11 16:32:35 mrmoku: probably we should ask jluebbe about that agps stuff. Jan 11 16:32:56 Or probably just forget about it and consider storing/loading ephemeri to be enough. Jan 11 16:33:29 at least that would be a very good start Jan 11 16:34:21 The newly added hook should enable that without much effort. Jan 11 16:34:31 great thing :D Jan 11 16:53:18 PaulFertser: congrats :) Jan 11 16:53:48 mickey|office: i also dug out that old code to get AGPS data from the ublox server. Jan 11 16:54:19 mickey|office: but someone has to understand how to get usernames and passwords... Or we just should setup a public service with one of the known ones. Jan 11 16:54:25 http://svn.openmoko.org/developers/matt_hsu/agps-online/ Jan 11 16:54:42 mickey|office: (username/passw problem) http://lists.openmoko.org/pipermail/community/2008-June/018690.html Jan 11 16:55:29 there was username/passwd for registration available before Jan 11 16:56:00 * JaMa is still using own l/p since then Jan 11 16:56:50 lets try to get a common FSO one Jan 11 16:59:45 i sent a request to agps-account@u-blox.com Jan 11 16:59:50 lets see whether this is still alive Jan 11 17:01:20 Nice idea. Probably we'll have the only open-source internet-AGPS-enabled device soon :) Jan 11 17:01:27 Alas FR is getting more and more outdated. Jan 11 17:01:40 But its gps receiver is still quite nice. Jan 11 17:02:10 it's not just for the FR Jan 11 17:02:19 there's a thousands of Navilock devices out there Jan 11 17:02:30 some models contain ublox chips Jan 11 17:02:46 (i.e. my BT dongle) Jan 11 17:03:43 Hm, if it's really wide-spread probably it would worth considering implementing agps for u-blox in gpsd itself. Jan 11 17:06:30 elisa42, hi were you the person that had headphones issues on om-gta02? Jan 11 17:06:35 does it work now? Jan 11 17:10:35 An interesting usecase would be to force downloading AGPS data a bit in advance (while you still have internet connectivity) and use it, say, 30 min later. Jan 11 17:15:36 yep Jan 11 17:15:40 ok, the mail still seems to work Jan 11 17:15:48 got an FSO account :) Jan 11 17:16:46 What are the usage conditions? Jan 11 17:16:55 dunno. need to read up on that Jan 11 17:16:57 And just WOW, that was fast! Jan 11 17:17:06 it looks like an automated process Jan 11 17:17:45 hmm Jan 11 17:17:53 i need to create a proxy server somewhere for FSO Jan 11 17:18:01 we're not allowed to share the username & password Jan 11 17:18:23 mickey|office: can you please pastebin the conditions? Jan 11 17:22:30 http://pastebin.com/j3QmuqrS Jan 11 17:24:01 mickey|office: 1.1 and 1.3 are clearly contradictory. Jan 11 17:24:48 mickey|office: i'd assume 1.3 means you shouldn't pass username and password to anybody as is but you can embed them in your product. Otherwise it makes no sense. Jan 11 17:24:59 correct Jan 11 17:25:25 by that logic, we don't even need a proxy Jan 11 17:25:36 but i just need to store them encrypted Jan 11 17:26:20 although a proxy server might still be a good idea Jan 11 17:26:50 To me it looks like hardcoding the login/password pair in the sources would be less abusive than setting up a proxy (from the wording it might be derived that proxy is not allowed, the pair is per-product which looks like it need to be not a public service) Jan 11 17:29:59 mickey|office: (encrypted) hm, they expect password in raw form, not hash or anything... Probably you can simply store a rot13 version in the sources, no? :) Jan 11 17:30:33 For any sane person it's obvious that it can easily be eavesdropped anyway since it's transferred in clear text. Jan 11 17:36:03 I think this service is clearly per-product, not per-user. End-users are not supposed to have their own login/password pair. Jan 11 17:37:05 hmm, right Jan 11 17:39:23 GNUtoo|laptop: hi, it seems to be working with both gsmheadset and headset. Jan 11 17:39:45 ok I'll try then but later Jan 11 17:39:53 because I've some headsets that I was given Jan 11 17:40:14 GNUtoo|laptop: though I'm not able to change the volume in the dialer with headset plugged in Jan 11 17:40:28 ah ok Jan 11 17:40:46 GNUtoo|laptop: openmoko ones? Jan 11 17:40:57 nokia ones I think Jan 11 17:41:03 but I think it's compatible Jan 11 17:41:05 old ones Jan 11 17:41:07 very old Jan 11 17:41:10 for feature phones Jan 11 17:41:58 GNUtoo|laptop: ok Jan 11 17:43:00 GNUtoo|laptop: i'm not quite sure if i'm using the orginal statefiles from shr or the ones paulus uploaded Jan 11 17:43:56 ok, it was just for testing if the headset worked Jan 11 17:44:00 *headsets Jan 11 17:45:05 GNUtoo|laptop: alright Jan 11 17:57:39 elisa42, GNUtoo|laptop I think statefiles paulus ploaded to trac are now in shr, so they should be the same afaik Jan 11 17:57:57 ok Jan 11 18:15:45 pespin, GNUtoo|laptop just test it with the statefiles from shr image. it works. also changing volume in dialer works. mic untested Jan 11 18:16:03 ok Jan 11 18:16:24 shr-image from downloads or shr-image that I build? Jan 11 18:16:54 GNUtoo|laptop: from current unstable Jan 11 18:16:58 ok Jan 11 18:17:52 GNUtoo|laptop, in case you don't know, JaMa pushed emtooth2 to OE :) Jan 11 18:17:59 ah nice Jan 11 18:18:02 rev 124 Jan 11 18:18:06 ok Jan 11 18:19:45 but I wasn't able to fix a bug which ocurs when I receive a "device disappeared signal" which produces weird things in a HashTable Jan 11 18:51:38 Has the new E version some new bugs? Or can i use it for testing too? Jan 11 19:05:19 playya: ping? Jan 11 19:30:53 Heinervdm, afaik new E version is not in default shr-unstable repos yet. I think it would be wise waiting some days after it hits shr-u repos and see if people have any complains :) Jan 11 19:33:22 pespin: it won't hit normal shr-u repos in the next days Jan 11 19:33:58 Heinervdm, do you need newer E in shr-t for some special reason? Jan 11 19:34:11 pespin: i think it will fix the startup issue Jan 11 19:35:15 hmm no idea, I'm using shr-u repos right now, not unstable-tests one ;) Jan 11 19:37:36 Heinervdm: want me to test :) Jan 11 19:38:00 is it in tests/shr-unstable yet? Jan 11 19:39:17 yes it is Jan 11 19:39:56 good, will test then :) Jan 11 19:40:03 Heinervdm: and better wait.. you would need also ie patch to libphone-ui-shr which is applied after gdbus switch.. etc Jan 11 19:41:08 should be cherry-pickable though Jan 11 19:41:15 JaMa|Off: ok Jan 11 19:41:19 Heinervdm: want a branch in libphone-ui-shr? Jan 11 19:41:41 well maybe first test to see if it fixes stuff Jan 11 19:41:59 mrmoku: i think a branch will be good Jan 11 19:44:30 freesmartphone.org: 03mickey 07specs * r2ee4b93795ff 10/org.freesmartphone.Context/org.freesmartphone.Context.Manager.xml.in: typo Jan 11 19:45:23 Heinervdm: pushed as dbus-glib Jan 11 19:45:38 mrmoku: thx Jan 11 19:45:43 yw Jan 11 19:47:31 And what's about the 2.6.34.8 kernel? Jan 11 19:48:46 it does not fix my WS on blank/unblank but other than that it looks good Jan 11 19:49:23 JaMa|Off: hmm... is the index not up-to-date ? Jan 11 19:49:31 * opkg_install_pkg: Package e-wm-icons md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'. Jan 11 19:49:34 * opkg_install_pkg: Package e-wm-config-default md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'. Jan 11 19:49:38 * opkg_install_pkg: Package illume-keyboard-default-alpha md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'. Jan 11 19:49:40 * opkg_install_pkg: Package e-wm-images md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'. Jan 11 19:52:50 can we enable the charger plugin unconditionally now? Jan 11 19:53:00 did anyone send this mail to shr-users? Jan 11 19:53:59 mickeyl: hmm... no, but I can do that now Jan 11 19:54:09 mickeyl: btw. still waiting for your key :-) Jan 11 19:54:12 mrmoku: yes, please. I'd turn it on then Jan 11 19:54:19 ok Jan 11 19:54:38 ah, right. i didn't make up my mind wrt. to which projects it should allow Jan 11 19:55:33 JaMa|Off: any particular reason why we apply a patch to OE's libeflvala instead of patching upstream? Jan 11 19:56:02 mickeyl: patch is applied upstream but 2 versions later as current oe Jan 11 19:56:19 Heinervdm: right, makes sense then Jan 11 19:56:42 and i think he don't want to bump it twice within a day :) Jan 11 19:58:47 mickeyl: sent Jan 11 19:59:22 thaqnx Jan 11 19:59:23 mickeyl: just send me the key and I will add you to all groups. That way you don't have to decide ;) Jan 11 19:59:29 fair enough :) Jan 11 20:00:17 on the way Jan 11 20:00:42 freesmartphone.org: 03mickey 07cornucopia * rb10f8ac2f8f2 10/fsotdld/conf/default/fsotdld.conf: fsotdld: add new context manager default options to configuration Jan 11 20:06:50 mickeyl: done Jan 11 20:14:05 JaMa|Off: ok, just was not done yet up to the index... now it is :) Jan 11 20:14:13 * mrmoku rebooting Jan 11 20:15:36 Heinervdm: no shr_elm_softkey after boot Jan 11 20:15:45 * mrmoku removes .e and retries Jan 11 20:15:48 :-/ Jan 11 20:16:18 mrmoku: was it the first boot? Jan 11 20:18:04 Heinervdm: no, after upgrade Jan 11 20:18:24 after removing .e and restarting enlightenment shr_elm_softkey is there Jan 11 20:18:27 * mrmoku reboots Jan 11 20:18:37 mickeyl: btw. fsodeviced is still segfaulting Jan 11 20:18:51 and why did you remove .e then? Jan 11 20:19:00 to get a fresh config Jan 11 20:19:04 ok Jan 11 20:19:26 IIRC after installing the last fresh image I had shr_elm_softkey on first boot Jan 11 20:19:30 and not on consequent boots Jan 11 20:19:54 good... after reboot it's still there :-) Jan 11 20:21:37 mrmoku: it's because armv7 build is still running and overwritting .ipk files before new index Jan 11 20:24:38 yeah Jan 11 20:24:48 finished meanwhile Jan 11 20:33:42 * JaMa|Off really off again Jan 11 20:35:58 GarthPS, pong Jan 11 20:58:18 ~nf Jan 11 20:58:19 The #openmoko-cdevel Newsflash Bulletin Board. (continued at ~NF2. For help see ~NF-help) - - - Recommended URLs and channels(chanlogs etc):see ~RL - - - NEWSFLASH [2010-10-07] wiki is down, see http://lists.openmoko.org/pipermail/community/2010-October/063395.html Jan 11 20:58:34 Lopi, hi there :) Jan 11 20:58:40 hey pespin :) Jan 11 20:58:41 how are you Jan 11 20:58:50 how's iphone+shr development going? :) Jan 11 20:59:04 Lopi, great, but having exams in a wekk hehe Jan 11 20:59:09 *week Jan 11 20:59:09 I took a break for a few weeks due to some personal problems Jan 11 20:59:27 I'm continuing development today Jan 11 20:59:33 Lopi, ugh, hope everything's better now ;) Jan 11 20:59:36 plan on doing a release this week Jan 11 20:59:46 yeah everything is fine now Jan 11 21:00:16 Lopi, will you be at fosdem this year? Jan 11 21:00:26 pespin: where is it located? Jan 11 21:00:52 Lopi, Brussels Jan 11 21:00:58 Lopi, http://fosdem.org/2011/ Jan 11 21:01:13 pespin: Yeah, I was just looking at that. I don't think I'll be able to afford to go. Jan 11 21:01:21 pespin: I live in the U.S. Jan 11 21:01:42 Lopi, ugh, yeah, that makes the travel a bit more difficult, and lot more expensive I suppouse ;) Jan 11 21:02:10 pespin: I mean I would love to go, but it's probably not in the cards. I don't even know if I'll make it to Defcon this year :/ Jan 11 21:02:38 pespin: eventually I'd like to give a talk about my iphone adventures though Jan 11 21:04:08 pespin: GNUtoo|laptop mentioned a migration to gdbus, what all is working atm? Jan 11 21:04:49 Lopi, afaik everything it's quite done in fso side, and needs a bit more tweaking in phoneui stuff I think Jan 11 21:05:43 Lopi, it is not sync to official shr-unstable feeds now thought, it's in tests/shr-unstable. But I suppouse that self-build images will have it already :) Jan 11 21:05:48 yes but does all the shr daemon start and stay on without segfaulting now? Jan 11 21:06:15 he self-build his images Jan 11 21:06:52 no idea, I need a working phone, so I haven't tried :P Jan 11 21:07:04 ok Jan 11 21:07:30 GNUtoo|laptop, btw, to build an image for another machine, what should I do? add MACHINES="whatever" to local.conf? Jan 11 21:07:45 MACHINE sorry Jan 11 21:08:00 yes Jan 11 21:08:04 ok thanks Jan 11 21:08:09 but you could export that Jan 11 21:08:11 too Jan 11 21:08:14 so you do: Jan 11 21:08:25 MACHINE="om-gta02" bitbake shr-image Jan 11 21:08:32 MACHINE="nokia900" bitbake shr-image Jan 11 21:08:34 ah great :) Jan 11 21:08:39 test it tough Jan 11 21:08:51 don't blindly rely on it Jan 11 21:08:56 ok I'll try. Jan 11 21:09:49 to make it work you must remove MACHINE= from local.conf Jan 11 21:09:54 I want to try building a newer image for htc-artemis. I was able to ssh into it with an old image. Rebuild it like 15 days ago and wasn't able to get ssh working again :S Jan 11 21:10:19 do you have serial? Jan 11 21:10:22 framebuffer? Jan 11 21:10:28 ping? Jan 11 21:10:36 keyboard? Jan 11 21:10:49 GNUtoo|laptop, ping + screen (without xerver). Jan 11 21:10:49 pespin, you go to fosdem? Jan 11 21:10:52 ok Jan 11 21:10:59 GNUtoo|laptop, yes, I'm planning to go there this yar .) Jan 11 21:11:01 *year Jan 11 21:11:24 I'll bring it with me :) Jan 11 21:11:39 do you want/need a better phone to hack on? Jan 11 21:11:59 GNUtoo|laptop, uhmm not atm, my hacking skills are the ones of a noob :P Jan 11 21:12:05 ah ok Jan 11 21:12:26 I prefer starting with a phone I own and learn :) Jan 11 21:12:30 ok Jan 11 21:12:40 you seemed to have a lot of skills Jan 11 21:12:41 vala Jan 11 21:12:43 autotools Jan 11 21:12:44 etc... Jan 11 21:13:07 I like programming, but I don't have much kernel-related knowledge Jan 11 21:13:13 ah ok Jan 11 21:13:13 eager to learn though :) Jan 11 21:13:24 so you need a device without kernel related work Jan 11 21:13:29 I don't have one to give Jan 11 21:13:34 but maybe other people do Jan 11 21:13:59 GNUtoo|laptop, nah, I have things to do atm. fso support for enjoy, add alsa statefiles suppor to shr-settings, more emtooth2 works, etc. Jan 11 21:14:16 ok Jan 11 21:14:23 nice Jan 11 21:14:36 we also need people working on userspace Jan 11 21:14:41 else what we do is useless Jan 11 21:15:34 yeah, I think we need some more cool apps to be competitive. Mail, IM, etc. Jan 11 21:16:04 for browser I fixed midori in SHR Jan 11 21:16:24 we need efl apps Jan 11 21:16:26 yes Jan 11 21:16:27 VOIP pespin, we need VOIP ;) Jan 11 21:16:29 having pidgin and xchat is great, but having some apps designed for embedded systems would be better imo Jan 11 21:16:32 indeed Jan 11 21:16:33 mrmoku, ah yeah! Jan 11 21:16:36 VOIP..... Jan 11 21:16:47 that would be sooo great..... Jan 11 21:16:49 and mail too... including gpg Jan 11 21:16:51 I think the best would be having empathy Jan 11 21:17:00 empathy + telepathy can be a good framework to work with Jan 11 21:17:05 for mail there are some stuff Jan 11 21:17:07 hmm... dunno Jan 11 21:17:09 but VOPI....none Jan 11 21:17:28 pespin: I want VOIP to be integrated into our phonestack Jan 11 21:17:32 empathy would give us jabber/gtalk voip, which is something to start with ;) Jan 11 21:17:38 mail there is claw mails that work on some phones Jan 11 21:17:47 or we could try ekiga btw Jan 11 21:17:48 yeah, though it's ugly to use Jan 11 21:17:52 without a stylus Jan 11 21:18:09 yeah, I don't like claws-mail Jan 11 21:18:18 mrmoku: I'm not sure if FR is fast enough for echo cancellation Jan 11 21:18:26 pespin: I would prefer to integrate something like sflphone Jan 11 21:18:29 mrmoku: at least I had to disable it and use usb headset... Jan 11 21:18:34 that's what I was referring when saying "apps designed for embedded systems" Jan 11 21:18:39 lindi-: yeah, that might be good possible Jan 11 21:18:58 but no reason not to add VOIP :) Jan 11 21:19:02 i played around with linphone some time ago, back then debug was still enabled in kernel and it was a little to slow Jan 11 21:19:06 with more powerfull stuff on the horizon Jan 11 21:19:11 is ekiga in oE? Jan 11 21:20:23 yes Jan 11 21:20:24 it is Jan 11 21:20:25 btw i tried adding newer versions of empathy to have it working in oE but arrived at some introspect error or something similar in some dep (telepathy-glib I think). Jan 11 21:20:29 not sure if it compiles tough Jan 11 21:20:38 hmm then would be great to try it Jan 11 21:20:54 playya: yop , you told me you have got something to de-simlock a pre or pre 2 right ? Jan 11 21:21:07 yes Jan 11 21:21:50 maybe. not tested Jan 11 21:22:16 do you have the read_tokens tool on the device? Jan 11 21:22:17 I'll try building it Jan 11 21:25:59 * pespin dinner Jan 11 21:27:03 playya, so it's possible to un-simlock a palm-pre Jan 11 21:27:05 nice Jan 11 21:27:08 mrmoku, hi Jan 11 21:27:17 GNUtoo|laptop, i don't know Jan 11 21:27:26 but there's a key oin the config Jan 11 21:27:31 ok Jan 11 21:27:39 because I'm in italy Jan 11 21:27:50 hi GNUtoo|laptop Jan 11 21:27:52 I can't get a pre-plus because of that simlock Jan 11 21:27:53 ok Jan 11 21:27:58 damn. forgot my password :/ Jan 11 21:28:02 mrmoku, what's the status? Jan 11 21:28:18 I did some kernel work yesterday Jan 11 21:28:24 tried that rebase I was talking about Jan 11 21:28:27 and failed :/ Jan 11 21:28:29 kernel+userland status of n900 + fso/shr daemons that segfaulted Jan 11 21:28:30 ok Jan 11 21:28:52 but I built the newer nokia kernel based on 2.6.37-rc8 overnight Jan 11 21:28:56 still have to try it Jan 11 21:29:02 ok Jan 11 21:29:05 we should base on that Jan 11 21:29:13 yeah Jan 11 21:29:24 or maybe released 2.6.37 Jan 11 21:29:25 btw. Linus merged the smartreflex patch series Jan 11 21:29:31 so 2.6.38 will have it Jan 11 21:29:38 wow Jan 11 21:29:59 rx51 is in 2.6.38? Jan 11 21:30:05 no :/ Jan 11 21:30:09 ah ok Jan 11 21:30:13 no machine config Jan 11 21:30:14 strange Jan 11 21:30:21 s/config/board file Jan 11 21:30:28 dunno why nokia isn't pushing that more Jan 11 21:30:49 probably they have to get in all device drivers first Jan 11 21:31:00 not necessaryly Jan 11 21:31:06 you can push a board with only serial Jan 11 21:31:08 if you want Jan 11 21:31:16 sure, but that's not what they want :) Jan 11 21:31:24 ok Jan 11 21:31:55 today I tried to rebase onto current Linus master... that has quite some conflicts Jan 11 21:32:01 did not try to resolve them :P Jan 11 21:32:02 ok Jan 11 21:32:20 but I want to give the nokia 2.6.37-rc8 a try Jan 11 21:32:27 ok Jan 11 21:32:44 and someday they will have to rebase onto 2.6.38 ;) Jan 11 21:32:56 yes Jan 11 21:33:14 * GNUtoo|laptop misses bt Jan 11 21:33:27 I had bought a keyboard and a mouse Jan 11 21:33:35 for bluetooth Jan 11 21:37:49 GNUtoo|laptop: btw. what exactly do you mean with bt coexistance? Jan 11 21:38:03 basically bluetooth and wifi share the same antenna Jan 11 21:38:23 result: when you use bluetooth and wifi at the same time it doesn't work Jan 11 21:38:42 so you must have a system that permit the 2 to work together Jan 11 21:38:58 at the mac level Jan 11 21:39:20 so usage scenario: Jan 11 21:39:28 use the internet with a bluetooth keyboard Jan 11 21:39:49 in order to type more rapidely in xchat Jan 11 21:39:56 or to type more rapidely in ssh Jan 11 21:40:48 GNUtoo|laptop, GarthPS, i think it should be possible to unlock a pre if you set SimLockDef=UNLOCKED Jan 11 21:41:28 can you tell me exactly what is nedded and how does it work? I have my idea but not sure Jan 11 21:41:37 GNUtoo|laptop: ahh, ok. thx for explaining :) Jan 11 21:41:55 do you have a locked phone by hand? Jan 11 21:45:11 GarthPS, what you mail add again? Jan 11 21:45:52 Hmm... somehow my laptop does not charge anymore :/ Jan 11 21:46:11 Or the battery is dying :-( Jan 11 21:46:26 playya: did not understannd your question Jan 11 21:46:58 i need your email address to send you the read_tokens tool Jan 11 21:53:47 mrmoku,ouch!!!!! Jan 11 21:53:58 try to fix your laptop Jan 11 21:56:21 as I tought Jan 11 21:56:27 ekiga fails to compile: Jan 11 21:57:00 GNUtoo|laptop: did you try linphone? Jan 11 21:57:11 linphone works on om-gta02 Jan 11 21:57:49 GNUtoo|laptop: on mine too. whats bad about it? Jan 11 21:58:12 the GUI Jan 11 21:58:48 GNUtoo|laptop, yeah ekiga failed here too Jan 11 21:58:57 GNUtoo|laptop: ekiga doesn't seem any better to me Jan 11 21:59:09 and the fact that it's unusable with the htcdream Jan 11 21:59:18 http://pastebin.com/YS6ZC7FY Jan 11 21:59:44 # Jan 11 21:59:44 ../../../../lib/engine/components/opal/opal-call.cpp: In member function 'virtual void Opal::Call::OnCleared()': Jan 11 21:59:46 hmmm Jan 11 21:59:59 that reminds me that I knew how to workarround Jan 11 22:00:05 asked ekiga people on irc Jan 11 22:00:09 but no one responded Jan 11 22:00:38 no it was on hold I think Jan 11 22:00:42 not the same error Jan 11 22:00:52 error: 'EndedWithQ931Code' is not a member of 'OpalConnection' Jan 11 22:00:57 I don't know this new error Jan 11 22:01:57 hmmm Jan 11 22:02:22 is linphonec configurable for audio capture? Jan 11 22:02:53 GNUtoo|hrcdream: yes Jan 11 22:02:58 wow Jan 11 22:03:02 how? Jan 11 22:03:20 GNUtoo|hrcdream: don't remember it by heart but I used it to record voice quality test samples Jan 11 22:03:27 ok Jan 11 22:03:38 i used only linphonec btw Jan 11 22:08:36 lol mickeyl is on ipad and i'm on htcdream(altough under 100%free android version on main cpu) Jan 11 22:09:25 you have it better... you have a keyboard Jan 11 22:09:49 lindi, you used linphonec or linphone? Jan 11 22:10:03 GNUtoo|hrcdream: both Jan 11 22:10:08 ok Jan 11 22:10:36 so if it's possible with linphonec...it's so nice Jan 11 22:10:50 mickey|: did you see my comment regarding fsodeviced and still segfaulting? Jan 11 22:10:57 i'll investigate tommorow Jan 11 22:11:06 no Jan 11 22:11:12 mrmoku, news of your laptop? Jan 11 22:11:53 GNUtoo|hrcdream: no, I'm on AC and battery says 76 % Jan 11 22:12:00 though I'm on AC the whole day long :P Jan 11 22:12:07 ok Jan 11 22:12:17 is it still discharging? Jan 11 22:12:39 don't think it's discharging Jan 11 22:12:46 ok Jan 11 22:12:51 I think it thinks battery is full Jan 11 22:13:01 might have to train it Jan 11 22:13:17 ok Jan 11 22:13:28 lol Jan 11 22:15:13 mickey|: ** (process:291): CRITICAL **: file dbusresource.c: line 287: uncaught error: An object is already exported for the interface org.freesmartphone.Resource at /org/freesmartphone/Resource/Bluetooth (g-io-error-quark, 2) Jan 11 22:15:14 1 2 1 2,laptop you can do better...(army-like talk) Jan 11 22:15:18 Program received signal SIGSEGV, Segmentation fault. Jan 11 22:15:20 still the same Jan 11 22:15:27 GNUtoo|hrcdream: yeah, will send it to the gym :P Jan 11 22:15:33 lol Jan 11 22:15:54 * mrmoku checks version Jan 11 22:16:02 if he does too much gym...it'll become a rugged netbook Jan 11 22:16:16 not a fat laptop Jan 11 22:16:28 :) Jan 11 22:16:46 If he's very brave he will become a smartphone ;) Jan 11 22:16:53 indeed Jan 11 22:17:49 brb Jan 11 22:20:54 mrmoku: hmm, which libfsoframework rev? Jan 11 22:21:41 bye Jan 11 22:21:44 cu GNUtoo|hrcdream Jan 11 22:22:12 will try linphonec record tommorow Jan 11 22:22:13 ooh Jan 11 22:22:19 mrmoku: d'oh Jan 11 22:23:26 <[Rui]> hi all Jan 11 22:24:54 freesmartphone.org: 03mickey 07cornucopia * rf2801579d937 10/libfsoresource/fsoresource/dbusresource.vala: Jan 11 22:24:54 freesmartphone.org: libfsoresource: catch errors during dbus object registration Jan 11 22:24:54 freesmartphone.org: TODO: Use subsystem infrastructure rather than registering the object itself Jan 11 22:24:59 mrmoku: ^^ Jan 11 22:27:34 mickeyl: great :D Jan 11 22:28:04 hi [Rui] Jan 11 22:28:08 and bye :P Jan 11 22:28:13 * mrmoku off to bed Jan 11 22:28:15 g'night Jan 11 22:28:17 <[Rui]> mrmoku: good night! :) Jan 11 22:28:18 same here Jan 11 22:28:20 <[Rui]> any news? Jan 11 22:28:20 gnight all :) Jan 11 22:28:31 <[Rui]> if I update now, will it be gsbusified? will it work? Jan 11 22:28:37 getting closer to sync gdbus every day Jan 11 22:28:41 <[Rui]> yay! Jan 11 22:28:43 but if you update form official feeds no Jan 11 22:28:51 it's in tests/shr-unstable Jan 11 22:28:52 <[Rui]> ok :) Jan 11 22:28:56 and if you actually use your phone Jan 11 22:29:03 better don't sync from there yet :P Jan 11 22:29:25 * [Rui] won't, have been enjoying it working :) Jan 11 22:29:28 <[Rui]> more or less stably Jan 11 22:29:34 :) Jan 11 22:29:37 * mrmoku off for real Jan 11 22:29:43 <[Rui]> either there's a problem with the µ-sd card, or the kernel is corrupting it frequently Jan 11 22:29:48 freesmartphone.org: 03mickey 07cornucopia * r9e5ec26d3ceb 10/fsotdld/conf/default/fsotdld.conf: fsotdld: fix typo in default conf Jan 11 22:29:57 <[Rui]> weird lockups sometime happen Jan 11 22:30:10 <[Rui]> then I mount on a card reader and fsck, and things get a little better for a while Jan 11 22:32:26 playya: oh sorry forgot you :) you should have notice a mail from me today on the community ML ans SHR MLs about advertising Jan 11 22:54:36 [Rui]: probably corruption will go away with non-kms kernel Jan 11 22:54:57 <[Rui]> gena2x: is a kms kernel adding anything really useful to me? Jan 11 22:55:38 they say if makes glamo graphic better Jan 11 22:55:47 i don't know in which way :( Jan 11 22:56:23 but here i am getting stable corruptions with kms kernel Jan 11 22:57:11 actually i think kms is not really user-visible thing Jan 11 22:58:58 i can only provide one example, - 1 of two anti-ws patches were already in kms (so it actually were reinvented twice) :) Jan 11 23:14:56 playya: anyway mail mail is written down here http://pare.sylvain.perso.sfr.fr/CV.html Jan 11 23:17:26 thx Jan 11 23:19:08 <[Rui]> gena2x: :) Jan 11 23:36:26 playya: thx you! Jan 11 23:36:41 I will see that tomorrow :) Jan 11 23:36:45 gn8 all Jan 11 23:37:38 <[Rui]> gnite Jan 11 23:39:41 gena2x: KMS should reduce the maintenance burden, as both X and framebuffer can use the same modesetting code Jan 11 23:39:53 it's also more robust in the X case Jan 11 23:40:18 (though in the framebuffer change the situation regarding that is essentially unchanged between the traditional FB drivers and KMS) Jan 11 23:40:31 err... in the framebuffer case Jan 11 23:42:04 OTOH, if acceleration is used, it should be more robust even in the framebuffer case, as fbdev requires hardware access in userspace for non-trivial acceleration Jan 11 23:52:42 is it possible to tell enlightenment to hide the keyboard if the keyboard lid is open? **** ENDING LOGGING AT Wed Jan 12 02:59:58 2011