Android Ril

The RIL part of Android is mainly divided into two parts: RILJ and RILC. RILJ runs in
the java part of framework->telephony, and RILC runs in the native part of the HAL
layer. In the era of android1.0-7.0, the RIL layer architecture is shown in the following
figure:

The interaction between RILJ and RILC is based on the local Socket. RILJ and RILC
use the Socket connection of the rild port for message interaction and processing;
between RILC and Modem, the AT command is sent and executed through the Socket
port of qemud, and the Modem is completed. Operation control and query request, and
the processing of messages actively reported by the Modem.

In the era of Android 8.0+, Google introduced HIDL to replace the socket
communication method between the framework and the HAL layer. So in the era of
Android 8.0+, the RIL layer architecture is shown in the following figure:

The reasons for using HIDL are as follows:

1. Improved communication efficiency, especially the use of memory.

2. Further decouple the version compatibility issues of android and modem
manufacturers.

3. The programming interface is more friendly, similar to binder calling.

QMI RIL
We know that the mobile phone has a multi-core architecture, the main core
application processor runs the android operating system, the modem processor is
responsible for the radio frequency and protocol part, and some other socs are
responsible for special audio, radio frequency, and display processing.

The RIL architecture is to implement calls, so in the final analysis it needs to

communicate with modems. Modem manufacturers include Qualcomm, mtk, HiSilicon,
Spreadtrum, etc. Different modems have different interfaces, internal mechanisms, etc.
The app processor part uses the Android native one, but there are manufacturer
differences in the RILC and modem communication part. QMI is the communication
mechanism between the app processor and RILC designed by Qualcomm. The QMI
framework includes a client part and a server part. The QMI client runs in the app
processor and is opened by rild in dlopen mode; the QMI server runs in the modem
processor; and the socket communication is used between the client and the server. As
shown below:

android QMI mechanism---Introduction

Achillisjack 2017-07-03 22:12:13 11938 Collection 15

Classification column: ---[QMI mechanism] Article tags: android QMI

copyright
Foreword:

Qualcomm MSM Interface, used for the interaction between AP and BP side, popular
saying is to let equipment terminal TE (can be mobile phone, PDA, computer)

Operate the AMSS system on the Qualcomm BP side, such as calling functions, reading
data, and setting NV items in it.

The core of QMI is called QMI Framework (QMI Framework), and its main functions
include the following 3 points:

1. Connect MSM module and equipment terminal to provide an orthogonal control and
data channel. There are two definitions of message usage in QMI, one is

QMIControl Message, the other is QMI DataMessage, which supports the concurrency of
these two messages and will not interfere with each other and cause errors.

2. List a series of enumerated logical devices and provide them for connection. The QMI
mechanism is similar to a server mechanism, with a corresponding client side

And services side, corresponding to QMI control point and service. When AP sends a
request to BP, AP acts as a client, when AP

When receiving the response from the BP side, the AP serves as the services side. QMI
includes a series of QMI Services, such as nas, voice, wds, etc.,

These different services are equivalent to different logical devices and are called by
different apps.

3. QMI has corresponding messages and message protocols, and the equipment
terminal accesses AMSS through these messages. For different qmi messages,

The message length is different, you can define the message length yourself. Different
qmi messages have the same message format.
The figure above is a software structure diagram of QMIFramework.

It can be seen from the figure that the upper control point packs the corresponding type
of QMI message or transmits the data to be sent to the AP through the framework of
other operating systems

The logic device of the bottom layer on the side, and finally the logic device is
transmitted to the AMSS on the BP side through the inline bus interface. You can find in
the code to send from the control point

The function sent to the logical device.

This is a function for the control point to send a synchronization message to the BP side.
The parameters include the type of QMI_Service, the name of the message in the
Service,

The initial address and length of the request message, and the corresponding initial
address and length are returned. There are also many types of inline buses between the
logic device and the BP side:
USB, SDIO, shared memory, wireless protocol 802.11 can be used as a bus to connect
AP and BP. The MSM platform we are developing now uses

It is shared memory. The enumeration qmi_connection_id_type in qmi_port_defs.h in the

code defines the AP side QMI and BP side

Connection channels, including MSM platform with integrated modem and MDM with
independent modem.

In the vendor\qcom\proprietary\qmi\platform directory in the code,

linux_qmi_qmux_if_client.c defines the communication with the BP side

The type of logical device.

At present, there are four types of logical devices supported by QMI: telephone system,
audio, Bluetooth, and GPS.

TE and MSM communication schematic diagram:

Two characteristics: 1. A single physical link bus must be multiplexed by multiple logical
devices.

2. Different logical devices require independent control channels and data

channels.

The schematic diagram of the QMI terminal is as follows:

It can be seen from the figure that in the entire QMI architecture, the interaction
between TE and MSM on the software is mainly completed through the QMUX layer.

1. One service can correspond to multiple control points, and one control point can only
correspond to one service.

