摘要

本文描述8541E芯片適配OpenHarmony的整體方案。?

本文描述的整體方案，不止適用于8541e，也適用于該芯片廠家的其他芯片，如7863、7885，少部分子系統(tǒng)會(huì)略有差異。

整體方案架構(gòu)

整體方案架構(gòu)如下圖，遵循OpenHarmony系統(tǒng)架構(gòu)，在內(nèi)核及HAL層與8541E芯片原廠SDK對(duì)接。

下文基于該方案架構(gòu)，進(jìn)一步闡述各子系統(tǒng)的對(duì)接方案。

內(nèi)核子系統(tǒng)

首先需要確定使用哪個(gè)內(nèi)核，這個(gè)問(wèn)題影響大，影響各模塊的適配方案，需要優(yōu)先確定。一般，內(nèi)核適配有兩種策略：

策略1、使用原廠內(nèi)核版本，打上OpenHarmony內(nèi)核補(bǔ)丁；

策略2、使用OpenHarmony內(nèi)核，移植原廠內(nèi)核SDK中的修改代碼，主要包括各種驅(qū)動(dòng)。

因?yàn)樵瓘S8541e內(nèi)核是4.14版本，比較老，原廠沒(méi)有基于該內(nèi)核的閉源GPU方案可用于OpenHarmony系統(tǒng)，需要我們選用開(kāi)源GPU來(lái)支撐芯片商用，而開(kāi)源GPU的驅(qū)動(dòng)Panfrost依賴(lài)5.x內(nèi)核版本。

因此，我們選擇策略2：使用OpenHarmony 5.10內(nèi)核，然后從原廠4.14內(nèi)核中移植各個(gè)模塊的驅(qū)動(dòng)到OpenHarmony 5.10內(nèi)核上。

對(duì)于原廠其他芯片，根據(jù)原廠SDK的內(nèi)核版本不同，這里可以采用不同的策略。

系統(tǒng)啟動(dòng)

如何使OpenHarmony正確啟動(dòng)，涉及的子系統(tǒng)有啟動(dòng)子系統(tǒng)、編譯子系統(tǒng)、內(nèi)核子系統(tǒng)等。

首先，內(nèi)核要能正常啟動(dòng)，這部分涉及編譯添加芯片和產(chǎn)品，編譯出boot、ramdisk等相關(guān)image，還涉及BootLoader、bootargs、dts等修改；另外，內(nèi)核要集成編譯HDF框架，確保后續(xù)其他模塊能正常啟動(dòng)。

然后，讓內(nèi)核能夠正常啟動(dòng)ramdisk，啟動(dòng)后，在分區(qū)配置文件fstab中，要配置OpenHarmony的各個(gè)系統(tǒng)分區(qū)system、vendor、data的正確mount參數(shù)。

然后，init cfg中各個(gè)配置要正確。

然后，啟動(dòng)samgr、appswapn、softbus、foundation等后臺(tái)程序，以及啟動(dòng)launcher、systemui等應(yīng)用程序，這過(guò)程依賴(lài)內(nèi)核要開(kāi)啟Access token、Binder、HDF等關(guān)鍵配置，這些關(guān)鍵配置可提前識(shí)別并打開(kāi)。

最后，確保能正常啟動(dòng)到Launcher。

啟動(dòng)這部分與所有L2標(biāo)準(zhǔn)產(chǎn)品一致，不詳細(xì)展開(kāi)。

圖形子系統(tǒng)

圖形的適配，分為3大部分：圖形基礎(chǔ)、渲染、合成，因?yàn)檫@3部分的底層驅(qū)動(dòng)和適配路徑都不一樣，因此分開(kāi)闡述。

圖形基礎(chǔ)部分

OpenHarmony的圖形子系統(tǒng)，支持對(duì)接DRM和FB兩種模型的圖形驅(qū)動(dòng)。

各大廠商的富設(shè)備，大都已支持DRM驅(qū)動(dòng)模型，8541E芯片也是如此，支持DRM圖形驅(qū)動(dòng)模型。

