​OH3.1从Hi3516到RK3568编译失败问题分析报告

鸿蒙使小强 鸿蒙使小强 墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年,写一次发全网 我也要 + 加入社区

1 关键字

编译失败;Hi3516;RK3568; 切换

2 问题描述

设备型号:Hi3516,RK3568

系统版本:OpenHarmony 3.1 Release

代码版本:OpenHarmony-v3.1-Release

问题现象:先编译Hi3516 后再编译RK3568 或者先编译RK3568 再编译Hi3516 ,会出现编译失败问题。

3 问题原因

3.1 正常机制

同一套代码可以编译Hi3516 也可以编译RK3568, 应互不影响。

3.2 异常机制

先编译Hi3516 后再编译RK3568 或者先编译RK3568 再编译Hi3516 ,会出现编译失败问题。

4 解决方案

手动解决这个问题的办法:

编译rk3568时,把 //device/board/hihope/rk3568/cfg/ramdisk_resource_config.ini 文件拷贝并替换掉 //build/ohos/images/mkimage/ramdisk_resource_config.ini【做好备份】,再去编译rk3568即可。

然后编译Hi3516时,又会报错,这时候再将原先备份的ramdisk_resource_config.ini替换回去,再去编译Hi3516即可。

附1: Hi3516的配置文件ramdisk_resource_config.ini

# current path: "out/ohos-arm-release/"

# Modification and deletion of section name is not allowed

# fstab.required path config, The fstab is device related

[fstab_required_path]

source_path = ./fstab.required

target_path = ./packages/phone/ramdisk/etc/fstab.required

# dtc_419 path config

[dtc_419_path]

source_path = ../../out/KERNEL_OBJ/kernel/src_tmp/linux-4.19/scripts/dtc/dtc

target_path = ../../third_party/e2fsprogs/prebuilt/host/bin/dtc

# dtc_510 path config

[dtc_510_path]

source_path = ../../out/KERNEL_OBJ/kernel/OBJ/linux-5.10/scripts/dtc/dtc

target_path = ../../third_party/e2fsprogs/prebuilt/host/bin/dtc

# mkimage path config

[mkimage_path]

source_path = ../../device/board/hisilicon/hispark_taurus/uboot/prebuilts/mkimage

target_path = ../../third_party/e2fsprogs/prebuilt/host/bin/mkimage

附2: rk3568的配置文件ramdisk_resource_config.ini

# current path: "out/ohos-arm-release/"

# Modification and deletion of section name is not allowed

# fstab.required path config, The fstab is device related

[fstab_required_path]

source_path = ./fstab.required

target_path = ./packages/phone/ramdisk/etc/fstab.required

# dtc_419 path config

[dtc_419_path]

source_path = ../../out/KERNEL_OBJ/kernel/src_tmp/linux-4.19/scripts/dtc/dtc

target_path = ../../third_party/e2fsprogs/prebuilt/host/bin/dtc

# dtc_510 path config

[dtc_510_path]

source_path = ../../out/kernel/src_tmp/linux-5.10/scripts/dtc/dtc

target_path = ../../third_party/e2fsprogs/prebuilt/host/bin/dtc

# mkimage path config

[mkimage_path]

source_path = ../../device/board/hisilicon/hispark_taurus/uboot/prebuilts/mkimage

target_path = ../../third_party/e2fsprogs/prebuilt/host/bin/mkimage

[board]

boot_type = two_stages

source_path = ../../out/kernel/src_tmp/linux-5.10/make-boot.sh

target_path = ./packages/phone/make-boot.sh

5 定位过程

5.1 问题现象

在源码库编译Hi3516之后再编译 rk3568 或者编译rk3568之后再编译Hi3516, 均会出现如下类似错误:

图片1:

img

或者如下错误:

图片2:

img

​ 总结起来就是:FAILED: ramdisk.img。

5.1 问题原因

编译系统对ramdisk_resource_config.ini的使用,有点奇怪,系统中有四个:

【1】//build/ohos/images/mkimage/ramdisk_resource_config.ini

【2】//device/board/hisilicon/hispark_taurus/linux/images/ramdisk_resource_config.ini

【3】//device/board/hihope/rk3568/cfg/ramdisk_resource_config.ini

【4】//out/hi3516dv300/packages/imagesconf/ramdisk_resource_config.ini

默认情况下【1】就是对应的Hi3516板子的配置,直接编译Hi3516不会出问题;直接编译rk3568 时,BUILD.gn 会把【3】copy 到【1】 也不会出以上问题。

1) 假如先编译了Hi3516, 再去编译rk3568, 这时【1】对应的配置依然是Hi3516的,在编译的过程中涉及到ramdisk.img 的地方总是去找Hi3516的目录,编译会失败。

2) 假如先编译了rk3568, 再去编译 Hi3516, 这时【1】对应的配置依然是 rk3568的,在编译的过程中涉及到ramdisk.img 的地方总是去找rk3568 的目录,编译会失败。

**两种配置文件的差异如下(左边Hi3516,右边rk3568)**:

图片3:

img

6 知识分享

​ OH3.1的源码库在编译环境配置完备的情况下,可同时编译Hi3516 、rk3568 等不同的版本,编译输出分别对应 out/Hi3516DV300 和 out/rk3568 两个目录,这两个目录完全是互相独立且没有任何依赖。但是依然可能会出现编译Hi3518 后再编译rk3568 或者编译完rk3568 再编译hi3516 ,编译失败的问题。 问题原因只在于ramdisk_resource_config.ini 这个配置文件的配置会不同。

...全文

相关推荐

华为鸿蒙HarmonyOS开发者资料汇总rar

(LiteOS-M)、小型系统(LiteOS-A)及标准系统(基于Linux内核)三类设备适配方案,明确芯片平台支持列表(如Hi3516、Hi3518、Hi3861、RK3399、昇腾系列等),并提供Bootloader

daily0531

鸿蒙OH实战开发:【PREPARE工作准备】下载、编译OpenHarmony代码

终于等到下载代码的时刻了,业内不叫下载代码叫“拉代码”,上传代码叫“上库”,编译叫构建。

彭家大少

OpenHarmony NAPI实战:从JS应用层控制GPIO驱动LED灯

在嵌入式开发与物联网(IoT)领域,GPIO(通用输入输出)是连接微控制器与外部世界的基础接口,其核心原理是通过读写特定引脚的电平状态来控制硬件或读取传感器数据。为实现上层应用对硬件的灵活操控,现代操作系统通常提供硬件抽象层和原生API桥接技术。OpenHarmony作为面向全场景的分布式操作系统,其NAPI(Native API)框架正是实现这一目标的关键,它允许JavaScript/TypeScript应用高效、安全地调用底层C/C++代码,从而访问GPIO等硬件资源。这项技术的工程价值在于打通了高级语

周含露

Flutter OpenHarmony二维码扫描[源码]

所有示例代码均通过DevEco Studio 4.1正式版验证,兼容x86_64与arm64-v8a双架构,已在Hi3516DV300、RK3566、PinePhone Pro等典型OpenHarmony

辣条鉴定师

linux系统es734e驱动程序

、Hi3516DV300、i.MX8MQ)实机验证;es7243l_4_19针对Linux 4.19 LTS内核定制,集成对legacy snd_soc_register_codec注册路径的支持,保留对旧版

Einsteinnn
评论
收藏 已收藏
分享
返回顶部