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