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