**** BEGIN LOGGING AT Thu Dec 16 02:59:57 2010 Dec 16 09:39:50 hello folks Dec 16 09:41:21 I have two openmoko phones, both have "date code" = 20090324 Dec 16 09:41:43 but they were bought about one year apart (and actually boot different-looking OS) Dec 16 09:42:08 I prepared one debian OS on microSD one the older one, then bought another one Dec 16 09:43:06 but despite having exactly the same part number and date code, the new one does not boot the microSD when I move it into it Dec 16 09:43:15 any clue what can cause this? Dec 16 09:45:17 michelem: different bootloader version. Dec 16 09:45:30 michelem: or if this's u-boot, different u-boot environment. Dec 16 09:45:47 michelem: either that, or some mechanical/electrical problem with uSD. Dec 16 09:47:03 makes sense, let me try to update the U-Boot Dec 16 10:00:16 uhm Dec 16 10:00:34 is the native u-boot supposed to export the unit on USB? Dec 16 10:00:53 because dfi-util fails with "No DFU capable device found" Dec 16 10:01:09 and lsusb actually shows no moko devices attached Dec 16 10:01:58 michelem: the recommended way to flash is with nor u-boot. Dec 16 10:03:32 yes Dec 16 10:03:55 AUX + power, get U-Boot screen, run dfu-util from there. There I get this message Dec 16 10:04:09 michelem: first hold AUX, then press power. Dec 16 10:04:17 yep Dec 16 10:04:28 I do see the U-Boot screen and all Dec 16 10:04:30 michelem: provided your cable is good, port is good and os is sane, dfu-util should see it. Dec 16 10:04:47 ouh Dec 16 10:05:12 i "pushed in" the cable more and it's now working Dec 16 10:06:21 nice. Dec 16 10:06:26 michelem: if you use u-boot, then you should care about the environment too. Dec 16 10:06:57 yes, I'm vegetarian indeed. Dec 16 10:07:34 michelem: lacto-ovo? Or a more strict one? Dec 16 10:07:44 lacto ovo Dec 16 10:07:51 Same here Dec 16 10:07:56 :) Dec 16 10:08:17 what's with the uboot environment? Dec 16 10:08:49 it works btw, essentially I needed a way to replicate the OS I prepared on an SD card Dec 16 10:09:07 re-flashing the u-boot provides. Dec 16 10:13:06 michelem: i meant that by reflashing u-boot to the same version you do not guarantee that the environment (and hence the menu and boot options and parameters) is the same. Dec 16 10:14:17 ok Dec 16 10:14:42 btw, it still seems to me to have the GPS / SD interference problem Dec 16 10:15:33 I do not have the capacitor from http://wiki.openmoko.org/images/d/dd/Gta02_gps_10pf_rework_sop.pdf Dec 16 10:16:26 but the hardware is from March 2009 indeed (that fix seems from 2008) Dec 16 10:16:31 2008 ) Dec 16 10:18:31 michelem: gps/sd interference is supposed to be completely mitigated by the kernel fix, capacitor is not necessary. Dec 16 10:19:24 I'm checking through to verify that my debian version has that patch Dec 16 10:24:14 I'm a debian user too but i've always used a self-compiled kernel of course. Dec 16 10:25:30 gosh. glamo-mci.0: glamo_mci driver ©2007 Openmoko, Inc Dec 16 10:26:06 PaulFertser: why of course? I didn't have any issue until needing this GPS stuff Dec 16 10:26:13 s/until/before Dec 16 10:29:03 michelem: as i was somewhat involved in the kernel work ever since i bought my FR. Dec 16 10:29:30 michelem: copyright date in the file doesn't mean much. Dec 16 10:49:00 PaulFertser: which out of the 100 kernel distributions listed on http://wiki.debian.org/DebianOnFreeRunner#KernelBranchesinAutumn2010 would you recommend? Dec 16 10:50:07 essentially, this is for a mobile app for time tracking to use in production, so stability is critical, battery life important, performance not. But the GPS fix must be in Dec 16 10:57:19 michelem: are you going to put your device in suspend-to-ram ever? Dec 16 10:57:41 if possible, yes, but no big deal Dec 16 10:58:02 it's not used as a phone, just to use this application. They can as well turn it on/off when needed Dec 16 10:58:14 michelem: there's one critical bug but it's rare and strange enough to not be fixed... Dec 16 10:58:20 but if suspend works, it's convenient to avoid the 2 minutes of boot time Dec 16 10:58:39 rare = unfrequent? Dec 16 10:58:49 infrequent, sorry Dec 16 10:59:17 uhm let's go without then, anyway Dec 16 10:59:44 michelem: judge for yourself: http://docs.openmoko.org/trac/ticket//2309 Dec 16 10:59:47 I prefer that the customer have UX complaints to stability ones Dec 16 11:00:38 michelem: i'm not sure but i suspect that 2.6.32 is as stable as 2.6.29. Dec 16 11:00:49 ok Dec 16 11:01:03 I didn't get whether this fix http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=1d04b142ffeaa15129f046751f1366b0f0614f47 Dec 16 11:01:11 made it into the upstream kernel Dec 16 11:01:34 or at least, "linux-image-2.6.29-openmoko-gta02" Dec 16 11:02:21 michelem: it most probably did, yes. You can check it on a running system with ls /sys/modules/glamo_mci/parameters Dec 16 11:03:08 thx Dec 16 11:03:18 in fact it appears to be on my current system too Dec 16 11:03:32 still the GPS doesn't get fixes in 5 minutes Dec 16 11:03:58 michelem: you can play with the tweaks run-time by echoing the values to the sysfs nodes, the effect is almost immediate. Dec 16 11:04:22 yes, I'm now reading that doc and will try to play around Dec 16 11:04:37 actually, I don't care about GPS other than for the clock Dec 16 11:04:38 michelem: probably you have problems with antenna connector. Dec 16 11:04:54 because after few days of phone off, the clock is reset to y2000 Dec 16 11:05:06 PaulFertser: antenna connector? Dec 16 11:05:20 I have no external antenna. But same problem on both hardware phones Dec 16 11:05:44 michelem: i mean internal connector, but it's strange you have issues on both devices. Dec 16 11:05:54 michelem: how exactly doesn't it work? Dec 16 11:06:31 ntpq -p shows Dec 16 11:06:31 SHM(0) .GPS. 0 l - 16 0 0.000 0.000 0.000 Dec 16 11:06:31 SHM(1) .GPS1. 0 l - 16 0 0.000 0.000 0.000 Dec 16 11:06:56 and if I open NeronGPS it won't get fixes in minutes Dec 16 11:07:20 michelem: no, how exactly gps doesn't work? I mean what exactly you use and how trying to make it work? Dec 16 11:07:37 rebooting, tell you in a sec... Dec 16 11:08:10 there's something I don't get about the environment btw Dec 16 11:08:30 when booting the phone, I see after <3sec the "INIT:" prompt already Dec 16 11:08:42 and in the initial distribution there was no "linux-image" package Dec 16 11:09:10 so when/how/by who is the kernel booted? 3s seems too fast Dec 16 11:11:59 and indeed, even installing linux-image-2.6.34-openmoko-gta02, dmesg still starts "Linux version 2.6.29-rc3-v24" Dec 16 11:13:12 GPS: I just run "/usr/sbin/gpsd -n -F /var/run/gpsd.sock -P /var/run/gpsd.pid /dev/ttySAC1" at boot Dec 16 11:14:01 then run ntpd on it ("server 127.127.28.0 minpoll 4 maxpoll 4" "fudge 127.127.28.0 time1 0.420 refid GPS" etc) and get no time set Dec 16 11:14:30 michelem: kernel is booted by the bootloader. Dec 16 11:14:50 i'm trying to read about that Dec 16 11:15:00 michelem: but when you boot from uSD, most probably you have you BL configured to load kernel from /boot/uImage-GTA02 or something like that. Dec 16 11:15:20 michelem: you should also power on the GPS device by using the corresponding sysnode. Dec 16 11:15:28 and that partition is mounted from the internal flas? Dec 16 11:15:57 michelem: no, /boot is just a directory on SD. It used to be a separate (first) fat partition on uSD for old u-boot versions. Dec 16 11:17:49 I don't find refs to powering it up Dec 16 11:18:29 Jan 1 02:23:16 neo Qtopia: Powering GPS on Dec 16 11:18:43 apparently the app does it already Dec 16 11:18:59 michelem: probably you shouldn't be starting qpe to have a more predictable system? Dec 16 11:19:20 what do you mean? Dec 16 11:19:23 michelem: i mean really, if you use your own gpsd instance, i think you should rather avoid possibilities for other apps to grab the port. Dec 16 11:20:28 I didn't check through the logs before Dec 16 11:20:35 michelem: /sys/bus/platform/devices/neo1973-pm-gps.0/ Dec 16 11:20:41 power_on there iirc Dec 16 11:20:43 Qtopia seems to try to update the clock from GPS already Dec 16 11:31:19 michelem: btw, do you know about the package "omhacks"? Dec 16 11:31:27 michelem: that's what you should use to toggle gps power. Dec 16 11:31:56 michelem: and make sure you disable everything gps-related in qtopia, that way you'll have full control over it, with your own gpsd and omhacks. Dec 16 11:32:35 I tried to install it before but it's only in sid Dec 16 11:32:39 and I run testing Dec 16 11:33:26 michelem: is it really dependent on something that's not in testing? Dec 16 11:34:00 PaulFertser: qtmoko has omhacks but it is not in package management system Dec 16 11:34:13 PaulFertser: they build it a part of qtopia to /opt Dec 16 11:34:20 hmm, it's there, why do I get can't find package then Dec 16 11:34:32 michelem: because it's not in a package :) Dec 16 11:34:36 lindi-: you're good at answering question before they're asked :) Dec 16 11:34:45 it is :) http://packages.debian.org/search?keywords=omhacks&searchon=names&suite=all§ion=all Dec 16 11:34:51 michelem: but not in qtmoko Dec 16 11:35:06 they also omit the manual page Dec 16 11:35:07 I actually run debian Dec 16 11:35:26 michelem: ah Dec 16 11:35:33 michelem: well omhacks is in squeeze Dec 16 11:36:01 michelem: and pkg-fso Dec 16 11:36:14 oh, I actually run stable, not testing. Dec 16 11:36:59 find /opt/qtmoko -name omhacks —> none Dec 16 11:37:18 michelem: ok Dec 16 11:37:40 michelem: you probably want to build omhacks for stable then, it shouldn't have too much dependencies Dec 16 11:38:00 the manual page generation depends on a few new help2man switches though Dec 16 11:38:18 maybe someone can pass me the plain binary? :) Dec 16 11:38:35 or I'll just fetch the deb by hand and dpkg -i -f it Dec 16 11:38:44 michelem: that's not recommended Dec 16 11:39:03 btw, what's with apt-get bitching "N: Ignoring file 'freesmartphone-org' in directory '/etc/apt/sources.list.d/' as it has no filename extension Dec 16 11:39:21 ls /etc/apt/sources.list.d/ —> backports freesmartphone-org Dec 16 11:39:42 michelem: are you sure you are running stable? where did that freesmartphone-org come from? Dec 16 11:39:49 me by hand Dec 16 11:40:09 I'll just move those to sources.list and workaround the pain Dec 16 11:43:29 thanks for all btw :) Dec 16 11:44:09 michelem: you could 1) add deb-src http://ftp.fi.debian.org/debian/ squeeze main Dec 16 11:44:13 michelem: 2) apt-get update Dec 16 11:44:19 michelem: 3) apt-get build-dep omhacks Dec 16 11:44:25 michelem: 4) apt-get --build source omhacks Dec 16 11:44:34 michelem: to rebuild omhacks for lenny Dec 16 13:10:08 ok, GPS takes minutes to get the fix Dec 16 13:10:21 that exceeds my reqs Dec 16 13:11:09 GSM contains timing information (NITZ), and I've seen Gsmd has been replaced with Qtopia's own stack. Anyone knows if/how to get the NITZ info from Qtopia? Dec 16 13:11:30 I can get no info on that Dec 16 13:15:10 michelem1: on my device gps takes ~40 seconds to get fix. Dec 16 13:15:12 michelem1: in qtmoko, nerongps can show gps time. you may use it's code as example, or use nerongps as tool to view gps clock. Dec 16 13:16:01 I'm trying to take the problem from a practical PoV Dec 16 13:16:30 it took me over 5 hours between reading up and trying to track down the problem, and I don't see the end yet Dec 16 13:17:16 also it's hard to debug because there is no feedback/logging or debugging tool for GPS Dec 16 13:17:22 which distribution you using? Dec 16 13:17:24 michelem1: cat /dev/gps? Dec 16 13:17:34 PaulFertser: does it work for you indoor (with windows)? Dec 16 13:17:59 michelem1: indoor it's not supposed to work at all. Dec 16 13:18:04 michelem1: so it depends Dec 16 13:18:31 my garmin can't get fix indoor, so don't expect that from fr Dec 16 13:18:55 michelem1: if i place the device very-very close to the window, near it's lower central part, i get a fix usually. Dec 16 13:19:06 iPhone works indoor :) Dec 16 13:19:18 michelem1: nah, it can't Dec 16 13:19:33 PaulFertser: yeah, that's what I tried in the last attempts. Still no fix in 10' Dec 16 13:19:35 michelem1: gps signal is too weak to reliably pass through. Dec 16 13:19:43 PaulFertser: seriously. It works. Dec 16 13:19:50 my garmin can see 1-2 sats indoor usually, so it can track current position Dec 16 13:19:54 michelem1: btw, you do not need a fix to get current time i'd say. Dec 16 13:19:57 michelem1: if you fetch ephemeris and almanac via gprs you'll get fix faster Dec 16 13:20:00 but can't get fix Dec 16 13:20:01 it's not very precise (50m?) but it gets a position Dec 16 13:20:05 michelem1: and yes, agps helps a lot. Dec 16 13:20:18 michelem1: iphone uses wlan base station ids too? Dec 16 13:20:32 lindi-: I'd like to get it working simple and slow first :) Dec 16 13:20:48 michelem1: but which distro you using? Dec 16 13:20:50 michelem1: i mean your iphone most probably uses agps, so no wonder it performs better. Dec 16 13:20:52 lindi-: that worked with WiFi off and GPRS off Dec 16 13:21:11 michelem1: they are valid for several hours Dec 16 13:21:12 guys don't take it as a neg :) Dec 16 13:21:34 michelem1: yeah, ephemeris last for 2-4 hours. Dec 16 13:21:35 gena4x: debian lenny Dec 16 13:21:51 michelem1: and it could easily cache some wlan info too Dec 16 13:22:02 I'm trying to shoot a very simple problem: Dec 16 13:22:26 this is used on some oil platforms with an RFID reader attached (USB) to track when teams go on mission Dec 16 13:22:56 so there is no WiFi for days/weeks, possibly no GSM, but there is clear sky (with a fair bit of reflection tho) Dec 16 13:23:04 all I want is to get reliable time Dec 16 13:23:15 michelem1: clear sky should provide your ~40 fix time. Dec 16 13:23:19 40s Dec 16 13:24:36 michelem1: why not launch gpsd or whatever you want? Dec 16 13:25:00 gena4x: I do (plus ntpd) but indeed it sets nothing Dec 16 13:25:14 michelem1: add some code? Dec 16 13:25:30 michelem1: indoor tests do not really correlate with the clear sky condition. Dec 16 13:26:03 fr has hard time to get fix 'in car door' too Dec 16 13:28:11 michelem1: basically time is just one more line in NMEA protocol, just read it and that's all? Dec 16 13:33:18 I'm tackling another problem with WiFi at the moment. Dec 16 13:33:35 since updating u-boot eth0 (wifi) is not detected anymore Dec 16 13:36:02 michelem1: which version of u-boot you using now? Dec 16 13:36:35 michelem1: or you updated just environment? Dec 16 13:37:56 gena4x: thanks :) let me locate the problem first, I'll save you some time. Dec 16 13:39:01 I have two phones, it may have happened that I flashed both. Which sucks, because I have the mid-term demo at the customer tomorrow morning :) Dec 16 15:09:48 uhm Dec 16 15:10:00 about the g_ether.host_addr and .dev_addr Dec 16 15:10:24 I guess U-Boot sets those params to the kernel Dec 16 15:10:35 are they actually a static MAC address assignment? Dec 16 15:18:34 g_ether is 'usb gadget ether'. overwise what's 'host addr' and 'dev addr' in wifi? Dec 16 15:36:05 indeed. Dec 16 15:36:29 I don't get why on phone1 wifi is eth0, and on phone2 it's eth1, with no eth0 interface existing Dec 16 15:37:04 I've seen that once or twice with other linux systems (not necessary GNU) Dec 16 15:37:15 I had a machine where the wireless card was wlan1, always Dec 16 15:37:56 that's a pain :) Dec 16 15:38:19 it was weird, it was detected as wlan0 then immediately re-detected as wlan1. not sure why Dec 16 15:38:30 i figured it was just the driver Dec 16 15:38:58 michelem1: I get the g.ether stuff and I use qi Dec 16 15:39:14 http://trac.hackable1.org/trac/ticket/88 Dec 16 15:39:15 4 lines on boot saying "I don't know what this parameter is" Dec 16 15:39:43 what surprises me is that both Qi and the OS image is 1:1 same Dec 16 15:41:53 there's some renaming mechanism that assigns same ethX to a particular mac addr Dec 16 16:01:07 so by the way Dec 16 16:01:23 concerning the GPS problem above: it works outside Dec 16 16:10:13 michelem1: external antenna might be what you want Dec 16 16:10:23 lucky you michelem1. Mine used to work w/ SHR but doesn't w/ QtMoko Dec 16 16:10:26 never gets a fix Dec 16 16:13:56 :) Dec 16 16:17:37 40'' is still too long for ntpd tho Dec 16 16:17:56 would ntpdate with the same trick (magic IP) work from GPS? Dec 16 16:18:19 I could run that after a minute from boot Dec 16 16:19:11 michelem1: why are you booting it so often? Dec 16 16:19:37 2-4 times a day Dec 16 16:19:47 yep but why? Dec 16 16:20:03 saves battery and saves me the hassle of tuning and dealing with power management Dec 16 16:20:32 lindi-: I get your wondering. It's not used as a phone, just as a portable time tracking machine Dec 16 16:22:01 michelem1: sure but why not keep it running 24/7? Dec 16 16:22:11 saves battery and saves me the hassle of tuning and dealing with power management Dec 16 16:22:36 Well if you can get it on a usb plug, that works, but then it's...not...mobile. Dec 16 16:22:40 :) Dec 16 16:22:59 michelem1: ntpd that is restarted 4 times a day sounds odd :) Dec 16 16:23:09 michelem1: if you want accurate time you need to let it stabilize for hours Dec 16 16:23:31 I don't need accurate time, just seconds-accurate Dec 16 16:23:39 michelem1: RTC should provide that? Dec 16 16:23:45 the problem is the hw clock of the phone is real bad Dec 16 16:23:53 michelem1: you can compensate Dec 16 16:24:18 lindi-: I've seen it slacks off pretty bad when the phone is off (one minute every few days?) and on one of the phones it just resets Dec 16 16:24:46 michelem1: yes if you remove the battery it resets Dec 16 16:26:37 michelem1: freerunner resumes now pretty well Dec 16 16:26:59 michelem1: and eats 7-10 ma in suspend even with GSM on Dec 16 16:27:12 the question is, why? Dec 16 16:27:14 michelem1: so no reason to power it down Dec 16 16:27:22 just suspend Dec 16 16:27:56 I'll check that out in the future Dec 16 16:28:20 low prio now, it don't carry significant value in their use cases Dec 16 16:28:32 michelem1: second thing, you can replace backup battery with capacitor (have you read that in community-ml?) and it will keep time even if you replacing battery Dec 16 16:29:44 gena4x: is that an Built-to-order option at OM? Dec 16 16:30:01 DIY fix Dec 16 16:30:17 ok, so thanks but no thanks :) Dec 16 16:31:07 but as long as you battery charged and inserted, it should keep you time anyway without problems Dec 16 16:31:54 if it has systematic drift, it should be corrected by debian's clock scripts Dec 16 16:35:10 register kaunhain nicky.gurbani@gmail.com Dec 16 16:35:56 ads\ Dec 16 16:37:55 gena2x: haha, debian's clock scripts, LOL Dec 16 16:38:58 those scripts are the most common cause of RTC severely skewing during power down Dec 16 16:41:44 btw, I assume in sleep mode whatever scripts/ntp shall not run anyways Dec 16 16:43:56 DocScrutinizer51: whoose scripts purpose is to correct systematic drift only, so they can't harm more than that. Dec 16 16:44:40 nope Dec 16 16:44:48 DocScrutinizer: and somehow i think most drift in rpc in computers is really systematic Dec 16 16:45:00 s/rpc/rtc/ Dec 16 16:45:00 gena2x meant: DocScrutinizer: and somehow i think most drift in rtc in computers is really systematic Dec 16 16:45:18 they cause a massively wrong drift compensation in /etc/adjtime Dec 16 16:45:48 adjust and set chattr +i? Dec 16 16:46:26 as they write back a more often than not incorrect szstime to hwclock, on shutdown Dec 16 16:46:49 gena2x: better fix the scripts Dec 16 16:47:23 ok, i never really debug them to great details, just read documentation. Dec 16 16:48:31 kill the crappy /etc/rcN/K42hwclock Dec 16 16:48:57 my time is ok on all computers even without ntp Dec 16 16:49:24 including freerunner Dec 16 16:49:52 and replace that by a cron job calling netdate&&hwclock --szstohc Dec 16 16:51:24 the debian scripts are made for always-online servers etc Dec 16 16:51:43 not for mobile device with random connectivity Dec 16 16:52:18 i am using it for 10 years on any kind of computers Dec 16 16:52:45 i think this piece is not changing for a while Dec 16 16:53:06 ok, may be not really 10, but 8 Dec 16 16:54:36 and really i do not want to depend on network (or what is netdate?) instead of rtc Dec 16 20:04:30 the point is: if you do a `hwclock --systohc` in shutdown, then you MUST be on network, otherwise odds are your systemclock is more off than the RTC, and this will give an unjustified adjtime punishment to RTC, whic next time you boot makes RTC getting "corrected" to a massively offset time, and when you then adjust it, the adjtime multiplier get calculated based even worse assumptions than last time Dec 16 20:04:51 It's basically even a bit more complex still, but that's the storyline Dec 16 20:06:12 while netdate&&hwclock --systohc, done by a cronjob or caled from ifup, is NOT depending on network actually avalable. It just *tries* if it is, and then adjusts RTC to a *correct* time **** ENDING LOGGING AT Fri Dec 17 02:59:59 2010