2. The relationship between control points and services is like the relationship between
client and server in the C/S model.

3. If a program uses several QMI services, then it must build a control point for each
service.
It can be seen that QMI is not a simple one-to-one transmission communication method,
but a service can receive messages from several control points at the same time.

The principle of its realization is also the multiplexing of transmission channels.

Introduction to Qualcomm QMI Architecture

keep_1024 2019-09-25 20:19:47 5531 Favorites 21

Classification column: Qualcomm QMI Article tags: Qualcomm QMI

copyright

What is QMI?
Qualcom Message Interface Qualcom Message Interface

Background: Deployed in 2005-2006 (formerly Qualcomm MSMTM interface), all services

were originally designed and maintained by the DATA team, and the functions were
constructed in accordance with AT command standards, mainly used for connection
manager type applications, which can be connected via USB (QMUX transmission)
Connect to the computer.

In 2009, QMI replaced RPC (Remote Procedure Call), the scope of QMI began to expand,
radio interface layer (RILs) began to transition to QMI, and defined the necessary
support; the bottom layer was replaced by more robust communication (IPC router
transmission), through sharing The memory mode (SMD) is available between on-chip
SOCs.

Qualcomm platforms are currently asymmetric multi-core, the most important ones are
AP and Modem. How do two processors communicate? We treat AP and Modem as two
hosts. The problem becomes very simple. The TCP/IP protocol is not a very successful
inter-process cross-host communication method. Qualcomm did not adopt this
approach, but borrowed from the TCP/IP framework design. Its framework is like this,
kernel mode: realizes the link layer based on shared memory (SMD) and extends the
protocol domain; user mode encapsulates an interface similar to the socket function for
use in user mode. The QMI I described is the API interface used by the user mode. These
interfaces are very similar to sockets. As long as you have experience in socket
programming, it will be easy to understand.

What does QMI provide?

Support synchronous and asynchronous interfaces;

Support communication between multiple processors;

Has good scalability;

Supports concurrent operation of multiple clients;

Support multiple servers to run concurrently, and each server corresponds to multiple
clients;

Each server also supports version information;

QMI architecture

Messages
Request message —— A request message is sent from the client to the server and
processed by the server.

Reponse message—Every request message has a response message corresponding to

it, similar to the return value of a function. If the request message is equivalent to the
calling function, the response message is equivalent to the result returned to the caller.

Indiction message—This type of message is an asynchronous message sent by the

server to the client. Before any indication message is sent, the client first needs to
establish a connection with the server through a request message. The indication
message can be sent at any time.

Features of the message:

1. The message is composed of Type-Length-Value (TLV) units;

2. Type and length are fixed size, and value is variable length;
3. Multiple tlv values can appear in each message;
4. Multiple data elements can be displayed in this value;
 5. The TLV id for each message is unique;
The structure of the message:

1. Composed of transmission header and service level message

2. The transmission head of each transmission is unique
Service Message service level load is common to all transmissions and contains the
following elements

Message ID

Message length

Zero or more variable length tlv

Clients
1. Any internal or external client application that wants to use QMI

Services
1. Any internal application service program that wants to use QMI


Common Libraries
1. Provide functions for client (QCCI) and service (QCSI)
2. Common API is applicable to all platforms/transmissions
3. Package transport and platform-specific changes to share client/service code
4. Provide encoding/decoding support for each service message

Transports
QMUX

1. Qualcomm Multiplexing Protocol (QMUX);

2. The original transmission is through a wired USB Ethernet adapter;
3. Support services on MPSS processor;
4. Support the client on the main PC connected with the application program (APPS) processor or
usb;
5. QMUX client is used for platform-specific, different platforms may be different;

IPC Router

1. IPC router is a message-oriented router that supports Qualcomm QCCI QCSI;

2. Enhanced transmission between processors on the same device;
 3. Pass QMI payload between routing nodes through SMD;
4. Support clients and services on any processor;
5. API is common to all platforms, even if the implementation is different;

QMI IDL
The QMI interface is written in Interface Definition Language (IDL), and the IDL compiler
automatically generates files .c and .h

Encoding/decoding library

1. The library is independent and decoupled from the automatically generated files
2. The meta information of the encoded/decoded message will be generated as Service_Object in
.c
3. During service/client startup, meta information will be registered to QCSI/QCCI for message
encoding/decoding
4. Client/service can send/receive messages using QCCI/QCSI API
QMI message encoding standard

1. Do not use floating-point data, but use Q16 type fixed points, that is, provide a fixed-
point implementation of 16-bit 2-bit complement integer part and 16-bit decimal part.

2. Naming Convention

1. In order to keep all message implementations consistent, the service side needs a fixed
unique prefix
2. The structure ends with _type
3. Enumeration ends with _enum
4. The request message ends with _req_msg, and the type ends with _REQ
5. The message response ends with _resp_msg, and the type ends with _RESP
6. Indicates that the message ends with _ind_msg, and the type ends with _IND

