[Historical note: this document was originally written in 2014 when the vision
 of FreeCalypso was very different from what it is today.  Since then we have
 transitioned from making aftermarket hacks on pre-existing Calypso phones and
 modems to producing and supporting our own FreeCalypso hardware products, and
 our firmware work has changed from a nebulous dream to stable production code.
 The ways in which we approach various technical aspects have changed
 accordingly, but much of our documentation has been slow to catch up.  The
 documentation is now being updated, but there may still be some passages where
 the old world view shines through.]

All TI GSM firmwares known to this author (Mother Mychaela of FreeCalypso)
implement some kind of flash file system, or FFS.  Several different FFS code
implementations, and correspondingly several different on-flash data formats,
have been used throughout the history of TI's involvement in the wireless
terminal business.  The FFS incarnation of primary interest to the FreeCalypso
project is the one invented by Mads Meisner-Jensen at TI in the early 2000s
(at least according to the comments in the sources available to us), and it is
relevant to us in the following ways:

* When targeting the GSM modem in Openmoko's GTA01/02 smartphones, we need to
  work with the original FFS from the factory (call it MokoFFS), the same FFS
  as used by the mokoN firmwares: this FFS contains the IMEI and the RF
  calibration values from the factory, which we most certainly don't want to go
  without.

* The Leonardo firmware semi-src which we are using as the reference for
  building our own full source, multi-target GSM fw contains a turnkey-working
  implementation of this very FFS, using the on-flash format in question and
  providing run-time APIs expected by the rest of the GSM fw suite.  Following
  the principle of ``if it ain't broke, don't fix it'', we use this FFS not
  only on the gtamodem target, but also on other targets, including those where
  we are starting from a blank state and thus have the freedom to use whatever
  FFS we like.

* The original proprietary fw on the Pirelli DP-L10 phone also happens to use
  an FFS in the same format, although Pirelli's FFS does *not* contain the IMEI
  or any of the RF calibration values.  This Pirelli phone was originally a
  target of high interest for FreeCalypso, as we had high hopes of turning it
  into a libre phone by way of our aftermarket firmware - but this plan has
  since been abandoned when it became clear that Pirelli's hw is unsuitable for
  aftermarket fw development because of the multitude of extra peripheral chips
  for non-GSM functions which get in the way.  In the earlier years of
  FreeCalypso a lot of effort had been invested into studying all aspects of
  the Pirelli DP-L10 phone and its original firmware, including the FFS.

Naming
======

I have previously referred to the FFS format in question as Mokopir-FFS or
MPFFS, from "Moko" and "Pirelli".  I was originally hesitant to call it TIFFS,
as lacking the source code, I had no way of knowing whether the FFS format and
implementation were of TI's own invention, or something that TI licensed as a
black box from one of their many proprietary software partners.  (I was unable
to identify it as any well-known, industry-standard FFS format, but absence of
evidence is not evidence of absence.)  But now that we have TI's original source
code which implements this FFS (first the MV100-0.1.rar source, then the full
Leonardo one), complete with comments and a HISTORY file, we know that our FFS
was invented and implemented by someone named Mads Meisner-Jensen at TI-DK,
apparently their flash chip expert who also wrote FLUID.

I am now making a naming transition from MPFFS to TIFFS: there is really no
link between this FFS format and the Openmoko+Pirelli duo, other than the
happenstance of me having first encountered this FFS on these two GSM device
brands, and the name TIFFS is more neutrally-descriptive.

What it is
==========

In a rare departure from TI's norm (most of TI's GSM firmware and associated
development tools suffer from heavy Windows poisoning), what I call TIFFS is
very Unixy.  It is a file system with a hierarchical directory tree structure
and with Unixy forward-slash-separated, case-sensitive pathnames; the semantics
of "what is a file" and "what is a directory" are exactly the same as in UNIX;
and TIFFS even supports symlinks, although that support is a little under-
developed, and apparently no FFS symlinks were ever used in any production GSM
device.  Thus the FFS implemented in TI-based GSM devices (modems and
"dumbphone" handsets) is really no different from, for example, JFFS2 in
embedded Linux systems.

(The only traditional UNIX file system features which are missing in TIFFS are
 the creation/modification/access timestamps and the ownership/permission
 fields.)

The FFS in a GSM device typically stores two kinds of content:

* Factory data: IMEI, RF calibration values, device make/model/revision
  ID strings etc.  These files are expected to be programmed on the factory
  production line and not changed afterward.

