芯片解决方案--SL8541e-OpenHarmony适配方案

摘要

本文描述8541E芯片适配OpenHarmony的整体方案。 

本文描述的整体方案，不止适用于8541e，也适用于该芯片厂家的其他芯片，如7863、7885，少部分子系统会略有差异。

 

整体方案架构

整体方案架构如下图，遵循OpenHarmony系统架构，在内核及HAL层与8541E芯片原厂SDK对接。

下文基于该方案架构，进一步阐述各子系统的对接方案。

 

内核子系统

首先需要确定使用哪个内核，这个问题影响大，影响各模块的适配方案，需要优先确定。一般，内核适配有两种策略：

策略1、使用原厂内核版本，打上OpenHarmony内核补丁；

策略2、使用OpenHarmony内核，移植原厂内核SDK中的修改代码，主要包括各种驱动。

因为原厂8541e内核是4.14版本，比较老，原厂没有基于该内核的闭源GPU方案可用于OpenHarmony系统，需要我们选用开源GPU来支撑芯片商用，而开源GPU的驱动Panfrost依赖5.x内核版本。

因此，我们选择策略2：使用OpenHarmony 5.10内核，然后从原厂4.14内核中移植各个模块的驱动到OpenHarmony 5.10内核上。

对于原厂其他芯片，根据原厂SDK的内核版本不同，这里可以采用不同的策略。

 

系统启动

如何使OpenHarmony正确启动，涉及的子系统有启动子系统、编译子系统、内核子系统等。

首先，内核要能正常启动，这部分涉及编译添加芯片和产品，编译出boot、ramdisk等相关image，还涉及BootLoader、bootargs、dts等修改；另外，内核要集成编译HDF框架，确保后续其他模块能正常启动。

然后，让内核能够正常启动ramdisk，启动后，在分区配置文件fstab中，要配置OpenHarmony的各个系统分区system、vendor、data的正确mount参数。

然后，init cfg中各个配置要正确。

然后，启动samgr、appswapn、softbus、foundation等后台程序，以及启动launcher、systemui等应用程序，这过程依赖内核要开启Access token、Binder、HDF等关键配置，这些关键配置可提前识别并打开。

最后，确保能正常启动到Launcher。

启动这部分与所有L2标准产品一致，不详细展开。

 

图形子系统

图形的适配，分为3大部分：图形基础、渲染、合成，因为这3部分的底层驱动和适配路径都不一样，因此分开阐述。

图形基础部分

OpenHarmony的图形子系统，支持对接DRM和FB两种模型的图形驱动。

各大厂商的富设备，大都已支持DRM驱动模型，8541E芯片也是如此，支持DRM图形驱动模型。

因此，我们在OpenHarmony Display HDI层采用DRM模型对接8541e图形驱动，准确的讲，是Display HDI通过DRM用户态接口库LibDRM对接8541e的DRM驱动。

主要工作有：

1、移植8541e DRM及相关的显示屏驱动，从4.14内核从5.10内核。

2、Display HDI接口适配。OpenHarmony社区代码已有RK3568的DRM适配示例，参考示例，结合8541e DRM驱动，调整各适配接口和参数。

为确保各部分工作是高质量完成的，从下到上可分步调试：

步骤1、使用ModeTest调试出图。当内核移植完之后，确保ModeTest正常可以获取DRM参数，可以显示界面。

步骤2、使用hello_composer调试出图。hello_composer是基于Display HDI接口的调试程序，在ModeTest出图正常之后，完成Display HDI接口适配，然后使用该程序调试Display HDI接口，确保HDI接口适配正确。

步骤3、显示OpenHarmony桌面。当hello_composer调试出图正常后，如果Launcher应用程序也正常启动，一般就可以显示OpenHarmony桌面；如果没有显示，一般是系统或者Launcher启动的问题。

渲染部分

各种不同方案的GPU库，都会提供Open GL和EGL接口，供上层渲染框架使用。OpenHarmony的渲染框架上也是使用Open GL和EGL接口。

因为不能使用闭源库，我们需要使用开源GPU mesa3D编译提供的OpenGL库。

开源GPU驱动为Mesa3D，Mesa3D是用户态库，在内核态需要配套使用Panfrost驱动。

OpenHarmony 3.2版本，已经提供了快速集成编译开源GPU的方法，相比3.1Release版本，适配过程已有很大简化，具体方法也不在此赘述。

更需要注意的是，8541e使用的是GPU是Mail T820，GPU架构比较老，不仅开源GPU Mesa3D的适配会有问题，而且OpenHarmony XTS认证也会有问题。因为，Mail T820与Mesa3D的组合，并没有通过OpenGL CTS测试；而OpenHarmony3.2版本的XTS会测试OpenGL CTS的满足度；当出现相关XTS问题的时候，需要去分析澄清。

合成部分

默认没有适配的情况下，采用CPU合成，合成效率很低，一帧需要80~100ms，帧率才10几。好在8541e芯片提供了专门的硬件GSP和DPU来提高合成效率，同时GPU也可以承担一部分合成工作，因此需要把硬件合成用起来，提高流畅度等使用体验。

主要方案是：使用GSP+DPU+GPU组合起来进行硬件合成。GSP、DPU、GPU的适用场景不同，比如当图层数目大于4的时候，或者在旋转的时候，需要使用GSP。在8541e上，dpu也不够强大，部分场景还需要GPU来合成。

主要工作：

1、移植GSP、DPU驱动

