Dear Alex, first off, congrats for getting that far! Seems you have made amazing progress.
> There are a few important differences that meant I needed to change > gsm0710muxd though. Firstly, in minimal functionality (AT+CFUN=0) mode, > the module responds with "ERROR" to almost every command except AT+CFUN > and AT+CMUX (and one or two info querying commands). Right. There are more modems behaving like that. > For now I've just > made gsm0710muxd ignore error responses to "ATZ" and "ATE0" as there's > no harm in issueing them, they just won't do anything. It also responds > with "*MRDY: 1" instead of "OK" to the AT+CFUN=0 command, as I think > issueing that also resets the chip. The proprietary, unsolicited *MRDY > responses indicate the module status, like "module ready", "emergency > call mode ready", "all AT commands ready", "sim card inserted" and so > forth. I've made gsm0710muxd treat this the same as "OK" as it was > timing out waiting for an "OK" in response to AT+CFUN=0. Ok. > Secondly there is no reset signal, so I've just removed the failure > checks to write to the $pm_base/reset file. Right. > > Thirdly and seemingly brokenly, it will only accept an AT+CMUX command > that specifies 115200 baud, however it continues to talk to the main CPU > at 460800 baud. Uh oh :) > In fact as far as I can tell there's no way to change > the baud, AT+IFR seems to accept most baud rates, but again it just > continues to use 460800. To work around this I've added an extra > command-line option so you can change the baud rate sent in the CMUX > command independently of what the serial port is opened at. Ok. > Fourthly, the GSM module has some sort of power saving feature that will > put the module to sleep when no commands are being issued. While in > this sleep state characters sent to the serial port are dropped. When > you want to send a command you have to pull a signal connected to one of > the CPU's GPIOs high, write the command and then pull it low again to > let it go back to sleep. Currently I'm just exposing this signal from > the kernel as /sys/devices/platform/palmt650-pm-gsm/wake and having > gsm0710muxd toggle it. I'm not really sure whether this is a decent way > of doing things. It's only necessary to do the wake signals once > AT+CFUN=1 has been issued, but it doesn't hurt to also do it in > AT+CFUN=0 mode. That's interesting (and a bit disgusting). > Finally, I got my Treo 650 second-hand and sometime in its past life it > must have been locked to a network. The locking seems to be flashed > into the GSM modules firmware. What this means is that after powering > on with AT+CFUN=1, unless a SIM for particular the network it is locked > to is inserted, the phone will connect to the network but it will refuse > to do anything much except make emergency calls. To unlock it you enter > an eight-digit "subsidy unlock code" also called a "PH-NET PIN" or > "network personalisation PIN" with AT+CPIN. Until you've done that many > commands will return an error like this: > > AT+CRC=1 > +CME ERROR: Network personalisation PIN required > > AT+CPIN? > +CPIN: PH-NET PIN > > AT+CPIN="12345678" > OK > +CREG: 2 > +CGREG: 2 > +CREG: 1 > +CGREG: 3 > +CGREG: 1 > > AT+CRC=1 > OK > > The subsidy unlock pin is cleared as soon as the module is reset so you > have to do it every time you issue AT+CFUN=1 to power it up. When it is > first entered Palm OS remembers the pin in the (main CPU's) flash and > automatically issues AT+CPIN for you from that point on. In fact this > is where I got the pin for my Treo from as it was unlocked before I > bought it. This gave me some confusion for a long time when trying to > make calls from Linux with minicom. ;-) > > How do you think the subsidy unlock pin could be handled with > frameworkd? I guess at the moment a client application could enter it > with org.freesmartphone.GSM.SIM's SendAuthCode(), assuming that just > issues AT+CPIN="whatever", but it would be nicer to just be able to put > the code in a config file somehow and have frameworkd do it itself > whenever it powers the phone on. As a modem class in the frameworkd you have the power to override everything as necessary. You can either add additional init commands, or extend dbus commands, or implement them in a completely different -- modem specific -- way. > So I've now got gsm0710muxd working reasonably with mickeyterm. Here is > a patch  and verbose log output of starting the daemon . I'll now > start looking at frameworkd. Amazing, thanks for the heads up. I'll need some time to look over that patch, to see how we can integrate your changes in the best way. Cheers, Mickey. -- :M: