FreeCalypso > hg > freecalypso-sw

comparison rvinterf/doc/README.older @ 971:53114af707f2

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
rvinterf: both README files are now outdated, moved into doc as README.old and README.older
author Mychaela Falconia <falcon@ivan.Harhan.ORG>
date Sat, 07 Nov 2015 06:59:51 +0000
parents rvinterf/README.old@f114f5c547ec
children
comparison
equal deleted inserted replaced
970:f46a914c455e 971:53114af707f2
1 I (Spacefalcon the Outlaw, FreeCalypso developer) am still learning what kinds
2 of traffic may be passed across TI's RVTMUX binary-packet serial interface. We
3 already know that much of this traffic is debug trace output, i.e.,
4 unidirectional and essentially unconditional output from the GSM device. All
5 of the "standard" firmwares we have (mokoN, our leo2moko which functions almost
6 identically, and Pirelli's fw) produce massive volumes of such trace output in
7 normal operation. We already know that this "unsolicited" trace output comes
8 in at least 3 different flavors:
9
10 * RiViera traces emitted by rvf_send_trace()
11 * L1 traces
12 * G23 traces
13
14 The RVTMUX interface can be used for more than just trace output, though: any
15 component in TI's fw suite can send and/or register to receive binary packets.
16 As I slowly work my way through various components which comprise TI's Leonardo
17 fw whose semi-source we use as our reference version, learning what they do and
18 reintegrating them in our own gsm-fw, I will undoubtedly uncover additional uses
19 to which the RVTMUX interface is put.
20
21 Aside from the trivial provision in the RVT module itself whereby an external
22 host can send a command to the target to set a filter masking some of the RV
23 trace output, so far the only entity I've come across which accepts packets from
24 an external host is ETM (Enhanced Test Mode). ETM implements a registration
25 system of its own, whereby other modules can register with ETM to receive
26 certain external command messages passing first through RVT, then through ETM.
27
28 Because I do not yet have a clear mental picture of *every* function for which
29 the RVTMUX interface will ever be used, it is correspondingly impractical to
30 decide on a once-and-for-all design of what the host-side software for talking
31 to this interface should be like. Therefore, it is currently premature to
32 expect any stability in the present rvinterf subdirectory of freecalypso-sw; I
33 may implement something one day, then toss it away the next day (without
34 providing much in the way of backward compatibility) when I come up with some
35 other idea.
36
37 The current roadmap for what the rvinterf suite of host tools is envisioned to
38 look like eventually is as follows:
39
40 rvtdump Opens the serial port, decodes TI's binary packet protocol, and
41 simply dumps every received/decoded packet on stdout in a human-
42 readable form. No provision for sending anything to the target.
43 Intended use: observing the debug trace output which all TI
44 firmwares emit as standard "background noise". This utility has
45 already been written, and it allows one to observe/log/study the
46 "noise" that appears on Pirelli's USB-serial port (running
47 Pirelli's original fw), as well as that emitted on the IrDA
48 (headset jack) port on the GTA02 by mokoN/leo2moko firmwares.
49
50 rvinterf My plan is to make a copy of rvtdump, called rvinterf, and have
51 it act very much like rvtdump: receive TI's packets from the
52 serial port, decode them and print the decoded form on stdout.
53 However, rvinterf will also create a listening UNIX domain
54 socket to which other programs in the present suite will
55 connect. These other programs connecting through rvinterf will
56 be able to send packets to the target, as well as register to
57 receive certain kinds of target->host message packets.
58
59 fc-tmsh FreeCalypso Test Mode Shell is my vision for the utility which
60 will provide a practically usable interface to ETM. ETM's
61 general mode of operation seems to be (weasel phrase inserted
62 because many other fw components may connect through ETM, and I
63 have yet to study all of them) command-response: an external
64 host sends a command to ETM, that command gets dispatched to the
65 proper registered handler, the command function is executed, a
66 response packet is composed, and finally that response is sent
67 back to the host. But because all code on the target side is
68 under active development and debugging, we should not expect
69 perfect lock-step behaviour on the interface; instead, our
70 fc-tmsh should be fundamentally asynchronous: when the user
71 enters a command, the appropriate command packet is sent to the
72 target, but we are prepared for target->host messages at any
73 time, without enforcing strict correspondence to issued
74 commands: let the developer-operator sort that out instead.
75
76 The usage scenario I envision is that one will need to run rvinterf first
77 (either directly or through fc-xram) in one terminal window, leave it running,
78 then run fc-tmsh in another terminal window, and have it connect to rvinterf
79 via the local UNIX domain socket interface. Why such complexity, why not have
80 one program do everything? I suspect that in many debug/experimentation
81 sessions it will be necessary to use fc-tmsh on "noisy" targets, i.e., in
82 scenarios where the target is continuously spewing its "normal" voluminous debug
83 trace output, such that the "interesting" output as in responses to commands
84 gets drowned in the noise. In such a scenario it would be helpful to have one
85 terminal window in which one sees the transcript of the fc-tmsh session,
86 consisting of issued commands and received ETM responses without the general
87 noise, and another window in which one sees all RVTMUX interface activity in
88 real time - the latter would allow one to observe commands having side effects
89 outside of ETM, such as crashing the whole fw. :-)