FreeCalypso > hg > freecalypso-tools

comparison doc/TIFFS-Overview @ 431:579441d7dcd8

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/TIFFS-Overview: long-overdue update for the current state of FC
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 04 Nov 2018 02:00:03 +0000
parents e7502631a0f9
children 3100f534340b
comparison
equal deleted inserted replaced
430:06442f27b144 431:579441d7dcd8
1 All TI GSM firmwares known to this author (FreeCalypso developer Space Falcon) 1 [Historical note: this document was originally written in 2014 when the vision
2 of FreeCalypso was very different from what it is today. Since then we have
3 transitioned from making aftermarket hacks on pre-existing Calypso phones and
4 modems to producing and supporting our own FreeCalypso hardware products, and
5 our firmware work has changed from a nebulous dream to stable production code.
6 The ways in which we approach various technical aspects have changed
7 accordingly, but much of our documentation has been slow to catch up. The
8 documentation is now being updated, but there may still be some passages where
9 the old world view shines through.]
10
11 All TI GSM firmwares known to this author (Mother Mychaela of FreeCalypso)
2 implement some kind of flash file system, or FFS. Several different FFS code 12 implement some kind of flash file system, or FFS. Several different FFS code
3 implementations, and correspondingly several different on-flash data formats, 13 implementations, and correspondingly several different on-flash data formats,
4 have been used throughout the history of TI's involvement in the wireless 14 have been used throughout the history of TI's involvement in the wireless
5 terminal business. The FFS incarnation of primary interest to the FreeCalypso 15 terminal business. The FFS incarnation of primary interest to the FreeCalypso
6 project is the one invented by Mads Meisner-Jensen at TI in the early 2000s 16 project is the one invented by Mads Meisner-Jensen at TI in the early 2000s
15 25
16 * The Leonardo firmware semi-src which we are using as the reference for 26 * The Leonardo firmware semi-src which we are using as the reference for
17 building our own full source, multi-target GSM fw contains a turnkey-working 27 building our own full source, multi-target GSM fw contains a turnkey-working
18 implementation of this very FFS, using the on-flash format in question and 28 implementation of this very FFS, using the on-flash format in question and
19 providing run-time APIs expected by the rest of the GSM fw suite. Following 29 providing run-time APIs expected by the rest of the GSM fw suite. Following
20 the principle of ``if it ain't broke, don't fix it'', we can use this FFS not 30 the principle of ``if it ain't broke, don't fix it'', we use this FFS not
21 only on the gtamodem target, but also on other targets, including those where 31 only on the gtamodem target, but also on other targets, including those where
22 we would be starting from a blank state and thus have the freedom to use 32 we are starting from a blank state and thus have the freedom to use whatever
23 whatever FFS we like. 33 FFS we like.
24 34
25 * The original proprietary fw on the Pirelli DP-L10 phone also happens to use 35 * The original proprietary fw on the Pirelli DP-L10 phone also happens to use
26 an FFS in the same format. Pirelli's FFS does *not* contain the IMEI or any 36 an FFS in the same format, although Pirelli's FFS does *not* contain the IMEI
27 of the RF calibration values though, and trying to reuse it directly for our 37 or any of the RF calibration values. This Pirelli phone was originally a
28 own FC GSM fw seems to be more trouble than benefit - so we'll probably have 38 target of high interest for FreeCalypso, as we had high hopes of turning it
29 our fw start with a blank TIFFS instead - but there is still insight to be 39 into a libre phone by way of our aftermarket firmware - but this plan has
30 gained from in-vitro examination of captured Pirelli FFS images. 40 since been abandoned when it became clear that Pirelli's hw is unsuitable for
41 aftermarket fw development because of the multitude of extra peripheral chips
42 for non-GSM functions which get in the way. In the earlier years of
43 FreeCalypso a lot of effort had been invested into studying all aspects of
44 the Pirelli DP-L10 phone and its original firmware, including the FFS.
31 45
32 Naming 46 Naming
33 ====== 47 ======
34 48
35 I have previously referred to the FFS format in question as Mokopir-FFS or 49 I have previously referred to the FFS format in question as Mokopir-FFS or
58 and with Unixy forward-slash-separated, case-sensitive pathnames; the semantics 72 and with Unixy forward-slash-separated, case-sensitive pathnames; the semantics
59 of "what is a file" and "what is a directory" are exactly the same as in UNIX; 73 of "what is a file" and "what is a directory" are exactly the same as in UNIX;
60 and TIFFS even supports symlinks, although that support is a little under- 74 and TIFFS even supports symlinks, although that support is a little under-
61 developed, and apparently no FFS symlinks were ever used in any production GSM 75 developed, and apparently no FFS symlinks were ever used in any production GSM
62 device. Thus the FFS implemented in TI-based GSM devices (modems and 76 device. Thus the FFS implemented in TI-based GSM devices (modems and
63 "dumbphones") is really no different from, for example, JFFS2 in embedded Linux 77 "dumbphone" handsets) is really no different from, for example, JFFS2 in
64 systems. 78 embedded Linux systems.
65 79
66 (The only traditional UNIX file system features which are missing in TIFFS are 80 (The only traditional UNIX file system features which are missing in TIFFS are
67 the creation/modification/access timestamps and the ownership/permission 81 the creation/modification/access timestamps and the ownership/permission
68 fields.) 82 fields.)
69 83
84 It needs to be noted that the "dynamic data" aspect of FFS usage applies not 98 It needs to be noted that the "dynamic data" aspect of FFS usage applies not
85 only to complete phones, but also to modems like the one used in the GTA01/02. 99 only to complete phones, but also to modems like the one used in the GTA01/02.
86 One would naively think that non-volatile storage of data in flash outside of 100 One would naively think that non-volatile storage of data in flash outside of
87 factory programming would be needed only in a device with its own UI, and that 101 factory programming would be needed only in a device with its own UI, and that
88 a modem subservient to external AT commands would be completely stateless 102 a modem subservient to external AT commands would be completely stateless
89 across reboot/power cycles; but that is not the case in actuality. TI's GSM 103 across reboot/power cycles; but that is not the case in actuality. TI-baseed
90 firmwares, including the Openmoko ones (the "standard" mokoN), are designed to 104 GSM firmwares, including Openmoko's mokoN and our own FreeCalypso, are designed
91 always "mount" their FFS with read/write access; TI's FFS implementation in the 105 to always "mount" their FFS with read/write access; TI's FFS implementation in
92 firmware has no concept of a "read-only mount". 106 the firmware has no concept of a "read-only mount".
93 107
94 I am still investigating just what kinds of data are routinely written into the 108 I am still investigating just what kinds of data are routinely written into the
95 non-volatile FFS by the firmware in normal operation on devices like the GTA0x 109 non-volatile FFS by the firmware in normal operation on devices like the GTA0x
96 modem, but there most definitely are some. 110 modem, but there most definitely are some.
97 111
108 The type of flash memory used in Calypso GSM modems and "dumbphones" is called 122 The type of flash memory used in Calypso GSM modems and "dumbphones" is called
109 NOR flash. This NOR flash memory is physically divided (by the design of the 123 NOR flash. This NOR flash memory is physically divided (by the design of the
110 flash chip itself) into units called "sectors" or more descriptively, erase 124 flash chip itself) into units called "sectors" or more descriptively, erase
111 blocks. The typical NOR flash sector size (in Calypso GSM devices) ranges from 125 blocks. The typical NOR flash sector size (in Calypso GSM devices) ranges from
112 64 KiB in the GTA02 modem's NOR flash (4 MiB total) to 256 KiB in the 126 64 KiB in the GTA02 modem's NOR flash (4 MiB total) to 256 KiB in the
113 S71PL129NC0 flash+RAM chip used in the Pirelli DP-L10 (16 MiB of flash total). 127 S71PL129NC0 flash+RAM chip used in the Pirelli DP-L10 and in our own FreeCalypso
114 The key physical property is that any bit may be changed from a '1' to a '0' at 128 hardware designs (16 MiB of flash total). The key physical property is that
115 any time, in any combination, but resetting of '0' bits back to ones can be 129 any bit may be changed from a '1' to a '0' at any time, in any combination, but
116 done only on the granularity of these largish sectors, in an operation called 130 resetting of '0' bits back to ones can be done only on the granularity of these
117 "sector erase". 131 largish sectors, in an operation called "sector erase".
118 132
119 The location of TIFFS within the flash memory of a given GSM device is defined 133 The location of TIFFS within the flash memory of a given GSM device is defined
120 by the firmware design of that device, but is always some integral number of 134 by the firmware design of that device, but is always some integral number of
121 contiguous flash sectors. Some examples: 135 contiguous flash sectors. Some examples:
122 136
129 143
130 * On Motorola/Compal C139/140 phones, the FFS used by the original proprietary 144 * On Motorola/Compal C139/140 phones, the FFS used by the original proprietary
131 fw occupies 5 sectors of 64 KiB each (320 KiB in total), starting at 0x370000. 145 fw occupies 5 sectors of 64 KiB each (320 KiB in total), starting at 0x370000.
132 C11x/123 use smaller FFS configurations, whereas C155/156 seem to have 146 C11x/123 use smaller FFS configurations, whereas C155/156 seem to have
133 switched to some other FFS format, different from our familiar TIFFS. 147 switched to some other FFS format, different from our familiar TIFFS.
148
149 * On our own FreeCalypso hardware family we have put our FFS in the first 8
150 sectors (of 256 KiB each) in the 2nd flash chip select bank, which appears at
151 0x01800000 in the ARM7 address space instead of Pirelli's 0x02000000 because
152 we have wired the 2nd flash chip select to nCS2 on the Calypso instead of
153 Pirelli's nCS3.
134 154
135 * The smallest real FFS configuration called for by the table in dev.c in TI's 155 * The smallest real FFS configuration called for by the table in dev.c in TI's
136 original Leonardo fw source is 3 sectors of 64 KiB each; the same table also 156 original Leonardo fw source is 3 sectors of 64 KiB each; the same table also
137 sports a 4 KiB x 4 configuration for RAM-based testing (emulation of FFS in 157 sports a 4 KiB x 4 configuration for RAM-based testing (emulation of FFS in
138 RAM without real flash). 158 RAM without real flash).
158 battery from the GSM device (or induce a firmware crash) at the most mis- 178 battery from the GSM device (or induce a firmware crash) at the most mis-
159 opportune moment in the middle of an FFS write operation, and the FFS is 179 opportune moment in the middle of an FFS write operation, and the FFS is
160 expected to recover on the next boot cycle. I won't be able to document here 180 expected to recover on the next boot cycle. I won't be able to document here
161 all gory details of exactly how this goal is achieved, partly because I haven't 181 all gory details of exactly how this goal is achieved, partly because I haven't
162 studied the code to the requisite level of depth myself yet, but all of the 182 studied the code to the requisite level of depth myself yet, but all of the
163 responsible code lives under gsm-fw/services/ffs in this freecalypso-sw source 183 responsible code lives under src/cs/drivers/drv_app/ffs in our fc-magnetite and
164 tree; feel free to study it. 184 fc-selenite source trees; feel free to study it.
165 185
166 In its "normal" or "clean" state (i.e., when not in the middle of a write 186 In its "normal" or "clean" state (i.e., when not in the middle of a write
167 operation or recovery from an ungracefully interrupted one), a TIFFS instance 187 operation or recovery from an ungracefully interrupted one), a TIFFS instance
168 consists of the following 3 types of blocks: 188 consists of the following 3 types of blocks:
169 189
218 238
219 How this FFS comes into being 239 How this FFS comes into being
220 ============================= 240 =============================
221 241
222 (This section is only relevant to you if you plan on physically producing your 242 (This section is only relevant to you if you plan on physically producing your
223 own GSM phones or modems on your own factory production line, like this author 243 own GSM phones or modems on your own factory production line, like we currently
224 fancies doing in the not-too-distant future, or if you simply enjoy knowing 244 do at our family company, or if you simply enjoy knowing how it is done.)
225 how it is done.)
226 245
227 To my knowledge, TI never used or produced a tool akin to mkfs.jffs2 in the 246 To my knowledge, TI never used or produced a tool akin to mkfs.jffs2 in the
228 embedded Linux world, which would produce a TIFFS image complete with some 247 embedded Linux world, which would produce a TIFFS image complete with some
229 initial directory and file content "in vitro". Instead it appears that the FFS 248 initial directory and file content "in vitro". Instead it appears that the FFS
230 instances found in shipped products such as Openmoko phones have been created 249 instances found in shipped products such as Openmoko phones have been created
231 "in vivo" by TI's firmware running on the device itself during the "production 250 "in vivo" by TI's firmware running on the device itself during the "production
232 test" phase. 251 test" phase.
233 252
234 The process seems to go like this: 253 We never got a copy of the original factory production line software that was
254 used by Openmoko, but we have successfully replicated the process using our own
255 Unix/Linux-based FreeCalypso host tools, the very same tools that are contained
256 in the present source package you are looking at. The process goes like this:
235 257
236 * When the printed circuit board is physically populated with components such 258 * When the printed circuit board is physically populated with components such
237 as the Calypso chip and the flash chip, the latter can be blank - if the 259 as the Calypso chip and the flash chip, the latter can be blank - if the
238 board design has the nIBOOT pin pulled low, enabling the Calypso boot ROM 260 board design has the nIBOOT pin pulled low, enabling the Calypso boot ROM
239 (Openmoko and Pirelli both good on this one, but shame on Compal!), there is 261 (Openmoko and Pirelli both good on this one, but shame on Compal!), there is
269 'cat > /dir/whatever/file', creating files in FFS and storing any desired data 291 'cat > /dir/whatever/file', creating files in FFS and storing any desired data
270 in them. 292 in them.
271 293
272 The IMEI is assigned and written into FFS in this process, but it is not the 294 The IMEI is assigned and written into FFS in this process, but it is not the
273 only data item that will be unique for each individual device made. Much more 295 only data item that will be unique for each individual device made. Much more
274 important are the RF calibration values: I have yet to learn exactly what is 296 important are the RF calibration values; the factory calibration procedure does
275 being (or needs to be) measured, how these measurements are performed (under 297 the following for each individual unit:
276 what conditions; what external test equipment is needed), and how these measured 298
277 and recorded RF calibration values affect GSM device operation, but this TI 299 * Measures the frequency offset produced by the VCXO as a function of the AFC
278 presentation gives some clues: 300 DAC control value and constructs the afcparams table based on these
279 301 measurements;
280 ftp://ftp.ifctf.org/pub/GSM/Calypso/rf_calibration.pdf 302
281 303 * Characterizes the dBm output of the Tx chain as a function of the APC DAC
282 All of these calibration values are stored in a bunch of files under the 304 control value and comes up with a set of these DAC values which produce Tx
283 /gsm/rf subtree, and these files seem to be "owned" by the L1 code. The latter 305 power levels prescribed by the GSM 05.05 spec;
284 has RAM data structures which correspond to these files; upon normal boot the 306
307 * Determines the correction values which need to be applied in order to set the
308 correct Rx path gains and to determine the true Rx signal level from the dBfs
309 power measurements made in the DSP from Rx I&Q samples.
310
311 These calibration procedures are performed by connecting a suitable RF test
312 instrument (R&S CMU200 is the industry gold standard) to the GSM device's
313 antenna connector or RF test port and running special calibration programs
314 which talk both to the CMU200 or other test instrument and to the L1TM (Layer 1
315 test modes) component in the DUT (device under test). In FreeCalypso hardware
316 manufacturing we use a CMU200 instrument which is itself maintained in good
317 calibration standing, and for the calibration software we use our own
318 fc-rfcal-tools which talk to the DUT via rvinterf.
319
320 All of the resulting calibration values are stored in a bunch of files under the
321 /gsm/rf subtree, and these files are "owned" by the L1 code. The latter has
322 RAM data structures which correspond to these files; upon normal boot the
285 initialization code looks in FFS, and if it finds any of the RF calibration 323 initialization code looks in FFS, and if it finds any of the RF calibration
286 files, it reads each present file into the corresponding RAM data structure, 324 files, it reads each present file into the corresponding RAM data structure,
287 overwriting the compiled-in defaults. It appears (slightly uncertain because I 325 overwriting the compiled-in defaults. With TI's standard production calibration
288 have not yet reintegrated the code in question into our own gsm-fw) that the RF 326 procedure which we have replicated in our FreeCalypso hw manufacturing setup,
289 calibration files in FFS come into being as follows: 327 these RF calibration files in FFS come into being as follows:
290 328
291 * The RF calibration code in L1 (i.e., part of the main GSM fw) performs the 329 * The Test Mode support code in L1 (i.e., part of the main GSM fw) performs the
292 measurements and stores results in its RAM data structures as commanded by 330 measurements and stores results in its RAM data structures as commanded by
293 the production test station through the "test mode" interface; 331 the production test station through the Test Mode interface;
294 332
295 * A final test mode command directs the above L1 code to write its RAM data 333 * Certain special test mode commands encoded via the MISC_ENABLE opcode direct
296 structures into FFS. 334 the above L1TM code to write its RAM data structures into FFS.
297 335
298 Once I actually learn this RF calibration process properly in connection with 336 See the RF_tables article for more information.
299 building my own Calypso-based GSM "dumbphone", I'll be able to say exactly what
300 it would take to recreate these RF calibration values if they are lost. But
301 until then the only advice I can give is to make a backup copy of your modem
302 FFS with fc-loadtool, and to save it securely.
303 337
304 Compal and Pirelli differences 338 Compal and Pirelli differences
305 ============================== 339 ==============================
306 340
307 The above description refers to TI's vanilla reference version, and it seems 341 The above description refers to TI's vanilla reference version, and it seems
308 like Openmoko (FIC) was the only phone/modem manufacturer who followed it 342 like Openmoko (FIC) was the only phone/modem manufacturer (prior to us!) who
309 without major deviations. In contrast, both Compal (Mot C1xx) and Foxconn 343 followed it without major deviations. In contrast, both Compal (Mot C1xx) and
310 (Pirelli DP-L10) moved the vital per-unit factory data (IMEI and RF calibration) 344 Foxconn (Pirelli DP-L10) moved their vital per-unit factory data (IMEI and RF
311 out of the FFS into their own ad hoc flash data structures (which are very 345 calibration) out of the FFS into their own ad hoc flash data structures (which
312 difficult to reverse-engineer and make use of, unfortunately), leaving their FFS 346 are very difficult to reverse-engineer and make use of, unfortunately), leaving
313 only for less critical data. 347 their FFS only for less critical data.
314 348
315 In Compal's case (at least on the C139 model with which I have extensive 349 In Compal's case (at least on the C139 model with which I have extensive
316 personal experience) the FFS stores only users' personal information and nothing 350 personal experience) the FFS stores only users' personal information and nothing
317 more. One can turn the phone off, use fc-loadtool to erase the FFS sectors, and 351 more. One can turn the phone off, use fc-loadtool to erase the FFS sectors, and
318 boot the regular fw back up; the fw will automatically do a new FFS format (it 352 boot the regular fw back up; the fw will automatically do a new FFS format (it
327 will auto-format the blank FFS sectors, it won't function normally with all of 361 will auto-format the blank FFS sectors, it won't function normally with all of
328 these "asset" files missing. Foxconn's original factory production line station 362 these "asset" files missing. Foxconn's original factory production line station
329 must have uploaded these files to each phone via the TMFFS2 protocol, and our 363 must have uploaded these files to each phone via the TMFFS2 protocol, and our
330 FreeCalypso suite now features a tool that can replicate this feat: fc-fsio. 364 FreeCalypso suite now features a tool that can replicate this feat: fc-fsio.
331 365
332 FreeCalypso support for TIFFS 366 Aftermarket FFS for FreeCalypso on Compal & Pirelli targets
333 ============================= 367 ===========================================================
334 368
335 Aside from implementing and using it in our own gsm-fw, FreeCalypso offers 369 When we run our own FreeCalypso fw on "alien" (not native to us) Mot C1xx and
336 the following support for TIFFS: 370 Pirelli DP-L10 hardware, we don't use the FFS from their respectively original
337 371 firmwares: those original FFS instances don't contain any bits of interest to
338 1. We have a utility for "in vitro" examination of FFS images read out of GSM 372 us, trying to make our fw use the same FFS as Mot/Compal's or Pirelli's original
339 devices with fc-loadtool. This tiffs utility (along with mokoffs and pirffs 373 fw would be more trouble than benefit, and on one of the target devices in this
340 wrappers) lives in the ffstools top-level directory of the freecalypso-sw 374 family (Mot C155/156) the original FFS is in some different format. Instead we
341 source tree. This TIFFS "in vitro analyzer" utility supplants the earlier 375 create our own aftermarket FFS for our FreeCalypso fw on these alien hw targets,
342 mpffs-* tools, and adds some additional examination functionality. It is 376 using a different flash location from the original so that the original fw's FFS
343 strictly a "read only" tool, however - it is not designed for "in vitro" 377 cannot be mistaken for our own.
344 editing of TIFFS images. 378
345 379 On the Pirelli DP-L10 we put our aftermarket FFS in an area of the flash which
346 2. A number of FC tools may be strung together into a kit for editing the FFS 380 the official fw family uses as a staging area for over-the-air firmware updates,
347 content of a GSM device, e.g., for changing the IMEI. The following pieces 381 thus as long as you are not doing official fw updates over WLAN (i.e., if you
348 will be involved: 382 only run one fixed official fw version or flash different official fw versions
349 383 with fc-loadtool without going through "fw update" protocols), our aftermarket
350 * What is destined to eventually become our totally free GSM fw (the gsm-fw 384 FFS used by our run-from-RAM FreeCalypso firmwares should remain undisturbed
351 source subtree at the top of freecalypso-sw) does not contain any of the 385 while the phone is in the official fw mode.
352 actual GSM protocol stack (or even L1) functionality yet, but it already 386
353 contains both the FFS code and those components (ETM and TMFFS[12]) which 387 The situation is different on Mot C1xx phones. The lower-end C1xx models
354 are needed for interfacing an external "test mode shell" to this FFS 388 including the C139 (our primary hw target in this family) have too little RAM
355 implementation through the RVTMUX interface. And when our gsm-fw does gain 389 to run our FreeCalypso fw entirely out of RAM without flashing; the C155/156
356 the actual GSM functionality, the ability to build a minimal FFS+ETM-only 390 subfamily does have enough RAM to allow a complete FC GSM fw image to be loaded
357 configuration will still be retained. 391 and run via fc-xram under some conditions (we previously supported such usage
358 392 in our now-retired Citrine fw and may bring it back in the gcc-built config of
359 * The minimal FFS+ETM subset of gsm-fw can be built into a ramImage (runs 393 FC Selenite), but there is no place in the flash where we can put our
360 entirely from RAM via fc-xram, no flashing), and run on a physical device 394 aftermarket FFS without overwriting some part of the original fw or its data -
361 such as the GTA0x GSM modem via the fc-xram host utility; 395 thus our general procedure for running FreeCalypso on any C1xx model is to
362 396 convert the victim phone to FC on a long-term basis by flashing our modified
363 * After loading the ramImage, fc-xram will immediately exec our rvinterf host 397 bootloader, flashing one of our fw builds and establishing a FreeCalypso
364 utility (see rvinterf/README); 398 aftermarket FFS in a flash area designated by us.
365 399
366 * Once the GSM device is running what is effectively an FFS editing agent out 400 It was already mentioned earlier that the factory RF calibration values on these
367 of RAM, accessed via rvinterf over the serial channel, the user can run 401 alien phones are stored in non-TIFFS flash data structures of Mot/Compal's or
368 fc-tmsh or fc-fsio, and this "test mode shell" provides commands for writing 402 Foxconn's invention, and our currently supported FreeCalypso firmwares
369 things to FFS exactly like one would do in the factory production line 403 (Magnetite and Selenite) do not contain any code for reading these alien data
370 environment for which TI taylored their tools. 404 structures. (FC Citrine could read directly from Pirelli's factory data block,
371 405 but none of our fw offerings ever parsed Compal's weird flash records.) Instead
372 The "in vivo" method of editing the FFS content of a GSM device described above 406 our current approach is to have an external tool extract the bits of interest
373 will probably sound very convoluted, and you may find yourself asking for a way 407 from the alien factory records, convert them to our TI-standard format if
374 to do it "in vitro" instead: read the FFS out of flash with fc-loadtool, edit 408 necessary, and upload them into our FreeCalypso aftermarket FFS. The specifics
375 that image "in vitro" with some utility on your PC, and then use fc-loadtool 409 are as follows:
376 again to program it back into your device. But consider that an "in vitro" FFS 410
377 modification would involve erasing and rewriting all sectors of your FFS, 411 * The Pirelli DP-L10 is a breeze: simply run our special pirelli-magnetite-init
378 whereas an "in vivo" modification of some small file like the IMEI would be 412 command in fc-fsio while connected to a Magnetite or Selenite fw instance
379 just a short flash write operation without any erasures at all, i.e., kinder 413 running with our aftermarket FFS, and the tool will copy both the IMEI and
380 on the flash. 414 the RF calibration records from Pirelli's factory data block into our
381 415 aftermarket FFS.
382 In any case, the "in vivo" method is already available now because all of the 416
383 components involved therein are also needed for other development uses in the 417 * Mot C1xx phones present a lot more hassle: our current official procedure is
384 FreeCalypso project, whereas developing a fully-functional "in vitro" 418 to make a dump of the flash prior to the xenotransplantation procedure (also
385 alternative (one that can create an FFS image "de novo" from a tree of files 419 serves as a backup), extract the RF calibration values with our c1xx-calextr
386 and directories a la mkfs.jffs2, or add new files to an existing TIFFS image 420 tool, and then later in the procedure when you initialize your aftermarket FFS
387 etc) would be a good amount of extra work which we otherwise don't need - hence 421 with fc-fsio, upload these extracted and format-converted RF calibration files
388 the latter is not very likely to be written any time soon. 422 as one of the several steps involved. You will need to enter your IMEI
389 423 manually: we never figured out where Mot/Compal have it stored and how it is
390 However, if the "in vitro" modification you seek is something trivial like 424 obfuscated.
391 changing the byte content of a file such as /pcm/IMEI or /gsm/com/rfcap without 425
392 changing its length, you can use the existing "in vitro, read-only" tiffs host 426 FreeCalypso host tools for TIFFS
393 utility to find the exact byte location of the file data within the TIFFS image, 427 ================================
394 and then use your favourite hex editor to whack whatever new byte content you 428
395 like at that offset. 429 Our FC host tools package supports TIFFS in two ways:
430
431 1) Our primary tool for working with GSM device file systems is fc-fsio. When
432 run against a compatible firmware version (primarily our own, but Pirelli's
433 proprietary fw is also compatible), fc-fsio allows various read and write
434 operations to be performed on the target device FFS.
435
436 2) We have a TIFFS In Vitro Analyzer (IVA) tool for "in vitro" examination of
437 FFS images that have been read out of raw flash with fc-loadtool. See the
438 TIFFS-IVA-usage article for more information.
439
440 In addition to the above, back in the days of Openmoko (back when the Openmoko
441 community was still active and we considered ourselves a part of it) we had
442 produced a kit for editing the modem FFS on Openmoko GTA01/02 devices, giving
443 users an easy way to change their /pcm/IMEI file. Changing IMEIs for no good
444 reason is completely pointless and is actually detrimental rather than helpful
445 for privacy, but whoever came up with the edicts that "the IMEI MUST be
446 immutable" had obviously failed Human Psychology 101: declaring something to be
447 forbidden causes people to want it simply because it is forbidden and for no
448 other reason - hence the popular demand for IMEI changing tools.
449
450 Our Openmoko FFS editing kit from early 2014 consisted of a very early version
451 of what much later became the present FC host tools package (more specifically,
452 it was before fc-fsio, and the set-imeisv command had been hacked into fc-tmsh
453 instead) plus a pair of "in vivo" FFS editing agent target binaries. Our
454 current FC host tools fully supplant the ancient version in that 2014 kit, but
455 we do not currently have a non-deprecated replacement for the old "in vivo" FFS
456 editing agent: those FFS editing agent binaries were built from our old gsm-fw
457 framework which was deemed to be a dead end in 2016 and fully retired in 2018.
458
459 We have not produced a new and actively maintained replacement for the "in vivo"
460 FFS editing function which was previously provided as a side product of the old
461 gsm-fw framework because we have no real need for it: the *only* use case we
462 have for it involves Openmoko devices, and even then only two special use cases:
463
464 1) If someone wishes to change their IMEI from within the FreeRunner (without
465 using an external serial cable) *or* while keeping an old firmware version
466 (without updating to moko13 or later), or
467
468 2) If someone has updated the modem fw on their FR to one of our current
469 releases, wishes to fix the /gsm/com/rfcap file to reflect the true tri900 or
470 tri850 band configuration of their device, but wishes to do it from within the
471 FR, without using an external serial cable.
472
473 If anyone does need to exercise one of the two special use cases listed above,
474 they can use the "in vivo" FFS editing agent binaries from the ancient
475 ffs-edit-kit-r1.tar.bz2 package - they are ancient, but will do the job just
476 fine for both use cases in question.