FreeCalypso > hg > freecalypso-sw

comparison doc/RVTMUX @ 388:821a26f90968

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/RVTMUX: minor fixes
author Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
date Tue, 10 Jun 2014 20:59:32 +0000
parents d6dfad22cccd
children 14618bd924ec
comparison
equal deleted inserted replaced
387:4391890bacd9 388:821a26f90968
18 calibration and IMEI etc programming), rather than for "normal" end users. 18 calibration and IMEI etc programming), rather than for "normal" end users.
19 19
20 Normally this debug/development serial interface (called RVTMUX as will be 20 Normally this debug/development serial interface (called RVTMUX as will be
21 explained momentarily) is hidden from "ordinary" users - for example, on FIC 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 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. But there also 23 which needs to be enabled through a GPIO signal from the AP. On Mot C139 and
24 exist some oddball devices on which the RVTMUX interface is presented "in your 24 its siblings the situation is similar: one needs to key in the secret magic
25 face". The Pirelli DP-L10 phone has a USB charging port which is also wired 25 sequence **16379#, and then the firmware presents a hidden menu for switching
26 (through a CP2102 USB-serial chip) to the IrDA UART on the Calypso - that's 26 the analog headset jack between its "normal" function and the UART carrying
27 right, IrDA, not MODEM - a design decision with which this hacker strongly 27 RVTMUX.
28 disagrees. (It'll definitely be wired to the MODEM UART instead on our own 28
29 semi-clone of this phone, but I digress.) Apparently Foxconn (the designers 29 But there also exist some oddball devices on which the RVTMUX interface is
30 of this phone) had no desire to provide a standard AT command interface, and 30 presented "in your face". The Pirelli DP-L10 phone has a USB charging port
31 instead the only "official" way to use the "data" function of their USB port 31 which is also wired (through a CP2102 USB-serial chip) to the IrDA UART on the
32 (rather than the charging function) is for their "PC sync" feature, i.e., their 32 Calypso - that's right, IrDA, not MODEM - a design decision with which this
33 proprietary Weendoze software. And guess what, their proprietary "PC sync" 33 hacker strongly disagrees. (It'll definitely be wired to the MODEM UART
34 feature works over TI's RVTMUX interface, as that is what's presented on 34 instead on our own semi-clone of this phone, but I digress.) Apparently Foxconn
35 Calypso's IrDA UART behind the CP2102! 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!
36 41
37 OK, so what is this RVTMUX? RV stands for RiViera, an application framework 42 OK, so what is this RVTMUX? RV stands for RiViera, an application framework
38 which TI added to their GSM firmware suite in the early 2000s, T stands for 43 which TI added to their GSM firmware suite in the early 2000s, T stands for
39 trace, and MUX stands for multiplexor. It's a binary packet interface, although 44 trace, and MUX stands for multiplexor. It's a binary packet interface, although
40 many of these packets contain ASCII debug messages inside. The framing format 45 many of these packets contain ASCII debug messages inside. The framing format
45 binary data, and the framing provides packet boundaries - although TI's version 50 binary data, and the framing provides packet boundaries - although TI's version
46 is a little less robust than async-HDLC when it comes to recovering after lost 51 is a little less robust than async-HDLC when it comes to recovering after lost
47 synchronization. 52 synchronization.
48 53
49 The firmware suite component responsible for actually sending and receiving 54 The firmware suite component responsible for actually sending and receiving
50 these packets over the assigned UART port (usually IrDA, but can be MODEM too) 55 these packets over the assigned UART port (usually IrDA, but can be MODEM too,
51 is called RVT (RiViera Trace), and it implements a MUX function. There are 56 as on Compal phones for example) is called RVT (RiViera Trace), and it
52 several logical channels multiplexed over one physical serial port, and the 57 implements a MUX function. There are several logical channels multiplexed over
53 first byte of every packet indicates which logical channel it belongs to. Any 58 one physical serial port, and the first byte of every packet indicates which
54 component within the GSM firmware suite can send packets to RVT for transmission 59 logical channel it belongs to. Any component within the GSM firmware suite can
55 on this serial interface, and can also register to receive packets beginning 60 send packets to RVT for transmission on this serial interface, and can also
56 with a particular type ID byte. 61 register to receive packets beginning with a particular type ID byte.
57 62
58 Use in FreeCalypso 63 Use in FreeCalypso
59 ================== 64 ==================
60 65
61 The FreeCalypso project has adopted the same general firmware architecture as 66 The FreeCalypso project has adopted the same general firmware architecture as
103 108
104 TMFFS protocol versions 109 TMFFS protocol versions
105 ======================= 110 =======================
106 111
107 TI made two different and entirely incompatible versions of the TMFFS protocol 112 TI made two different and entirely incompatible versions of the TMFFS protocol
108 for accessing a device's FFS via RVT/ETM: TIFFS1 and TIFFS2. The fw sources 113 for accessing a device's FFS via RVT/ETM: TMFFS1 and TMFFS2. The fw sources
109 available to us contain implementations of both versions, so we have the freedom 114 available to us contain implementations of both versions, so we have the freedom
110 to use whichever we like better for FreeCalypso. After studying the fw source 115 to use whichever we like better for FreeCalypso. After studying the fw source
111 implementing the two TMFFS protocols, I (Space Falcon) came to the conclusion 116 implementing the two TMFFS protocols, I (Space Falcon) came to the conclusion
112 that TMFFS2 is both more capable and more reliable; my guess is that TMFFS1 was 117 that TMFFS2 is both more capable and more reliable; my guess is that TMFFS1 was
113 likely kept around only because some of TI's crappy Weendoze host software 118 likely kept around only because some of TI's crappy Weendoze host software
124 129
125 The leo2moko-r1 firmware produced by the FreeCalypso project in 2013-10 130 The leo2moko-r1 firmware produced by the FreeCalypso project in 2013-10
126 implements TMFFS1, simply because that was the selected configuration in the 131 implements TMFFS1, simply because that was the selected configuration in the
127 found Leonardo source that transitional fw is based on, and that release was 132 found Leonardo source that transitional fw is based on, and that release was
128 made before I learned RVTMUX, FFS, ETM and TMFFS properly. All future 133 made before I learned RVTMUX, FFS, ETM and TMFFS properly. All future
129 FreeCalypso firmwares will use TIFFS2, or at least that's the current plan. 134 FreeCalypso firmwares will use TMFFS2, or at least that's the current plan.
130 135
131 Host utility support 136 Host utility support
132 ==================== 137 ====================
133 138
134 As one would naturally expect, the FreeCalypso project has developed some host 139 As one would naturally expect, the FreeCalypso project has developed some host