4412開發板移植Openharmony3.0標準版-原來移植ohos可以這樣簡單!
大家好!我是拓維信息的鴻蒙開發者，廖永恒。最近，我在4412開發板上移植openharmony3.0(標準版)。并顯示成功。在這里，我簡單分享我移植過程。
4412開發板(1G+8G)采用Cortex-A9四核的Exynos 4412 (Exynos 4 Quad)，主頻1.4～1.6 GHz，GPU采用的是Mali 400MP四核心圖形處理器，支持2D/3D圖形加速。
在文章中，我更多介紹移植解決問題方向、方法、調試手段。因為我覺得，在移植過程，你會遇到各種各樣的問題，自己要懂得分析問題，懂得解決問題。在文章中我更多充當“指路人”，同時文章教程在移植別的平臺芯片起到借鑒作用。我是一名才疏學淺的晚輩，同時妥妥一名鴻蒙小學生。在文章中有錯誤與不足，還望各位前輩們不吝指正。
一、我的移植環境
參考文章：一種快速移植OpenHarmony Linux內核的方法
1.uboot：隨意，能引導kernel內核就好。
2.kernel內核:5.8 其實內核不做什么要求，我也看到有人3.幾也可以用。之所以我用5.8，因為我看到4412最新的移植驅動好的內核是這個版本。關于內核，采用圖中三方Linux內核方式。
3.根文件系統：我是直接拿3516編譯后的system.img、userdata.img、vendor.img 。燒錄到mmc分區上。updater.img可以不燒錄。燒錄鏡像，各個平臺不同，自己需要想辦法燒錄成功。3516鏡像采用OpenHarmony-v3.0-LTS版本。
二、其他移植
1.移植好上圖中oh內核態基礎代碼
2.Oh內核態特性(如hdf)可以不移植，這個不會影響系統的啟動，UI界面的顯示。
3.移植顯示屏觸摸驅動。
4.重要移植點，就是移植顯示驅(drm驅動)要移植好，在dev/dri/ 存在cardx 。我的是card0 ，你可能會問，fb驅動呢?行不行?這個我沒有驗證。目前我見到幾款開發板，它們都是drm驅動。
三、關鍵配置
1.內核配置里面必須要開啟IPC，不然系統啟動后有幾個進程處在高占用率狀態，導致系統卡頓。
Device Drivers —>
Android —>
[] Android Drivers (開啟)
[] Android Binder IPC Driver (開啟)
2.內核配置開啟SELinux Support 不然在啟動系統中報錯，但可以不開啟，不會影響系統啟動或顯知問題。
3.重新編譯內核。
四、啟動系統
1.正確引導內核啟動，根文件系統啟動。
我的bootargs是這個，
“mem=900M mmz=anonymous,0,0xA8000000,384M clk_ignore_unused androidboot.selinux=permissive skip_initramfs rootdelay=5 init=/init root=/dev/mmcblk1p2 rootfstype=ext4 rw blkdevparts=mmcblk1:1982M(updater),3075M(system),2048M(userdata),-(vendor)”
供參考。
2.啟動系統后修改三個文件
a.system/etc/init.cfg
我的修改成這樣，這里是掛載vendor與data分區，看自身情況修改。
b.system/etc/weston.ini
這里是指定顯示設備來顯示。
c./system/etc/udev/rules.d/ touchscreen.rules
這里是指定觸摸設備。其中TSC2007 Touchscreen是我的觸摸設備名稱。
獲取方式：cat /proc/bus/input/devices
五、測試過程
如果顯示、觸摸驅動都弄好，燒錄鏡像正常。重啟設備后會可以直接顯示并觸摸。就這么簡單?就是這么簡單。
如果顯示不正常,解決思路是這樣:
(1)DRM 是否存在dev/dri/cardx x=1、2、3
(2)libdrm 是否通過modetest測試。 ohos 的third_party源碼有libdrm庫想辦法編譯出來。
我的測試方法：自己寫測試文件，然后顯示出各種顏色。
測試結果：
(3)wmtest 測試
在這個目錄下的BUILD.gn 31行中改為ture。編譯生成wmtest可執行文件。
測試命令：
測試結果：
六、查原因與解決問題
如果在上面的測試都通過了，還是不顯示系統界面，那就按下面的方法找原因。
參考文章：啟動恢復子系統概述
1.首先查看重要進程是否開啟
shell命令行輸入：ps -A
比如 installs、accountmgr、ueventd 、foundation、weston、appspawn 、com.ohos.launch、com.ohos.system
上圖詮釋系統啟動過程，先初始化init，根據/etc/ init.cfg 拉起
ueventd線程，然后再根據/etc/init/.cfg文件如圖拉起各個線程。比如：accountmgr、appspawn、系統界面等等。
在這里演示找到不能啟動開機動畫原因。開機動畫在graphic.cfg 拉起
正常情況下 在shell 輸入bootanimation 會顯示開機動畫的。
假設開機界面出現異常
在shell下輸入
bootanimation & hilog | grep BootAnimation
報錯是因為找不到這個開機文件。
為什么要 grep BootAnimation? 因為關于開機動畫源碼中指定log標簽BootAnimation 可以過濾無關日志。
再舉例
所有com開頭的進程如com.ohos.systemui進程沒有起來。這個怎么樣查原因，有點難入手，我采用對比法，用好的3516開發板來做對比。我想到這些進程跟系統界面有關，我想想讓它重啟界面，讓它報錯出來。我讀到文中的一句話：“由于應用都需要加載JS的運行環境，涉及大量準備工作，因此appspawn作為應用的孵化器，在接收到foundation里的應用啟動請求時，可以直接孵化出應用進程，減少應用啟動時間。”我直接kill foundation進程試試?因為kill foundation進程重啟UI界面的，然后shell輸入：kill 824 & hilog > /data/foundation.log 其中824 是foundation的pid ，把hilog日志保存在/data/foundation.log中。在4412開發板與3516開發板做同樣的動作。
在foundation.log 搜關鍵字 “E” 發現一處，4412開發板讀system/lib/****.so文件失敗。3516開發板不報錯。最后我把3516開發板的lib庫全部拷貝到4412開發板上，重啟4412開發板，com開頭的進程都起來，界面顯示正常。
總之一句話：不怕bug多，就怕找不到error，不怕它異常，就怕沒有解決思路、方向。
七、其他
1.shell aa命令的使用
aa start -a com.ohos.photos.MainAbility -b com.ohos.photos
aa start -a com.ohos.settings.MainAbility -b com.ohos.settings
aa start -a com.ohos.launcher.MainAbility -b com.ohos.launcher
八、總結
移植過程還有諸多不足：
(1)顯示屏是4.3寸的電阻屏，界面顯示不全，觸摸沒做校驗，觸摸不準，亂跳。后期換大屏的電容屏。
(2)沒有加到openharmony編譯框架里面。
(3)hdc、hdf框架沒有使用起來。
展望：會把上面的不足慢慢完善起來。
異常問題千千萬，解決方向與方法很關鍵。今與各位同仁共享移植心得，在開鴻道路上越走越順、越快。
