Project

General

Profile

QMI » History » Version 9

Version 8 (zecke, 12/17/2016 07:23 PM) → Version 9/15 (laforge, 12/23/2016 10:54 AM)

{{>toc}}

h1. QMI

h2. QMI (Qualcomm MSM Interface)

This is the general term for all related messaging between processors
and their software stacks on Qualcomm cellular processors.

h2. IDL

* @int32_t qmi_idl_get_service_id(service_obj, service_id)@
get service ID for a given service object

* @qmi_idl_message_decode()@
Decode from TLV to C structure

* @qmi_idl_message_encode()@
Encode from C structure to wire format TLV

h3. IDL Structures

Individual services are implemented in a data-driven manner by data
structures describing the type of messsages and the message TLV
structure.

In the end, a service describes itself using the master structure
qmi_idl_service_object, consisting of
* library version (0x04)
* idl version
* service ID
* maximum message length
* number of command/response/indication messges in tables
* tables describing messages (@qmi_idl_service_message_table_entry@)
* tables describing types (@qmi_idl_type_table_object@)

The data structures describing a given service are generated by an IDL
compiler.

If you have a binary libqmi* providing IDL definitions, you can use the following
commadn to extract the IDL service definitions supported:
<pre>
strings libqmi* | grep _idl_service_object | sort | uniq
</pre>

h2. CSI (Common Service Interface)

Data model (see @qmi_csi_common.h@ for more info):

* each service list has a list of active services
* each service has a table of transports associated with it
* each service also has a list of connected clients
* each client has a pointer to the transport it connected from
* each client also has a list of outstanding transactions

CSI has only a single transport on Linux, using te AF_MSM_IPC type
sockets as a basis.

h2. SAP (Service Access Proxy)

Intended to export a service off-chip using QMUX daemon.

Encodes/Decodes messages for registering services:
* register_service request/response
* deregister_service request/response
* client_connect indication
* client_disconnect indication

h2. QMUX (QMI Multiplex)

The related code can either talk directly to the shared-memory devices
on Linux and thus the hardware (see @qmi_platform_qmux_io.c@).

It can however also establish a connection via a multiplex daemon.
This connection utilizes unix domain STREAM type sockets in
/dev/socket, specifically:
* @/dev/socket/qmux_audio/qmux_{client,connect}_socket@
* @/dev/socket/qmux_bluetooth/qmux_{client,connect}_socket@
* @/dev/socket/qmux_radio/qmux_{client,connect}_socket@
* @/dev/socket/qmux_gps/qmux_{client,connect}_socket@
* @/var/qmux_{client,connect}_socket@ on non-android devices

h2. QCCI (QMI Common Client Interface)

The QCCI layer wraps QMI into the respective transport. The
transports supported are:

* IPC router (linux kernel socket family)
* QMUXD (using qmi_qmux_... API, via unix domain sockets)
* UDP packets (base port 10000)

The CCI API is what QMI clients normally would call to initiate a
client connection to a service. The CCI functions would then normally
be wrapped by some service specific code that wraps the IDL
definitions for message encoding/decoding and provides
service-specific API to the client.

h2. IPC (Inter Process Communications)

Qualcomm implements a socket-based inter process communication on
Linux. It is implemented usinga new address family, @AF_MSM_IPC@ (27).

The socket is used as datagram type socket (SOCK_DGRAM).

The socket address of a related socket consists of:

* the socket family (AF_MSM_IPC)
* a @struct msm_ipc_addr@, consisting of
** a single address type byte
** a port address (node_id, port_id)
** a port name (service, instance)

h2. IRSC (IPC Router Security Control)

FIXME

h2. Shared Memory based Logging

There's a @/dev/smem_log@ which can be opened and read from. It
supports some specific ioctl() to set binary mode.

More information in @smem_log.h@

h2. AT command implementation (QMI ATCOP service layer)

This is used by client programs to register AT command call-backs
within the modems AT command interpreter.

The QMI ATCOP service layer seems to be pre-IDL, as it doesn't have
the usual IDL compiler code structure.

h3. qmi_atcop_fwd_at_urc_req()

used to send unsolicited response codes to modem

h3. qmi_atcop_fwd_at_cmd_resp()

used by client to send response to an AT command previously forwarded
to the client from the modem

h3. qmi_atcop_reg_at_command_fwd_req()

used by client to registre any AT commands that need to be forwarded
to it from the modem

h3. qmi_atcop_srvc_init_client()

intialization

h3. qmi_atcop_srvc_release_client()

cleanup

h2. QMI Services (via IDL)

See [[EC20_QMI]] and [[EC25_QMI]] for the IDLs included in the respective modem firmware

h3. Test Service

Part of qmi-framework. IDL descriptions for

* ping req/resp
* test_ind
* data req/resp
* large_data req/resp
* data_ind_reg req/resp
* test_data_ind
* get_service_name req/resp

h3. common_v01

* get_supported_msgs req/resp
* get_supported_fields req/resp

h3. application_traffic_pairing_v01

h3. card_application_toolkit_v02

SIM/USIM toolkit related

h3. circuit_switched_video_telephony_v01

h3. coexistence_manager_v01

bt/wifi coexistance?

h3. control_service_v01

h3. data_system_determination_v01

check for availability of wlan/modem/... data bearers and set related
policy

h3. device_management_service_v01

* inquiry about device maker/model/version
* MSISDN, ICCID, IMSI, MAC address inquiry
* PIN entry/management
* locking

h3. ip_multimedia_subsystem_application_v01

h3. ip_multimedia_subsystem_dcm_v01

h3. ip_multimedia_subsystem_presence_v01

h3. ip_multimedia_subsystem_rtp_v01

h3. ip_multimedia_subsystem_settings_v01

h3. ip_multimedia_subsystem_video_telephony_v01

h3. network_access_service_common_v01

h3. network_access_service_v01

* network scan / registration
* network preference
* forbidden networks
* rf band information
* operator name
* rx diversity

h3. persistent_device_configuration_v01

h3. phonebook_manager_service_v01

h3. qmi_adc_service_v01

* ADC conversion/calibration

h3. qmi_ims_vt_v01

h3. qualcomm_mobile_access_point_msgr_v01



h3. qualcomm_mobile_access_point_v01

See [[QCMAP]]

h3. radio_frequency_radiated_performance_enhancement_v01

h3. sar_vs_service_v01

h3. specific_absorption_rate_v01

h3. user_identity_module_remote_v01

APDU forwarding of SIM/USIM to remote location?

Probably more te opposite: A way how a modem can export a CCID device
towards a PC and then map the APDUs in something that the modem can
digest?

h3. user_identity_module_v01

SIM/USIM card access

* read/write transparent / record EF
* verify / unblock / change pin
* card power up/down
* authenticate
* raw APDU
* SAP
* logicla channels
* ATR
* multi sim (slot) management

h3. voice_service_common_v02

h3. voice_service_v02

call control

h3. wireless_data_administrative_service_v01

h3. wireless_data_service_v01

cellular data

h3. wireless_messaging_service_v01

SMS-PP, SMS-CB

h2. further reading

http://www.lanedo.com/documents/Qualcomm%20Gobi%20devices%20on%20Linux.pdf
Add picture from clipboard (Maximum size: 48.8 MB)