FreeCalypso > hg > freecalypso-tools

comparison doc/RVTMUX @ 429:05dc91d011a6

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/RVTMUX: updated for the current state of FreeCalypso
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 03 Nov 2018 05:51:17 +0000
parents ac49d8814893
children 06442f27b144
comparison
equal deleted inserted replaced
428:2beb5bae0796 429:05dc91d011a6
114 RVTMUX serial channel, an external host can examine or modify any memory 114 RVTMUX serial channel, an external host can examine or modify any memory
115 location and any hardware register, cause the device to reset, etc. Prior to 115 location and any hardware register, cause the device to reset, etc. Prior to
116 ETM some of these functions (but not all) could be exercised through older TM3 116 ETM some of these functions (but not all) could be exercised through older TM3
117 commands, but in FreeCalypso we became familiar with the ETM versions of these 117 commands, but in FreeCalypso we became familiar with the ETM versions of these
118 commands long before the older ones because we got the ETM component in full 118 commands long before the older ones because we got the ETM component in full
119 source form, whereas our copy of TCS211 (TI's reference fw) has L1TM in a 119 source form, whereas the sole surviving copy of TCS211 that serves as our golden
120 binary library. 120 reference came with L1TM in binary object form like the rest of L1, and we got
121 121 to source-reconstructing it only much later.
122 Our TCS211/leo2moko reference fw has both ETM and L1TM, thus it accepts both 122
123 ETM and TM3 command packets. ETM commands (including TMFFS2, see below) work 123 Our TCS211 reference fw has both ETM and L1TM, thus it accepts both ETM and TM3
124 on Pirelli's fw, but Mot/Compal's original fw for the C139 has only the 124 command packets; the same holds for our current production firmwares that are
125 based on this TCS211 reference. ETM commands (including TMFFS2, see below) also
126 work on Pirelli's fw, but Mot/Compal's original fw for the C139 has only the
125 original non-enhanced Test Mode, not ETM. 127 original non-enhanced Test Mode, not ETM.
126 128
127 FFS access via TM/ETM 129 FFS access via TM/ETM
128 ===================== 130 =====================
129 131
148 packets), but it is pretty clear that TI never intended to have both enabled 150 packets), but it is pretty clear that TI never intended to have both enabled
149 at the same time. Our copy of TCS211 came with TMFFS1 enabled and we didn't 151 at the same time. Our copy of TCS211 came with TMFFS1 enabled and we didn't
150 change it when we made the moko12 (leo2moko-r1) fw release for the Openmoko 152 change it when we made the moko12 (leo2moko-r1) fw release for the Openmoko
151 community (the previous proprietary mokoN firmwares also implement TMFFS1), 153 community (the previous proprietary mokoN firmwares also implement TMFFS1),
152 but we have subsequently switched to TMFFS2 for our current TCS211-based work. 154 but we have subsequently switched to TMFFS2 for our current TCS211-based work.
155 Our current production firmwares implement TMFFS2.
153 156
154 Pirelli's fw implements TMFFS2: we don't have any source for this fw, but our 157 Pirelli's fw implements TMFFS2: we don't have any source for this fw, but our
155 FreeCalypso host utilities written to talk the TMFFS2 protocol based on our 158 FreeCalypso host utilities written to talk the TMFFS2 protocol based on our
156 available TCS211 source work beautifully when run against Pirelli's fw. 159 available TCS211 source work beautifully when run against Pirelli's fw.
157 160
158 Use in FreeCalypso 161 Use in FreeCalypso
159 ================== 162 ==================
160 163
161 The FreeCalypso project has adopted the same general firmware architecture as 164 Our current production firmwares for FreeCalypso modems faithfully follow the
162 that exhibited by TI's standard firmwares from the Moko/Pirelli time frame. We 165 architecture of TI's TCS211 without any fundamental changes. Thus the
163 use TI's RiViera framework lifted directly out of the TCS211 reference fw, and 166 functionality which we present via RVTMUX is exactly the same as TI's original:
164 that includes the RVT module and the RVTMUX interface it presents. Our GSM fw 167 our firmwares emit the same 3 kinds of debug traces (RV, L1 and GPF) as various
165 emits the same 3 kinds of debug traces (RV, L1 and GPF) as the pre-existing 168 pre-existing ones, and for Test Mode functionality we have ETM, L1TM and TMFFS2.
166 firmwares with which we are seeking functional parity, and for Test Mode
167 functionality we have the option of including ETM, TMFFS1 and/or TMFFS2 in our
168 firmware builds. (Both TMFFS versions require ETM in our implementation, and
169 it is possible to build a firmware image with both included.)
170 169
171 We have adopted ETM and TMFFS2 as the standard combination for FreeCalypso, 170 We have adopted ETM and TMFFS2 as the standard combination for FreeCalypso,
172 i.e., ETM_CORE for memory and ABB register reads and writes and TMFFS2 for 171 i.e., ETM_CORE for memory and ABB register reads and writes and TMFFS2 for
173 external FFS access. We needed to develop our own host tools for operating on 172 external FFS access. We needed to develop our own host tools for operating on
174 GSM device FFS via one of the two TMFFS protocols, and after studying the fw 173 GSM device FFS via one of the two TMFFS protocols, and after studying the fw
210 system of a GSM device. It operates synchronously, i.e., it 209 system of a GSM device. It operates synchronously, i.e., it
211 sends ETM/TMFFS2 commands and expects responses in strict 210 sends ETM/TMFFS2 commands and expects responses in strict
212 lock-step; a single user command may translate into a large 211 lock-step; a single user command may translate into a large
213 number of ETM/TMFFS2 command packet exchanges. 212 number of ETM/TMFFS2 command packet exchanges.
214 213
214 fc-shell This tool is asynchronous like fc-tmsh, but instead of talking
215 and listening on the TM/ETM RVTMUX channel, it talks and listens
216 on GPF's channel and on the new AT-over-RVTMUX channel which we
217 added in FreeCalypso. fc-shell can be used to issue system
218 primitive commands to GPF (and to see firmware responses to
219 them), and to talk AT commands via RVTMUX.
220
215 AT commands over RVTMUX 221 AT commands over RVTMUX
216 ======================= 222 =======================
217 223
218 There is one more use to which we put the RVTMUX debug serial interface that is 224 There is one more use to which we put the RVTMUX debug serial interface that is
219 an original FreeCalypso invention: communicating with the AT command interpreter 225 an original FreeCalypso invention: communicating with the AT command interpreter
221 standard AT command interface (the product is either a GSM/GPRS modem for which 227 standard AT command interface (the product is either a GSM/GPRS modem for which
222 this AT command interface is the sole mode of usage or a feature phone that 228 this AT command interface is the sole mode of usage or a feature phone that
223 offers a data port as one of its features), then it will be presented on a 229 offers a data port as one of its features), then it will be presented on a
224 dedicated UART separate from RVTMUX. 230 dedicated UART separate from RVTMUX.
225 231
226 However, many of our target devices have only one UART practically accessible, 232 However, in the case of our FreeCalypso family of projects about 2 years had
227 and even when we use Openmoko's modem as our development platform, the RVTMUX 233 passed between our first functional GSM fw attempts in 2015 and us successfully
228 interface is more convenient because it connects externally, whereas the MODEM 234 building our own development board in 2017; during this time we had to work on
229 UART is connected to the application processor of the smartphone. Therefore, 235 various crippled pre-existing Calypso devices, and many of them had only one
230 we developed a way to pass AT commands over RVTMUX. We created a new RVTMUX 236 UART practically accessible. In response to this situation we developed a way
231 channel for this interface and assigned it RVT packet type 0x1A. Packets sent 237 to pass AT commands over RVTMUX. We created a new RVTMUX channel for this
232 from an external host to the GSM device carry AT commands and SMS string input, 238 interface and assigned it RVT packet type 0x1A. Packets sent from an external
233 whereas packets flowing the other way carry ATI's responses to commands and 239 host to the GSM device carry AT commands and SMS string input, whereas packets
234 asynchronous notifications such as incoming calls. 240 flowing the other way carry ATI's responses to commands and asynchronous
235 241 notifications such as incoming calls. The host utility for talking AT commands
236 The host utility for talking AT commands to a FreeCalypso GSM device via RVTMUX 242 to a FreeCalypso GSM device via RVTMUX is fc-shell, described above.
237 is fc-shell; it works via rvinterf just like fc-fsio and fc-tmsh. 243
244 Now that we have built a proper FreeCalypso development board with two UARTs,
245 the use of this AT-over-RVTMUX hack is deprecated for general usage: this hack
246 does not support any data services (CSD or GPRS), and even for SMS it is
247 crippled because maximum-length messages cannot be sent in the more capable PDU
248 mode. However, it still comes in handy during certain casual testing sessions,
249 and it is required if one needs to run our FreeCalypso firmware on Mot C1xx or
250 Pirelli DP-L10 hardware.
238 251
239 Keepalive mechanism 252 Keepalive mechanism
240 =================== 253 ===================
241 254
242 Another FreeCalypso addition to TI's RVTMUX interface is our optional keepalive 255 Another FreeCalypso addition to TI's RVTMUX interface is our keepalive mechanism
243 mechanism. The FreeCalypso family includes many subprojects, and one of these 256 for the voice pseudo-modem hack on Mot C1xx targets. The FreeCalypso family
244 subprojects involves running modem-like firmware (control via AT commands only, 257 includes many subprojects, and one of these subprojects involves running modem-
245 no local UI) on Mot C1xx phones. Having a device that was originally made to 258 like firmware (control via AT commands only, no local UI) on Mot C1xx phones.
246 be a phone with LCD and buttons turn into a serially-controlled pseudo-modem 259 Having a device that was originally made to be a phone with LCD and buttons
247 (LCD stays dark, buttons do nothing) feels quite weird, and this situation is 260 turn into a serially-controlled pseudo-modem (LCD stays dark, buttons do
248 exacerbated on low-end Mot C1xx models that have small RAM and thus require our 261 nothing) feels quite weird, and this situation is exacerbated by the flashing
249 pseudo-modem fw to be flashed. 262 requirement: the only way to run our pseudo-modem fw on Mot C1xx phones is to
250 263 flash it, there is no way to run it out of RAM without disturbing the phone's
251 Our optional keepalive mechanism is intended for the latter scenario. There 264 original fw.
252 will be an optional feature added to pseudo-modem fw builds for C1xx targets 265
253 (not yet implemented as of this writing) to have the firmware send periodic 266 When our Magnetite and Selenite firmwares are built for a C1xx target in the
254 keepalive queries out the serial port, to see if there is a running rvinterf 267 VPM configuration, they implement the following keepalive logic: if the phone
255 process on the other end of the wire, and automatically power off if there is 268 is powered on and running our fw, but the charging power source is not plugged
256 no keepalive response. 269 in, the fw sends periodic keepalive queries out the serial port to see if there
270 is a running rvinterf process on the other end of the wire, and automatically
271 powers off if there is no keepalive response.
257 272
258 Code has been added to rvinterf to respond with a keepalive answer packet when 273 Code has been added to rvinterf to respond with a keepalive answer packet when
259 a keepalive query packet is received; the feature has been implemented on the 274 a keepalive query packet is received; the feature has been implemented on the
260 rvinterf side ahead of the target fw so that when and if we do get around to 275 rvinterf side first, and then subsequently in our Magnetite fw for C1xx targets.
261 implementing the target side, the necessary rvinterf support will be there
262 waiting for us.