Nick <openmoko-commun...@njw.me.uk> wrote: > I haven't been using my phone much recently, but it's always been > reasonably reliable when I have. Today I turned it on, and all day > it has just said "searching for network". > [...] > I'm not sure where to go or what to look for to debug this. I've > restarted the phone multiple times without success.
What modem firmware version is this? > Any advice? Since the GSM modem is no longer an impenetrable black box, you could try debugging the apparently misbehaving modem using standard Free Software debugging methods: study the source and the documentation, and make use of the modem debug interface accessible via the headset jack. Start by taking QtMoko high-level software out of the equation and talking AT commands directly to the modem: http://wiki.openmoko.org/wiki/Manually_using_GSM Try the AT commands shown on that wiki page, and tell us the results. That right there might spot an issue. If the modem behavior at the AT command level is that of failing to register for no good reason, the next debugging step would be to look at the debug trace output. Get a debug cable, if you haven't already: http://bb.osmocom.org/trac/wiki/Hardware/SerialCable Put the debug serial channel on the headset jack with this command: echo 1 > /sys/bus/platform/devices/gta02-pm-gsm.0/download Make sure the audio is routed to your Neo's earpiece speaker and not the loudspeaker, to avoid damaging the latter or your ears. Plug the debug serial cable into the headset jack, and plug the other end into your PC or other host computer running GNU/Linux or some other Unix. Run the rvtdump utility from the FreeCalypso suite, e.g., rvtdump -l logfile /dev/ttyUSB0 With the serial cable connected, rvtdump running on the other end, and 1 written into that /sys/.../download node, power up the modem. You should get a bunch of debug output; tell us what you see. (The -l option will save this output into a log file, with a timestamp prepended to each line.) You should get more interested debug output when you issue AT+CFUN=1 and AT+COPS commands which start the actual GSM operation; tell us what you see at those steps as well. If the above steps don't reveal anything amiss, next debugging steps would be to examine firmware state variables in memory with fc-tmsh and/or send special commands (called "system primitives", enabling more verbose traces and other debug functions) to the running fw with g23sh, both of which are FreeCalypso tools operating via the debug interface (called RVTMUX) presented on that headset jack. If you are running a firmware version such as leo2moko for which we have a linker map file, we can examine every single variable that fw maintains, and the "system primitives" provided by the GPF component (Condat's Generic Protocol stack Framework) allows us to capture and examine every primitive exchanged between GSM protocol stack layers: e.g., we could see the exchange between L1 and L2, or between RR and MM, etc. But let's see if you can manage the simpler steps above before I go into details of what you should peek and poke with fc-tmsh and g23sh tools - getting the simpler rvtdump working would be a prerequisite for the more advanced tools anyway. HTH, SF _______________________________________________ Openmoko community mailing list firstname.lastname@example.org http://lists.openmoko.org/mailman/listinfo/community