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.