QMI QCCI
QCCI is a set of API collections for the client to receive information from the server or
send messages to the server.

The following steps describe initializing the client:

1. The QMI client creates a notification handle to receive notifications of service arrival
and exit events. Then the client

Register a notification callback function with the notifier handle;

2. When the service arrives, the signal will be set, and the notification callback function
will be called to the client's message about the service arrival;

3. The QMI client resolves the service address after receiving the service arrival
notification;

4. The QMI client initializes the client handle of the service, and the address of the
service is resolved in step 3. Then, this client handle is used to exchange QMI messages
with related QMI services;

5. When the client handle is initialized, an error callback function will be registered with
the client handle. This error callback is used to receive any notification about service
restart or subsystem restart;

6. At this time, the QMI client can release the notifier handle to avoid any resource
leakage;

7. The QMI client sends the request message synchronously or asynchronously, as

shown in the figure above;

8. When all related QMI message communication is completed, the QMI client releases
the client handle.

QCCI APIs Callback function prototypes

1. qmi_client_recv_raw_msg_async_cb
2. qmi_client_recv_msg_async_cb
3. qmi_client_ind_cb
Connection APIs

1. qmi_client_notifier_init
2. qmi_client_init
 3. qmi_client_get_service_list
Message sending APIs

1. qmi_client_send_raw_msg_sync
2. qmi_client_send_msg_sync
3. qmi_client_delete_async_txn
Release connection APIs

1. qmi_client_release
Encode and decode APIs

1. qmi_client_message_encode
2. qmi_client_message_decode

QMI QCSI
QCSI is used to receive client requests and respond to them. In addition, it is also used
to send indication messages and encode/decode messages. This message is sent by the
server.

There are three types of messages as follows:

Request message —— A request message is sent from the client to the server and
processed by the server.

Reponse message—Every request message has a response message corresponding to

it, similar to the return value of a function. If the request message is equivalent to the
calling function, the response message is equivalent to the result returned to the caller.

Indiction message-This type of message is an asynchronous message sent from the

server to the client. Before any indication message is sent, the client first needs to
establish a connection with the server through a request message. The indication
message can be sent at any time. Callback function prototypes

1. qmi_csi_connect
2. qmi_csi_disconnect
3. qmi_csi_process_req
Registration APIs

1. qmi_csi_register
2. qmi_csi_unregister
Message sending APIs

1. qmi_csi_send_resp
2. qmi_csi_send_ind
3. qmi_csi_send_broadcast_ind
Event handling APIs

1. qmi_csi_handle_event
QMI SERVER
This api is built on top of the QCSI framework

Its main purpose is to facilitate the client to implement the server with less workload

The framework allows users to write object-based servers and extend core server
objects. The core server object provides common functions that every service needs

Callback Function Prototypes

1. qmi_csi_connect
2. qmi_csi_disconnect
3. qmi_csi_process_req
Constructor/Destructor APIs

1. qmi_core_server_new
2. qmi_core_server_delete
Registration APIs

1. qmi_core_server_register
2. qmi_core_server_unregister
3. qmi_core_server_register_client
4. qmi_core_server_unregister_client
Message Dispatch APIs

1. qmi_core_server_dispatch_msg
2. qmi_core_server_send_ind
3. qmi_core_server_send_resp

QMUX
QMI Multiplexing Protocol (QMUX): QMI multiplexing protocol

After the message is transmitted from the control point to the QMI interface through a
socket-like thread, QMI is responsible for encapsulating the data, adding the header of
the QMUX message, and sending it to the QMUX layer.

Then pass the QMUX layer to the shared memory to the BP side.

QMUX message format:

The structure of the entire QMUX control channel is as shown above,

1. I/FType: After QMI encapsulates the control point data and sends it to QMUX, the added
message header is one byte in length, and the value is usually 0x01, indicating that this
message is a QMUX message. If it has other values, it is another message.
 2. Length: The length of the QMUX message, excluding I/F Type.
3. ControlFlags: Control bits, indicating the direction of message transmission. The length is 1
byte, only the 7th bit is a flag bit, and the other bits are 0. Bit7=1 indicates that the QMUX
message is sent by the server, and bit7=0 is sent by the control point.
4. Clien ID: The identification of the control point, which needs to be assigned on both the control
point and the server. When the value of the Client ID of the message sent on the server is
0xFF, it means that the message is a broadcast message, which is actively sent by the server
and searched by all control points. To.
QMUX SDU and TLV structure:

In the entire control channel message, the message identification header I/F Type and
the QMUX message header are sent out. The data transmission is completed in the
QMUXSDU. The data in the QMUX SDU needs to support the Type Length Value (TLV)
format.

The data in TLV format is stored in Value in QMI Service Message.

1. Control Flags: Indicates whether the message is a request, response or indication.