testing the free calypso software
Michael Spacefalcon
msokolov at ivan.Harhan.ORG
Tue Jan 28 21:39:48 CET 2014
Norayr Chilingarian <norayr at 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 <joerg at 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
More information about the community
mailing list