# HG changeset patch # User Michael Spacefalcon # Date 1403386136 0 # Node ID 14618bd924ec838d9a53d71692ac65b3006daea9 # Parent f114f5c547eccf502c3e338c6f75106be0c10374 doc/RVTMUX and doc/TIFFS-Overview: updates diff -r f114f5c547ec -r 14618bd924ec doc/RVTMUX --- a/doc/RVTMUX Sat Jun 21 19:36:32 2014 +0000 +++ b/doc/RVTMUX Sat Jun 21 21:28:56 2014 +0000 @@ -120,12 +120,12 @@ for yourself.) Thus TMFFS2 is currently the "officially adopted" version for FreeCalypso. -Our fc-tmsh utility (described below) allows a developer-operator to send TMFFS -"get version" queries to a running GSM fw in both ETM_FFS1 and ETM_FFS2 formats; -this capability allows us to determine experimentally which protocol (if any) is -implemented by a given proprietary firmware version. Experiments reveal that -Openmoko's moko11 firmware implements TMFFS1, whereas Pirelli's fw implements -TMFFS2. +Our fc-tmsh utility (see below and ../rvinterf/README) allows a developer- +operator to send TMFFS "get version" queries to a running GSM fw in both +ETM_FFS1 and ETM_FFS2 formats; this capability allows us to determine +experimentally which protocol (if any) is implemented by a given proprietary +firmware version. Experiments reveal that Openmoko's moko11 firmware +implements TMFFS1, whereas Pirelli's fw implements TMFFS2. The leo2moko-r1 firmware produced by the FreeCalypso project in 2013-10 implements TMFFS1, simply because that was the selected configuration in the @@ -138,38 +138,5 @@ As one would naturally expect, the FreeCalypso project has developed some host tools that allow a PC running GNU/Linux (or other Unix systems) to interface to -running firmwares on GSM devices via RVTMUX. The following tools are currently -available: - -rvtdump Opens the serial port, decodes TI's binary packet protocol, and - simply dumps every received/decoded packet on stdout in a human- - readable form. No provision for sending anything to the target. - Intended use: observing the debug trace output which all TI - firmwares emit as standard "background noise". This utility - allows one to observe/log/study the "noise" that appears on - Pirelli's USB-serial port (running Pirelli's original fw), - as well as that emitted on the IrDA (headset jack) port on the - GTA02 by mokoN/leo2moko firmwares. - -rvinterf Provides a bidirectional interface to RVTMUX on the host side. - It dumps and/or logs the "background noise" emitted by the - target just like rvtdump, but also creates a local UNIX domain - socket on the host machine to which other programs can connect, - replicating the MUXing function on the host side. - -fc-tmsh Interactive asynchronous test mode shell. This program connects - to a target GSM device through rvinterf and allows a developer- - operator to send various ETM commands to the target. ETM - responses are decoded (sometimes only lightly) and displayed. - fc-tmsh is fully asynchronous in that it continuously listens - (via select(2)) for both user input and for packets from the - target at the same time, translating any user-entered commands - into packets to the target and conversely, scribbling on the - terminal when a packet arrives from the target. It has no - knowledge of any correspondence between commands and responses - they normally elicit. - -fc-tmsh implements some low-level ffs2 commands (see above regarding our design -decision to use TMFFS2 rather than TMFFS1), but it is already known that this -implementation approach is a dead end, and a different host utility is planned -to be written for full FFS read/write access via the TMFFS2 protocol. +running firmwares on GSM devices via RVTMUX. See the rvinterf subtree of +freecalypso-sw for the source and documentation. diff -r f114f5c547ec -r 14618bd924ec doc/TIFFS-Overview --- a/doc/TIFFS-Overview Sat Jun 21 19:36:32 2014 +0000 +++ b/doc/TIFFS-Overview Sat Jun 21 21:28:56 2014 +0000 @@ -127,6 +127,11 @@ 18 sectors of 256 KiB each (for 4.5 MiB in total), starting at the beginning of the 2nd flash chip select (0x02000000 in the ARM7 address space). +* On Motorola/Compal C139/140 phones, the FFS used by the original proprietary + fw occupies 5 sectors of 64 KiB each (320 KiB in total), starting at 0x370000. + C11x/123 use smaller FFS configurations, whereas C155/156 seem to have + switched to some other FFS format, different from our familiar TIFFS. + * The smallest real FFS configuration called for by the table in dev.c in TI's original Leonardo fw source is 3 sectors of 64 KiB each; the same table also sports a 4 KiB x 4 configuration for RAM-based testing (emulation of FFS in @@ -296,6 +301,34 @@ until then the only advice I can give is to make a backup copy of your modem FFS with fc-loadtool, and to save it securely. +Compal and Pirelli differences +============================== + +The above description refers to TI's vanilla reference version, and it seems +like Openmoko (FIC) was the only phone/modem manufacturer who followed it +without major deviations. In contrast, both Compal (Mot C1xx) and Foxconn +(Pirelli DP-L10) moved the vital per-unit factory data (IMEI and RF calibration) +out of the FFS into their own ad hoc flash data structures (which are very +difficult to reverse-engineer and make use of, unfortunately), leaving their FFS +only for less critical data. + +In Compal's case (at least on the C139 model with which I have extensive +personal experience) the FFS stores only users' personal information and nothing +more. One can turn the phone off, use fc-loadtool to erase the FFS sectors, and +boot the regular fw back up; the fw will automatically do a new FFS format (it +even displays a message on the LCD as it does so) and carry on happily as a +"fresh" or "blank", perfectly functional and usable phone. + +In Pirelli's case, booting their official fw with blank FFS sectors will also +result in the FFS being automatically formatted, but their fw expects some +static "asset" files to be present in this FFS: UI graphics and language +strings, ringtones, firmware images for the WiFi and VoIP processors and some +static configuration files, about 3 MiB in total. Thus although the firmware +will auto-format the blank FFS sectors, it won't function normally with all of +these "asset" files missing. Foxconn's original factory production line station +must have uploaded these files to each phone via the TMFFS2 protocol, and our +FreeCalypso suite now features a tool that can replicate this feat: fc-fsio. + FreeCalypso support for TIFFS ============================= @@ -308,7 +341,7 @@ source tree. This TIFFS "in vitro analyzer" utility supplants the earlier mpffs-* tools, and adds some additional examination functionality. It is strictly a "read only" tool, however - it is not designed for "in vitro" - editing" of TIFFS images. + editing of TIFFS images. 2. A number of FC tools may be strung together into a kit for editing the FFS content of a GSM device, e.g., for changing the IMEI. The following pieces @@ -328,14 +361,13 @@ such as the GTA0x GSM modem via the fc-xram host utility; * After loading the ramImage, fc-xram will immediately exec our rvinterf host - utility described in the RVTMUX write-up; + utility (see rvinterf/README); * Once the GSM device is running what is effectively an FFS editing agent out - of RAM, accessed via rvinterf over the serial channel, the user will be able - to run fc-tmsh (or perhaps the FFS operations will be implemented in some - other utility, we'll see), and that "test mode shell" will provide commands - for writing things to FFS exactly like one would do in the factory production - line environment for which TI taylored their tools. + of RAM, accessed via rvinterf over the serial channel, the user can run + fc-tmsh or fc-fsio, and this "test mode shell" provides commands for writing + things to FFS exactly like one would do in the factory production line + environment for which TI taylored their tools. The "in vivo" method of editing the FFS content of a GSM device described above will probably sound very convoluted, and you may find yourself asking for a way @@ -347,9 +379,9 @@ just a short flash write operation without any erasures at all, i.e., kinder on the flash. -In any case, the "in vivo" method will definitely be available soon because all -of the components involved therein are also needed for other development uses -in the FreeCalypso project, whereas developing a fully-functional "in vitro" +In any case, the "in vivo" method is already available now because all of the +components involved therein are also needed for other development uses in the +FreeCalypso project, whereas developing a fully-functional "in vitro" alternative (one that can create an FFS image "de novo" from a tree of files and directories a la mkfs.jffs2, or add new files to an existing TIFFS image etc) would be a good amount of extra work which we otherwise don't need - hence