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是我的触摸设备名称。
获取方式：


五、测试过程如果显示、触摸驱动都弄好，烧录镜像正常。重启设备后会可以直接显示并触摸。就这么简单？就是这么简单。
如果显示不正常,解决思路是这样:
（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下输入


报错是因为找不到这个开机文件。
为什么要 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命令的使用


八、总结一、移植过程还有诸多不足：（1）显示屏是4.3寸的电阻屏，界面显示不全，触摸没做校验，触摸不准，乱跳。后期换大屏的电容屏。
（2）没有加到openharmony编译框架里面。
（3）hdc、hdf框架没有使用起来。
二、展望：会把上面的不足慢慢完善起来异常问题千千万，解决方向与方法很关键。今与各位同仁共享移植心得，在开鸿道路上越走越顺、越快。