[RFC] gsmd on HTC Magician

pHilipp Zabel philipp.zabel at gmail.com
Sat Feb 17 13:40:04 CET 2007

On 2/17/07, Harald Welte <laforge at openmoko.org> wrote:
> 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.

I'm quite aware of  that, too. But I very much prefer a construction site with
a clean design to the somewhat-working hacks I've encountered so far :)

> The (ordered) list of priorities is
> * debug current random crashes

I didn't encounter any yet, but then again I only used libgsmd-tool
so far. The UI doesn't run too well on 240x320, currently.

> * 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)

Sounds good.

> > - 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.

Ok, then the platform plugin initialization could set the ready value to 0 / 1,
depending on whether the interpreter is expected to be ready when gsmd
starts up on the given platform.

> > - 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.

I'm looking forward to it. I have no idea about TS07.10 multiplexing -
is there some documentation about how the kernel bits work
together, already?
So far I don't use any multiplexing at all. The GPRS data channel is
connected directly to a second UART, and wince on those devices
doesn't use multiplexing either.

+CMUX: (1),(0),(1-5),(10-100),(1-255),(0-100),(2-255),(1-255),(1-7)


So I tried and sent, using the default values from GSM 07.07:


Next thing I get is:

\x2\x2\x16AT-Command Interpreter ready\r\n\x2

And the initialization starts again...

> > - 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.

I see. will do.


More information about the gsmd-devel mailing list