* Dynamic data written into the FFS in normal device operation: when you use a
  "dumbphone" running TI-based firmware, every time you store something "on the
  phone" or in "non-volatile memory", that item is actually stored in the FFS.
  (Where else, if you think of it?)  That includes contacts and received SMS
  stored "on the phone" instead of the SIM, any selections you make in the
  settings/preferences menus which persist across reboots (power cycles), call
  history etc.

It needs to be noted that the "dynamic data" aspect of FFS usage applies not
only to complete phones, but also to modems like the one used in the GTA01/02.
One would naively think that non-volatile storage of data in flash outside of
factory programming would be needed only in a device with its own UI, and that
a modem subservient to external AT commands would be completely stateless
across reboot/power cycles; but that is not the case in actuality.  TI-baseed
GSM firmwares, including Openmoko's mokoN and our own FreeCalypso, are designed
to always "mount" their FFS with read/write access; TI's FFS implementation in
the firmware has no concept of a "read-only mount".

I am still investigating just what kinds of data are routinely written into the
non-volatile FFS by the firmware in normal operation on devices like the GTA0x
modem, but there most definitely are some.

There is no hard separation between "static" and "dynamic" data in the file
system structure; TIFFS is thus akin to an embedded Linux system with just a
single root file system containing both "static" files like userland binaries
and "dynamic" ones like configuration files under /etc which the user is
expected to edit with vi after logging into the box, or log and similar files
created by the system itself under /var, for example.

Where it lives
==============

The type of flash memory used in Calypso GSM modems and "dumbphones" is called
NOR flash.  This NOR flash memory is physically divided (by the design of the
flash chip itself) into units called "sectors" or more descriptively, erase
blocks.  The typical NOR flash sector size (in Calypso GSM devices) ranges from
64 KiB in the GTA02 modem's NOR flash (4 MiB total) to 256 KiB in the
S71PL129NC0 flash+RAM chip used in the Pirelli DP-L10 and in our own FreeCalypso
hardware designs (16 MiB of flash total).  The key physical property is that
any bit may be changed from a '1' to a '0' at any time, in any combination, but
resetting of '0' bits back to ones can be done only on the granularity of these
largish sectors, in an operation called "sector erase".

The location of TIFFS within the flash memory of a given GSM device is defined
by the firmware design of that device, but is always some integral number of
contiguous flash sectors.  Some examples:

* On the GTA01/02 GSM modem, FFS occupies 7 sectors of 64 KiB each, starting at
  flash offset 0x380000.

* On the Pirelli DP-L10, the FFS used by the original proprietary fw occupies
  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/12x use smaller FFS configurations, whereas C155/156 use a different FFS
  implementation with a completely different on-flash format - see the new
  Compal-FFS article for more details.

* On our own FreeCalypso hardware family we have put our FFS in the first 8
  sectors (of 256 KiB each) in the 2nd flash chip select bank, which appears at
  0x01800000 in the ARM7 address space instead of Pirelli's 0x02000000 because
  we have wired the 2nd flash chip select to nCS2 on the Calypso instead of
  Pirelli's nCS3.

* 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
  RAM without real flash).

* The largest FFS configuration that has been envisioned by the original
  designers seems to be somewhere around 128 sectors.

Each flash sector used for TIFFS begins with this 6-byte signature:

46 66 73 23 10 02

The first 4 bytes are 'Ffs#' in ASCII, and the following two bytes are the
format version number of 0x0210 in little-endian byte order.  The following two
bytes give a count of how many times that sector has been erased and rewritten
(FF FF in "fresh" or "virgin" FFS images), and the following byte indicates
that block's role and status in the FFS life cycle.

How it works
============

Just like JFFS2 and other high-quality flash file systems, TIFFS is designed to
recover gracefully from any possible power failure or crash: one can yank the
battery from the GSM device (or induce a firmware crash) at the most mis-
opportune moment in the middle of an FFS write operation, and the FFS is
expected to recover on the next boot cycle.  I won't be able to document here
all gory details of exactly how this goal is achieved, partly because I haven't
studied the code to the requisite level of depth myself yet, but all of the
responsible code lives under src/cs/drivers/drv_app/ffs in our fc-magnetite and
fc-selenite source trees; feel free to study it.

In its "normal" or "clean" state (i.e., when not in the middle of a write
operation or recovery from an ungracefully interrupted one), a TIFFS instance
consists of the following 3 types of blocks:

* One block containing inode records, indicated by AB in its type/flags/status
  byte in the block header;
