Firmware bring-up status

[Spacefalcon the Outlaw]

Status update: I fixed the AT+CFUN breakage (the bug that caused
AT+CFUN=1 or AT+CFUN=4 to return ERROR and not proceed further), and
now these initial commands succeed.  After successfully executing
AT+CFUN=1 or AT+CFUN=4, I can execute AT+CNUM and/or AT+CIMI, and the
firmware successfully responds with my test SIM's phone number and
IMSI.  This observation means that our gcc-built G23M protocol stack
that came from TCS3.2 and never ran on the Calypso before is functional
enough to communicate with the SIM correctly.  Good news indeed.

But this is where the joy ends so far.  The next step is to bring the
GSM radio up, and it currently fails.  The standard AT command sequence
to bring the GTA02 Calypso modem's radio up with the stable mokoN and
leo2moko firmwares is AT+CFUN=1 followed by AT+COPS; if one is using a
SIM that doesn't require a PIN, both commands succeed on the first try
with leo2moko.  With our own gcc-built fw using the GSM stack from
TCS3.2, AT+CFUN=1 now succeeds, but AT+COPS returns ERROR.  (To give
credit where it's due, it does not crash under that test, just returns
ERROR. :)

The other issue we have, the one that seems to involve something weird
with the hardware as it happens across power cycles, is still there:
if I power the modem off
(echo 0 > /sys/bus/platform/devices/gta02-pm-gsm.0/power_on), wait a
good while (e.g., go read some article on the web), then power it back
on (echo 1 into the same sysfs pseudo-file), the firmware boots
successfully and behaves as above: SIM bring-up works, radio bring-up
doesn't.  However, if the time between powering the modem off and
powering it back on is only a few seconds, then the firmware crashes
on boot; the symptom of the crash visible in the RVTMUX output is that
the GPF partition memory allocation mechanism goes awry.

To make matters even more unpleasant, I confirmed earlier today that
Calypso JTAG signals are absolutely NOT accessible on Openmoko
devices, see:

http://lists.openmoko.org/pipermail/hardware/2015-May/001364.html
http://lists.openmoko.org/pipermail/hardware/2015-May/001365.html

:-(

I'm thinking about instrumenting the firmware so I can debug exactly
what happens in the fw when this boot time crash occurs; I've got
ideas on how to do it, but it's late hour and I'm tired, so I won't
try to explain it right now - maybe later.

Hasta la Victoria, Siempre,
SF