FreeCalypso > hg > freecalypso-reveng

comparison pirelli/rfcal @ 220:2cc7a17c3859

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
pirelli/rfcal: new understanding
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 16 Nov 2017 04:19:58 +0000
parents 30ba25056ecd
children
comparison
equal deleted inserted replaced
219:e3bbb8cfbbc0 220:2cc7a17c3859
1 The 64 KiB flash sector at 0x027F0000 (the last sector of the 2nd flash bank) 1 The 64 KiB flash sector at 0x027F0000 (the last sector of the 2nd flash bank)
2 contains per-unit factory data, including the IMEI and RF calibration values. 2 contains per-unit factory data, including the IMEI and RF calibration values.
3 The location of the IMEI record (at offset 0x504) was found back in 2013-07 and 3 The location of the IMEI record (at offset 0x504) was found back in 2013-07 and
4 its encryption was figured out in 2013-11, but it took a bit longer to find the 4 its encryption was figured out in 2013-11, but it took a bit longer to find the
5 RF calibration data. But I finally found most of the latter as well. Here 5 RF calibration data. Most of the RF calibration bits were found in 2014-07,
6 they are: 6 but the complete picture presented below has only been reconstructed in 2017-11.
7
8 The data structure corresponding to TI's RF calibration files listed in the
9 config_files_common[] and config_files_band[] arrays in l1_cust.c begins at
10 offset 0x528, and has space allocated for each and every one of the files
11 listed in those arrays in TI's canonical version, in the same order as in that
12 canonical version, with the single exception of /sys/uartswitch. Behold:
7 13
8 Hex offset Corresponding FFS file in TI's canonical version 14 Hex offset Corresponding FFS file in TI's canonical version
9 ---------------------------------------------------------------- 15 ----------------------------------------------------------------
16 0528 /gsm/rf/afcdac
17 052A checksum byte
18 052B 442 (0x1BA) unused (all FF) bytes making room for:
19 /gsm/rf/stdmap
20 /gsm/rf/afcparams
21 /gsm/rf/rx/agcglobals
22 /gsm/rf/rx/il2agc
23 /gsm/rf/rx/agcwords
24
10 06E5 /sys/adccal 25 06E5 /sys/adccal
11 0709 checksum byte 26 0709 checksum byte
27 070A 33 (0x21) unused (all FF) bytes making room for:
28 /sys/abb
12 29
13 072B /gsm/rf/tx/ramps.900 30 072B /gsm/rf/tx/ramps.900
14 092B checksum byte 31 092B checksum byte
15 092C /gsm/rf/tx/levels.900 32 092C /gsm/rf/tx/levels.900
16 09AC checksum byte 33 09AC checksum byte
26 0F31 checksum byte 43 0F31 checksum byte
27 0F32 /gsm/rf/tx/levels.1900 44 0F32 /gsm/rf/tx/levels.1900
28 0FB2 checksum byte 45 0FB2 checksum byte
29 0FB3 /gsm/rf/tx/calchan.1900 46 0FB3 /gsm/rf/tx/calchan.1900
30 1033 checksum byte 47 1033 checksum byte
48 1034 123 (0x7B) unused (all FF) bytes making room for:
49 /gsm/rf/tx/caltemp.900
50 /gsm/rf/tx/caltemp.1800
51 /gsm/rf/tx/caltemp.1900
31 52
32 10AF /gsm/rf/rx/calchan.900 53 10AF /gsm/rf/rx/calchan.900
33 10D7 checksum byte 54 10D7 checksum byte
34 10D8 /gsm/rf/rx/agcparams.900 55 10D8 /gsm/rf/rx/agcparams.900
35 10E0 checksum byte 56 10E0 checksum byte
39 1112 checksum byte 60 1112 checksum byte
40 1113 /gsm/rf/rx/calchan.1900 61 1113 /gsm/rf/rx/calchan.1900
41 113B checksum byte 62 113B checksum byte
42 113C /gsm/rf/rx/agcparams.1900 63 113C /gsm/rf/rx/agcparams.1900
43 1144 checksum byte 64 1144 checksum byte
65 1145 more than enough unused (all FF) bytes to fit:
66 /gsm/rf/rx/caltemp.900
67 /gsm/rf/rx/caltemp.1800
68 /gsm/rf/rx/caltemp.1900
69
70 TI's canonical version classifies each of the files listed in those
71 config_files_common[] and config_files_band[] arrays into one of 8 categories:
72
73 f = RF calibration
74 F = RF config
75 r = Rx calibration
76 R = Rx config
77 t = Tx calibration
78 T = Tx config
79 s = system calibration
80 S = system config
81
82 Pirelli's factory data structure allocates space for all of the possible files
83 in all 8 categories, but out of all these spaces, the only ones that are
84 actually filled with bits (not all FF) are the ones corresponding to the 4
85 "calibration" categories, and not the "config" ones. It is my (Mychaela's)
86 guess that Foxconn folks probably preserved the logic invoked by me 102 through
87 me 109 commands unchanged from TI's original, and thus had the theoretical
88 ability to write everything into their invented data structure, but only issued
89 the me 102/104/106/108 commands in their factory production flow, hence only
90 the "calibration" record slots got filled.
91
92 Please note that the slots corresponding to the missing files in the "config"
93 categories are filled with all FF bytes, and do NOT contain the "standard" or
94 "never changed" bits compiled into the firmware. Because these bits are not
95 present in the factory record in the flash, any aftermarket firmware running on
96 these phones needs to provide these bits on its own. This category very notably
97 includes the afcparams table.
44 98
45 Each calibration record is followed by a checksum byte. It is a simple ripple- 99 Each calibration record is followed by a checksum byte. It is a simple ripple-
46 carry sum of all bytes in the preceding record. Note that this checksum byte 100 carry sum of all bytes in the preceding record. Note that this checksum byte
47 is always 0 for the ramps records, as each correctly-formed ramp adds up to 128 101 is always 0 for the ramps records, as each correctly-formed ramp adds up to 128
48 (0x80), and the array has an even number of ramps in total. 102 (0x80), and the array has an even number of ramps in total. It is also my
103 (Mychaela's) guess that Pirelli's fw probably uses this checksum byte to detect
104 that the "config" files are missing and avoid loading the FF bytes into the
105 corresponding L1 RAM data structures: the sum of all FF bytes in the data space
106 does not equal FF unless the record length is 1 byte or 257 or 513... bytes,
107 and none of TI's calibration/config records match those byte lengths.
49 108
50 Unfortunately though, I have not been able to locate these two records: 109 Absence of the afcparams table
110 ==============================
51 111
52 /gsm/rf/afcdac 112 The afcparams table is placed in the "RF config" category in TI's TCS211
53 /gsm/rf/afcparams 113 reference fw, rather than "RF calibration". It appears that in the very old
114 days of Sara RF (before the D-Sample) this table contained only the Psi
115 constants (no min/max/nominal DAC), and these Psi constants were tweaked in the
116 source code in l1_rfN.h, rather than via per-unit calibration - hence the
117 "config" rather than "calibration" classification. Then RF 10 (Clara) came
118 along, TI started using "plain" VCXOs without the "TC" part, they implemented a
119 new AFC algorithm (VCXO_ALGO), and the min/max/nominal DAC fields got added to
120 the afcparams table. The complete story is not clear, but the end result is
121 that when the days of Openmoko came around, FIC (OM's factory) had a production
122 line calibration program, presumably from TI (I never got a copy of it, but I
123 was told it was a Windows binary sans source), that performed individual
124 per-unit calibration of the VCXO along with the expected Rx and Tx band
125 calibrations, and the afcparams table is calibrated per unit on Openmoko
126 devices.
54 127
55 These two files appear in Openmoko's FFS on GTA02 modems, and the byte content 128 Both theory and practice indicate that OM's way of calibrating the afcparams
56 differs for each physical unit, so I assume that these values really do need to 129 table on a per-unit basis is not the only way: the per-unit calibration does
57 be calibrated per unit, but I haven't been able to locate them in Pirelli's 130 not help much in practice because of the strong temperature sensitivity, and
58 factory data block. /gsm/rf/afcdac is only 2 bytes long, thus very hard to 131 the new AFC algorithm implemented by TI has to deal with wide uncertainties in
59 spot visually in a hex dump of an unknown larger data structure; 132 the initial VCXO frequency. Instead it appears to be sufficient to calibrate
60 /gsm/rf/afcparams is 24 bytes long and has some structure to it, so I was 133 the VCXO and the settings in the afcparams table on a per-design basis, rather
61 hoping to recognize the latter, but no luck. 134 than per unit, and it appears that Motorola/Compal did just that on their C1xx
135 phones - which use a "plain" VCXO and not a VCTCXO like the Pirelli.
62 136
63 We will have to try running uncalibrated, or perhaps we'll find the code in 137 Querying Pirelli's fw for the actively used afcparams table via rftr 9 returns
64 Pirelli's fw that fills the parts of the T_RF structure that are normally read 138 the following:
65 from these files. 139
140 rf_table afcparams
141
142 6974 # psi_sta_inv
143 8 # psi_st
144 492713 # psi_st_32
145 8717 # psi_st_inv
146
147 888 # dac_center
148 -9568 # dac_min
149 11352 # dac_max
150 2560 # snr_thr
151
152 Because the slot in the factory data structure where the afcparams record ought
153 to go is all FF bytes, the table returned by the fw above can only be hard-coded
154 in the fw itself. The 4 numbers in the second group are exactly the same as
155 the hard-coded numbers in l1_rf12.h in TI's reference fw, but the Psi numbers
156 are different - Foxconn/Pirelli folks must have tuned them for their VCTCXO.
157
158 In this light, it is worthy to note that the afcdac record *is* present in
159 Pirelli's factory data block, and it differs from one unit to the next, i.e.,
160 it has been calibrated on a per-unit basis. TI's reference fw selects the
161 ALGO_AFC_LQG_PREDICTOR AFC algorithm which does not use this afcdac setting
162 at all, but perhaps Pirelli's fw does something different because of their use
163 of a VCTCXO instead of a "plain" VCXO - we don't know, and the reverse eng
164 effort to find the needed answers would be more than we can currently justify.