Project

General

Profile

QMI » History » Revision 4

Revision 3 (laforge, 12/17/2016 01:29 PM) → Revision 4/15 (laforge, 12/17/2016 01:37 PM)

{{>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 clien 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 toolkint 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 

 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
Add picture from clipboard (Maximum size: 48.8 MB)