FreeCalypso > hg > freecalypso-tools

comparison doc/RVTMUX @ 0:e7502631a0f9

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 11 Jun 2016 00:13:35 +0000
parents
children d9307880f59f
comparison
equal deleted inserted replaced
-1:000000000000 0:e7502631a0f9
1 TI's Calypso GSM/GPRS baseband processor chip has not one but two UART serial
2 ports, called "MODEM" and "IrDA" in the hardware documentation. In hardware
3 terms, both support basic data-leads-only UART operation at a fixed baud rate,
4 but their extended capabilities differ: the IrDA UART adds IrDA capability (no
5 surprise), whereas the MODEM UART adds hardware flow control and autobaud. If
6 one is not implementing an actual IrDA interface, then the so-called "IrDA"
7 UART becomes a strict subset of the MODEM one in terms of hw capabilities -
8 just an extra UART, but a somewhat less capable one.
9
10 In a classic modem design such as that present in the GTA0x smartphones made by
11 FIC/Openmoko, the Calypso presents a standard AT command interface on its MODEM
12 UART port. (In the case of GTA0x phones this serial channel is wired to the
13 phone's application processor; in a standalone modem it would be wired to a
14 USB-serial chip or even to a classic RS-232 DB25 port.) However, what is less
15 known is that the standard firmware for such modems simultaneously presents an
16 entirely different interface on the IrDA UART - an interface intended for
17 development, debugging and factory production testing (which includes RF
18 calibration and IMEI etc programming), rather than for "normal" end users.
19
20 Normally this debug/development serial interface (called RVTMUX as will be
21 explained momentarily) is hidden from "ordinary" users - for example, on FIC
22 GTA0x phones it is wired to the analog headset jack through a hardware switch
23 which needs to be enabled through a GPIO signal from the AP. On Mot C139 and
24 its siblings the situation is similar: one needs to key in the secret magic
25 sequence **16379#, and then the firmware presents a hidden menu for switching
26 the analog headset jack between its "normal" function and the UART carrying
27 RVTMUX.
28
29 But there also exist some oddball devices on which the RVTMUX interface is
30 presented "in your face". The Pirelli DP-L10 phone has a USB charging port
31 which is also wired (through a CP2102 USB-serial chip) to the IrDA UART on the
32 Calypso - that's right, IrDA, not MODEM - a design decision with which this
33 hacker strongly disagrees. (It'll definitely be wired to the MODEM UART
34 instead on our own semi-clone of this phone, but I digress.) Apparently Foxconn
35 (the designers of this phone) had no desire to provide a standard AT command
36 interface, and instead the only "official" way to use the "data" function of
37 their USB port (rather than the charging function) is for their "PC sync"
38 feature, i.e., their proprietary Weendoze software. And guess what, their
39 proprietary "PC sync" feature works over TI's RVTMUX interface, as that is
40 what's presented on Calypso's IrDA UART behind the CP2102!
41
42 OK, so what is this RVTMUX? RV stands for RiViera, an application framework
43 which TI added to their GSM firmware suite in the early 2000s, T stands for
44 trace, and MUX stands for multiplexor. It's a binary packet interface, although
45 many of these packets contain ASCII debug messages inside. The framing format
46 is the same in both directions: each packet begins and ends with an STX (0x02)
47 byte, all payload bytes except 0x02 and 0x10 are sent literally, and there is a
48 DLE (0x10) byte prepended before any 0x02 or 0x10 in the payload. It's the same
49 general principle as asynchronous HDLC (RFC 1662): packets can contain any
50 binary data, and the framing provides packet boundaries - although TI's version
51 is a little less robust than async-HDLC when it comes to recovering after lost
52 synchronization.
53
54 The firmware suite component responsible for actually sending and receiving
55 these packets over the assigned UART port (usually IrDA, but can be MODEM too,
56 as on Compal phones for example) is called RVT (RiViera Trace), and it
57 implements a MUX function. There are several logical channels multiplexed over
58 one physical serial port, and the first byte of every packet indicates which
59 logical channel it belongs to. Any component within the GSM firmware suite can
60 send packets to RVT for transmission on this serial interface, and can also
61 register to receive packets beginning with a particular type ID byte.
62
63 Debug trace output
64 ==================
65
66 All GSM device firmwares that are based on TI's Calypso chipset reference fw
67 continuously emit quite voluminous debug trace output on their RVTMUX serial
68 port, whether it is hidden or exposed on a given device. Like all RVTMUX
69 traffic, this debug trace output takes the form of binary packets as explained
70 above, but the content of these packets is mostly ASCII with some binary header
71 bytes prepended. FreeCalypso host utility rvtdump captures all serial output
72 from a GSM device's RVTMUX port, parses the packet structure and displays this
73 output in line-oriented pure ASCII with all binary parts decoded.
74
75 Test Mode commands
76 ==================
77
78 The other major use of the RVTMUX interface is sending so-called Test Mode
79 commands from an external host to a running GSM device. Depending on the
80 firmware version, a GSM device can be commanded to do any of the following
81 things through this mechanism:
82
83 * Exercise RF test modes, e.g., transmit continuously at a set frequency and
84 power level;
85 * Read and write arbitrary memory locations in the Calypso ARM7 address space;
86 * Read and write ABB chip registers;
87 * Reboot or power off;
88 * Access and manipulate the device's flash file system (FFS).
89
90 In the segment of history of interest to us TI has produced two different
91 target firmware components that can receive, interpret and act upon Test Mode
92 command packets:
93
94 * The original Test Mode component of Layer 1, called L1TM or TML1: this
95 component handles all RF test modes (needed for RF calibration on device
96 production lines), and originally it also implemented memory and ABB register
97 read and write commands, and provided access to TMFFS1 (see below). In the
98 original implementation this component registered itself as the handler for
99 the "TM" RVTMUX channel (RVT packet type 0x14), so it would receive all TM
100 packets sent to the device.
101
102 * Enhanced Test Mode (ETM) is a later invention. It registers itself (instead
103 of the old TM in L1) with RVT as the handler for the "TM" RVTMUX channel, and
104 then provides a registration service of its own, such that various components
105 in the fw suite can register to receive external command packets passing
106 first through RVT, then through ETM, and can send responses passing through
107 ETM, then through RVT back to the external host. If a given fw version
108 contains both ETM and L1TM, then L1TM registers itself with ETM; an external
109 host would send exactly the same binary command packets to exercise RF test
110 modes, but inside the firmware they now pass through ETM on their way to L1TM.
111
112 The ETM_CORE module contained within ETM itself provides some low-level debug
113 commands: by sending the right binary command packets to the GSM device via the
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
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
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
120 binary library.
121
122 Our TCS211/leo2moko reference fw has both ETM and L1TM, thus it accepts both
123 ETM and TM3 command packets. ETM commands (including TMFFS2, see below) work
124 on Pirelli's fw, but Mot/Compal's original fw for the C139 has only the
125 original non-enhanced Test Mode, not ETM.
126
127 FFS access via TM/ETM
128 =====================
129
130 One of the essential facilities provided in one form or another in all known
131 incarnations of the Test Mode mechanism is the ability to access and manipulate
132 the GSM device's flash file system (FFS). See TIFFS-Overview for a description
133 of this file system. TI's TMFFS1 and TMFFS2 protocols provide a command and
134 response packet interface to the FFS API functions inside the fw, and enable an
135 external host connected to the GSM device via the RVTMUX channel to perform
136 arbitrary read and write operations on the device file system.
137
138 In the segment of history of interest to us TI has produced two different
139 and entirely incompatible versions of the TMFFS protocol: TMFFS1 and TMFFS2.
140 Or rather, what is now called TMFFS1 was originally just TMFFS, and then came
141 TMFFS2. TMFFS2 works only through ETM, whereas TMFFS1 predates ETM: in the
142 original implementation the tm_ffs() function in the FFS code was called from
143 L1TM code.
144
145 Our copy of TCS211 reference fw includes the source for both TMFFS1 and TMFFS2;
146 it is theoretically possible to build a firmware image that includes both TMFFS
147 versions (they won't conflict because they respond to different command
148 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
150 change it when we made the moko12 (leo2moko-r1) fw release for the Openmoko
151 community (the previous proprietary mokoN firmwares also implement TMFFS1),
152 but we have subsequently switched to TMFFS2 for our current TCS211-based work.
153
154 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
156 available TCS211 source work beautifully when run against Pirelli's fw.
157
158 Use in FreeCalypso
159 ==================
160
161 The FreeCalypso project has adopted the same general firmware architecture as
162 that exhibited by TI's standard firmwares from the Moko/Pirelli time frame. We
163 use TI's RiViera framework lifted directly out of the TCS211 reference fw, and
164 that includes the RVT module and the RVTMUX interface it presents. Our GSM fw
165 emits the same 3 kinds of debug traces (RV, L1 and GPF) as the pre-existing
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
171 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
173 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
175 source implementing both, I (Space Falcon) came to the conclusion that TMFFS2
176 is both more capable and more reliable; my guess is that TMFFS1 was likely kept
177 around only because some of TI's crappy Weendoze host software depended on it.
178 (See gsm-fw/services/ffs/tmffs.c if you would like to judge for yourself.)
179
180 We have the following host tools for communicating with TI-based GSM firmwares
181 (both our own and some of the existing proprietary ones):
182
183 rvtdump This tool produces a human-readable dump of all output emitted
184 by a TI-based GSM fw in the form of RVTMUX binary packets. It
185 can also log this dump to a file.
186
187 rvinterf This tool is a superset of rvtdump: it not only dumps and/or
188 logs all output from the GSM fw, but also provides a mechanism
189 for sending command packets to it.
190
191 Rvinterf is the engine behind the following host tools that send Test Mode
192 commands to a target:
193
194 fc-tmsh This is our basic tool for sending Test Mode commands to a
195 running GSM fw. It is strictly asynchronous in that commands
196 entered by the operator get sent to the target, and any response
197 packets received from the target are displayed as they come in.
198 The tool has no knowledge of any correspondence between commands
199 being sent and whatever responses they should elicit, i.e., it
200 is perfectly suited for experimental discovery of firmware
201 behaviour in response to Test Mode commands.
202
203 This tool was written before we realized that there was/is an
204 older, more basic Test Mode predating ETM, hence in many place
205 we say "ETM" when we really should have said "TM". Oh well...
206
207 fc-fsio This tool speaks the TMFFS2 protocol and allows a user or
208 developer to perform a wide range of operations on the file
209 system of a GSM device. It operates synchronously, i.e., it
210 sends ETM/TMFFS2 commands and expects responses in strict
211 lock-step; a single user command may translate into a large
212 number of ETM/TMFFS2 command packet exchanges.
213
214 AT commands over RVTMUX
215 =======================
216
217 There is one more use to which we put the RVTMUX debug serial interface that is
218 an original FreeCalypso invention: communicating with the AT command interpreter
219 (ATI). TI's original architecture assumes that if a product is to offer a
220 standard AT command interface (the product is either a GSM/GPRS modem for which
221 this AT command interface is the sole mode of usage or a feature phone that
222 offers a data port as one of its features), then it will be presented on a
223 dedicated UART separate from RVTMUX.
224
225 However, many of our target devices have only one UART practically accessible,
226 and even when we use Openmoko's modem as our development platform, the RVTMUX
227 interface is more convenient because it connects externally, whereas the MODEM
228 UART is connected to the application processor of the smartphone. Therefore,
229 we developed a way to pass AT commands over RVTMUX. We created a new RVTMUX
230 channel for this interface and assigned it RVT packet type 0x1A. Packets sent
231 from an external host to the GSM device carry AT commands and SMS string input,
232 whereas packets flowing the other way carry ATI's responses to commands and
233 asynchronous notifications such as incoming calls.
234
235 The host utility for talking AT commands to a FreeCalypso GSM device via RVTMUX
236 is fc-shell; it works via rvinterf just like fc-fsio and fc-tmsh.