--- 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.

--- 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