[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
Fresh off the Qualcomm printing press:

"Comprehensive AT Command Set in AMSS Software" [80-VR432-1 Rev.C] (Dec 21, 2012)

This is a very thorough and useful document of the complete QC AT command set and AT Command Processor (ATCoP). As is clear from that document it is easy to build your own custom AT commands...if you have the source code. It also confirms some of our previous findings and speculations about the transports and protocols used for these Qualcomm modems.

ATCoP overview

The ATCoP implements the parsing and processing of modem AT commands for

packet-switched data support, circuit-switched data support, SMS, and GSM FAX

support as per the requirements specified in [S1], [S2], [S3], and [S6].

General architecture and control flow

The ATCoP implementation consists of a processing engine containing lists of

the supported AT commands. The processing engine parses the AT commands and

executes commands from command tables.

The ATCoP processing engine processes AT commands received from the serial

port (the Rm interface) in the AT Command state. Figure 3-1 depicts the basic

architecture and data flow of ATCoP.

During the initialization, the shim layer between SIO driver and data services

(SIOLIB) registers with the Runtime Device Mapper (RDM) for all of the port

opening and closing functionalities.

Whenever a device is connected (or disconnected), the RDM invokes the SIOLIB

call back function to notify the opening (or closing) of the corresponding

port. SIOLIB then raises a respective signal to itself (DS task). Figure 3-1

illustrates the basic ATCoP architecture and data flow, and indicates a USB

being plugged in.

In the signal handler, the SIOLIB registers watermarks and various callbacks

for events, e.g., non-empty watermark, low watermark, high watermark, with

SIO.

Whenever data is queued into the SIO driver from the USB, it will invoke

appropriate callbacks, e.g., non_empty watermark, etc., to raise a signal to

the SIOLIB. If the USB is selected as a modem port (modem ports are selected

through UI), then data from USB will be routed to ATCoP via SIOLIB.

In the signal handler, the ATCoP extracts the data and processes the AT

commands and returns the result to SIO via SIOLIB. This job of extraction and

processing by the ATCoP is spread across several modules. These modules

include:

SIO data preprocessor

AT command parser

ATCoP

AT command response generator

(1) AT command data received by the serial drivers from the DTE is first processed

by the SIO data preprocessor. A NULL-terminated command line is produced and

passed to the AT command parser.

(2) The NULL-terminated command line is parsed by the AT command parser. A token

structure is produced by the parser for each command parsed and is queued for

processing by the ATCoP. The parser places a token structure on the queue for

each command contained within the command line before the ATCoP is invoked.

AT commands are defined in command tables, with each command table entry

containing a pointer to an associated command execution function.

(3) The ATCoP performs a table lookup on each command token structure removed from

the token queue. If a match is found, the associated command execution

function is called to process the command.

(4) The AT command response generator provides utilities that format command

responses, generate result codes, and send responses to the DTE.

The ATCoP processes an AT command line one command at a time. If any command

within the command line produces an error, command responses are generated for

any commands processed before the error. An error result code is then

generated to terminate the command line response and the remaining commands in

the command line are dropped without further processing.

Only after the completion of execution of the current AT command will it

service other modem ports if any data is present.
​

and FWIW:

"SoC Android and Linux platforms (shared memory)

On-chip Qualcomm modems are enabled using Linux sockets and Qualcomm’s proprietary QMUX daemon (qmuxd). The SMD channel number is specified as the device ID. Currently the only channel number used is 0 (zero)."

This is why we (used to) see /dev/smd0 as our modem device..