Mux cli

Mux cli is the Openezx name given to Motorola's implementation of the 3GPP 27.010 protocol

3GPP specification [1]

Additions

Motorola has made a couple of proprietary additions to the standard 27.010 basic protocol.

1. Sequence number & ack

After every receive the AP (application processor) sends an ack with the sequence number for the next frame for the BP (baseband processor) to use (the sequence number wraps back to zero upon reaching 4).

This addition is unusual for a 27.010 implementation and appears to be a deliberate mechanism to limit the throughput of the link, potentially a problem with the UART.

 4f = ack command

 Example AP ack frame (flag,dlc(0),ack,len(1),seqnumber(2),crc,flag)
 f9 03 4f 03 02 94 f9

2. Command & Data identification

The advantage of using your own silicon, you can specify enhancements. This simple addition of command or data for BP->AP flows enables the AP driver to quickly interpret and route the user packet (useful for identification of GPRS commands and GPRS data).

 Command tag 0x55
 Data tag 0XAA

Files

 drivers/char/
 ts0710.h
 ts0710_mux.h
 ts0710_mux.c
 ts0710_mux_usb.h
 ts0710_mux_usb.c

Current status

The mux code looks complete with minor changes for workqueues and Alan Cox's tty flip buffer changes.

Write of the initial SABM frame occurs but the underlying USB driver does not send the frame since it is not in the correct state, the driver has not been probed. Probing is when a device is associated with a driver. The lack of probing appears to be due to a lack of interrupts from the baseband.

To reproduce ...

 modprobe ts0710_mux
 mknod /dev/mux0 c 250 0
 chmod 664 /dev/mux0
 echo "AT" > /dev/mux0

 send_sabm: Creating SABM packet to DLCI 0
 f9 03 3f 01 1c f9 drivers/char/ts0710_mux_usb.c: usb_ipc_write: count=6, buf:
 bvd_dbg_hex: f9 03 3f 01 1c f9
 drivers/char/ts0710_mux_usb.c: usb_ipc_write: ret=6, bvd_ipc->xmit.buf:
 bvd_dbg_hex: f9 03 3f 01 1c f9
 drivers/char/ts0710_mux_usb.c: usb_ipc_write: ret=6

Tracing the lack of interrupts ...

The phone appears to have 3 modes - pass through mode, flash mode and regular mode.

• In flash mode the baseband appears as a usb device S Flash Neptune LTE, whilst in this mode it appears that the baseband does not generate any interrupts.

• In pass through mode the baseband appears to be set up to talk to the PC via USB.

The current focus is on how the baseband is set to particular mode by Motorola's apboot (blob boot loader) and how to persuade the baseband back into regular mode (or pass through mode) upon entering the newly loaded 2.6 kernel.

The setting of interrupts and handshaking between BP/AP is done in arch/arm/mach-pxa/ezx.c and apboot a780-blob/src/blob/start.S & main.c involving GPIO_BB_RESET, GPIO_MCU_INT_SW & GPIO_BP_RDY

 Revelevant ML entries about BP/AP interrupts/handshaking (by Harald):
 ML 2006-May/000372.html [2]
 ML 2006-May/000435.html [3]

Diagrams

The following diagrams use Alessandro Rubini's notation to describe the structure and flows [4].

Simplified receive

Steps:

• Interrupt occurs and the driver retrieves the byte stream - data stored in flip buffer (tty_io.c) and entry added to work queue by mux_dispatcher.
• At some point later, when out of interrupt context, the work queue processing is invoked and at some further point of time the receive_worker method is executed. Data is retrieved from the tty buffer and if valid length and crc, passed to ts0710_recv_data (note that the receive_worker also does the AP ack of the frame).
• The ts0710_recv_data method handles the 07.10 protocol, the decode and control responses for the protocol. In this example the frame contains user data (a UIH frame). The DLC is mapped to the correct tty and control transferred to the receive_buf function for the line discipline related to that tty.
• The line discipline holds the data until a user read is actioned, at which point it transfers the data depending on the line discipline to userspace (if n_tty to /dev/muxN) or onwards to TCP/IP (if gprsv or ppp to netif_rx).

Simplified write

Steps:

• Write is invoked from user space or the TCP/IP stack on the line discipline. To the line discipline the mux code looks like any other driver. The data is passed to the driver, via tty_io, by use of the driver write function pointer.
• The mux_write function validates the state of the associated DLC (see mapping at bottom of page) and if connected, stores the data as a UIH frame in the mux_send_info array. If not already scheduled the work queue is enabled and control returns to the line discipline with the number of bytes 'written'.
• At some later point, the work queue invokes the send_worker function. All waiting frames at that point are processed, for each frame checking that the underlying driver is connected and capable of handling the frame (by calling mux_chars_in_serial_buffer) before invoking the basic_write method to transfer the frame to the underlying driver (usb currently).

A generic solution - using a line discipline

The ts0710_mux driver requires particular methods to be called upon data being sent or data being received. The names are encapsulated in defines COMM_MUX_SENDER and COMM_MUX_DISPATCHER. The use of these hardcoded names restricts portability, requiring that each transport be modified to call these methods at the correct time.

To remove this dependency, and to allow for traversal between muxed and non muxed modes, a line discipline can be used. The line discipline is then responsible for calling the hardcoded ts0710_mux methods, allowing the multiplexing protocol to be used with any transport. The user can switch between muxed and non muxed operation by switching the line discipline associated, using ioctl call TIOCSETD.

TODO - coming soon

diagram showing frame definitions

gprsv line discipline - detail the concatenation of data to create IP packets & placement on netif_rx

CSD handling - conventional ppp line discipline

Distant future - standardise the implementation - test with a range of basebands (TI-Condat, Agere-Optimay, TTPCom etc) - enable inclusion of advanced mode & convergence layers. Emulation of link.

Handy lookup

DLC to /dev/mux mapping (from ts0710_mux.h)

DLC	Description	Cmd	Data
0	Control Channel	-	-
1	Voice Call & Network MM	0
2	SMS MO	1
3	SMS MT	2
4	Phonebook SIM	3
5	Misc	4
6	CSD / Fax	5	8
7	GPRS 1	6	9
8	GPRS 2	7	10
9	Logger CMD		11
10	Logger Data		12
11	Test CMD		13
12	AGPS		14
13	NetMonitor		15

TCmd - provides test commands
Log - debugging info from BP and DSP
NetMonitor - data from BP (also nm kernel module)