**** BEGIN LOGGING AT Fri Oct 14 02:59:57 2011 Oct 14 05:24:48 moin Oct 14 06:44:14 moin Oct 14 09:01:33 JaMa|Wrk: hi. about my ticket's interface network. So we have to cahnge our manners ?it will always stay as 192.168.7.2 ? so we need to change our conf on our laptop to be able to log via ssh for example ? Oct 14 09:11:17 GarthPS: yes Oct 14 09:12:40 JaMa|Wrk: ok. thx. (Surely there must be a good reason :) ) Oct 14 09:16:15 we've discussed it here with GNUtoo and others.. and decided to stay closer to oe-core defaults (and change onlu usb0 to auto) Oct 14 09:17:09 resulting in http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=550ea1bdf74d3cf77713d95f91052bab2bdf623c Oct 14 09:17:35 and FWIW my input on discussion was that I don't care, because I never used default interfaces.. Oct 14 09:19:09 GarthPS: do you still have old image? Oct 14 09:19:23 JaMa|Wrk: hmm I think so .. Oct 14 09:19:27 did you have /media/card in your /etc/fstab? Oct 14 09:20:03 I see there only this: Oct 14 09:20:03 # uncomment this if your device has a SD/MMC/Transflash slot Oct 14 09:20:04 #/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0 Oct 14 09:20:33 and in old shr-u it was Oct 14 09:20:34 # microSD slot Oct 14 09:20:34 /dev/mmcblk0p1 /media/card auto defaults 0 0 Oct 14 09:20:50 so you have to uncomment it and remove noauto if you want it in shr-core Oct 14 09:26:18 JaMa|Wrk: ohw to go through an ubi image ? Oct 14 09:26:31 to look into without flashing it Oct 14 09:26:56 ohw? Oct 14 09:27:06 ah Oct 14 09:27:24 you can mount it with -o loop iirc Oct 14 09:27:34 if you have ubifs support in your host kernel Oct 14 09:32:56 JaMa|Wrk: what is the diff between .ubi file and .ubifs ? Oct 14 09:34:10 .ubi is ubinized Oct 14 09:35:21 http://wiki.openmoko.org/wiki/UBIFS Oct 14 09:37:49 JaMa|Wrk: thx for the link! (but I still don't understand ubi ubinized..) Oct 14 09:38:19 then read some docs :) Oct 14 09:38:32 polite version of rtfm ^ :) Oct 14 09:41:27 JaMa|Wrk: ;) Oct 14 09:43:49 GarthPS, basically you need .ubi and not .ubifs Oct 14 09:44:32 mrmoku, I'll do the priorities: Oct 14 09:44:39 1)test om-gta02 patch Oct 14 09:44:45 so where's the patch? Oct 14 09:44:52 2)n900 charging Oct 14 09:44:57 build.shr-project.org/tests/mrmoku/shr.patch Oct 14 09:45:05 JaMa|Wrk: did you take a look? ^ Oct 14 09:45:09 it still doesn't charge on x90 and says 0x10 Oct 14 09:45:25 3)om-gta02 gps Oct 14 09:45:26 mrmoku: yup I did.. looks sane Oct 14 09:45:32 good Oct 14 09:45:37 maybe GPS need some discussion Oct 14 09:45:41 4)nexus S suspend Oct 14 09:45:48 5)htcdream build Oct 14 09:45:56 mrmoku: should I apply? I have it locally already Oct 14 09:46:13 should we test before? hmm... telephony is broken anyway now Oct 14 09:46:34 GNUtoo: what do you think? test or apply? Oct 14 09:46:50 * JaMa|Wrk was going to build new images on buildhost.. so it could be in already Oct 14 09:47:00 then apply :-) Oct 14 09:47:05 mrmoku, you apply and then I test Oct 14 09:47:21 GNUtoo: JaMa|Wrk applies and then we both test :-) Oct 14 09:47:25 ok Oct 14 09:47:57 GNUtoo: charging n900 works now at least as before with your patch? Oct 14 09:48:11 yes Oct 14 09:48:14 no Oct 14 09:48:19 oops no Oct 14 09:48:28 before it charged at 0x10 Oct 14 09:48:30 if yes then commit and push? Oct 14 09:48:34 on charger Oct 14 09:48:39 basically before: Oct 14 09:48:47 usb -> 0x10 [OK] Oct 14 09:49:02 charger -> 0x10 [too slow] Oct 14 09:49:04 now: Oct 14 09:49:07 usb -> 0x10 [OK] Oct 14 09:49:13 charger -> 0x10 [discharges] Oct 14 09:49:23 so not ok Oct 14 09:49:32 ok Oct 14 09:49:54 but anyway I've the whole day + the week-end to work on all that Oct 14 09:50:03 if the right people are there it should go fine Oct 14 09:50:18 good Oct 14 09:52:05 what discussion does gta02 gps need? Oct 14 09:52:24 mrmoku: I'm a bit woried about those changes in begining of shr.patch Oct 14 09:52:43 mrmoku: maybe your git diff didn't take one patch, because it doesn't look like only reformating Oct 14 09:53:07 n Oct 14 09:53:19 hmm Oct 14 09:53:40 try to regenerate it your way? Oct 14 09:54:22 yup trying now Oct 14 09:54:29 mrmoku, the discussion is : is it worth switching to fsotdldt + gpsd Oct 14 09:54:34 does it supports all features Oct 14 09:54:58 what is the alternative? Oct 14 09:55:45 getting rid of a frameworkd subsystem is a step in the right direction :) Oct 14 09:56:18 the alternative is my fix Oct 14 09:58:37 good morning Oct 14 09:59:34 GNUtoo: ogpsd + fso-gpsd + fsotdld then? Oct 14 10:00:08 if that works and you have it ready we can do that first Oct 14 10:00:31 my fix works Oct 14 10:00:36 and it's sent to ml Oct 14 10:00:43 including fsotdld? Oct 14 10:00:45 but it doesn't make use of fsodtld Oct 14 10:00:49 ok Oct 14 10:01:00 I've also fixed the gpsd plugin of fsodtld Oct 14 10:01:03 but with fixed libgps plugin it might work Oct 14 10:01:10 I'll try Oct 14 10:01:15 but first Oct 14 10:01:18 telephony test Oct 14 10:01:21 yup Oct 14 10:01:24 that's the most important Oct 14 10:01:32 who cares about GPS when telephony fails Oct 14 10:01:41 JaMa|Wrk: yes you are right . In a shr-u image form juin I also have this in my fstab # microSD slot Oct 14 10:01:41 /dev/mmcblk0p1 /media/card auto defaults 0 0 Oct 14 10:01:52 GarthPS, om-gta02? Oct 14 10:01:58 GNUtoo: yes Oct 14 10:02:27 ok Oct 14 10:06:22 mrmoku, is the fix for telephony pushed? Oct 14 10:06:34 should I pull and build and workarround morphis's problem Oct 14 10:08:47 an update will show :) Oct 14 10:08:50 SHR: 03Martin.Jansa 07meta-smartphone * r3ddb0a8a69b2 10/meta-openmoko/recipes-kernel/linux/ (linux-2.6.39/shr.patch linux_2.6.39.bb): meta-openmoko: linux-2.6.39: apply patch for setting DAI mode while pcm is active Oct 14 10:09:34 JaMa|Wrk: thx :) regenerated and looks better? Oct 14 10:09:43 mrmoku: weird, my way does the same diff Oct 14 10:09:50 hehe, ok Oct 14 10:09:58 well my way and your way is only using local stable branch instead of remote Oct 14 10:09:58 I compared the revs listed on top Oct 14 10:10:03 and they were the same Oct 14 10:10:11 ok Oct 14 10:10:13 yup, me too Oct 14 10:10:46 maybe it's because of newer git version Oct 14 10:10:54 sorting chunks in git diff a bit different Oct 14 10:11:22 mrmoku: btw have you noticed subversion-1.7 in shr-chroot? Oct 14 10:11:23 yup Oct 14 10:11:28 no Oct 14 10:11:41 then be awere.. warning is on wiki and shr-chroot commit Oct 14 10:11:58 http://wiki.shr-project.org/trac/wiki/Building%20SHR#subversion1.7inshr-chroot Oct 14 10:12:31 ok Oct 14 10:14:31 * mrmoku upgrading has checkouts Oct 14 10:15:31 mrmoku: check for eglibc.. this one can fail to svn upgrade Oct 14 10:15:46 mrmoku: not sure why.. I've removed it to recheckout later Oct 14 10:18:01 JaMa|Wrk: second run of your command showed only the error which is ok Oct 14 10:18:23 probably because I have no eglibc checkout Oct 14 10:18:45 downloads/svn has only enlightnement Oct 14 10:19:55 * mrmoku lunch Oct 14 10:19:56 good.. that's expected Oct 14 10:20:00 :) Oct 14 10:20:12 usually you get tarballed checkouts with right SRCREV from buildhost Oct 14 10:20:27 * JaMa|Wrk has downloads/svn full of stuff :) Oct 14 10:27:57 SHR: 03Martin.Jansa 07shr-chroot * r612edd913ebc 10/ (276 files in 12 dirs): system upgrade Oct 14 11:43:39 JaMa|Wrk: | Requested 'elementary >= 0.7.0.52890' but version of elementary is 0.7.0.0 Oct 14 11:43:42 known thing? Oct 14 11:45:07 fsck.. yes it's :/ Oct 14 11:45:27 there is autotools hack parsing revision from .svn dir Oct 14 11:45:54 and if you don't have right .svn dir it cannot parse revision and puts 0 there.. Oct 14 11:46:06 I'll recheck why it doesn't work for you (here it does) Oct 14 11:48:39 ok thx :) Oct 14 11:48:50 mrmoku, for passing fsogsmd remove --enable-modem-samsung in recipe Oct 14 11:48:55 I'm trying that right now Oct 14 11:49:05 GNUtoo: indeed... that's the other one failing :) Oct 14 11:49:17 JaMa|Wrk: would removing the e checkout help? Oct 14 11:49:50 mrmoku: not sure.. because I have checkout here and I've upgraded EFL yesterday just fine Oct 14 11:49:56 ok Oct 14 11:50:03 actually I've upgraded it a bit mostly to test new subversion :) Oct 14 11:50:37 JaMa|Wrk, iirc you created a git from e svn. is it up-to-date? Oct 14 11:53:23 I'm using git-svn locally, but haven't created git repo Oct 14 11:53:52 hmm. ok Oct 14 11:54:11 then i'll create one and maybe pull it to github Oct 14 11:55:01 GNUtoo: what do I need in DEPENDS for --enable-provider-libgps ? Oct 14 11:57:10 playya: I think there was one from e guys... TAsn should know Oct 14 11:57:10 yes you need gpsd Oct 14 11:57:19 ok Oct 14 11:57:25 mrmoku: the magic is: m4_define([v_rev], m4_esyscmd([(svnversion "${SVN_REPO_PATH:-.}" | grep -v export || echo 0) | awk -F : '{printf("%s\n", $1);}' | tr -d ' :MSP\n'])) Oct 14 11:58:13 heh Oct 14 11:58:27 and here it works Oct 14 11:58:28 OE @ ~/downloads/svn/svn.enlightenment.org/svn/e/trunk/elementary $ svnversion . | grep -v export || echo 0 Oct 14 11:58:31 64050 Oct 14 11:59:23 mrmoku, JaMa|Wrk git clone git://git.enlightenment.org/git/e.git Oct 14 11:59:29 OE om-gta02@shr ~/downloads/svn/svn.enlightenment.org/svn/e/trunk/elementary $ svnversion . Oct 14 11:59:32 mrmoku: did you already upgraded your svn checkout? Oct 14 11:59:32 63721 Oct 14 11:59:40 err shr-chroot? Oct 14 11:59:57 not after your very last system upgrade from today Oct 14 12:00:23 * mrmoku will remove the svn checkout, update chroot and retry Oct 14 12:01:38 mrmoku: can you try to run it in unpacked elementary_svn.enlightenment.org_.svn.e.trunk_63721_.tar.gz Oct 14 12:01:42 from downloads dir? Oct 14 12:02:11 moment Oct 14 12:03:04 OE @ /tmp/elementary $ svnversion Oct 14 12:03:04 svn: E155036: Working copy '/tmp/elementary' is too old (format 10, created by Subversion 1.6) Oct 14 12:03:05 well if you get that file from SHR buildhost (instead of your checkout) you're right.. it fails Oct 14 12:03:07 :P Oct 14 12:03:08 OE @ ~/downloads/svn/elementary $ svnversion "${SVN_REPO_PATH:-.}" | grep -v export || echo 0 Oct 14 12:03:12 svn: E155036: Working copy '/OE/downloads/svn/elementary' is too old (format 10, created by Subversion 1.6) Oct 14 12:03:14 0 Oct 14 12:03:30 so you have to keep your checkout but remove those files from downloads Oct 14 12:03:41 well... checkout is gone already :) Oct 14 12:03:46 will remove the downloads too Oct 14 12:05:12 * JaMa|Wrk cleaning downloads dir on buildhost Oct 14 12:05:32 we need more space anyway Oct 14 12:12:11 mrmoku: and your eglibc patch is in :) Oct 14 12:12:47 JaMa|Wrk: yeah, I saw the pull request :-) Oct 14 12:12:53 JaMa|Wrk: thx again Oct 14 12:21:10 JaMa|Wrk: python-elementary built :-) Oct 14 12:22:49 great Oct 14 12:31:09 will test as soon as my dream registers Oct 14 12:31:13 which can take some time Oct 14 12:31:20 (new ril) Oct 14 12:31:31 (with french card on italian network) Oct 14 12:35:20 JaMa|Wrk, mrmoku thanks a lot tested => works Oct 14 12:35:56 ~hail mrmoku Oct 14 12:35:56 * apt bows down to mrmoku and chants, "I'M NOT WORTHY!!" Oct 14 12:41:56 mrmoku, ? Oct 14 12:42:08 mrmoku, ahh, git. Oct 14 12:42:14 mrmoku, git.enlightenment.fr iirc Oct 14 12:45:50 TAsn: thx... playa already gone :P Oct 14 12:46:09 well, stash that info until next time. :P Oct 14 12:46:10 DocScrutinizer51: parcel hit me :-) Oct 14 12:46:32 git stash info Oct 14 12:46:48 :P Oct 14 12:46:57 git really does everything ;P Oct 14 12:48:06 yup Oct 14 12:48:24 mrmoku: good :-) Oct 14 12:48:29 hope it's all OK Oct 14 12:48:32 okie, off again, can't sit on a chair for more than 5 minutes. Oct 14 12:48:33 cioa. Oct 14 12:48:46 DocScrutinizer: looks good... still have to identify what those two small parts are :P Oct 14 12:49:03 two small parts? Oct 14 12:49:18 one antenna probably Oct 14 12:50:29 there's a GPS antenna in there (small green board with large ceramic cube patch antenna, and short "cable" with golden plug), plus a black banana GSM antenna Oct 14 12:50:54 yup, that's one of the two pieces Oct 14 12:50:55 then there's also a WLAN module board Oct 14 12:51:23 with a B2B connector to plug in on top of the open shield can Oct 14 12:51:26 ahh ok, that's probably the other one Oct 14 12:52:10 hope you appreciate my sylus rework ;-D Oct 14 12:52:16 stylus* Oct 14 12:52:41 if not: there's a second case ;-D Oct 14 12:53:11 hehe, yeah interesting that wood stylus :-) Oct 14 12:54:00 I think those BBQ-needles are available in steel as well, same diameter Oct 14 12:54:10 :) Oct 14 12:56:51 DocScrutinizer: what is missing is the two torx screws... but I probably don't need them anyway Oct 14 13:00:49 DocScrutinizer: which part is the GSM antenna? the half moon on the bottom? Oct 14 13:01:02 yup Oct 14 13:01:28 good Oct 14 13:01:33 mrmoku: ooops, those torx are so utterly useless I forget them :-) Oct 14 13:04:24 :) Oct 14 13:04:44 I think I lost them when fixing the Aux button on my gta02 too Oct 14 13:04:56 so nothing to bother... those plastic clips are good enough Oct 14 13:07:16 ahh I think I start to understand Oct 14 13:07:20 for n900 charger Oct 14 13:07:28 I didn't read the script really until now Oct 14 13:30:35 hi DocScrutinizer Oct 14 13:30:49 for battery charging I made a huge mistake not reading the script carefully Oct 14 13:31:07 now I'm reading it and I don't understand the comments Oct 14 13:31:17 I'm used to that kind of notation tough Oct 14 13:31:32 (I worked with an ADC that had raw commands) Oct 14 13:31:55 so for the register 0x1 in : http://enivax.net/jk/n900/charge21.sh.txt Oct 14 13:32:11 I don't understand which is which Oct 14 13:32:35 for instance 0x8 correspond to 0000 1000 Oct 14 13:33:17 but then it's not consistent Oct 14 13:33:41 I mean the MSB would be on the bottom in the comments? Oct 14 13:34:13 s/would be/is Oct 14 13:35:34 maybe the half lower part is sent first Oct 14 13:35:38 and then the higher part Oct 14 13:35:50 (I don't know i2c well) Oct 14 13:36:01 GNUtoo: 0x8 means 100mA limit Oct 14 13:36:37 ok let me re-think about it with that new info Oct 14 13:37:26 GNUtoo: look further for i2cset -y 2 0x6b 0x01, e.g. i2cset -y 2 0x6b 0x01 0x48, it means 500 (01001000)ma Oct 14 13:37:36 GNUtoo: the first one (disabling the charger) is 11001100 Oct 14 13:37:49 new question: Oct 14 13:38:07 why it says 00 01 and 10 in a single bit part of the register (8) Oct 14 13:38:18 GNUtoo: comment is misleading Oct 14 13:38:29 ahh ok Oct 14 13:38:34 GNUtoo: it means that bits 6-7 are used together. Oct 14 13:38:38 ok Oct 14 13:39:07 He should have put all of the values on the single line i guess. Oct 14 13:39:52 ok got it Oct 14 13:40:53 thanks a lot Oct 14 13:42:16 :) GNUtoo please pass me a note when you have an opinion about using upstream kernel on n900 for everyday activities. Oct 14 13:42:37 I've no opinion since I didn't look at the current state Oct 14 13:42:42 but... Oct 14 13:42:50 I know how to look at current state Oct 14 13:43:10 basically you must look if their 3.0 is ready Oct 14 13:43:15 if so look at their patches Oct 14 13:43:17 and decide Oct 14 13:43:27 with the kernel we have: Oct 14 13:43:34 *power off is a hack and not in mainline Oct 14 13:43:41 *lots of other patches Oct 14 13:43:53 s/is not/was not Oct 14 13:43:57 no idea if it is now Oct 14 13:44:18 Their == meego? Oct 14 13:45:47 I mean from a user point of view, i just want to start using an n900 but i was unhappy with what i tried last time. Oct 14 13:46:00 yes meego Oct 14 13:46:12 with what? Oct 14 13:46:13 shr? Oct 14 13:46:29 you'll still be unhappy it didn't change a lot since last time(we lack manpower) Oct 14 13:47:34 when did you try? Oct 14 13:47:41 because telephony is still not good Oct 14 13:47:45 GNUtoo: A year ago. Oct 14 13:47:49 I tried SHR Oct 14 13:47:50 ah ok Oct 14 13:47:56 GNUtoo: comments in charge21.sh are not that great, maybe http://maemo.cloud-7.de/bq24150-sysnode.spec.txt helps a bit Oct 14 13:47:58 now we have voice calls Oct 14 13:48:09 but the sound quality is not good Oct 14 13:48:16 too much underruns/overruns Oct 14 13:48:23 then we don't have sms Oct 14 13:48:39 3g should work altough it didn't for me in France Oct 14 13:48:53 but it worked in italy here some time ago Oct 14 13:50:49 GNUtoo: what about power consumption? and SIP? Oct 14 13:53:32 hi paul Oct 14 13:53:45 Hey Doc :) Oct 14 13:53:50 PaulFertser, right now it's unusable as a phone Oct 14 13:54:11 about power consumation: no one tested, suspend resume lacks an fso plugin Oct 14 13:54:33 about SIP: it should work, for instance linphone should work, however not out of the box Oct 14 13:54:46 GNUtoo: should there be suspend at all? Ain't zeroclock working? Oct 14 13:55:03 http://www.shr-project.org/trac/ticket/1487 for sip Oct 14 13:55:09 suspend works Oct 14 13:55:20 but it's not handled well by userspace: Oct 14 13:55:29 for instance let's say you suspend the phone Oct 14 13:55:33 But why suspend the device at all? Oct 14 13:55:34 it will suspend Oct 14 13:55:39 then resume because of a sensor Oct 14 13:55:53 yes good question Oct 14 13:56:16 maybe we should power off the screen (FBIOBLANK) and let the CPU scale itself Oct 14 13:56:21 *CPU freq Oct 14 13:56:22 PaulFertser: we have to teach it not to suspend Oct 14 13:56:51 probably should be an easy thing to do Oct 14 13:56:57 GNUtoo: DocScrutinizer told us so many times how great it is to not have to suspend thanks to that 0Mhz cpu state. Oct 14 13:57:17 mrmoku: not suspending is easy, just do not write anything to /sys/power/state ;) Oct 14 13:57:47 indeed Oct 14 13:57:48 PaulFertser: :P I have to find where fso does that and add a config for that :) Oct 14 13:57:51 already looking Oct 14 13:58:14 mrmoku, I know Oct 14 13:58:20 mrmoku, fsousaged plugins Oct 14 13:58:31 So for me a working n900 would mean a device that utilizes that state and consumes no more than maemo on average. Oct 14 13:58:35 the kenrel26 plugin I think Oct 14 13:58:49 PaulFertser, you don't need telephony? Oct 14 13:59:12 GNUtoo: well, if i have a device that works that way even without telephony i would get interested. Oct 14 13:59:19 ok Oct 14 13:59:23 but would you contribute Oct 14 13:59:32 shr is in huge trouble because we lack time and manpower Oct 14 13:59:33 GNUtoo: so: excellent power consumption would make me actively look if i can fix anything else. Oct 14 13:59:40 ok Oct 14 14:00:07 GNUtoo: but if dynamic voltage scaling, zeroclock etc doesn't work, i'm not doing anything: that's too core stuff for me. Oct 14 14:00:40 ok Oct 14 14:00:44 the kenrel part works Oct 14 14:00:48 DVFS now works Oct 14 14:00:53 we lost bluetooth but it works Oct 14 14:01:18 Works but nobody has actually tested it? Hm. Oct 14 14:01:24 dynamic core voltage aka SamrtReflex doesn't pull it Oct 14 14:01:27 no Oct 14 14:01:31 it's not that Oct 14 14:01:34 almost worthless Oct 14 14:01:45 it's rather that it need a very simple userspace fso plugin Oct 14 14:01:56 FsoFramework.FileHandling.write( "mem\n", sys_power_state ); Oct 14 14:02:15 mrmoku: you just should not suspend Oct 14 14:02:18 mrmoku: fsodeviced Oct 14 14:02:36 mrmoku: and SHR used to have its own suspending trigger in phonefsod. Oct 14 14:02:57 hmm... how stupid am I :-P Oct 14 14:02:58 mrmoku: if you just comment it out in FSO it would work too but it would be a rather strange way to configure the suspending behaviour. Oct 14 14:03:19 hehe Oct 14 14:03:41 # when to automatically suspend the device (one of: never, normal, always) Oct 14 14:03:44 auto_suspend=normal Oct 14 14:03:51 man... this is sad ;) Oct 14 14:03:52 better strange than borked Oct 14 14:04:15 PaulFertser: so just setting it to never and we should be done :) Oct 14 14:04:15 * DocScrutinizer suggests "never" ;-D Oct 14 14:04:33 DocScrutinizer: if something's consistently borked, that's usually easier to fix than some of the stranger things. Oct 14 14:04:37 ;) Oct 14 14:04:45 indeed Oct 14 14:04:52 +1 :) Oct 14 14:05:30 GNUtoo: we have to machine-ify phonefsod config then :/ Oct 14 14:05:36 I just applied for a job as COBOL coder, to manage pharma delivery EU-wide :-S Oct 14 14:05:49 heh Oct 14 14:06:48 DocScrutinizer, why not working in embedded stuff? Oct 14 14:07:07 like hardware/software embedded stuff Oct 14 14:07:40 you got a job for me? Oct 14 14:08:51 no, but I wondered if the usual companies that work in embedded free software stuff got jobs for someone like you Oct 14 14:08:53 rtp: Hi :) any idea if i really must supply 5V to VBUS's pin of the OTG controller to make it work? How on earth does your machine perform vbus detection? Oct 14 14:09:05 GNUtoo: usually not Oct 14 14:09:11 ah ok, that's sad Oct 14 14:09:23 if you hear about such company, they usually got their EE team Oct 14 14:09:28 ok Oct 14 14:09:38 maybe buglabs but I guess you already tried Oct 14 14:09:45 nope Oct 14 14:09:57 I gave up on really trying Oct 14 14:10:09 ok Oct 14 14:10:43 btw is it possible that it stll displays 0x10 but charge faster? Oct 14 14:10:51 because % seem growing much faster Oct 14 14:10:53 PaulFertser: hi. I guess that my systems are far from being the normal way of working, so can't really answer (Look for efika in ehci-mxc :/ ) Oct 14 14:10:56 note the seem Oct 14 14:11:11 who's displaying 0x10? Oct 14 14:11:39 fsodeviced Oct 14 14:11:46 nfc Oct 14 14:11:48 let me find the line Oct 14 14:12:21 I fail to appreciate the management of bq24150 in a fso daemon Oct 14 14:13:06 var status = pullByteFromI2C( fd, 0x6b, 0x00 ); Oct 14 14:13:09 as for management of bq24150 you need user root or user power, while fso might move to user middleware eventually Oct 14 14:13:21 basically i2cget 0x6b 0x00 Oct 14 14:13:45 rtp: but do you use the OTG controller in device mode? Do you supply anything to its vbus pin? Do you use vbus-gpio or other driver to detect it? Do you use internal UTMI PHY? Oct 14 14:13:51 (sorry so many OT questions) Oct 14 14:14:00 GNUtoo: see http://maemo.cloud-7.de/bq24150-sysnode.spec.txt Oct 14 14:14:09 PaulFertser: host only Oct 14 14:14:46 rtp: ok, thanks. I'm so tired of reading those useless FS docs and my vbus pin is not routed out :( Oct 14 14:15:39 0x10 means: "normal", no-boost, "ready", sTAT=0, OTG-sense=1 Oct 14 14:15:43 ok Oct 14 14:15:57 no info about curlim or anything Oct 14 14:16:09 ok Oct 14 14:16:19 curlim is in reg 1 Oct 14 14:17:09 PaulFertser: don't you have an external chip to provide vbus, as suggested iirc by otg/usb docs ? Oct 14 14:17:22 OTG-sense=1 indicates you attached fastcharger, I guess Oct 14 14:17:42 yes Oct 14 14:17:42 ooops 0x10, not 0x80 Oct 14 14:18:02 usually I got -0x90 when attaching charger Oct 14 14:18:08 s/-// Oct 14 14:18:09 GNUtoo meant: usually I got 0x90 when attaching charger Oct 14 14:18:19 so this is "in-progress", OTG=0 Oct 14 14:18:42 GNUtoo: yes, as OTG=0x80 Oct 14 14:18:59 & 0x10 for "in-progress" is 0x90 Oct 14 14:20:14 hmmm Oct 14 14:21:22 however that doesn't yet mean a thing, as some other subsystem may have reset the PHY chip 1707 so it can't detect D+/- short anymore Oct 14 14:22:16 ok Oct 14 14:22:21 rtp: we wanted to have a really minimal system with that otg controller in device mode only. Somehow our EE understood minimal as "do not even route out the vbus pin" :( Oct 14 14:22:31