View source for User:Emdete

From Openmoko

Jump to: navigation, search

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Administrators.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

Return to User:Emdete.

Personal tools

I got my neo1973 gta01 some month ago now and want to share my expiriences with it. Because the gui at that point did not work at all and i was interested to develop an own gui anyway i deinstalled all gui stuff with

ipkg remove -recursive <all x11 libs>

(i don't remember which one and can't take a look because they are gone on my neo right now). Now i started to check all low-level functionality i thought i would need for my application with simple scripts to start them and python programs to test them (see the edits i made on the pages "manually using [GSM|GPRS|GPS|BT]" here in the wiki). With that basis i was able to do longrunning tests. here is the outcome:

unit software in use expirience hints
GPS gsmd did not work reliable. clients can't determine the state. i found no documentation when to issue which call (i.e. if you connect but don't get called for pin, when do you call to register into a network). is not able to decode special sms (like initiating sms for mms). sample client libgsmd-tool coredumps all the way. does not use (the glib recommended way) of using dbus. manually playing around shows something that looks like a kernel bug: linux freezes entirely. this is not a bug but a flow problem. switching on/off the modem toggles also a serial device where the kernel loggs. if there is flow control enabled the kernel waits for 'RTS' which never comes without debug board. issue the command `stty -F /dev/ttySAC0 -crtscts` before tampering around with "/sys/bus/ platform/devices/ gta01-pm-gsm.0/power_on".
GPRS pppd works well if chatscript take over everythink (like pin entry). same problems for auto-detect as mentioned with pan apply. using the options lcp-echo-interval allowed to keep a connection open over days without any problems.
GPS gllin for long running gllin some option must be changed (like named pipe and logfile output) but i never got a reliable fix for a ling time. gllin seems to have a memory leak or the like (after running for several hours cpu usage raised from about 2% to 20%). switching off logging (option -nmea) and writing to the named pipe (-np) allowed a long running gllin - otherwise the rootfs was filled up fast.
PM sys fs everything here is not documented very well. battemp show -6 (which should be in celsius), chgcur says 17213 (which would be 17A current!) while battvol is decreasing. i often encounter a neo that switches off even if it's connected to usb because the charing does not start.
BT PAN bluez-utils using internet over pan works fine while i did not figure out how to auto-detect the best way into the inter for the neo. i would prefere a fallback-rule like use usb, pan, gprs. libc makes some trouble when changing the nameserver, running processes will use a old one.
FS jffs2 if the filesystem runs full you are doomed. jffs2 is not able to delete files after that. you have to flash your neo again. i moved my logfiles, database and the like to (ext2) sd-card. i keep rootfs at around 50%.

conclusion: openmoko concentrates on nice gui stuff but the base is missing. i found not one longrunning testcase for one of the bases services of phone functionality. effect of this is the state these services are currently in.