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