<8> 紫光展锐[ENGPC] EngPC动态研究

校准模式进入
    开机通过一个接口(? 哪个口D2S_DIAG),正常模式下发送AT命令控制手机进入校准模式。
1. PS:AT命令控制
    AT+MODECHAN=0,0控制进入校准模式 (? 时间限制)
    AT+MODECHAN=0,2控制退出校准模式 (? 目前未用到)
2. Engpc:通过同一个UART接口,下面开发两个线程,一个用于纯AT命令传输,一个用于DIAG命令传输。用calibration flag标志是AT还是DIAG。当接收到 ‘AT+MODECHAN=0,0’进入校准模式, 设置calibration flag 为 1 走DIAG通路;当接收到 ‘AT+MODECHAN=0,2’进入正常模式, 设置calibration flag 为 0 走AT通路。(? 哪些工具走AT,哪些工具走DIAG?)

开机进校准平台部分ENGPC实现:
1.在device/sprd 具体项目的BoardConfig.mk 中(如scx35_tsharkcoreprime/BoardConfig.mk) 定义宏:NORMAL_UART_MODE
如果NORMAL_UART_MODE =true,就是将此开机进校准功能打开
如果NORMAL_UART_MODE =flase ,就是之前我们常用的关机进校准。(?待确认)
2.在device/sprd正常开机运行的init.sc8830.rc 中对此宏进行判断,例如定义在engpc对应的服务中将AT口设置为ttyS1如下:
service engpcclientw /system/bin/engpc -t 0 -a /dev/ttyS1 -d /dev/ttyGS1
3.ENGPC的实现代码中: 
定义全局变量calibration_flag,  默认值为0。ENGPC ENGPC 一直监听读USB AT 通路,    如果收到‘AT+MODECHAN=0,0',此时开始进入校准模式将 calibration_flag 置为1,此前(包括此AT)所有来自ttyS1的数据都是AT命令,ENGPC将其全部透传给SIPC的AT 通路,从而透传给CP.
如果收到‘AT+MODECHAN=0,2',此时开始离开校准模式将 calibration_flag 置为0,此前(包括此AT)所有来自ttyS1的数据都是DIAG命令,ENGPC将解析每义条DIAG命令,如果是AP处理的,ENGPC将该命令处理完后,将回复的DIAG写给ttyS1,其余的透传给SIPC的DIAG通路,从而透传给CP.

NORMAL_UART_MODE = true,ENGPC会根据不开启线程eng_vdiag_wthread,在进入校准后,在uart_vdiag_wthread_function函数中对diag 帧进行解析,同时在eng_vdiag_rthread线程中打开的是/ttyS1,即从SIPC Diag 口中读到的数据全部透传给ttyS1。

另外:开机进校准功能打开后,由于受UART  速率限制(?),需要
1.关闭kernel log
2.关闭console
3.CP侧armlog dsplog 转存T 卡

ENGPC中AT和DIAG流程

Engpc会监听/dev/ttyGS0及/dev/vser,分别对应PC虚拟出的AT口和Diag口。Engpc从以上端口获取数据后,分别由eng_pcclient_hdlr及eng_diag处理相关的AT及Diag命令,各平台实现有些差别,但都是从AT和DIAG口获取数据,然后交由对应处理模块处理。

处理PC发过来AT的流程:

处理PC发过来DIAG的流程:

数据通路与数据传输

当U-BOOT进入校准模式后,启动kernel后进入recovery模式。在这个模式中有两个重要的服务必须启动:ENGPC和NVITEMD。这两个服务将协调CP一起完成PC校准命令的传输与校准数据同步的重要工作,其中ENGPC负责将PC通过USB/UART下发的DIAG命令截取或者通过SIPC通路转发给CP,而NVITEMD这个进程是通过SIPC通路完成NV数据的同步与保存。下面是校准通路连接框图:

通常每个产品都有自己system.prop文件以管理diag通路和nv sync通路,下面是device/sprd/scx35l_sp9630xxx/system.prop中sharkL 3 模属性配置:
 ro.modem.tl.diag=/dev/slog_lte
 ro.modem.tl.log=/dev/slog_lte
 ro.modem.tl.nv=/dev/spipe_lte1
在这里可以看到diag通路和log通路都设置成slog_lte,而nv sync通路设置为spipe_lte1,具体设置需要结合各个产品形态与CP共同协商。配置好这些属性后就可以打开对应文件节点以收发校准命令和数据了。(?研究这几个配置)