因此，我們?cè)贠penHarmony Display HDI層采用DRM模型對(duì)接8541e圖形驅(qū)動(dòng)，準(zhǔn)確的講，是Display HDI通過(guò)DRM用戶(hù)態(tài)接口庫(kù)LibDRM對(duì)接8541e的DRM驅(qū)動(dòng)。

主要工作有：

1、移植8541e DRM及相關(guān)的顯示屏驅(qū)動(dòng)，從4.14內(nèi)核從5.10內(nèi)核。

2、Display HDI接口適配。OpenHarmony社區(qū)代碼已有RK3568的DRM適配示例，參考示例，結(jié)合8541e DRM驅(qū)動(dòng)，調(diào)整各適配接口和參數(shù)。

為確保各部分工作是高質(zhì)量完成的，從下到上可分步調(diào)試：

步驟1、使用ModeTest調(diào)試出圖。當(dāng)內(nèi)核移植完之后，確保ModeTest正?？梢垣@取DRM參數(shù)，可以顯示界面。

步驟2、使用hello_composer調(diào)試出圖。hello_composer是基于Display HDI接口的調(diào)試程序，在ModeTest出圖正常之后，完成Display HDI接口適配，然后使用該程序調(diào)試Display HDI接口，確保HDI接口適配正確。

步驟3、顯示OpenHarmony桌面。當(dāng)hello_composer調(diào)試出圖正常后，如果Launcher應(yīng)用程序也正常啟動(dòng)，一般就可以顯示OpenHarmony桌面；如果沒(méi)有顯示，一般是系統(tǒng)或者Launcher啟動(dòng)的問(wèn)題。

渲染部分

各種不同方案的GPU庫(kù)，都會(huì)提供Open GL和EGL接口，供上層渲染框架使用。OpenHarmony的渲染框架上也是使用Open GL和EGL接口。

因?yàn)椴荒苁褂瞄]源庫(kù)，我們需要使用開(kāi)源GPU mesa3D編譯提供的OpenGL庫(kù)。

開(kāi)源GPU驅(qū)動(dòng)為Mesa3D，Mesa3D是用戶(hù)態(tài)庫(kù)，在內(nèi)核態(tài)需要配套使用Panfrost驅(qū)動(dòng)。

OpenHarmony 3.2版本，已經(jīng)提供了快速集成編譯開(kāi)源GPU的方法，相比3.1Release版本，適配過(guò)程已有很大簡(jiǎn)化，具體方法也不在此贅述。

更需要注意的是，8541e使用的是GPU是Mail T820，GPU架構(gòu)比較老，不僅開(kāi)源GPU Mesa3D的適配會(huì)有問(wèn)題，而且OpenHarmony XTS認(rèn)證也會(huì)有問(wèn)題。因?yàn)?#xff0c;Mail T820與Mesa3D的組合，并沒(méi)有通過(guò)OpenGL CTS測(cè)試；而OpenHarmony3.2版本的XTS會(huì)測(cè)試OpenGL CTS的滿(mǎn)足度；當(dāng)出現(xiàn)相關(guān)XTS問(wèn)題的時(shí)候，需要去分析澄清。

合成部分

默認(rèn)沒(méi)有適配的情況下，采用CPU合成，合成效率很低，一幀需要80~100ms，幀率才10幾。好在8541e芯片提供了專(zhuān)門(mén)的硬件GSP和DPU來(lái)提高合成效率，同時(shí)GPU也可以承擔(dān)一部分合成工作，因此需要把硬件合成用起來(lái)，提高流暢度等使用體驗(yàn)。

主要方案是：使用GSP+DPU+GPU組合起來(lái)進(jìn)行硬件合成。GSP、DPU、GPU的適用場(chǎng)景不同，比如當(dāng)圖層數(shù)目大于4的時(shí)候，或者在旋轉(zhuǎn)的時(shí)候，需要使用GSP。在8541e上，dpu也不夠強(qiáng)大，部分場(chǎng)景還需要GPU來(lái)合成。

主要工作：

1、移植GSP、DPU驅(qū)動(dòng)

2、適配合成HDI接口，根據(jù)情況合理使用GSP、DPU、GPU進(jìn)行合成。

需要注意的是：使用GSP或者DPU合成時(shí)，可以調(diào)用GSP、DPU的用戶(hù)態(tài)程序接口，而使用GPU合成時(shí)，不能直接調(diào)用接口，而是設(shè)置GPU合成標(biāo)志，讓流程重新走回渲染，在渲染階段調(diào)用GPU完成合成工作。

多模輸入子系統(tǒng)

OpenHarmony采用udev管理輸入設(shè)備節(jié)點(diǎn)，確保udev的輸入規(guī)則集/etc/udev/rules.d/touchscreen.rules中，有規(guī)則與內(nèi)核驅(qū)動(dòng)的輸入設(shè)備屬性能匹配上，一般默認(rèn)都有，不需要適配什么。

移植4.14的8541e輸入驅(qū)動(dòng)，確保內(nèi)核驅(qū)動(dòng)能將輸入事件正確記錄到dev設(shè)備節(jié)點(diǎn)。

WiFi

主要移植內(nèi)核驅(qū)動(dòng)，系統(tǒng)已對(duì)接好wpa，沒(méi)有多少適配工作 。

Bluetooth

芯片廠家在hal層有提供vendor lib，將Bluetooth HDI接口對(duì)接到vendor lib即可。

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

社區(qū)提供的rk3568示例，是直接修改了芯片廠家的vendor lib庫(kù)，讓能夠直接對(duì)接OpenHarmony Bluetooth HDI，但這樣不利于各自獨(dú)立演進(jìn)，當(dāng)后續(xù)芯片廠家的vendor lib庫(kù)需要升級(jí)時(shí)，會(huì)產(chǎn)生較大的維護(hù)工作量。

我們采用的是增加vendor lib的adapter層，在adapter層去做接口轉(zhuǎn)換，保障OpenHarmony Bluetooth和廠家的vendor lib能各自獨(dú)立演進(jìn)。

電話子系統(tǒng)

8541內(nèi)置了Modem芯片，支持4G能力。

OpenHarmony的電話子系統(tǒng)，在HAL層的RIL適配部件采用的是hril_hdf、hril、vendorlib三層架構(gòu)（如下圖），適配不同的芯片或者外接模組主要在vendorlib層進(jìn)行對(duì)接。

OpenHarmony社區(qū)示例產(chǎn)品rk3568，在vendorlib層對(duì)接了外接模組的at指令，但這種適配方案不適合8541等ZR芯片。

芯片廠家的8541e Modem方案中，有自己的rild程序，已經(jīng)完整的實(shí)現(xiàn)了ril層功能，我們不需要再?gòu)淖畹讓覣T去適配重新去造一個(gè)ril，使用廠家的ril程序質(zhì)量上也更有保障。

因此，整體方案為：rild改造為ril lib閉源庫(kù)，OpenHarmony RIL適配部件在vendorlib對(duì)接廠家ril lib，摒棄原來(lái)的AT實(shí)現(xiàn)方式。

具體方案如下圖：

關(guān)鍵工作有：

1、內(nèi)核驅(qū)動(dòng)移植

2、集成原廠閉源二進(jìn)制程序和閉源庫(kù)

2.1 保留原廠modem control、cp disk、ref notify等原生二進(jìn)制程序。

2.2 改造rild程序?yàn)閞il lib閉源庫(kù)

3、OH適配
3.1?OH啟動(dòng)時(shí)拉起原廠二進(jìn)制程序，使能和配置好Modem。

3.2 實(shí)現(xiàn)Vendor Lib，適配對(duì)接sprd ril lib

在Vendor Lib中需要逐個(gè)適配各指令接口，包括下發(fā)和主動(dòng)上報(bào)接口；僅數(shù)據(jù)功能，就有60+接口。

接口傳遞的數(shù)據(jù)結(jié)構(gòu)差異較大，需要在適配層轉(zhuǎn)換，部分缺失的信息需要sprd ril lib中補(bǔ)充；

部分邏輯需要修改，指令異步機(jī)制，指令時(shí)序不一樣，等等。

4、HCS根據(jù)設(shè)備能力和業(yè)務(wù)需求進(jìn)行配置

Camera

OpenHarmony的Camera驅(qū)動(dòng)框架也是多層架構(gòu)，對(duì)上提供HDI接口，對(duì)下兼容不同平臺(tái)實(shí)現(xiàn)。

在Platform Adatper層，提供了MPP和V4L2兩種架構(gòu)的對(duì)接方案，社區(qū)上Hisi產(chǎn)品采用MPP架構(gòu)，其他大部分產(chǎn)品采用Linux標(biāo)準(zhǔn)的V4L2架構(gòu)。

8541e原廠的Camera驅(qū)動(dòng)，并沒(méi)有使用標(biāo)準(zhǔn)的V4L2，主要是由用戶(hù)態(tài)的Unisoc Camera OEM子系統(tǒng)實(shí)現(xiàn)，里面包括大量的閉源部分和大量的有源碼部分。

但基于Unisoc Camera OEM，可以封裝提供“仿冒的”V4L2接口（原廠有類(lèi)似樣例），這讓雙方在不破壞各自架構(gòu)的前提下，有了快速對(duì)接的可能性。

最終對(duì)接方案如下：

關(guān)鍵點(diǎn)有：

1、內(nèi)核Kernel移植。包括DCAM驅(qū)動(dòng)和Sensor驅(qū)動(dòng)。

2、集成原廠閉源庫(kù)。包括3a算法在類(lèi)的10+個(gè)閉源庫(kù)。

3、開(kāi)源庫(kù)移植。包括Unisoc Camera OEM接口、sensor接口等15+個(gè)開(kāi)源庫(kù)，涉及源碼75萬(wàn)行以上。

4、OH適配。在Platform Adapter選用V4L2模型，對(duì)接廠家適配庫(kù)V4L2 Adapter，但需要改造V4L2模型的適配源碼。

4.1 修改使用原廠API接口來(lái)實(shí)現(xiàn)，不再使用Linux V4L2設(shè)備節(jié)點(diǎn)；

4.2 同時(shí)，修改適配原廠閉源庫(kù)邏輯，比如取buffer的方式、設(shè)備匹配的方式，等等。

4.3 Sensor修改 Codec轉(zhuǎn)碼使用廠家硬件轉(zhuǎn)碼庫(kù)，如libjpeg，來(lái)提升性能。

4.4 HCS根據(jù)設(shè)備能力和業(yè)務(wù)需求進(jìn)行配置

Audio

原廠SDK支持ALSA框架，OpenHarmony也支持對(duì)接ALSA框架，因此基于libalsa三方庫(kù)來(lái)進(jìn)行對(duì)接。

位置子系統(tǒng)GNSS

與OpenHarmony部分子系統(tǒng)類(lèi)似，GNSS驅(qū)動(dòng)框架也是多層分離的架構(gòu)，對(duì)上提供統(tǒng)一的HDI接口，對(duì)下預(yù)留了vendorlib做不用芯片的適配。

GNSS驅(qū)動(dòng)框架按功能可以分為三部分：gnss（基礎(chǔ)定位）、agnss（輔助定位）、geofence（地理圍欄），每部分可以單獨(dú)與vendorlib對(duì)接。

8541e采用vendorlib來(lái)適配對(duì)接芯片廠家的vendorlib，主要完成了gnss基礎(chǔ)定位功能的適配對(duì)接，agnss輔助定位和地理圍欄的適配對(duì)接方法類(lèi)似。

主要工作有：

1、移植gnss驅(qū)動(dòng)

2、集成原廠gnss閉源庫(kù)

3、實(shí)現(xiàn)vendorlib，對(duì)接原廠閉源庫(kù)