FreeCalypso > hg > freecalypso-sw
annotate doc/RVTMUX @ 378:3164604a6c70
install compalstage-*.bin and loadagent.srec from target-utils
author | Michael Spacefalcon <msokolov@ivan.Harhan.ORG> |
---|---|
date | Mon, 09 Jun 2014 06:10:01 +0000 |
parents | d6dfad22cccd |
children | 821a26f90968 |
rev | line source |
---|---|
270
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
1 TI's Calypso GSM/GPRS baseband processor chip has not one but two UART serial |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
2 ports, called "MODEM" and "IrDA" in the hardware documentation. In hardware |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
3 terms, both support basic data-leads-only UART operation at a fixed baud rate, |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
4 but their extended capabilities differ: the IrDA UART adds IrDA capability (no |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
5 surprise), whereas the MODEM UART adds hardware flow control and autobaud. If |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
6 one is not implementing an actual IrDA interface, then the so-called "IrDA" |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
7 UART becomes a strict subset of the MODEM one in terms of hw capabilities - |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
8 just an extra UART, but a somewhat less capable one. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
9 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
10 In a classic modem design such as that present in the GTA0x smartphones made by |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
11 FIC/Openmoko, the Calypso presents a standard AT command interface on its MODEM |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
12 UART port. (In the case of GTA0x phones this serial channel is wired to the |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
13 phone's application processor; in a standalone modem it would be wired to a |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
14 USB-serial chip or even to a classic RS-232 DB25 port.) However, what is less |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
15 known is that the standard firmware for such modems simultaneously presents an |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
16 entirely different interface on the IrDA UART - an interface intended for |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
17 development, debugging and factory production testing (which includes RF |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
18 calibration and IMEI etc programming), rather than for "normal" end users. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
19 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
20 Normally this debug/development serial interface (called RVTMUX as will be |
272
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
21 explained momentarily) is hidden from "ordinary" users - for example, on FIC |
270
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
22 GTA0x phones it is wired to the analog headset jack through a hardware switch |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
23 which needs to be enabled through a GPIO signal from the AP. But there also |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
24 exist some oddball devices on which the RVTMUX interface is presented "in your |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
25 face". The Pirelli DP-L10 phone has a USB charging port which is also wired |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
26 (through a CP2102 USB-serial chip) to the IrDA UART on the Calypso - that's |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
27 right, IrDA, not MODEM - a design decision with which this hacker strongly |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
28 disagrees. (It'll definitely be wired to the MODEM UART instead on our own |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
29 semi-clone of this phone, but I digress.) Apparently Foxconn (the designers |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
30 of this phone) had no desire to provide a standard AT command interface, and |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
31 instead the only "official" way to use the "data" function of their USB port |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
32 (rather than the charging function) is for their "PC sync" feature, i.e., their |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
33 proprietary Weendoze software. And guess what, their proprietary "PC sync" |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
34 feature works over TI's RVTMUX interface, as that is what's presented on |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
35 Calypso's IrDA UART behind the CP2102! |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
36 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
37 OK, so what is this RVTMUX? RV stands for RiViera, an application framework |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
38 which TI added to their GSM firmware suite in the early 2000s, T stands for |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
39 trace, and MUX stands for multiplexor. It's a binary packet interface, although |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
40 many of these packets contain ASCII debug messages inside. The framing format |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
41 is the same in both directions: each packet begins and ends with an STX (0x02) |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
42 byte, all payload bytes except 0x02 and 0x10 are sent literally, and there is a |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
43 DLE (0x10) byte prepended before any 0x02 or 0x10 in the payload. It's the same |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
44 general principle as asynchronous HDLC (RFC 1662): packets can contain any |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
45 binary data, and the framing provides packet boundaries - although TI's version |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
46 is a little less robust than async-HDLC when it comes to recovering after lost |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
47 synchronization. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
48 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
49 The firmware suite component responsible for actually sending and receiving |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
50 these packets over the assigned UART port (usually IrDA, but can be MODEM too) |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
51 is called RVT (RiViera Trace), and it implements a MUX function. There are |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
52 several logical channels multiplexed over one physical serial port, and the |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
53 first byte of every packet indicates which logical channel it belongs to. Any |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
54 component within the GSM firmware suite can send packets to RVT for transmission |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
55 on this serial interface, and can also register to receive packets beginning |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
56 with a particular type ID byte. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
57 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
58 Use in FreeCalypso |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
59 ================== |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
60 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
61 The FreeCalypso project has adopted the same general firmware architecture as |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
62 that exhibited by TI's standard firmwares from the Moko/Pirelli time frame. We |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
63 use TI's RiViera framework lifted directly out of the TCS211 reference fw, and |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
64 that includes the RVT module and the RVTMUX interface it presents. At the |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
65 present time (early development stage, none of the actual GSM functionality has |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
66 been integrated yet) this RVTMUX interface is put to the following uses in our |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
67 own gsm-fw: |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
68 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
69 * Debug trace output from various components sent via the rvf_send_trace() |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
70 function - it is the RiViera Trace output in the proper sense; |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
71 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
72 * The ETM module and the associated FFS access protocol described below. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
73 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
74 In the existing proprietary firmwares which serve as our reference, the RVTMUX |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
75 serial channel is continuously spewing very voluminous debug output. This debug |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
76 output exhibits 3 different packet types: RV traces described above, and also |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
77 L1 and G23 traces, each in its own format. We expect that our own gsm-fw will |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
78 become just like these reference versions in this regard, once we integrate |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
79 those code layers. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
80 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
81 ETM and FFS access |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
82 ================== |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
83 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
84 Another component which we have lifted out of the TCS211 reference fw is ETM, |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
85 which stands for Enhanced Test Mode. This module registers its own "top level" |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
86 protocol over RVTMUX, and provides a registration service of its own, such that |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
87 various components in the fw suite can register to receive external command |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
88 packets passing first through RVT, then through ETM, and can send responses |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
89 passing through ETM, then through RVT back to the external host. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
90 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
91 The ETM_CORE module contained within ETM itself provides some low-level debug |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
92 commands: by sending the right binary command packets to the GSM device via the |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
93 RVTMUX serial channel, an external host can examine or modify any memory |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
94 location and any hardware register, cause the device to reset, etc. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
95 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
96 The only other ETM-based functionality currently integrated in our gsm-fw |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
97 besides ETM_CORE is TMFFS (Test Mode for FFS), which is the external access |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
98 channel to the device file system - see TIFFS-Overview. The TMFFS1 and TMFFS2 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
99 protocols provide a command/response packet interface to the FFS API functions |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
100 inside the fw, and enable an external host connected to the GSM device via the |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
101 RVTMUX channel to perform arbitrary read and write operations on the device |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
102 file system. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
103 |
272
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
104 TMFFS protocol versions |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
105 ======================= |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
106 |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
107 TI made two different and entirely incompatible versions of the TMFFS protocol |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
108 for accessing a device's FFS via RVT/ETM: TIFFS1 and TIFFS2. The fw sources |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
109 available to us contain implementations of both versions, so we have the freedom |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
110 to use whichever we like better for FreeCalypso. After studying the fw source |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
111 implementing the two TMFFS protocols, I (Space Falcon) came to the conclusion |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
112 that TMFFS2 is both more capable and more reliable; my guess is that TMFFS1 was |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
113 likely kept around only because some of TI's crappy Weendoze host software |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
114 depended on it. (See gsm-fw/services/ffs/tmffs.c if you would like to judge |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
115 for yourself.) Thus TMFFS2 is currently the "officially adopted" version for |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
116 FreeCalypso. |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
117 |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
118 Our fc-tmsh utility (described below) allows a developer-operator to send TMFFS |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
119 "get version" queries to a running GSM fw in both ETM_FFS1 and ETM_FFS2 formats; |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
120 this capability allows us to determine experimentally which protocol (if any) is |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
121 implemented by a given proprietary firmware version. Experiments reveal that |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
122 Openmoko's moko11 firmware implements TMFFS1, whereas Pirelli's fw implements |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
123 TMFFS2. |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
124 |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
125 The leo2moko-r1 firmware produced by the FreeCalypso project in 2013-10 |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
126 implements TMFFS1, simply because that was the selected configuration in the |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
127 found Leonardo source that transitional fw is based on, and that release was |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
128 made before I learned RVTMUX, FFS, ETM and TMFFS properly. All future |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
129 FreeCalypso firmwares will use TIFFS2, or at least that's the current plan. |
9c34d938a645
doc/RVTMUX: TMFFS protocol versions documented
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
270
diff
changeset
|
130 |
270
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
131 Host utility support |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
132 ==================== |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
133 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
134 As one would naturally expect, the FreeCalypso project has developed some host |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
135 tools that allow a PC running GNU/Linux (or other Unix systems) to interface to |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
136 running firmwares on GSM devices via RVTMUX. The following tools are currently |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
137 available: |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
138 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
139 rvtdump Opens the serial port, decodes TI's binary packet protocol, and |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
140 simply dumps every received/decoded packet on stdout in a human- |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
141 readable form. No provision for sending anything to the target. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
142 Intended use: observing the debug trace output which all TI |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
143 firmwares emit as standard "background noise". This utility |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
144 allows one to observe/log/study the "noise" that appears on |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
145 Pirelli's USB-serial port (running Pirelli's original fw), |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
146 as well as that emitted on the IrDA (headset jack) port on the |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
147 GTA02 by mokoN/leo2moko firmwares. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
148 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
149 rvinterf Provides a bidirectional interface to RVTMUX on the host side. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
150 It dumps and/or logs the "background noise" emitted by the |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
151 target just like rvtdump, but also creates a local UNIX domain |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
152 socket on the host machine to which other programs can connect, |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
153 replicating the MUXing function on the host side. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
154 |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
155 fc-tmsh Interactive asynchronous test mode shell. This program connects |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
156 to a target GSM device through rvinterf and allows a developer- |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
157 operator to send various ETM commands to the target. ETM |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
158 responses are decoded (sometimes only lightly) and displayed. |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
159 fc-tmsh is fully asynchronous in that it continuously listens |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
160 (via select(2)) for both user input and for packets from the |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
161 target at the same time, translating any user-entered commands |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
162 into packets to the target and conversely, scribbling on the |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
163 terminal when a packet arrives from the target. It has no |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
164 knowledge of any correspondence between commands and responses |
d1388095ab27
doc/RVTMUX write-up
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
diff
changeset
|
165 they normally elicit. |
273
d6dfad22cccd
doc/RVTMUX: note about fc-tmsh ffs2 commands being a known dead end
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
272
diff
changeset
|
166 |
d6dfad22cccd
doc/RVTMUX: note about fc-tmsh ffs2 commands being a known dead end
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
272
diff
changeset
|
167 fc-tmsh implements some low-level ffs2 commands (see above regarding our design |
d6dfad22cccd
doc/RVTMUX: note about fc-tmsh ffs2 commands being a known dead end
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
272
diff
changeset
|
168 decision to use TMFFS2 rather than TMFFS1), but it is already known that this |
d6dfad22cccd
doc/RVTMUX: note about fc-tmsh ffs2 commands being a known dead end
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
272
diff
changeset
|
169 implementation approach is a dead end, and a different host utility is planned |
d6dfad22cccd
doc/RVTMUX: note about fc-tmsh ffs2 commands being a known dead end
Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
parents:
272
diff
changeset
|
170 to be written for full FFS read/write access via the TMFFS2 protocol. |