On Thu 16 January 2014 02:58:29 Michael Spacefalcon wrote: > 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/1852900ce9ea4ac52d4648f7 > d9ca46897eb3640b/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
A friend of mine complained about poor reception of the FR I handed to him which I used for 6 months without any trouble. Turned out he's using D1 (900MHz) carrier while my SIM was E1 (1800MHz), and the FR happened to be a US model which I forgot about. Bottom line: even 850MHz FR can do 900MHz but the reception is pretty poor though just sufficient in usual urban environment. I don't think network/BTS can "direct" the mobile to another channel, it can only adveritse other channels but it's up to mobile to determine if that channel actually works in the particular situation - there may be other problems to receive 900MHz band than just a SAW filter, like local interference or whatever. When the mobile can't use a certain frequency, the BTS will not "force" the mobile to that frequency. PS: yes, the firmware is the very same for all Openmoko phones. No differences in firmware according to model or version. /j -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (alas the above page got scrapped due to resignation(!!), so here some supplementary links:) http://www.georgedillon.com/web/html_email_is_evil.shtml http://www.nonhtmlmail.org/campaign.html http://www.georgedillon.com/web/html_email_is_evil_still.shtml http://www.gerstbach.at/2004/ascii/ (German)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community