2、适配合成HDI接口，根据情况合理使用GSP、DPU、GPU进行合成。

需要注意的是：使用GSP或者DPU合成时，可以调用GSP、DPU的用户态程序接口，而使用GPU合成时，不能直接调用接口，而是设置GPU合成标志，让流程重新走回渲染，在渲染阶段调用GPU完成合成工作。

 

多模输入子系统

OpenHarmony采用udev管理输入设备节点，确保udev的输入规则集/etc/udev/rules.d/touchscreen.rules中，有规则与内核驱动的输入设备属性能匹配上，一般默认都有，不需要适配什么。

移植4.14的8541e输入驱动，确保内核驱动能将输入事件正确记录到dev设备节点。

 

WiFi

主要移植内核驱动，系统已对接好wpa，没有多少适配工作 。

 

Bluetooth

芯片厂家在hal层有提供vendor lib，将Bluetooth HDI接口对接到vendor lib即可。

由于芯片厂家vendor lib提供的接口，与OpenHarmony Bluetooth HDI需要的接口，不完全一致，需要修改。

社区提供的rk3568示例，是直接修改了芯片厂家的vendor lib库，让能够直接对接OpenHarmony Bluetooth HDI，但这样不利于各自独立演进，当后续芯片厂家的vendor lib库需要升级时，会产生较大的维护工作量。

我们采用的是增加vendor lib的adapter层，在adapter层去做接口转换，保障OpenHarmony Bluetooth和厂家的vendor lib能各自独立演进。

 

电话子系统

8541内置了Modem芯片，支持4G能力。

OpenHarmony的电话子系统，在HAL层的RIL适配部件采用的是hril_hdf、hril、vendorlib三层架构（如下图），适配不同的芯片或者外接模组主要在vendorlib层进行对接。

OpenHarmony社区示例产品rk3568，在vendorlib层对接了外接模组的at指令，但这种适配方案不适合8541等ZR芯片。

芯片厂家的8541e Modem方案中，有自己的rild程序，已经完整的实现了ril层功能，我们不需要再从最底层AT去适配重新去造一个ril，使用厂家的ril程序质量上也更有保障。

因此，整体方案为：rild改造为ril lib闭源库，OpenHarmony RIL适配部件在vendorlib对接厂家ril lib，摒弃原来的AT实现方式。

具体方案如下图：

关键工作有：

1、内核驱动移植

2、集成原厂闭源二进制程序和闭源库

2.1 保留原厂modem control、cp disk、ref notify等原生二进制程序。

2.2 改造rild程序为ril lib闭源库

3、OH适配
3.1 OH启动时拉起原厂二进制程序，使能和配置好Modem。

3.2 实现Vendor Lib，适配对接sprd ril lib

在Vendor Lib中需要逐个适配各指令接口，包括下发和主动上报接口；仅数据功能，就有60+接口。

接口传递的数据结构差异较大，需要在适配层转换，部分缺失的信息需要sprd ril lib中补充；

部分逻辑需要修改，指令异步机制，指令时序不一样，等等。

4、HCS根据设备能力和业务需求进行配置

 

Camera

OpenHarmony的Camera驱动框架也是多层架构，对上提供HDI接口，对下兼容不同平台实现。

在Platform Adatper层，提供了MPP和V4L2两种架构的对接方案，社区上Hisi产品采用MPP架构，其他大部分产品采用Linux标准的V4L2架构。

8541e原厂的Camera驱动，并没有使用标准的V4L2，主要是由用户态的Unisoc Camera OEM子系统实现，里面包括大量的闭源部分和大量的有源码部分。

但基于Unisoc Camera OEM，可以封装提供“仿冒的”V4L2接口（原厂有类似样例），这让双方在不破坏各自架构的前提下，有了快速对接的可能性。

最终对接方案如下：

关键点有：

1、内核Kernel移植。包括DCAM驱动和Sensor驱动。

2、集成原厂闭源库。包括3a算法在类的10+个闭源库。

3、开源库移植。包括Unisoc Camera OEM接口、sensor接口等15+个开源库，涉及源码75万行以上。

4、OH适配。在Platform Adapter选用V4L2模型，对接厂家适配库V4L2 Adapter，但需要改造V4L2模型的适配源码。

4.1 修改使用原厂API接口来实现，不再使用Linux V4L2设备节点；

4.2 同时，修改适配原厂闭源库逻辑，比如取buffer的方式、设备匹配的方式，等等。

4.3 Sensor修改 Codec转码使用厂家硬件转码库，如libjpeg，来提升性能。

4.4 HCS根据设备能力和业务需求进行配置

 

Audio

原厂SDK支持ALSA框架，OpenHarmony也支持对接ALSA框架，因此基于libalsa三方库来进行对接。

 

位置子系统GNSS

与OpenHarmony部分子系统类似，GNSS驱动框架也是多层分离的架构，对上提供统一的HDI接口，对下预留了vendorlib做不用芯片的适配。

GNSS驱动框架按功能可以分为三部分：gnss（基础定位）、agnss（辅助定位）、geofence（地理围栏），每部分可以单独与vendorlib对接。

8541e采用vendorlib来适配对接芯片厂家的vendorlib，主要完成了gnss基础定位功能的适配对接，agnss辅助定位和地理围栏的适配对接方法类似。

主要工作有：

1、移植gnss驱动

2、集成原厂gnss闭源库

3、实现vendorlib，对接原厂闭源库