FreeCalypso > hg > freecalypso-sw
diff rvinterf/doc/README.old @ 971:53114af707f2
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@f114f5c547ec |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/rvinterf/doc/README.old Sat Nov 07 06:59:51 2015 +0000 @@ -0,0 +1,70 @@ +You are looking at the suite of FreeCalypso tools for talking to the RVTMUX +interface provided by TI-based GSM firmwares. If you haven't already, please +read ../doc/RVTMUX first. + +The fundamental difference between these tools and loadtools is that loadtools +operate on a GSM device while its regular firmware is shut down, whereas the +present rvinterf tools talk to active running GSM firmwares. + +The following tools are currently implemented: + +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 + 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 Provides a bidirectional interface to RVTMUX on the host side. + It dumps and/or logs the "background noise" emitted by the + target just like rvtdump, but also creates a local UNIX domain + socket on the host machine to which other programs can connect, + replicating the MUXing function on the host side. + +fc-tmsh Interactive asynchronous test mode shell. This program connects + to a target GSM device through rvinterf and allows a developer- + operator to send various ETM commands to the target. ETM + responses are decoded (sometimes only lightly) and displayed. + fc-tmsh is fully asynchronous in that it continuously listens + (via select(2)) both for user input and for packets from the + target at the same time, translating any user-entered commands + into packets to the target and conversely, scribbling on the + terminal when a packet arrives from the target. It has no + knowledge of any correspondence between commands and responses + they normally elicit. + +g23sh Like fc-tmsh (same asynchronous design), but for GPF/G23 rather + than ETM. This tool and FreeCalypso project's understanding of + GPF/G23 in general are currently in the earliest stages, so it + is premature to try to describe it any further at this point. + +fc-sendsp Precursor to g23sh; even less worthy of further documentation. + +fc-fsio This program uses RVTMUX, ETM and TMFFS2 to access the live file + system of a running GSM firmware. Of the existing proprietary + firmwares, the only one that implements the TMFFS2 protocol + required for fc-fsio is Pirelli's, to the best of our knowledge. + This program connects to the target through rvinterf, but it + differs from fc-tmsh in that it operates in a synchronous + manner: the flow of operation is driven by user commands (just + like in fc-loadtool), and every time the program sends an ETM + command packet to the target, it expects a lock-step response. + +tfc139 See ../doc/Compal-unlock + +The fc-fsio, fc-tmsh and g23sh tools connect to the target not directly, but +via rvinterf. Two usage scenarios are supported: + +1. The user explicitly runs rvinterf (either directly or secondary to fc-xram, + when testing an experimental FreeCalypso firmware ramImage), leaves it + running (either backgrounded or in its own terminal window), and then runs + one of the "client" programs: fc-fsio, fc-tmsh or g23sh. The two programs + connect via local UNIX domain sockets on the host machine. + +2. All of the "client" programs under discussion can also launch rvinterf + themselves. An instance of rvinterf lauched in this manner becomes a child + process of the "client" program, terminating together with it, and the two + processes communicate via an unnamed and unbound socket pair.