[FSO] add QCT msm7* modem support

Stefan Schmidt stefan at openmoko.org
Sat Nov 22 17:01:40 CET 2008


On Sat, 2008-11-22 at 11:31, Lukas Gorris wrote:
> Everyone feel free to add infos here. I will do as
> > well over the next days:
> > http://www.freesmartphone.org/index.php/HW_Platforms
> I will update the msm section there.

Great, thanks.

> >> msm7200 devices (for gsm networks): (htc-msm branch)
> >> kaiser (aka HTC TyTn II; buildable machine type in OE), polaris (aka
> >> HTC Touch Cruise; also in OE), nike, neon, sedna, wings, ...
> >
> > Are there plans to have machine support for more devices in OE?
> I will sit down and add some more. atm there are only kaiser and
> polaris with msm7200 chipset. I'll try adding everything we have a
> machine type and working git for. The older htc machines could use
> some updating I think.

How different are these machines? Do you have some multimachine kernel? Or one
kernel per machine?

For EZX we have one kernel runnng on all devices. That way we only have one
kernel recipe in OE. Mickey is working on some re-vamp. The idea is to have
separate machine name (ezx-a780, ezx-a1200,..) which mostly depend on an -inc
file having the logic inside. Inmost cases different images will also run on
oither machine, but sometimes you have to care about stuff like buttons, TS,
etc. Also different frameword conf files.

> > So far we don't have any devices with cdma on our agenda. This is not very
> > likely driven by us  as we live in GSM countries. Not sure what mickeys opinion
> > is on this, but if anybody would came up with clean support for CDMA in FSO we
> > could discuss this.
> I see no problem about no OM devs living in CDMA countries. I will
> talk to people who have the devices and live in cdma areas.

Sure, we would welcome support for it.

> >>... All of the AT commands go through /dev/smd0 . Then there
> >> is /dev/smd1 for gprs data and /dev/smd7 for the GPS NMEA data, etc
> >> ...
> >
> > So that would be the interfaces FSO would mostly be interested in.
> >
> > As long as the GPS device provides NMEA over a char device that is easy.
> Yes it is normal NMEA dataflow through the char devices as are AT and
> the other relevant channels.

Good. Should not be that hard to integrate then.

> > Modem is, as always, a bit more difficult. Does the modem support standard TS 07.10
> > muxer support on these devices?
> Afaik we don't have any muxing here because all the data goes through
> different serial channels. That was also the first thing mickey asked
> about the msm7* modems. I don't know exactly how the 3g stuff works,
> because in angstrom I only use gprs on the kaiser. Never tried the
> other data connections. But it must be very similar.

So it is:
/dev/smd0 for AT commands. (Any restriction, or all all comand allowed?)
/dev/smd1 for GPRS
/dev/smd7 for GPS

What it about about /dev/smd{2,3,4,5,6} ? does they exist? If yes it could good
be that we really need to userspace muxer for this as it is all handled inside
the kernel. We have a similar setup for EZX. The kernel driver already does the
multiplexing, a heavily modified variant of TS07.10 from Moto, and just exports
the char devices to userspace.

> > What kind of propriatary AT commands do they
> > support e.g. for call in progress indication?
> I think calling is 100% standard. (at least when you have the phone
> init. from wince since I don't know about proprietary commands in the
> init sequences). You just run ATD and optionally set speaker/earpiece
> mode etc. That works for me in angstrom when I use minicom.

How do you set the speaker or earpiece mode? Is this over alsa mixer controls or
AT commands?

> > Afterwards working together with you guys to help you and integrate your stuff.
> That would be nice. I don't know much about programming. I have some
> old revision of the framework tree on my hard driver with msm7200
> modem added as a copy of the neptune modem where I ripped out some
> things.

That is already a start. If you get to the point where frameword talks to the
device nodes and goes through all the init fine we can loo k at your patch and
help you to get it into good shape.

> > OK, that sounds not to bad. I would suggest something like the following to slay
> > the monster:
> >
> > * Good development setup
> > ** framework-console-image with cli-framework mdbus, mickeyterm, etc
> >
> Already have one. For the kaiser and polaris, just build a
> framework-console-image for machine htckaiser or htcpolaris.


> btw I only have got the kaiser.

As the modem are pretty similar one device is already enough to get started. I
would not worry about tis. Once you have done some basics it is very likely that
other people jump on.
> A whole different aspect here, not really radio related: There are
> problems with X and the framebuffer driver of the htc msm devices
> (msm_fb). Somehow only one frame gets drawn. You don't get further
> than the standard checkered X wallpaper and the cursor pixmap.
> Sometimes not even the wallpaper gets drawn entirely. I think it is
> some refresh problem. The android gui which accesses the framebuffer
> more directly works fine. Any hints appreaciated.

Hmm, the first thing I would to is to look at what kind of ioctl() the Android
UI is using and comapre it to what X is doing.

> > * Seek as much information about the modem as possible.
> > ** Datasheets would be great
> > ** AT command references
> > ** Used muxer protocols
> > ** Special handling for powermanagement, etc
> Will put some first bits of info I found. Here is the "V0 init
> sequence". There are more of these, only found the v0 on my hd.
> ATZE0S0=0Q0V0X3&C1&D1|+GTKC=2
> +CMEE=1
> +CRC=1
> +CR=1
> +CREG=1
> +CMGF=0
> +CSSN=0,1
> +CLIP=1
> +COLP=0
> +CCWA=1
> +CMUT=0
> +CLIR=0
> +CNMI=1,2,2,2,0
> +CGREG=1
> +CUSD=1
> +CPPP=1|@v

> @HTCSAP=1|

The three above are for sure HTC specific. Mickey, can you comment on the

> # Send the modem init and access point name
> /bin/echo -e "AT+CGDCONT=1,\"IP\",\"$1\",\"\",0,0\r" > /dev/smd0

Mickey, normal?

> # Dial up the connection
> /bin/echo -e 'ATD*99***1#\r' > /dev/smd0


> As you can see we send the AT commands to smd0 and pppd is ran on smd1
> where the gprs data flows.

ok, great

We should save this kind of infos in some central place. Feel free to add a new
wiki site about it.

Thanks a lot for stepping up and bringing the msm7* support forward in FSO.

Stefan Schmidt

More information about the devel mailing list