QMI » History » Revision 9
Revision 8 (zecke, 12/17/2016 07:23 PM) → Revision 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