FreeCalypso > hg > freecalypso-tools
view rvinterf/doc/README.older @ 429:05dc91d011a6
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 | e7502631a0f9 |
children |
line wrap: on
line source
I (Spacefalcon the Outlaw, FreeCalypso developer) am still learning what kinds of traffic may be passed across TI's RVTMUX binary-packet serial interface. We already know that much of this traffic is debug trace output, i.e., unidirectional and essentially unconditional output from the GSM device. All of the "standard" firmwares we have (mokoN, our leo2moko which functions almost identically, and Pirelli's fw) produce massive volumes of such trace output in normal operation. We already know that this "unsolicited" trace output comes in at least 3 different flavors: * RiViera traces emitted by rvf_send_trace() * L1 traces * G23 traces The RVTMUX interface can be used for more than just trace output, though: any component in TI's fw suite can send and/or register to receive binary packets. As I slowly work my way through various components which comprise TI's Leonardo fw whose semi-source we use as our reference version, learning what they do and reintegrating them in our own gsm-fw, I will undoubtedly uncover additional uses to which the RVTMUX interface is put. Aside from the trivial provision in the RVT module itself whereby an external host can send a command to the target to set a filter masking some of the RV trace output, so far the only entity I've come across which accepts packets from an external host is ETM (Enhanced Test Mode). ETM implements a registration system of its own, whereby other modules can register with ETM to receive certain external command messages passing first through RVT, then through ETM. Because I do not yet have a clear mental picture of *every* function for which the RVTMUX interface will ever be used, it is correspondingly impractical to decide on a once-and-for-all design of what the host-side software for talking to this interface should be like. Therefore, it is currently premature to expect any stability in the present rvinterf subdirectory of freecalypso-sw; I may implement something one day, then toss it away the next day (without providing much in the way of backward compatibility) when I come up with some other idea. The current roadmap for what the rvinterf suite of host tools is envisioned to look like eventually is as follows: rvtdump Opens the serial port, decodes TI's binary packet protocol, and simply dumps every received/decoded packet on stdout in a human- readable form. No provision for sending anything to the target. Intended use: observing the debug trace output which all TI firmwares emit as standard "background noise". This utility has already been written, and it allows one to observe/log/study the "noise" that appears on Pirelli's USB-serial port (running Pirelli's original fw), as well as that emitted on the IrDA (headset jack) port on the GTA02 by mokoN/leo2moko firmwares. rvinterf My plan is to make a copy of rvtdump, called rvinterf, and have it act very much like rvtdump: receive TI's packets from the serial port, decode them and print the decoded form on stdout. However, rvinterf will also create a listening UNIX domain socket to which other programs in the present suite will connect. These other programs connecting through rvinterf will be able to send packets to the target, as well as register to receive certain kinds of target->host message packets. fc-tmsh FreeCalypso Test Mode Shell is my vision for the utility which will provide a practically usable interface to ETM. ETM's general mode of operation seems to be (weasel phrase inserted because many other fw components may connect through ETM, and I have yet to study all of them) command-response: an external host sends a command to ETM, that command gets dispatched to the proper registered handler, the command function is executed, a response packet is composed, and finally that response is sent back to the host. But because all code on the target side is under active development and debugging, we should not expect perfect lock-step behaviour on the interface; instead, our fc-tmsh should be fundamentally asynchronous: when the user enters a command, the appropriate command packet is sent to the target, but we are prepared for target->host messages at any time, without enforcing strict correspondence to issued commands: let the developer-operator sort that out instead. The usage scenario I envision is that one will need to run rvinterf first (either directly or through fc-xram) in one terminal window, leave it running, then run fc-tmsh in another terminal window, and have it connect to rvinterf via the local UNIX domain socket interface. Why such complexity, why not have one program do everything? I suspect that in many debug/experimentation sessions it will be necessary to use fc-tmsh on "noisy" targets, i.e., in scenarios where the target is continuously spewing its "normal" voluminous debug trace output, such that the "interesting" output as in responses to commands gets drowned in the noise. In such a scenario it would be helpful to have one terminal window in which one sees the transcript of the fc-tmsh session, consisting of issued commands and received ETM responses without the general noise, and another window in which one sees all RVTMUX interface activity in real time - the latter would allow one to observe commands having side effects outside of ETM, such as crashing the whole fw. :-)