* N-2 blocks (where N is the total number of flash sectors allocated for the
  FFS) containing (or waiting to be filled with) data chunks - indicated by BD
  in the type/flags/status byte;
* One "free" block, indicated by BF - destined to become a new AB or a new BD
  at some point.

Each object written into the FFS (file, directory or symlink) consists of a
16-byte inode record written into the AB block and a data chunk written into
one of the BD blocks.  The data chunk includes the name of the object, hence
one is required even for directories.  Data chunks are contiguous, uncompressed,
and subject to an upper size limit of 2048 or 8192 bytes, depending on the FFS
configuration.  Files larger than this limit are stored in a "segmented" form,
giving rise to a 4th inode or object type (after file, directory and symlink):
segment.  Each segment of a segmented file consists of not only a data chunk,
but also an inode record for the segment, which gives the location of the data
chunk and ties the segment object into the overall FFS structure, making it
accessible.

Because aside from complete sector erasure, flash memory bits can only
transition from '1' to '0' but not the other way around, overwriting an existing
file with some new content (an operation which any reasonable file system must
implement in some way) cannot be done in place.  Instead like most flash file
systems, TIFFS implements this common operation by writing the new version of
the file to a new location (previously blank flash) and then invalidating the
old version - and doing all that while keeping in mind the possibility of an
ungraceful crash or powerdown at any moment, and the requirement of recovering
gracefully from any such event.

Of course as an FFS receives more write activity, even if one keeps overwriting
some existing files with new content of the same size, without adding to the
visible total content size (think du(1) command), eventually all remaining blank
flash space will fill up.  At that point (or at some earlier point, depending
on the FFS design and/or configuration) the FFS has to invoke a compaction or
reclamation or garbage collection procedure: any "mixed" blocks containing both
valid and stale data are transitioned into a "stale-only" state by having the
active data moved to a new block, and then the "all stale" blocks are subjected
to sector erasure, becoming new blank sectors.  The logic responsible for these
operations once again needs to be resilient to the possibility of a crash or
powerdown occurring at the most mis-opportune moment, and it also needs to
implement flash wear leveling: there is a physical limit to how many times a
given flash sector can be erased and rewritten before it goes bad.

All of the above are common and well-known principles, successfully implemented
in well-known flash file systems such as JFFS2 in Linux.  TIFFS is absolutely
no different in this regard; for the implementation details, read the source
code.

TIFFS filename and pathname limits
==================================

Classic TIFFS, as in the canonical firmware source from TI, imposes the
following limits on the content written into FFS:

* Each elementary filename or pathname component (the name of each individual
  file or subdirectory within its parent directory) is limited to 20 characters;

