Re: Some weird new GOBI card

[Dan Williams <dcbw redhat com>]

On Thu, 2009-11-26 at 07:39 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > Pretty straight forward and normal stuff. Even works fine with my
> > > prototype GOBI loader application that uses libusb directly instead of
> > > bothering with the kernel driver and the TTY layer. However my other
> > > card looks like this:
> > 
> > Got something against qcserial or the tty layer? :)
> 
> I have nothing against the TTY layer per se, but attaching two bulk
> endpoints to the TTY layer while you could just pipe the firmware
> loading magic over it directly seems overhead. Not that it matters. I
> was just playing with the protocol itself and messing with the USB
> endpoints directly ;)
> 
> My other problem is that I really wanna get proper devtype support for
> serial ports into the kernel. I have fixed most of the network devices
> now and next is the TTY stuff.
> 
> > Is this an HP 0x241d device?
> 
> The mysterious card that I have is not an HP card, but could be well
> that newer HP cards are similar. Maybe this is just 2nd generation GOBI
> card. If I knew that they sell these cards I would tell you, but I have
> actually no idea, it just ended up on my desk with GOBI written on it.
> 
> > I've got Windows USB traces of the HP connection manager talking to my
> > Gobi but haven't ever had time to dig into them.  It appears to use the
> > standard Qualcomm PPP-style framing for talking to the card.  I'd love
> > to be able to activate the cdc-ether-like functionality of the device
> > but of course nobody knows how.  Perhaps you can get Qualcomm to tell us
> > how to talk to it?
> 
> So far what I have been able to tell is that it involves QMI (and maybe
> QMUX) for their control path and the rest is some form of Ethernet

Yup; it's pretty much QMI all the way.  You can usually tell by the
PPP-style framing that it uses.  The firmware has references to CDC-EEM
and RMNET but I haven't found a way to expose those yet; the android
sources have some rmnet stuff but rmnet is really just wrapped ethernet.
I simply haven't sat down to look at the USB traces of a connect
sequence yet from my Gobi 1000 to try and figure out what's going on.

Beyond that, we'd still need to reverse-engineer the QMI message IDs and
structures.  The Windows drivers don't really use AT commands at all and
appear to prefer straight QMI.

bitpim might be interesting here too, since it has some knowledge of the
Qualcomm diag mode (which I assume to be related to QMI) but given that
it's all python the frame parsing code is completely unfollowable.

> framing. Also my HP card under Windows will not load the firmware. Seems
> that only works with AT&T account or I am too stupid to get this up and
> running. Otherwise I have USB protocol analyzer hardware that I could
> stick between it to get some proper traces.

Eh, depends; if you get a good USB tracer on Windows you can usually get
between the connection manager and the card itself.

> And yes, I am trying to get Qualcomm to do the right thing and open
> source this beast. We need the full GPRS node handling for signal
> strength and roaming indicators. Having one TTY is just not enough for
> proper driving this card.

Don't forget CDMA; not sure what the difference between their CDMA and
GSM firmware is, but it's likely just different QMI command indices and
structures.  Will be a great day when anything can get pried out of
them.

> Also my guess is that what we have in the Palm Pre or the Android/G1
> phones is actually similar to what we have in the GOBI card. For all I
> know all older Qualcomm based cards are similar, but most vendors are
> hiding the Qualcomm specific QMI interfaces.

Perhaps; but I've looked through what Android sources there are and the
data setup is pretty simple AFAICT.  I don't think we have much access
to what the RIL is actually pushing down to the chipset, though there is
a bit of stuff in the "rmnet" driver and arch/msm that apparently talks
QMUX and WMI (no, not Windows, but probably Wireless).  The problem is
that all these pieces don't seem to fit together yet.

The Palm Pre sources (for the CDMA part) aren't very illuminating
either; it looks like they just have a tty open to the device and push
down AT commands.  The bits that do signal strength while connected
probably aren't open-sourced, or it's gotten through some other bus or
GPIO or whatever.  Maybe further firmware images have leaked it out; the
one I saw was the first update after release.  Or if somebody can get a
filesystem for the GSM Pre that just got released, that would be
interesting to look through.

Dan