QMI » History » Version 11
laforge, 12/25/2016 10:02 PM
1 | 2 | laforge | {{>toc}} |
---|---|---|---|
2 | |||
3 | 1 | laforge | h1. QMI |
4 | 2 | laforge | |
5 | h2. QMI (Qualcomm MSM Interface) |
||
6 | 1 | laforge | |
7 | 11 | laforge | This is the general term for all related messaging between processors and their software stacks on Qualcomm cellular processors. |
8 | |||
9 | In case of data cards / data modems, QMI is often exposed to the host PC via USB. On Linux hosts, the open source libqmi-glib (https://www.freedesktop.org/wiki/Software/libqmi/) is often used to inplement the QMI protocols to control the cellular modem. |
||
10 | |||
11 | QMI offers various different _services_ (e.g. WDS, the wireless data service) which are exposed via the QMI protocol stack on one or many QMI _ports_. |
||
12 | |||
13 | In the context of multi-processor Qualcomm chipsets, such as the MDM9615/9x07 used in cellular modems / data cards, or also in the case of Android smartphones, QMI ports are exposed to the Linux-running application CPU core inside the chip. There can be many different transport mechanisms, but in the case of modern integrated chips, it is primarily SMD (Shared Memory Device). |
||
14 | |||
15 | On the OE based Linux in the cellular modems, there is a proprietary QMI multiplex daemon (@qmuxd@), which acts as a proxy between the shared memory device and various userspace processes accessing QMI services. Those client programs communicate with qmuxd over a unix-domain socket. There are (proprietary) libraries (@libqmi.so2, @libqmi-framework.so@) that encapsulate the qmuxd and QMI communication protocols, the message encoding/decoding and state machines. |
||
16 | |||
17 | On Android phones using integrated Qualcomm chipsets, there is an Android RIL daemon that converts from RIL to QMI. |
||
18 | |||
19 | |||
20 | 2 | laforge | |
21 | h2. IDL |
||
22 | |||
23 | * @int32_t qmi_idl_get_service_id(service_obj, service_id)@ |
||
24 | get service ID for a given service object |
||
25 | |||
26 | * @qmi_idl_message_decode()@ |
||
27 | Decode from TLV to C structure |
||
28 | |||
29 | * @qmi_idl_message_encode()@ |
||
30 | Encode from C structure to wire format TLV |
||
31 | |||
32 | h3. IDL Structures |
||
33 | |||
34 | Individual services are implemented in a data-driven manner by data |
||
35 | structures describing the type of messsages and the message TLV |
||
36 | structure. |
||
37 | |||
38 | In the end, a service describes itself using the master structure |
||
39 | qmi_idl_service_object, consisting of |
||
40 | * library version (0x04) |
||
41 | * idl version |
||
42 | * service ID |
||
43 | * maximum message length |
||
44 | * number of command/response/indication messges in tables |
||
45 | * tables describing messages (@qmi_idl_service_message_table_entry@) |
||
46 | * tables describing types (@qmi_idl_type_table_object@) |
||
47 | |||
48 | The data structures describing a given service are generated by an IDL |
||
49 | compiler. |
||
50 | |||
51 | 3 | laforge | If you have a binary libqmi* providing IDL definitions, you can use the following |
52 | commadn to extract the IDL service definitions supported: |
||
53 | <pre> |
||
54 | strings libqmi* | grep _idl_service_object | sort | uniq |
||
55 | </pre> |
||
56 | 2 | laforge | |
57 | h2. CSI (Common Service Interface) |
||
58 | |||
59 | Data model (see @qmi_csi_common.h@ for more info): |
||
60 | |||
61 | * each service list has a list of active services |
||
62 | * each service has a table of transports associated with it |
||
63 | * each service also has a list of connected clients |
||
64 | * each client has a pointer to the transport it connected from |
||
65 | * each client also has a list of outstanding transactions |
||
66 | |||
67 | CSI has only a single transport on Linux, using te AF_MSM_IPC type |
||
68 | sockets as a basis. |
||
69 | |||
70 | |||
71 | h2. SAP (Service Access Proxy) |
||
72 | |||
73 | Intended to export a service off-chip using QMUX daemon. |
||
74 | |||
75 | Encodes/Decodes messages for registering services: |
||
76 | * register_service request/response |
||
77 | * deregister_service request/response |
||
78 | * client_connect indication |
||
79 | * client_disconnect indication |
||
80 | |||
81 | |||
82 | h2. QMUX (QMI Multiplex) |
||
83 | |||
84 | The related code can either talk directly to the shared-memory devices |
||
85 | on Linux and thus the hardware (see @qmi_platform_qmux_io.c@). |
||
86 | |||
87 | It can however also establish a connection via a multiplex daemon. |
||
88 | This connection utilizes unix domain STREAM type sockets in |
||
89 | /dev/socket, specifically: |
||
90 | * @/dev/socket/qmux_audio/qmux_{client,connect}_socket@ |
||
91 | * @/dev/socket/qmux_bluetooth/qmux_{client,connect}_socket@ |
||
92 | * @/dev/socket/qmux_radio/qmux_{client,connect}_socket@ |
||
93 | * @/dev/socket/qmux_gps/qmux_{client,connect}_socket@ |
||
94 | * @/var/qmux_{client,connect}_socket@ on non-android devices |
||
95 | |||
96 | h2. QCCI (QMI Common Client Interface) |
||
97 | |||
98 | The QCCI layer wraps QMI into the respective transport. The |
||
99 | transports supported are: |
||
100 | |||
101 | * IPC router (linux kernel socket family) |
||
102 | * QMUXD (using qmi_qmux_... API, via unix domain sockets) |
||
103 | * UDP packets (base port 10000) |
||
104 | |||
105 | The CCI API is what QMI clients normally would call to initiate a |
||
106 | client connection to a service. The CCI functions would then normally |
||
107 | be wrapped by some service specific code that wraps the IDL |
||
108 | definitions for message encoding/decoding and provides |
||
109 | service-specific API to the client. |
||
110 | |||
111 | |||
112 | h2. IPC (Inter Process Communications) |
||
113 | |||
114 | Qualcomm implements a socket-based inter process communication on |
||
115 | Linux. It is implemented usinga new address family, @AF_MSM_IPC@ (27). |
||
116 | |||
117 | The socket is used as datagram type socket (SOCK_DGRAM). |
||
118 | |||
119 | The socket address of a related socket consists of: |
||
120 | |||
121 | * the socket family (AF_MSM_IPC) |
||
122 | * a @struct msm_ipc_addr@, consisting of |
||
123 | ** a single address type byte |
||
124 | ** a port address (node_id, port_id) |
||
125 | ** a port name (service, instance) |
||
126 | |||
127 | h2. IRSC (IPC Router Security Control) |
||
128 | |||
129 | FIXME |
||
130 | |||
131 | h2. Shared Memory based Logging |
||
132 | |||
133 | There's a @/dev/smem_log@ which can be opened and read from. It |
||
134 | supports some specific ioctl() to set binary mode. |
||
135 | |||
136 | More information in @smem_log.h@ |
||
137 | |||
138 | h2. AT command implementation (QMI ATCOP service layer) |
||
139 | 1 | laforge | |
140 | 10 | laforge | This is used by client programs to register AT command call-backs within the modems AT command interpreter. |
141 | 1 | laforge | |
142 | 10 | laforge | The QMI ATCOP service layer seems to be pre-IDL, as it doesn't have the usual IDL compiler code structure. |
143 | |||
144 | The baseband firmware appears have a compile-time white-list of AT commands for which the AT command forwarding is permitted. Any other commands are rejected with error 48 (invalid argument) |
||
145 | |||
146 | Qualcomm default seems to permit +CLVL, +CKPD, +CMUT, +CTSA, +CBKLT, +CFUN, +CDIS, +CRSL, +CMAR, +CSO, +CSS, +CBC, $QCPWRDN and this may be extended by vendor-specific commands, such as +QFOTADL in the Quectel case |
||
147 | 2 | laforge | |
148 | h3. qmi_atcop_fwd_at_urc_req() |
||
149 | |||
150 | used to send unsolicited response codes to modem |
||
151 | |||
152 | h3. qmi_atcop_fwd_at_cmd_resp() |
||
153 | |||
154 | 6 | zecke | used by client to send response to an AT command previously forwarded |
155 | 2 | laforge | to the client from the modem |
156 | |||
157 | h3. qmi_atcop_reg_at_command_fwd_req() |
||
158 | |||
159 | used by client to registre any AT commands that need to be forwarded |
||
160 | to it from the modem |
||
161 | |||
162 | h3. qmi_atcop_srvc_init_client() |
||
163 | |||
164 | intialization |
||
165 | |||
166 | h3. qmi_atcop_srvc_release_client() |
||
167 | |||
168 | cleanup |
||
169 | |||
170 | h2. QMI Services (via IDL) |
||
171 | |||
172 | 4 | laforge | See [[EC20_QMI]] and [[EC25_QMI]] for the IDLs included in the respective modem firmware |
173 | |||
174 | 2 | laforge | h3. Test Service |
175 | |||
176 | Part of qmi-framework. IDL descriptions for |
||
177 | |||
178 | * ping req/resp |
||
179 | * test_ind |
||
180 | * data req/resp |
||
181 | * large_data req/resp |
||
182 | * data_ind_reg req/resp |
||
183 | * test_data_ind |
||
184 | * get_service_name req/resp |
||
185 | |||
186 | h3. common_v01 |
||
187 | |||
188 | * get_supported_msgs req/resp |
||
189 | * get_supported_fields req/resp |
||
190 | |||
191 | h3. application_traffic_pairing_v01 |
||
192 | |||
193 | h3. card_application_toolkit_v02 |
||
194 | |||
195 | 7 | zecke | SIM/USIM toolkit related |
196 | 2 | laforge | |
197 | h3. circuit_switched_video_telephony_v01 |
||
198 | |||
199 | h3. coexistence_manager_v01 |
||
200 | |||
201 | bt/wifi coexistance? |
||
202 | |||
203 | h3. control_service_v01 |
||
204 | |||
205 | h3. data_system_determination_v01 |
||
206 | |||
207 | check for availability of wlan/modem/... data bearers and set related |
||
208 | policy |
||
209 | |||
210 | h3. device_management_service_v01 |
||
211 | |||
212 | * inquiry about device maker/model/version |
||
213 | * MSISDN, ICCID, IMSI, MAC address inquiry |
||
214 | * PIN entry/management |
||
215 | * locking |
||
216 | |||
217 | h3. ip_multimedia_subsystem_application_v01 |
||
218 | |||
219 | h3. ip_multimedia_subsystem_dcm_v01 |
||
220 | |||
221 | h3. ip_multimedia_subsystem_presence_v01 |
||
222 | |||
223 | h3. ip_multimedia_subsystem_rtp_v01 |
||
224 | |||
225 | h3. ip_multimedia_subsystem_settings_v01 |
||
226 | |||
227 | h3. ip_multimedia_subsystem_video_telephony_v01 |
||
228 | |||
229 | h3. network_access_service_common_v01 |
||
230 | |||
231 | h3. network_access_service_v01 |
||
232 | |||
233 | * network scan / registration |
||
234 | * network preference |
||
235 | * forbidden networks |
||
236 | * rf band information |
||
237 | * operator name |
||
238 | * rx diversity |
||
239 | |||
240 | h3. persistent_device_configuration_v01 |
||
241 | |||
242 | h3. phonebook_manager_service_v01 |
||
243 | |||
244 | h3. qmi_adc_service_v01 |
||
245 | |||
246 | * ADC conversion/calibration |
||
247 | |||
248 | h3. qmi_ims_vt_v01 |
||
249 | |||
250 | h3. qualcomm_mobile_access_point_msgr_v01 |
||
251 | |||
252 | h3. qualcomm_mobile_access_point_v01 |
||
253 | |||
254 | 9 | laforge | See [[QCMAP]] |
255 | |||
256 | 2 | laforge | h3. radio_frequency_radiated_performance_enhancement_v01 |
257 | |||
258 | h3. sar_vs_service_v01 |
||
259 | |||
260 | h3. specific_absorption_rate_v01 |
||
261 | |||
262 | h3. user_identity_module_remote_v01 |
||
263 | |||
264 | APDU forwarding of SIM/USIM to remote location? |
||
265 | |||
266 | Probably more te opposite: A way how a modem can export a CCID device |
||
267 | towards a PC and then map the APDUs in something that the modem can |
||
268 | digest? |
||
269 | |||
270 | h3. user_identity_module_v01 |
||
271 | |||
272 | SIM/USIM card access |
||
273 | |||
274 | * read/write transparent / record EF |
||
275 | * verify / unblock / change pin |
||
276 | * card power up/down |
||
277 | * authenticate |
||
278 | * raw APDU |
||
279 | * SAP |
||
280 | * logicla channels |
||
281 | * ATR |
||
282 | * multi sim (slot) management |
||
283 | |||
284 | h3. voice_service_common_v02 |
||
285 | |||
286 | h3. voice_service_v02 |
||
287 | |||
288 | call control |
||
289 | |||
290 | h3. wireless_data_administrative_service_v01 |
||
291 | 8 | zecke | |
292 | 2 | laforge | h3. wireless_data_service_v01 |
293 | |||
294 | cellular data |
||
295 | |||
296 | h3. wireless_messaging_service_v01 |
||
297 | |||
298 | SMS-PP, SMS-CB |
||
299 | 5 | laforge | |
300 | h2. further reading |
||
301 | |||
302 | http://www.lanedo.com/documents/Qualcomm%20Gobi%20devices%20on%20Linux.pdf |