* The set of allowed characters in these elementary filenames is limited to
  [A-Za-z0-9_.,+%$#-];

* The maximum pathname depth is limited to 6.

As an illustration of the pathname depth limit, the deepest allowed path to a
non-directory file is /d1/d2/d3/d4/d5/file.  It is also possible to have a
directory nesting of /d1/d2/d3/d4/d5/d6, but in this case the deepest directory
can only be empty.

How this FFS comes into being
=============================

(This section is only relevant to you if you plan on physically producing your
 own GSM phones or modems on your own factory production line, like we currently
 do at our family company, or if you simply enjoy knowing how it is done.)

To my knowledge, TI never used or produced a tool akin to mkfs.jffs2 in the
embedded Linux world, or akin to our recently developed tiffs-mkfs, which would
produce a TIFFS image complete with some initial directory and file content
"in vitro".  Instead it appears that the FFS instances found in shipped products
such as Openmoko phones have been created "in vivo" by TI's firmware running on
the device itself during the "production test" phase.

We never got a copy of the original factory production line software that was
used by Openmoko, but we have successfully replicated the process using our own
Unix/Linux-based FreeCalypso host tools, the very same tools that are contained
in the present source package you are looking at.  The process goes like this:

* When the printed circuit board is physically populated with components such
  as the Calypso chip and the flash chip, the latter can be blank - if the
  board design has the nIBOOT pin pulled low, enabling the Calypso boot ROM
  (Openmoko and Pirelli both good on this one, but shame on Compal!), there is
  no need to preprogram the flash chip with anything prior to populating it on
  the board, and the device remains fully unbrickable at all times afterward.

* When the assembled board is powered up for the first time, with completely
  blank flash, the Calypso boot ROM will sit there and patiently wait for a
  code download on either of its two UARTs.

* Using TI's FLUID (Flash Loader Utility Independent of Device) or FreeCalypso's
  fc-loadtool free replacement, the factory production station loads the main
  firmware image into the flash.  Note, it is just the firmware image at this
  step, and the FFS sectors remain blank.

* The board is commanded to reboot (or power-cycled), and the firmware image
  boots for the first time.

* TI's FFS implementation code in their standard firmware reacts to all blank
  flash in the FFS sectors as follows: it performs what they call the preformat
  operation, writing the TIFFS signature and a BF state byte into every FFS
  sector, but the main "format" operation, which sets up the AB/BD block roles,
  creates the root inode and makes the FFS ready to accept the creation of its
  first directories and files, is not done automatically.

In order to perform the FFS format operation and then fill the new FFS with
whatever directories and files are deemed needed to be present in "fresh"
shipping products, the factory production station connects to the just-booted
firmware running on the target via the RVT/ETM protocol (see the RVTMUX
write-up), and sends "test mode" commands to this running firmware.  These
"FFS test mode" (or TMFFS) commands include the format operation, an mkdir
operation to create directories, and a "file write" operation akin to doing
'cat > /dir/whatever/file', creating files in FFS and storing any desired data
in them.

The IMEI is assigned and written into FFS in this process, but it is not the
only data item that will be unique for each individual device made.  Much more
important are the RF calibration values; the factory calibration procedure does
the following for each individual unit:

* Measures the frequency offset produced by the VCXO as a function of the AFC
  DAC control value and constructs the afcparams table based on these
  measurements;

* Characterizes the dBm output of the Tx chain as a function of the APC DAC
  control value and comes up with a set of these DAC values which produce Tx
  power levels prescribed by the GSM 05.05 spec;

* Determines the correction values which need to be applied in order to set the
  correct Rx path gains and to determine the true Rx signal level from the dBfs
  power measurements made in the DSP from Rx I&Q samples.

These calibration procedures are performed by connecting a suitable RF test
instrument (R&S CMU200 is the industry gold standard) to the GSM device's
antenna connector or RF test port and running special calibration programs
which talk both to the CMU200 or other test instrument and to the L1TM (Layer 1
test modes) component in the DUT (device under test).  In FreeCalypso hardware
manufacturing we use a CMU200 instrument which is itself maintained in good
calibration standing, and for the calibration software we use our own
fc-rfcal-tools which talk to the DUT via rvinterf.

All of the resulting calibration values are stored in a bunch of files under the
/gsm/rf subtree, and these files are "owned" by the L1 code.  The latter has
RAM data structures which correspond to these files; upon normal boot the
initialization code looks in FFS, and if it finds any of the RF calibration
files, it reads each present file into the corresponding RAM data structure,
overwriting the compiled-in defaults.  With TI's standard production calibration
procedure which we have replicated in our FreeCalypso hw manufacturing setup,
these RF calibration files in FFS come into being as follows:

* The Test Mode support code in L1 (i.e., part of the main GSM fw) performs the
  measurements and stores results in its RAM data structures as commanded by
  the production test station through the Test Mode interface;

* Certain special test mode commands encoded via the MISC_ENABLE opcode direct
  the above L1TM code to write its RAM data structures into FFS.

See the RF_tables article for more information.

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 (prior to us!) who
followed it without major deviations.  In contrast, both Compal (Motorola C1xx
and Sony Ericsson J100) and Foxconn (Pirelli DP-L10) moved their 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 (all C1xx models and SE J100) 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.  Please see the new Compal-FFS article for further
details.

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.

Aftermarket FFS for FreeCalypso on Compal & Pirelli targets
===========================================================

When we run our own FreeCalypso fw on "alien" (not native to us) Mot C1xx and
Pirelli DP-L10 hardware, we don't use the FFS from their respectively original
firmwares: those original FFS instances don't contain any bits of interest to
us, trying to make our fw use the same FFS as Mot/Compal's or Pirelli's original
fw would be more trouble than benefit, and on one of the target devices in this
family (Mot C155/156) the original FFS is in some different format.  Instead we
create our own aftermarket FFS for our FreeCalypso fw on these alien hw targets,
using a different flash location from the original so that the original fw's FFS
cannot be mistaken for our own.

On the Pirelli DP-L10 we put our aftermarket FFS in an area of the flash which
the official fw family uses as a staging area for over-the-air firmware updates,
thus as long as you are not doing official fw updates over WLAN (i.e., if you
only run one fixed official fw version or flash different official fw versions
with fc-loadtool without going through "fw update" protocols), our aftermarket
FFS used by our run-from-RAM FreeCalypso firmwares should remain undisturbed
while the phone is in the official fw mode.

The situation is different on Mot C1xx phones.  The lower-end C1xx models
including the C139 (our primary hw target in this family) have too little RAM
to run our FreeCalypso fw entirely out of RAM without flashing; the C155/156
subfamily does have enough RAM to allow a complete FC GSM fw image to be loaded
and run via fc-xram under some conditions (we previously supported such usage
in our now-retired Citrine fw and we also support it in the gcc-built config of
FC Selenite), but there is no place in the flash where we can put our
aftermarket FFS without overwriting some part of the original fw or its data -
thus our general procedure for running FreeCalypso on any C1xx model is to
convert the victim phone to FC on a long-term basis by flashing our modified
bootloader, flashing one of our fw builds and establishing a FreeCalypso
aftermarket FFS in a flash area designated by us.

It was already mentioned earlier that the factory RF calibration values on these
alien phones are stored in non-TIFFS flash data structures of Compal's or
Foxconn's invention, and our currently supported FreeCalypso firmwares
(Magnetite and Selenite) do not contain any code for reading these alien data
structures.  (FC Citrine could read directly from Pirelli's factory data block,
but none of our fw offerings ever parsed Compal's weird flash records.)  Instead
our current approach is to have an external tool extract the bits of interest
from the alien factory records, convert them to our TI-standard format if
necessary, and upload them into our FreeCalypso aftermarket FFS.  The specifics
are as follows:

* The Pirelli DP-L10 is a breeze: simply run our special pirelli-magnetite-init
  command in fc-fsio while connected to a Magnetite or Selenite fw instance
  running with our aftermarket FFS, and the tool will copy both the IMEI and
  the RF calibration records from Pirelli's factory data block into our
  aftermarket FFS.

* Mot C1xx phones present a lot more hassle: our current official procedure is
  to make a dump of the flash prior to the xenotransplantation procedure (also
  serves as a backup), extract the RF calibration values with our c1xx-calextr
  tool, and then later in the procedure when you initialize your aftermarket FFS
  with fc-fsio, upload these extracted and format-converted RF calibration files
  as one of the several steps involved.  You will also need to enter your IMEI
  manually: fc-loadtool flash compal-imei command can extract the factory IMEI
  record from the flash chip's protection register and save it into a text file,
  but you still need to feed it manually to the new firmware with fc-fsio
  set-imeisv command.

FreeCalypso host tools for TIFFS
================================

Our FC host tools package supports TIFFS in two ways:

1) Our primary tool for working with GSM device file systems is fc-fsio.  When
run against a compatible firmware version (primarily our own, but Pirelli's
proprietary fw is also compatible), fc-fsio allows various read and write
operations to be performed on the target device FFS.  fc-fsio can also be used
together with our fc-xram based FFS editing agent described below.

2) We have a TIFFS In Vitro Analyzer (IVA) tool for "in vitro" examination of
FFS images that have been read out of raw flash with fc-loadtool.  See the
TIFFS-IVA-usage article for more information.  As a very recent addition, we
also have another "in vitro" tool (tiffs-mkfs) that goes the other way, creating
new complete TIFFS images from a tree of directories and files.

