QMI » History » Version 14
domi, 08/26/2018 03:43 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 | 12 | laforge | 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.so@, @libqmi-framework.so@) that encapsulate the qmuxd and QMI communication protocols, the message encoding/decoding and state machines. |
16 | 11 | laforge | |
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 | h2. AT command implementation (QMI ATCOP service layer) |
||
112 | 1 | laforge | |
113 | 10 | laforge | This is used by client programs to register AT command call-backs within the modems AT command interpreter. |
114 | 1 | laforge | |
115 | 10 | laforge | The QMI ATCOP service layer seems to be pre-IDL, as it doesn't have the usual IDL compiler code structure. |
116 | |||
117 | 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) |
||
118 | |||
119 | 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 |
||
120 | 2 | laforge | |
121 | h3. qmi_atcop_fwd_at_urc_req() |
||
122 | |||
123 | used to send unsolicited response codes to modem |
||
124 | |||
125 | h3. qmi_atcop_fwd_at_cmd_resp() |
||
126 | |||
127 | 6 | zecke | used by client to send response to an AT command previously forwarded |
128 | 2 | laforge | to the client from the modem |
129 | |||
130 | h3. qmi_atcop_reg_at_command_fwd_req() |
||
131 | |||
132 | used by client to registre any AT commands that need to be forwarded |
||
133 | to it from the modem |
||
134 | |||
135 | h3. qmi_atcop_srvc_init_client() |
||
136 | |||
137 | intialization |
||
138 | |||
139 | h3. qmi_atcop_srvc_release_client() |
||
140 | |||
141 | cleanup |
||
142 | |||
143 | h2. QMI Services (via IDL) |
||
144 | |||
145 | 4 | laforge | See [[EC20_QMI]] and [[EC25_QMI]] for the IDLs included in the respective modem firmware |
146 | |||
147 | 2 | laforge | h3. Test Service |
148 | |||
149 | Part of qmi-framework. IDL descriptions for |
||
150 | |||
151 | * ping req/resp |
||
152 | * test_ind |
||
153 | * data req/resp |
||
154 | * large_data req/resp |
||
155 | * data_ind_reg req/resp |
||
156 | * test_data_ind |
||
157 | * get_service_name req/resp |
||
158 | |||
159 | h3. common_v01 |
||
160 | |||
161 | * get_supported_msgs req/resp |
||
162 | * get_supported_fields req/resp |
||
163 | |||
164 | h3. application_traffic_pairing_v01 |
||
165 | |||
166 | h3. card_application_toolkit_v02 |
||
167 | |||
168 | 7 | zecke | SIM/USIM toolkit related |
169 | 2 | laforge | |
170 | h3. circuit_switched_video_telephony_v01 |
||
171 | |||
172 | h3. coexistence_manager_v01 |
||
173 | |||
174 | bt/wifi coexistance? |
||
175 | |||
176 | h3. control_service_v01 |
||
177 | |||
178 | h3. data_system_determination_v01 |
||
179 | |||
180 | check for availability of wlan/modem/... data bearers and set related |
||
181 | policy |
||
182 | |||
183 | h3. device_management_service_v01 |
||
184 | |||
185 | * inquiry about device maker/model/version |
||
186 | * MSISDN, ICCID, IMSI, MAC address inquiry |
||
187 | * PIN entry/management |
||
188 | * locking |
||
189 | |||
190 | h3. ip_multimedia_subsystem_application_v01 |
||
191 | |||
192 | h3. ip_multimedia_subsystem_dcm_v01 |
||
193 | |||
194 | h3. ip_multimedia_subsystem_presence_v01 |
||
195 | |||
196 | h3. ip_multimedia_subsystem_rtp_v01 |
||
197 | |||
198 | h3. ip_multimedia_subsystem_settings_v01 |
||
199 | |||
200 | h3. ip_multimedia_subsystem_video_telephony_v01 |
||
201 | |||
202 | h3. network_access_service_common_v01 |
||
203 | |||
204 | h3. network_access_service_v01 |
||
205 | |||
206 | * network scan / registration |
||
207 | * network preference |
||
208 | * forbidden networks |
||
209 | * rf band information |
||
210 | * operator name |
||
211 | * rx diversity |
||
212 | |||
213 | h3. persistent_device_configuration_v01 |
||
214 | |||
215 | h3. phonebook_manager_service_v01 |
||
216 | |||
217 | h3. qmi_adc_service_v01 |
||
218 | |||
219 | * ADC conversion/calibration |
||
220 | |||
221 | h3. qmi_ims_vt_v01 |
||
222 | |||
223 | h3. qualcomm_mobile_access_point_msgr_v01 |
||
224 | |||
225 | h3. qualcomm_mobile_access_point_v01 |
||
226 | |||
227 | 9 | laforge | See [[QCMAP]] |
228 | |||
229 | 2 | laforge | h3. radio_frequency_radiated_performance_enhancement_v01 |
230 | |||
231 | h3. sar_vs_service_v01 |
||
232 | |||
233 | h3. specific_absorption_rate_v01 |
||
234 | |||
235 | h3. user_identity_module_remote_v01 |
||
236 | |||
237 | APDU forwarding of SIM/USIM to remote location? |
||
238 | |||
239 | Probably more te opposite: A way how a modem can export a CCID device |
||
240 | towards a PC and then map the APDUs in something that the modem can |
||
241 | digest? |
||
242 | |||
243 | h3. user_identity_module_v01 |
||
244 | |||
245 | SIM/USIM card access |
||
246 | |||
247 | * read/write transparent / record EF |
||
248 | * verify / unblock / change pin |
||
249 | * card power up/down |
||
250 | * authenticate |
||
251 | * raw APDU |
||
252 | * SAP |
||
253 | * logicla channels |
||
254 | * ATR |
||
255 | * multi sim (slot) management |
||
256 | |||
257 | h3. voice_service_common_v02 |
||
258 | |||
259 | h3. voice_service_v02 |
||
260 | |||
261 | call control |
||
262 | |||
263 | h3. wireless_data_administrative_service_v01 |
||
264 | 8 | zecke | |
265 | 2 | laforge | h3. wireless_data_service_v01 |
266 | |||
267 | cellular data |
||
268 | |||
269 | h3. wireless_messaging_service_v01 |
||
270 | |||
271 | SMS-PP, SMS-CB |
||
272 | 5 | laforge | |
273 | h2. further reading |
||
274 | |||
275 | 14 | domi | -http://www.lanedo.com/documents/Qualcomm%20Gobi%20devices%20on%20Linux.pdf- |
276 | File has since been removed. After extracting it from Archive.org it has been attached here. |