FreeCalypso > hg > freecalypso-docs

comparison MEMIF-wait-states @ 17:3d65bdaf00da

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
MEMIF-wait-states article written
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 16 Jun 2019 23:30:33 +0000
parents
children c01155dec65b
comparison
equal deleted inserted replaced
16:396d44c543e3 17:3d65bdaf00da
1 The Calypso chip's MEMIF (ARM memory interface) block has a few configuration
2 registers; most settings in these registers are quite straightforward, but the
3 WS setting (number of wait states to be inserted for external memory access)
4 requires some non-trivial analysis.
5
6 Calypso MEMIF timings are described on pages 7 through 11 of this TI document:
7
8 ftp://ftp.freecalypso.org/pub/GSM/Calypso/cal000_a.pdf
9
10 When running on a Calypso C035 target, our TCS211 reference fw as well as most
11 vendor firmwares we've examined run the ARM7 core at its maximum clock frequency
12 of 52 MHz. These same firmwares typically configure WS=3 for both flash and
13 XRAM. Most Calypso-based phones and modems have flash and RAM chips with 70 ns
14 access time, and for a long time it seemed that this combination of ARM7 at
15 52 MHz and WS=3 was OK for 70 ns memories: one ARM7 clock cycle at 52 MHz is
16 19.23 ns, WS=3 means 4 cycles total per access (it's an N+1 arrangement),
17 19.23 ns * 4 = 76.92 ns, thus it should be OK for 70 ns memories, right? Not
18 so fast: as shown in the formula on cal000_a.pdf page 11 and can be seen from
19 the timing diagrams, two other timing parameters (tda and tsu) also need to be
20 factored in. The sum of tda+tsu for 2.8V MEMIF as given in the only document
21 we have available is 10.5 ns, thus if we run the ARM7 core at 52 MHz and set
22 WS=3, the available safe window for memory access time is only about 66 ns,
23 which is 4 ns short of the 70 ns flash and RAM access time specs.
24
25 TI's reference fw setting of WS=3 in conjuction with ARM7 running at 52 MHz has
26 made its way into the official firmwares of Openmoko devices and several Compal
27 phones, including Mot C11x/12x, Mot C139/140 and Sony Ericsson J100. At least
28 in the case of Openmoko we know that the hardware features a flash chip with
29 70 ns access time (the combined flash+RAM chip is K5A3281CTM-D755, with the
30 suffix meaning 70 ns access time for flash and 55 ns for RAM), and in the case
31 of Compal phones it is highly unlikely that they used flash chips faster than
32 70 ns, thus we have strong evidence that the access time spec is being violated
33 by about 4 ns. It works in practice because the official specs are guaranteed
34 worst-case numbers, but it is still wrong in the strict sense.
35
36 We have strong evidence that this WS=3 setting comes from TI's mainline
37 reference fw, as opposed to being customized by or for Openmoko or Compal.
38 The evidence is in the following instruction sequence which appears verbatim-
39 identical across Openmoko's, Mot C11x/12x and C139/140 firmware versions:
40
41 ldr r1, =0xFFFFFB00
42 mov r0, #0xA3
43 strh r0, [r1, #0]
44 strh r0, [r1, #2]
45 mov r2, #0xA5
46 strh r2, [r1, #4]
47 strh r0, [r1, #6]
48 mov r0, #0x80
49 strh r0, [r1, #0xA]
50 mov r0, #0xC0
51 strh r0, [r1, #0xC]
52 mov r0, #0x40
53 strh r0, [r1, #8]
54
55 (The SE J100 version differs only in the nCS2 configuration; apparently this
56 SE J100 phone has its ringtone melody generator chip hooked up to nCS2, whereas
57 on both OM's modem and Mot C11x/12x/139/140 this chip select is unused and
58 unconnected, meaning that its setting is a dummy just like nCS3 and nCS4.)
59
60 The above instruction sequence has been reconstructed into the following
61 sequence of C macro calls:
62
63 MEM_INIT_CS0(3, MEM_DVS_16, MEM_WRITE_EN, 0);
64 MEM_INIT_CS1(3, MEM_DVS_16, MEM_WRITE_EN, 0);
65 MEM_INIT_CS2(5, MEM_DVS_16, MEM_WRITE_EN, 0);
66 MEM_INIT_CS3(3, MEM_DVS_16, MEM_WRITE_EN, 0);
67 MEM_INIT_CS4(0, MEM_DVS_8, MEM_WRITE_EN, 0);
68
69 MEM_INIT_CS6(0, MEM_DVS_32, MEM_WRITE_EN, 0);
70 MEM_INIT_CS7(0, MEM_DVS_32, MEM_WRITE_DIS, 0);
71
72 (The last two lines setting nCS6 and nCS7 don't need to be considered, as those
73 are internal to the Calypso chip itself.)
74
75 Thus we see that what appears to be TI's mainline code sets WS=3 for both nCS0
76 and nCS1 (flash and XRAM, respectively), and then sets what appears to be a
77 dummy config for the unused nCS2, nCS3 and nCS4. I say "appears to be" because
78 we have no original source with comments, only a COFF binary object which our
79 reconstructed recompilable C code has been made to match.
80
81 We may never know the truth unless we miraculously find a surviving copy of the
82 original (not reconstructed from disassembly) init.c source from TCS211, but my
83 (Mother Mychaela's) current working hypothesis is that the above MEMIF settings
84 were originally made for the D-Sample board and never changed for Leonardo.
85 The D-Sample board has flash on nCS0, main XRAM bank on nCS1, an additional
86 XRAM bank (typically unused) on nCS2 and peripherals (principally the LCD) on
87 nCS3. Furthermore, the original D-Sample boards had Calypso C05 chips populated
88 on them, and that chip version has no nCS4, only CS4 which is muxed with ADD22
89 and used for the latter on the D-Sample.
90
91 I further hypothetize that the above MEMIF settings were likely cast into code
92 in the days of Calypso C05, and that the WS=3 setting was computed when the
93 ARM7 core ran at 39 MHz. The combination of ARM7 at 39 MHz, WS=3 and the same
94 tda+tsu = 10.5 ns adjustment from the available cal000_a.pdf document
95 (officially corresponding to Calypso C035 F751774) gives an access time of
96 92 ns, which is very sensible. The hypothesis further goes that later TI moved
97 to Calypso C035 silicon and started running the ARM7 core at 52 MHz, but the WS
98 setting was never changed (overlooked), and the 92 ns access time turned into a
99 mere 66 ns. The latter works with 70 ns memories in practice despite being
100 strictly incorrect (negative margin), and so the error escaped notice.
101
102 Solution adopted for FreeCalypso
103 ================================
104
105 Pirelli's firmware on the DP-L10 sets WS=4 for both flash and XRAM, and we have
106 always used the same setting in FreeCalypso when running on this target. When
107 we made our FCDEV3B hardware using the same Spansion flash+RAM chip copied from
108 the Pirelli DP-L10, we adopted the same WS=4 setting for our own FreeCalypso
109 hardware family on the reasoning that it is needed for this chip. But now we
110 have a better theoretical foundation: the flash+RAM chip in question has 70 ns
111 access time for both flash and pSRAM parts, same as most other flash and RAM
112 chips used in most Calypso devices, and the WS=4 setting should really be used
113 for all Calypso C035 targets (ARM7 at 52 MHz) with 70 ns memories. Thus the
114 new FreeCalypso strategy is to treat WS=4 as the generic default for Calypso
115 C035 platforms unless explicitly overridden for specific targets, and to stop
116 treating TI's reconstructed setup with WS=3 as canonical.
117
118 When running on Openmoko GTA01/02, Mot C11x/12x, Mot C139/140 and SE J100
119 targets (this specific list), we are going to keep WS=3 for nCS0 and nCS1 and
120 the dummies for nCS2, nCS3 and nCS4 unchanged for now, i.e., run with exactly
121 the same MEMIF settings as each manufacturer's respective original official fw.
122 The reason is political: we are not the product manufacturer of record, and the
123 error of negative design margin in the memory access timings is the liability
124 of FIC/Openmoko and Compal/Motorola/SE, not us. If we change from WS=3 to WS=4
125 on these targets, our firmware will necessarily run a little slower, and given
126 that the original official fw "works just fine", we may be accused of needlessly
127 or artificially slowing down our aftermarket fw. But when we market our own
128 handset or modem products under the FreeCalypso trademark, then the full
129 responsibility for the entire product (hw+fw) falls on us, hence we use the
130 correct WS=4 setting.
131
132 Interim WS setting during boot
133 ==============================
134
135 There is one more complication to this picture. The MEMIF settings discussed
136 above for the operational phase with Calypso DPLL producing fast clocks are
137 made in the Init_Target() function, but there is another interim setting
138 established early on in assembly code, used prior to DPLL enabling, when the
139 ARM7 core runs at unmultiplied 13 MHz or 26 MHz as fed to the Calypso by the
140 board. This interim setting is first set in bootloader.s, then again in int.s
141 (with the definition residing in the included init.asm file), and the registers
142 are set to 0x2A1, meaning WS=1 and 1 dummy cycle.
143
144 Unlike the situation with the censored init.c source file, we have the original
145 source for the assembly modules in question, and the only preprocessor
146 conditionals found therein are based on BOARD and CHIPSET symbols. Remember
147 that TI's Leonardo board never got its own BOARD number, instead it shares
148 BOARD=41 with D-Sample, yet the two boards have different Calypso clock inputs:
149 13 MHz on the DS, 26 MHz on the Leonardo. The C code in init.c (this part
150 survived in the LoCosto source) uses a preprocessor conditional on the RF_FAM
151 symbol to differentiate between 13 MHz and 26 MHz input clock arrangements, but
152 there is no conditional of any such sort in the assembly code. Thus it is my
153 (Mother Mychaela's) educated guess that the WS=1 setting was chosen assuming a
154 13 MHz clock, and when Leonardo came along with its 26 MHz clock, the problem
155 spot was once again overlooked.
156
157 WS=1 at 13 MHz is equivalent to WS=7 at 52 MHz, thus there is plenty of margin.
158 But WS=1 at 26 MHz is equivalent to WS=3 at 52 MHz, once again putting us in
159 the troubled territory of negative margin with 70 ns flash and RAM chips.
160 Except that this case is even more difficult for firmware engineers to spot:
161 Pirelli's fw still has the same 0x2A1 setting in its early boot path, i.e.,
162 their fw engineers have changed WS=3 to WS=4 for the main body of the fw, but
163 missed the early boot code.
164
165 The solution adopted for FreeCalypso is to change the early MEMIF setting from
166 0x2A1 to 0x2A2, i.e., set WS=2 for the interim boot phase.