In addition to the above, back in the days of Openmoko (back when the Openmoko
community was still active and we considered ourselves a part of it) we had
produced a kit for editing the modem FFS on Openmoko GTA01/02 devices, giving
users an easy way to change their /pcm/IMEI file.  Changing IMEIs for no good
reason is completely pointless and is actually detrimental rather than helpful
for privacy, but whoever came up with the edicts that "the IMEI MUST be
immutable" had obviously failed Human Psychology 101: declaring something to be
forbidden causes people to want it simply because it is forbidden and for no
other reason - hence the popular demand for IMEI changing tools.

Our Openmoko FFS editing kit from early 2014 consisted of a very early version
of what much later became the present FC host tools package (more specifically,
it was before fc-fsio, and the set-imeisv command had been hacked into fc-tmsh
instead) plus a pair of "in vivo" FFS editing agent target binaries that run on
the target by way of fc-xram.  Our current FC host tools fully supplant the
ancient version in that 2014 kit, and our current replacement for the ancient
FFS editing agent is this new version:

https://www.freecalypso.org/hg/ffs-editor/

The new FFS editing agent linked above is run via fc-xram, while it is running
you communicate with it via rvinterf (launched directly from fc-xram as the 2nd
program), and you can run fc-fsio against it to perform whatever actual FFS
manipulations are needed.