ENGPC中diag 处理 

PC工具通过DIAG命令与手机数据交互,控制手机进行RF射频参数校准、读取手机信息(如IMEI、手机软件版本)等功能.


 

typedef struct msg_head_tag 
{
    unsigned int  seq_num;      
    unsigned short  len;          
    unsigned char   type;         // Main command type
    unsigned char   subtype;      // Sub command type
}__attribute__((packed)) MSG_HEAD_T; 

typedef struct {
    unsigned short  cmd;        //
    unsigned short  length;   // Length of structure
} TOOLS_DIAG_AP_CMD_T;

ENGPC权限管理

受SELinux的约束,有的时候我们调用驱动等等情况会出现失败的情况,查看log会发现是权限问题,这时,我们就可以给相关操作配置权限,来使操作流程可以正常进行下去.

在调试的时候,我们可以采取临时关闭SElinux的方法,来避免因权限问题导致EngPC的问题,方法如下:

setenforce 0   ##设置SELinux 成为permissive模式(SELinux开启,但对违反selinux规则的行为只记录,不会阻止)

setenforce 1   ##设置SELinux 成为enforcing模式 (SELinux开启)

getenforce     ##获取SELinux状态(permissive,enforcing,disabled)

这种是临时关闭的方法,在重启之后,SELinux还是会恢复正常状态,当然,也可以永久关闭,方法自己百度.也不推荐这种方法,正确的方法是给调用模块添加相应的权限.权限配置文件的位置在如下路径(这里以SC9832e为例,项目代号sharkle):

/device/sprd/sharkle/common/sepolicy/engpc.te

我们来截取部分权限配置的信息:

allow engpc serial_device:chr_file { read write open ioctl };
allow engpc sysfs:file { read open write ioctl};
allow engpc system_data_file:dir { rw_file_perms add_name create remove_name setattr };
allow engpc system_data_file:file { open };
allow engpc system_data_file:fifo_file { open read write};
allow engpc audio_device:chr_file { ioctl open read write create };
allow engpc audio_device:dir { search };
allow engpc audio_device:fifo_file { open read write };
allow engpc engpc:netlink_kobject_uevent_socket { create setopt bind read };
allow engpc prod_file:dir { search open read write remove_name add_name};
allow engpc prod_file:file { open read write lock unlink getattr setattr create rw_file_perms };
allow engpc engpc:capability { net_admin chown fsetid sys_module net_raw };
allow engpc engpc:capability2 { syslog };

配置的基本语法就是上面这段代码,需要学习则请自行百度学习,至于怎么添加权限,添加什么权限,则可以根据log来判定.

EngPC新架构

原本的架构有一些缺点:

①功能耦合:经常修改一个bug,可能会影响到其他模块,前几天刚接手一个bug,修改的GPIO,导致LCD测不过,就是这种的体现.
②架构固化:命令完全是一一对应的关系,不支持动态扩展,任何需求与命令扩展、新增任何设备都需要修改上下层代码,给开发、联合调试增加了很大的资源消耗和困难.
③自动化和验证环节缺失:接入生产的命令没有完整的自动化和功能验证环节,导致功能模块修改出错后直接在产线验证环节报错,事后再紧急处理,就要加班.,当然,加班很正常.就算没有问题也会加班做自己的事.

为了解决上述问题,将改用新架构,在新架构当中,ENGPC从多角色身份转变为只负责Command通路的搭建和传输,具体各Command的处理都剥离处理,放在各功能模块so来处理,从而实现功能的解耦.下面是新架构的一个流程图:

由原来的执行固定代码的方式,转变为加载动态库,然后通过注册的方式,把动态库中的回调按照约定好的封装注册到EngPC的链表中,当PC端有命令时,先遍历链表有没有符合条件的命令,如果没有就走旧流程,当然,这是过渡时期,等完善好之后,旧流程最终代码应该从主线代码中删除,以减少不必要的麻烦,误导开发者.

动态库统一安装路径: /vendor/lib/npidevice/, 当然考虑到有些动态库的路径不能改变,所以,可以通过软链接的方式,把软链接放在这里.动态库执行功能的代码,则由各个模块的负责人提供,因为这个过程设计到一些协议和约定,说起来时间比较长,我现在有点忙,如果后边有机会就深入讲解一下,现在就现讲这么多吧.

猜你喜欢

转载自blog.csdn.net/qq_23922117/article/details/81202413
今日推荐