FreeCalypso > hg > freecalypso-tools
view rvinterf/doc/README.old @ 752:c79aaed75bd8
compile-fc-batt: allow possible third field in source lines
Battery tables maintained in the fc-battery-conf repository will now
have a third field added, defining thresholds for the battery bars icon,
and there will be a new utility to compile them into the new
/etc/batterytab2 file read by the FC Tourmaline version of our
FCHG driver. For backward compatibility with the original Magnetite
version of FCHG, compile-fc-batt remains the tool for compiling the
original /etc/batterytab file format, and it needs to ignore the
newly added third field in battery table sources.
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Thu, 05 Nov 2020 20:37:55 +0000 |
parents | e7502631a0f9 |
children |
line wrap: on
line source
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.