+
−[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.