FreeCalypso > hg > freecalypso-sw

comparison doc/TIFFS-Overview @ 430:14618bd924ec

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/RVTMUX and doc/TIFFS-Overview: updates
author Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
date Sat, 21 Jun 2014 21:28:56 +0000
parents 3d88461d8284
children
comparison
equal deleted inserted replaced
429:f114f5c547ec 430:14618bd924ec
124 flash offset 0x380000. 124 flash offset 0x380000.
125 125
126 * On the Pirelli DP-L10, the FFS used by the original proprietary fw occupies 126 * On the Pirelli DP-L10, the FFS used by the original proprietary fw occupies
127 18 sectors of 256 KiB each (for 4.5 MiB in total), starting at the beginning 127 18 sectors of 256 KiB each (for 4.5 MiB in total), starting at the beginning
128 of the 2nd flash chip select (0x02000000 in the ARM7 address space). 128 of the 2nd flash chip select (0x02000000 in the ARM7 address space).
129
130 * 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.
132 C11x/123 use smaller FFS configurations, whereas C155/156 seem to have
133 switched to some other FFS format, different from our familiar TIFFS.
129 134
130 * The smallest real FFS configuration called for by the table in dev.c in TI's 135 * The smallest real FFS configuration called for by the table in dev.c in TI's
131 original Leonardo fw source is 3 sectors of 64 KiB each; the same table also 136 original Leonardo fw source is 3 sectors of 64 KiB each; the same table also
132 sports a 4 KiB x 4 configuration for RAM-based testing (emulation of FFS in 137 sports a 4 KiB x 4 configuration for RAM-based testing (emulation of FFS in
133 RAM without real flash). 138 RAM without real flash).
294 building my own Calypso-based GSM "dumbphone", I'll be able to say exactly what 299 building my own Calypso-based GSM "dumbphone", I'll be able to say exactly what
295 it would take to recreate these RF calibration values if they are lost. But 300 it would take to recreate these RF calibration values if they are lost. But
296 until then the only advice I can give is to make a backup copy of your modem 301 until then the only advice I can give is to make a backup copy of your modem
297 FFS with fc-loadtool, and to save it securely. 302 FFS with fc-loadtool, and to save it securely.
298 303
304 Compal and Pirelli differences
305 ==============================
306
307 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
309 without major deviations. In contrast, both Compal (Mot C1xx) and Foxconn
310 (Pirelli DP-L10) moved the vital per-unit factory data (IMEI and RF calibration)
311 out of the FFS into their own ad hoc flash data structures (which are very
312 difficult to reverse-engineer and make use of, unfortunately), leaving their FFS
313 only for less critical data.
314
315 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
317 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
319 even displays a message on the LCD as it does so) and carry on happily as a
320 "fresh" or "blank", perfectly functional and usable phone.
321
322 In Pirelli's case, booting their official fw with blank FFS sectors will also
323 result in the FFS being automatically formatted, but their fw expects some
324 static "asset" files to be present in this FFS: UI graphics and language
325 strings, ringtones, firmware images for the WiFi and VoIP processors and some
326 static configuration files, about 3 MiB in total. Thus although the firmware
327 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
329 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.
331
299 FreeCalypso support for TIFFS 332 FreeCalypso support for TIFFS
300 ============================= 333 =============================
301 334
302 Aside from implementing and using it in our own gsm-fw, FreeCalypso offers 335 Aside from implementing and using it in our own gsm-fw, FreeCalypso offers
303 the following support for TIFFS: 336 the following support for TIFFS:
306 devices with fc-loadtool. This tiffs utility (along with mokoffs and pirffs 339 devices with fc-loadtool. This tiffs utility (along with mokoffs and pirffs
307 wrappers) lives in the ffstools top-level directory of the freecalypso-sw 340 wrappers) lives in the ffstools top-level directory of the freecalypso-sw
308 source tree. This TIFFS "in vitro analyzer" utility supplants the earlier 341 source tree. This TIFFS "in vitro analyzer" utility supplants the earlier
309 mpffs-* tools, and adds some additional examination functionality. It is 342 mpffs-* tools, and adds some additional examination functionality. It is
310 strictly a "read only" tool, however - it is not designed for "in vitro" 343 strictly a "read only" tool, however - it is not designed for "in vitro"
311 editing" of TIFFS images. 344 editing of TIFFS images.
312 345
313 2. A number of FC tools may be strung together into a kit for editing the FFS 346 2. A number of FC tools may be strung together into a kit for editing the FFS
314 content of a GSM device, e.g., for changing the IMEI. The following pieces 347 content of a GSM device, e.g., for changing the IMEI. The following pieces
315 will be involved: 348 will be involved:
316 349
326 * The minimal FFS+ETM subset of gsm-fw can be built into a ramImage (runs 359 * The minimal FFS+ETM subset of gsm-fw can be built into a ramImage (runs
327 entirely from RAM via fc-xram, no flashing), and run on a physical device 360 entirely from RAM via fc-xram, no flashing), and run on a physical device
328 such as the GTA0x GSM modem via the fc-xram host utility; 361 such as the GTA0x GSM modem via the fc-xram host utility;
329 362
330 * After loading the ramImage, fc-xram will immediately exec our rvinterf host 363 * After loading the ramImage, fc-xram will immediately exec our rvinterf host
331 utility described in the RVTMUX write-up; 364 utility (see rvinterf/README);
332 365
333 * Once the GSM device is running what is effectively an FFS editing agent out 366 * Once the GSM device is running what is effectively an FFS editing agent out
334 of RAM, accessed via rvinterf over the serial channel, the user will be able 367 of RAM, accessed via rvinterf over the serial channel, the user can run
335 to run fc-tmsh (or perhaps the FFS operations will be implemented in some 368 fc-tmsh or fc-fsio, and this "test mode shell" provides commands for writing
336 other utility, we'll see), and that "test mode shell" will provide commands 369 things to FFS exactly like one would do in the factory production line
337 for writing things to FFS exactly like one would do in the factory production 370 environment for which TI taylored their tools.
338 line environment for which TI taylored their tools.
339 371
340 The "in vivo" method of editing the FFS content of a GSM device described above 372 The "in vivo" method of editing the FFS content of a GSM device described above
341 will probably sound very convoluted, and you may find yourself asking for a way 373 will probably sound very convoluted, and you may find yourself asking for a way
342 to do it "in vitro" instead: read the FFS out of flash with fc-loadtool, edit 374 to do it "in vitro" instead: read the FFS out of flash with fc-loadtool, edit
343 that image "in vitro" with some utility on your PC, and then use fc-loadtool 375 that image "in vitro" with some utility on your PC, and then use fc-loadtool
345 modification would involve erasing and rewriting all sectors of your FFS, 377 modification would involve erasing and rewriting all sectors of your FFS,
346 whereas an "in vivo" modification of some small file like the IMEI would be 378 whereas an "in vivo" modification of some small file like the IMEI would be
347 just a short flash write operation without any erasures at all, i.e., kinder 379 just a short flash write operation without any erasures at all, i.e., kinder
348 on the flash. 380 on the flash.
349 381
350 In any case, the "in vivo" method will definitely be available soon because all 382 In any case, the "in vivo" method is already available now because all of the
351 of the components involved therein are also needed for other development uses 383 components involved therein are also needed for other development uses in the
352 in the FreeCalypso project, whereas developing a fully-functional "in vitro" 384 FreeCalypso project, whereas developing a fully-functional "in vitro"
353 alternative (one that can create an FFS image "de novo" from a tree of files 385 alternative (one that can create an FFS image "de novo" from a tree of files
354 and directories a la mkfs.jffs2, or add new files to an existing TIFFS image 386 and directories a la mkfs.jffs2, or add new files to an existing TIFFS image
355 etc) would be a good amount of extra work which we otherwise don't need - hence 387 etc) would be a good amount of extra work which we otherwise don't need - hence
356 the latter is not very likely to be written any time soon. 388 the latter is not very likely to be written any time soon.
357 389