移动端公众号网站开发关键词提取工具app

什么是QMI?

Qualcom Message Interface 高通信息接口

高通平台目前都是非对称多核心，最主要的是AP和Modem。两个处理器怎么进行通信呢，我们把AP和Modem当作两个主机，问题就变得了很简单，TCP/IP协议不是一种非常成功的进程间跨主机通信方式。高通没有采用这种方式，但是借鉴了TCP/IP的框架设计。它的框架是这样的，内核态：基于共享内存（SMD）实现链路层，扩展协议域；用户态，封装出类似于socket函数的接口，用于用户态使用。而我所描述的QMI就是用户态使用的API接口，这些接口非常类似于socket

QMI协议常用组件

DMS(设备管理Device Management)
提供查询设备信息功能
参考: qmi/device_management_service_v01.h
NAS(网络访问Network Access)
提供网络管理功能
参考:qmi/network_access_service_v01.h
WDS(数据连接)
参考:qmi/wireless_data_service_v01.h
UIM(管理User Identity Module)
提供查询UIM卡信息
参考:qmi/user_identity_module_v01.h
CTL(控制服务)
用户发起其他服务请求前，必须先申请 ClientID, 这个ID就是由控制服务分配的, 这个服务永远在线
参考:qmi/control_service_v01.h
数据(拨号服务)
建立数据连接
参考:data/qualcomm_mobile_access_point_msgr_v01.h

每个服务模块都定义了 请求、响应、通知Indication（指示）, 请求分为同步和异步,其中异步请求的结果通过indication指示 通知。每个请求响应都有一个匹配的ID，这样用户可以一次发出多个请求。并且响应也不必严格按照请求的顺序进行回应。

Indication指示作为主动提供的消息， 要么发送给某个特定的客户端, 要么是广播消息（广播给所有使用这个服务的客户)。 通常情况下，用户需要通过一些请求/响应 来打开indication
指示协议中的每条消息都定义了一系列输入（在请求中才有输入）参数，或者输出（在响应或者indications指示中才有输出)参数。 这些参数，我们命名为TLV

安卓架构很多人都有印象，从APP层到FrameWork层到HAL层再到Linux Kernel层。由于安卓有两个处理器，一个是AP（Application Processor），一个是BP（baseband processor），而通话主要由BP去处理。

高通的芯片里面又分什么AP、BP，甚是不解，于是百度之，终于知其大概。

AP：Application Processor，即应用芯片

BP：Baseband Processor，即基带芯片

搞什么嘛，双核就双核呗，怎么又搞出个AP和BP啊

原来，FCC（美国联邦通信委员会）认证要求将AP和BP分开，因为射频控制相关的功能（信号调制、编码、射频位移等）都是高度的时间相关的，最好能将这些函数放在一个CPU核上运行，并在这个CPU核上运行一个实时的操作系统，这样AP核上操作系统和驱动的bug就不会导致设备发送灾难性的数据到移动网络中；并且一旦BP被设计和认证好，不管你采用的操作系统和应用软件怎么变化，它都可以正确的执行通讯功能，手机的设计者也可以更加自由的设计用户界面和应用软件。

QMI举例

越来越多9X07模块被用于物联网，那么首要解决的问题即建立数据连接，所以本文使用QMI建立数据网络连接示意。

QMI初始化及释放

9X07模块提供了qcmap_msgr服务来进行拨号，通过与dsi_netctrl对比，qcmap_msgr接口更清晰，而且操作也简单。
AP侧使用QMI架构和modem通信初始化流程是固定的：

qcmap_msgr_get_service_object_v01查询服务对象 =>
qmi_client_notifier_init初始化client通知信息 =>
qmi_client_get_service_list查询支持的服务列表个数 =>
qmi_client_get_service_list查询支持的服务列表信息 =>
qmi_client_init使用其中一个服务信息初始化client

QMI机制Qualcomm MSM Interface,作用用于AP和BP侧的交互，通俗说法就是让设备终端TE（可以是手机，PDA，计算机）对高通BP侧的AMSS系统进行操作，如调用函数，读取数据，设置其中的NV项等。QMI的核心称之为QMI框架（QMI Framework），其主要功能包括以下3点：

1,连接MSM模块和设备终端，提供一个正交的控制和数据通道。在QMI的消息用有两种定义，一种是QMIControl Message,另一种是QMI DataMessage，支持这两种消息并发，不会互相干扰导致出错。

2,列举一系列的枚举逻辑设备，提供给连接使用。QMI机制类似于一个服务器机制，有相应的client端和services端，对应于QMI的control point和service。在AP向BP发送请求时，AP作为client客户端，BP作为services服务端 当AP接收BP侧返回的响应时，BP作为client客户端AP作为services服务端。

QMI包含了一系列的QMI Service，例如nas,voice,wds等，这些不同的services相当于不同逻辑设备，给不同的app调用。

3,QMI有相应的消息和消息的协议，设备终端就是通过这些消息来访问AMSS。对于不同的qmi消息，消息长度不一样，可自己定义消息长度，不同的qmi消息，消息格式是相同的。

下图是QMIFramework的一个软件结构图。从图中可以看出，上层控制点打包对应类型的QMI消息或通过其他操作系统的框架，将要发出的数据传到AP。

侧底层的逻辑设备，最后逻辑设备通过内联的总线接口，传到BP侧的AMSS。在代码中可以找到从控制点发送到逻辑设备的函数。

这个是控制点向BP侧发送同步（sync）消息的函数，参数包括走的QMI_Service类型，Service里面消息的名称，

请求消息的初始地址，长度，返回相应的初始地址和长度。逻辑设备和BP侧内联的总线也可以分很多种：USB,SDIO，共享内存，无线协议802.11等都可以作为总线连接AP和BP。咱们现在开发的MSM平台用的是共享内存。代码中qmi_port_defs.h中的枚举qmi_connection_id_type定义了AP侧QMI和BP侧的连接通道，包括集成modem的MSM平台和独立modem的MDM。在代码中的vendor\qcom\proprietary\qmi\platform目录，linux_qmi_qmux_if_client.c，定义了和BP侧通信的逻辑设备种类。

目前我们QMI支持的逻辑设备有图中四种，电话系统，音频，蓝牙，GPS。

bp的AMSS实时系统

AMSS的source实际上是Qualcomm平台的的底层部分，去掉了为应用程序提供接口的AEE(application execution environment)部分，高通在DualProc芯片上的其他平台基本上都是采用的这样的架构。所以如果要了解这套source的话有必要对BREW作一个基本的了解，不需要了解它应用程序的运作机制，只需要了解底层的操作系统，尤其是REX(Run Time Executive)的运行机制必须了解。在6K平台只有单芯片（ARM9或者ARM11）。在7K&8K平台硬件上采用的是ARM9+ARM11（最新的采用Cotex-A8或是Cotex-A9）的架构。其中ANDROID是在ARM11上运行，而ARM9部分负责处理通信协议、射频、GPIO等，或者可以称作MODEM端，同样也运行一个OS，称为AMSS（Advanced Mobile Subscriber Software）