/gsm/com/rfcap: tri-band GSM modem believes itself to be quad-band

[Michael Spacefalcon]

Hello Om community,

In the course of hacking TI GSM firmwares, I have come across something
that some of you may find interesting, or might even have some insight
into.

We all know that our good familiar Neo Freerunner (GTA02) was made in
two versions: one with 900/1800/1900 MHz bands, the other with
850/1800/1900 MHz instead.  The hardware difference is one RF SAW
filter part populated differently on the same PCB; see this picture:

http://wiki.openmoko.org/wiki/File:Gta02a6_comms_chips_under_shield.JPG

The SAW filters for the GSM downlink Rx path are the 3 little buggers
near the upper right corner, immediately adjacent to the shiny metallic
component which is the antenna switch.  There is one Rx SAW filter for
each of the 3 supported bands: one for 1800 MHz (both GTA02 versions),
one for 1900 MHz (ditto), and one populated for either 850 or 900 MHz.
(*I think* the topmost one out of the 3 in that picture is the one
responsible for the 850 vs. 900 MHz difference, but please double-check
that before attempting any surgery on your Neo!)

Well, here is the part which will surely surprise at least some of you:
the standard firmware for the GTA01/02 modem (which is the same for
all versions, both GTA01 and GTA02) does not actually know which 3
frequency bands are supported by the device it runs on!  And no, it
does not auto-detect either: there is no way (short of ESP) for any
firmware running on the Calypso/Iota/Rita chipset to divine what kind
of SAW filter sits between that chipset and the antenna.

Instead, as strange as it may sound, the modem (at least when running
the standard mokoN firmware, see below) believes itself to be quad-
band!

In TI's universe, the "standard" way to "teach" a GSM device (phone or
modem) which GSM frequency bands it supports is *not* to hard-code
that knowledge in the firmware at compile time; instead this property
is stored in a configuration file named /gsm/com/rfcap in the GSM
device file system.  Yes, TI-based GSM devices all use a flash file
system with a very UNIX-like "look and feel", including UNIX-style
pathnames; see my write-up:

https://bitbucket.org/falconian/freecalypso-sw/src/1852900ce9ea4ac52d4648f7d9ca46897eb3640b/doc/TIFFS?at=default

Like most files in TI's GSM FFS, /gsm/com/rfcap is a binary file, not
ASCII.  It is a file of exactly 16 bytes, and although I haven't found
a formal document describing its format in plain English, we can study
the code that reads this file and acts upon its content:

http://scottn.us/downloads/peek/TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src/g23m-gsm/rr/rr_csf.c

The 16-byte file is being read into a variable of type EF_RFCAP, which
is defined here:

http://scottn.us/downloads/peek/TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src/g23m/condat/com/include/pcm.h

Lines 442 through 460 (inclusive) give the structure definition, which
is followed by the definitions for the bit fields in each byte.

And here is what this /gsm/com/rfcap file contains on a standard GTA02
modem, as revealed by a TIFFS parsing tool such as the mpffs-tools-r1
package I released last summer:

00 1F 41 14 00 00 00 00  50 00 00 A5 05 00 C0 00

Decoding the meaning of the rest of the bytes is left as an exercise
for the reader, but I draw your attention to the 2nd byte, which is 1F.
This byte indicates which RF bands are physically supported by the MS
(mobile station) hardware, and 1F means quad-band, i.e., all 4 of 850,
900, 1800 and 1900 MHz.  Thus even though my trusty GTA02 is only
900/1800/1900 MHz tri-band in reality, it believes itself to be
quad-band!

Digging some more, one finds that the 16 bytes quoted above appear in
the moko10 and moko11 fw images (convert them from *.m0 to plain binary
with the mokosrec2bin.c utility I wrote almost a year ago, then do the
"binary grep" with the memmem() C library function), and further
analysis reveals that these "standard" firmwares unconditionally
overwrite the /gsm/com/rfcap file in FFS with the hard-coded "string"
of bytes on every boot.  To convince yourself of the latter fact, take
a GTA02 modem with moko11 in it, change the rfcap file in FFS to
something else, reboot the modem normally, and observe that the rfcap
file will be reverted back to the 16 bytes shown above, claiming to be
a quad-band GSM device.

My leo2moko firmware does not contain this rfcap-resetting "feature":
it does not automatically overwrite the rfcap file with anything, and
uses whatever settings happen to be written in the FFS (the modem's
flash file system).  At the present, there is no practical difference:
if your modem ever ran moko10 or moko11 prior to being flashed with
leo2moko, the content of the /gsm/com/rfcap file in FFS will be what
moko10/11 wrote into it the last time it booted, which is the hard-
coded "I am quad-band" value.

But I wonder - and this is really the main reason for this lengthy
post of mine - is it really a good idea for a tri-band GSM modem to
believe itself to be quad-band?  There are two potential problems I
can think of:

1. The modem will waste some time scanning frequencies which it cannot
   receive because of the "wrong" SAW filter standing in the way.

2. Potentially more serious: suppose you are in a geographic region
   with 850/1900 MHz GSM coverage, and your FR is the (much more
   common) 900+etc version (my situation), or vice-versa, you are in
   the 900/1800 MHz lands (EU etc), but have an 850+etc Neo FR.  If
   the FR advertises itself to the network as supporting all 4 bands,
   then there is at least a theoretically conceivable possibility of
   the network then directing it to a low ARFCN which it cannot
   receive, causing the phone to not work "for no good reason".  OTOH,
   if the GSM device advertises its RF capabilities truthfully, there
   a chance that the network will accommodate its limitations and
   stick to high ARFCNs, which are fully supported by all hw versions.

I do not know whether there is any GSM network anywhere in the world
that would direct a mobile station to a low ARFCN if it receives an
advertisement of such capability, but would stick with high ARFCNs for
less-capable mobile equipment; much less whether or not any FR user
has ever been bitten by my hypothetical scenario in the real world.
Hence I am soliciting the wisdom of the mailing list.

If the community concludes that having the tri-band modem believe and
advertise itself as quad-band is *not* a good idea, I would be happy
to publish the tools and instructions for changing that /gsm/com/rfcap
file in the modem's FFS to reflect a 900/1800/1900 or 850/1800/1900
MHz configuration, matching the hardware reality.

VLR,
SF