Norayr Chilingarian <nor...@arnet.am> wrote: > If someone has no backup of calibration data, can she use calibration > data from other phone? > Then we can send our data to that person. Or it won't work this way? > I probably don't understand it well.
joerg Reisenweber <jo...@openmoko.org> followed up: > Not recommended and not entirely correct procedure but nevertheless should > sort of work, yes. You might want to edit the IMEI to what yours been, before > (or after) you flash that alien calib data. I still have a lot of learning ahead of me in this department, but per my current understanding, the purpose of RF calibration is to measure those physical variations which exist from one produced unit to the next, and to record these measurements (or some values derived from the measurements) in per-device non-volatile memory, such that the modem firmware can then take account of and compensate for these per- device differences. I'm guessing it has something to do with non- linearity in the amplifiers, process variations in the ADCs and DACs, temperature sensitivities etc. This document from TI attempts to explain some of it: ftp://ftp.ifctf.org/pub/GSM/Calypso/rf_calibration.pdf So my current understanding is that at least some of the calibration values will differ from one unit to the next, and I reason that taking the values from one unit and using them on a different unit may cause some poor RF performance, or out-of-spec operation in terms of Tx power levels perhaps. I have no way of knowing just how much difference there is between one GTA02 and the next, and hence what would the magnitude of ill effects from a calibration transplant be. A good experiment would be to compare the calibration values (properly programmed at the factory, presumably) read out of different GTA02 units. The flash dump from my GTA02 can be found here: ftp://ftp.ifctf.org/pub/GSM/GTA02/flashdump.bin I made that dump from my GTA02 back in 2013-04, and put it on the FTP site in 2013-07, long before the recent project breakthroughs. The first 0x225594 bytes of that flash image (just under 2.25 MiB) contain the moko10 fw image (what my FR came with); the interesting part (the FFS) starts at offset 0x380000. Using the new tiffs/mokoffs tools I just wrote (get them from the Hg repository on Bitbucket or wait for my coming-soon tarball release), we can examine the content in this FFS image. Let's start with the basic vital stats: $ mokoffs -f flashdump.bin blkhdr Block 0: age FFFF, type/status AB Block 1: age FFFF, type/status BD Block 2: age FFFF, type/status BD Block 3: age FFFF, type/status BD Block 4: age FFFF, type/status BD Block 5: age FFFF, type/status BD Block 6: age FFFF, type/status BF $ mokoffs -f flashdump.bin fsinfo Active inode block (AB) is block #0 Root inode is #1 Root inode (format) name: /ffs-root (mokoffs is a trivial wrapper around tiffs that spares the user from having to specify the 64x7 FFS organization argument every time, and -f means that one is looking at a complete flash dump, rather than just the FFS sectors - hence the tool needs to go to offset 0x380000.) Listing the actual content is easy too: $ mokoffs -f flashdump.bin ls fr 4096 /.journal d /gsm d /gsm/rf d /gsm/rf/tx f 512 /gsm/rf/tx/ramps.900 f 128 /gsm/rf/tx/levels.900 f 128 /gsm/rf/tx/calchan.900 f 512 /gsm/rf/tx/ramps.1800 f 128 /gsm/rf/tx/levels.1800 f 128 /gsm/rf/tx/calchan.1800 f 512 /gsm/rf/tx/ramps.850 f 128 /gsm/rf/tx/levels.850 f 128 /gsm/rf/tx/calchan.850 f 512 /gsm/rf/tx/ramps.1900 f 128 /gsm/rf/tx/levels.1900 f 128 /gsm/rf/tx/calchan.1900 d /gsm/rf/rx f 40 /gsm/rf/rx/calchan.900 f 8 /gsm/rf/rx/agcparams.900 f 40 /gsm/rf/rx/calchan.1800 f 8 /gsm/rf/rx/agcparams.1800 f 40 /gsm/rf/rx/calchan.850 f 8 /gsm/rf/rx/agcparams.850 f 40 /gsm/rf/rx/calchan.1900 f 8 /gsm/rf/rx/agcparams.1900 f 2 /gsm/rf/afcdac f 2 /gsm/rf/stdmap f 24 /gsm/rf/afcparams d /gsm/com f 16 /gsm/com/rfcap d /gsm/l3 f 144 /gsm/l3/rr_white_list f 256 /gsm/l3/rr_black_list f 44 /gsm/l3/eplmn d /gsm/cops f 16 /gsm/cops/operimsi d /pcm f 12 /pcm/CGMI f 13 /pcm/CGMM f 14 /pcm/CGMR f 8 /pcm/IMEI f 9 /pcm/IMSI f 23 /pcm/LRN f 21 /pcm/LMN f 22 /pcm/LDN d /sys d /mmi d /vos d /vos/vm d /vos/vrm d /vos/vrp d /var d /var/log d /var/tst d /var/dbg f 3152 /var/dbg/dar d /Test f 4 /Test/Teststate.bin f 196 /Test/Production.bin d /aud f 164 /aud/para0.cfg Most of the above should be self-explanatory; the numbers shown before the pathname for files ('f' as opposed to 'd') are the lengths of each file in bytes. The files containing the RF calibration values we are currently discussing are the ones under the /gsm/rf subtree. Let's look at the content of some files: $ mokoffs -f flashdump.bin cat -v /pcm/CGMI FIC/OpenMoko $ mokoffs -f flashdump.bin cat -v /pcm/CGMM Neo1973 GTA02 Almost all files in the GSM file system are binary rather than ASCII, so when cat'ing a file, use -v (standard cat option) or -h (hex dump), unless you are redirecting the output to a file. Even for files that contain ASCII strings like the two above, I used cat -v for safety. Here's a pure binary file: $ mokoffs -f flashdump.bin cat -h /gsm/com/rfcap 00000000: 00 1F 41 14 00 00 00 00 50 00 00 A5 05 00 C0 00 ..A.....P....... Now for a "forensic" command - let's see in which order all of the FFS content we've just listed has been created back at the factory: $ mokoffs -f flashdump.bin lsino #0001 d / active root #0002 f /.journal read-only object #0003 d /gsm #0004 d /pcm #0005 d /sys #0006 d /mmi #0007 d /vos #0008 d /var #0009 d /gsm/rf #000a d /gsm/com #000b d /vos/vm #000c d /vos/vrm #000d d /vos/vrp #000e d /var/log #000f d /var/tst #0010 d /gsm/rf/tx #0011 d /gsm/rf/rx #0012 d /Test #0013 ~ /Test/Production.bin #0014 ~ /pcm/IMEI #0015 ~ /gsm/com/rfcap #0016 ~ /Test/Teststate.bin #0017 f /pcm/CGMI #0018 f /pcm/CGMM #0019 f /pcm/CGMR #001a d /aud #001b f /aud/para0.cfg #001c ~ /Test/Production.bin #001d ~ /Test/Production.bin #001e ~ /Test/Production.bin #001f d /var/dbg #0020 ~ /var/dbg/dar #0021 ~ -nopath- parent: #20 #0022 ~ -nopath- parent: #21 #0023 ~ /gsm/com/rfcap #0024 d /gsm/l3 #0025 f /gsm/rf/afcdac #0026 f /gsm/rf/stdmap #0027 f /gsm/rf/afcparams #0028 ~ /Test/Teststate.bin #0029 ~ /gsm/rf/rx/calchan.900 #002a ~ /gsm/rf/rx/agcparams.900 #002b ~ /gsm/rf/rx/calchan.1800 #002c ~ /gsm/rf/rx/agcparams.1800 #002d ~ /Test/Teststate.bin #002e ~ /gsm/rf/tx/ramps.900 #002f ~ /gsm/rf/tx/levels.900 #0030 ~ /gsm/rf/tx/calchan.900 #0031 ~ /gsm/rf/tx/ramps.1800 #0032 ~ /gsm/rf/tx/levels.1800 #0033 ~ /gsm/rf/tx/calchan.1800 #0034 ~ /Test/Teststate.bin #0035 f /gsm/rf/rx/calchan.900 #0036 f /gsm/rf/rx/agcparams.900 #0037 f /gsm/rf/rx/calchan.1800 #0038 f /gsm/rf/rx/agcparams.1800 #0039 ~ /Test/Teststate.bin #003a f /gsm/rf/tx/ramps.900 #003b f /gsm/rf/tx/levels.900 #003c f /gsm/rf/tx/calchan.900 #003d f /gsm/rf/tx/ramps.1800 #003e f /gsm/rf/tx/levels.1800 #003f f /gsm/rf/tx/calchan.1800 #0040 ~ /Test/Teststate.bin #0041 f /gsm/rf/rx/calchan.850 #0042 f /gsm/rf/rx/agcparams.850 #0043 f /gsm/rf/rx/calchan.1900 #0044 f /gsm/rf/rx/agcparams.1900 #0045 ~ /Test/Teststate.bin #0046 f /gsm/rf/tx/ramps.850 #0047 f /gsm/rf/tx/levels.850 #0048 f /gsm/rf/tx/calchan.850 #0049 f /gsm/rf/tx/ramps.1900 #004a f /gsm/rf/tx/levels.1900 #004b f /gsm/rf/tx/calchan.1900 #004c f /Test/Teststate.bin #004d ~ /var/dbg/dar #004e ~ -nopath- parent: #4d #004f ~ /gsm/com/rfcap #0050 ~ -nopath- parent: #4e #0051 ~ /pcm/IMSI #0052 ~ /gsm/l3/eplmn #0053 ~ /gsm/l3/eplmn #0054 d /gsm/cops #0055 ~ /gsm/cops/operimsi #0056 ~ /var/dbg/dar #0057 ~ -nopath- parent: #56 #0058 ~ /gsm/com/rfcap #0059 ~ -nopath- parent: #57 #005a ~ /gsm/l3/eplmn #005b ~ /gsm/l3/eplmn #005c ~ /gsm/cops/operimsi #005d ~ /var/dbg/dar #005e ~ -nopath- parent: #5d #005f ~ /gsm/com/rfcap #0060 ~ -nopath- parent: #5e #0061 ~ /Test/Production.bin #0062 ~ /Test/Production.bin #0063 ~ /Test/Production.bin #0064 ~ /var/dbg/dar #0065 ~ -nopath- parent: #64 #0066 ~ /gsm/com/rfcap #0067 ~ -nopath- parent: #65 #0068 ~ /var/dbg/dar #0069 ~ -nopath- parent: #68 #006a ~ /gsm/com/rfcap #006b ~ -nopath- parent: #69 #006c ~ /var/dbg/dar #006d ~ -nopath- parent: #6c #006e ~ /gsm/com/rfcap #006f ~ -nopath- parent: #6d #0070 ~ /var/dbg/dar #0071 ~ -nopath- parent: #70 #0072 ~ /gsm/com/rfcap #0073 ~ -nopath- parent: #71 #0074 ~ /var/dbg/dar #0075 ~ -nopath- parent: #74 #0076 ~ /gsm/com/rfcap #0077 ~ -nopath- parent: #75 #0078 ~ /pcm/LDN #0079 ~ /pcm/LRN #007a ~ /pcm/LMN #007b ~ /gsm/l3/eplmn #007c ~ /pcm/LDN #007d ~ /pcm/LRN #007e ~ /pcm/LMN #007f ~ /gsm/com/rfcap #0080 ~ /gsm/l3/eplmn #0081 ~ /gsm/l3/rr_black_list #0082 ~ /pcm/LRN #0083 ~ /pcm/LMN #0084 ~ /pcm/LRN #0085 ~ /pcm/LMN #0086 ~ /gsm/l3/eplmn #0087 ~ /gsm/com/rfcap #0088 ~ /gsm/l3/eplmn #0089 ~ /gsm/l3/eplmn #008a ~ /gsm/cops/operimsi #008b ~ /gsm/l3/eplmn #008c f /gsm/l3/rr_white_list #008d f /gsm/l3/rr_black_list #008e f /pcm/IMEI #008f ~ /Test/Production.bin #0090 ~ /Test/Production.bin #0091 f /Test/Production.bin #0092 ~ /var/dbg/dar #0093 ~ -nopath- parent: #92 #0094 ~ /gsm/com/rfcap #0095 ~ -nopath- parent: #93 #0096 ~ /var/dbg/dar #0097 ~ -nopath- parent: #96 #0098 ~ /gsm/com/rfcap #0099 ~ -nopath- parent: #97 #009a ~ /gsm/l3/eplmn #009b ~ /var/dbg/dar #009c ~ -nopath- parent: #9b #009d ~ /gsm/com/rfcap #009e ~ -nopath- parent: #9c #009f ~ /gsm/l3/eplmn #00a0 ~ /gsm/com/rfcap #00a1 ~ /gsm/com/rfcap #00a2 ~ /gsm/com/rfcap #00a3 f /pcm/IMSI #00a4 ~ /gsm/l3/eplmn #00a5 ~ /gsm/cops/operimsi #00a6 ~ /gsm/l3/eplmn #00a7 ~ /pcm/LDN #00a8 f /pcm/LRN #00a9 f /pcm/LMN #00aa f /pcm/LDN #00ab ~ /gsm/l3/eplmn #00ac ~ /gsm/com/rfcap #00ad ~ /gsm/l3/eplmn #00ae f /gsm/cops/operimsi #00af ~ /var/dbg/dar #00b0 ~ -nopath- parent: #af #00b1 ~ /gsm/com/rfcap #00b2 ~ -nopath- parent: #b0 #00b3 ~ /gsm/com/rfcap #00b4 ~ /gsm/com/rfcap #00b5 ~ /gsm/com/rfcap #00b6 ~ /var/dbg/dar #00b7 ~ -nopath- parent: #b6 #00b8 ~ /gsm/com/rfcap #00b9 ~ -nopath- parent: #b7 #00ba ~ /gsm/l3/eplmn #00bb ~ /var/dbg/dar #00bc ~ -nopath- parent: #bb #00bd ~ /gsm/com/rfcap #00be ~ -nopath- parent: #bc #00bf ~ /gsm/l3/eplmn #00c0 ~ /var/dbg/dar #00c1 ~ -nopath- parent: #c0 #00c2 ~ /gsm/com/rfcap #00c3 ~ -nopath- parent: #c1 #00c4 ~ /var/dbg/dar #00c5 ~ -nopath- parent: #c4 #00c6 ~ /gsm/com/rfcap #00c7 ~ -nopath- parent: #c5 #00c8 ~ /gsm/l3/eplmn #00c9 ~ /var/dbg/dar #00ca ~ -nopath- parent: #c9 #00cb ~ /gsm/com/rfcap #00cc ~ -nopath- parent: #ca #00cd ~ /gsm/l3/eplmn #00ce ~ /var/dbg/dar #00cf ~ -nopath- parent: #ce #00d0 ~ /gsm/com/rfcap #00d1 ~ -nopath- parent: #cf #00d2 f /gsm/l3/eplmn #00d3 f /var/dbg/dar #00d4 . -nopath- parent: #d3 #00d5 f /gsm/com/rfcap #00d6 . -nopath- parent: #d4 A '.' character in the place of 'f' or 'd' denotes segment inodes (a TIFFS internal implementation detail, read the source code for more details), and a '~' character in the place of 'f', 'd' or '.' means a deleted or overwritten object - its original type is not readily visible without deeper forensic digging, which the present tool doesn't do currently. But one can see the old content of overwritten or deleted files, as long as that flash space hasn't been reclaimed yet. For example, here is the final content of the production test status files on this FR: $ mokoffs -f flashdump.bin cat -h /Test/Production.bin 00000000: 00 01 00 F0 31 32 33 34 00 00 05 79 47 54 41 30 ....1234...yGTA0 00000010: 32 2D 56 35 20 20 20 20 20 20 20 20 38 00 47 54 2-V5 8.GT 00000020: 41 30 32 30 31 20 20 20 20 20 44 4D 30 31 20 20 A0201 DM01 00000030: 20 20 20 20 30 39 31 31 30 34 31 30 30 34 38 41 09110410048A 00000040: 39 31 30 31 32 34 32 FF FF FF 32 30 30 FF 4D 6F 9101242...200.Mo 00000050: 62 69 6C 65 20 50 41 53 53 20 38 41 39 31 30 31 bile PASS 8A9101 00000060: 32 34 32 00 00 00 00 00 50 50 50 FF FF FF FF FF 242.....PPP..... 00000070: FF FF FF FF FF FF FF FF FF FF FF FF 44 20 20 20 ............D 00000080: 20 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ............... 00000090: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 000000A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 000000B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 000000C0: AA BB CC DD .... $ mokoffs -f flashdump.bin cat -h /Test/Teststate.bin 00000000: 7F 00 00 00 .... Looking at the lsino output above, we see that /Test/Production.bin was first created at inode #13 (hex). What was its original content? Here's the answer: $ mokoffs -f flashdump.bin catino -h 13 00000000: 00 01 00 F0 31 32 33 34 FF FF FF FF FF FF FF FF ....1234........ 00000010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 00000020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 00000030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 00000040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 00000050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 00000060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 00000070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 00000080: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 00000090: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 000000A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 000000B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 000000C0: AA BB CC DD .... Looking at all of the intermediate states (in the history revealed with the lsino command) is left as an exercise for the reader. And yes, there is that file named /pcm/IMEI in there, with quite obvious content. Use cat -h as it's a binary file, two IMEI digits per byte, using the least significant nibble first - so it looks counter-intuitive in a hex dump. So yes, by publishing the flash dump from my GTA02 I have also published this unit's IMEI. I don't really mind, as this device is strictly for FreeCalypso development, and is unlikely to ever see "real" personal use. Anyway, back to the original subject of discussion - the RF calibration values stored in this FFS. One can extract the complete FFS content like this: $ mkdir myffs $ mokoffs -f myflashdump.bin xtr myffs I invite you to extract the content of your Freerunner's FFS (read your FFS out with fc-loadtool, or use the backup file you should have made before flashing leo2moko etc, and do mokoffs xtr on that file), do the same extraction on the image from my FTP site (from my FR), and then do a classic diff -r between the two extracted directory trees. The extraction step (mokoffs xtr, or the equivalent mpffs-xtr utility from the older tools I wrote and released back in the summer) is essential; if you simply diff the two FFS images, you'll get a "Binary files $x and $y differ" message, but no useful information as to what the actual content differences are. VLR, SF _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community