[RFC] gsmd on HTC Magician

Harald Welte laforge at openmoko.org
Sat Feb 17 00:23:01 CET 2007

On Fri, Feb 16, 2007 at 08:09:26PM +0100, Philipp Zabel wrote:
> Hi!
> I tried to run gsmd on a HTC Magician, which (like Blueangel, Himalaya,
> Alpine and Apache) is built around a TI Calypso GSM/GPRS chip, but with
> a HTC-specific firmware.

First of all, thanks for trying gsmd on a differrent device :)  I'm more
than aware that it's currently a really large construction site, but I'm
constantly getting distracted by way too many other (moko-related) tasks
to finish it.

The (ordered) list of priorities is

* debug current random crashes
* add support for SIM phonebook handling
* add support for SMS send/receive/store
* add support for oparator selection
* add support for GPRS setup/teardown (once kernel ts07.10 gets in shape)
* add a nice dbus interface (as optional plugin or compile option)

> I have attached the patch I used because I have some questions regarding
> HTC specifics that look like they don't fit into a vendor plugin.

I'd rather have the vendor plugin mechanism extended somewhat.  In the
end, we'll probably need something like 

* chipset plugin (something like the current vendor plugin)
* platform plugin (something like 'neo1973' that defines specifics
  of a particular system)

> - I introduced the "ready" variable to stop the atcmd_select_cb from
>   is seen. Also I commented out the call to "gsmd_initsettings" in
>   gsmd.c. We only turn on power to the phone in the kernel when the tty
>   is opened, so it takes a while for the interpreter to be ready. The
>   unpatched gsmd would run the complete init sequence twice in this
>   case. Is there a sane way for gsmd to support this behaviour?

I'd rather have it as part of some context structure than a global
variable.  Apart from that, it's fine.

> - The HTC firmware envelopes all serial communication in frames which
>   start with 0x02 0x02 0x16, followed by the data, followed by 0x02.
>   0x16 indicates the AT command channel, there are other channels for
>   debug messages and configuration of the GSM chip.
>   I therefore added ti_htc_filter which filters the incoming AT channel
>   out of the incoming communication (and drops the rest) and I added
>   the envelope for outgoing data.

>   Will there be a facility to plug in this kind of manipulation of the
>   serial stream or should this be done somewhere else?

Well, one possibility could be to make this one plugin to the in-kernel
gsm [de]multiplex that I'm currently writing for TS07.10.  How does the
HTC do this when you switch into multiplex mode?  Are all DLC's of the
multiplex within this single 'at command channel'?  If yes, then the
'htc envelope' removal will definitely need to be done in the kernel.

Unfortunataly there's little progress in my ts07.10 code, but its Nr. 1
priority for next week.

> - The HTC firmware does not have support for +CTZR. Because of this
>   the AT+CTZR=1 in the default init sequence produces an ERROR which
>   somehow causes the init sequence not to complete. At least the vendor
>   specific init commands are never called unless I comment out AT+CTZR.
>   Is this expected behaviour?
> Also the HTC firmware in my device only supports the parameters 0,1,2
> for the call progress indication command (AT%CPI). I have no idea what
> those parameters mean, is this documented somewhere or chipset specific?

It is documented, but I cannot releese that documentation.  Nonetheless,
it's something completely unimportant, so we can just get rid of it.

In the end, I would like to see a config file to which user-specified
additional init strings can be added.  That would be a good place to put
this.  So until then, please submit a patch to just completely remove
that line.

- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
Software for the world's first truly open Free Software mobile phone

More information about the gsmd-devel mailing list