最近在开发Openharmony系统，因为Openharmony涉及的目录特别多，而且需要来回的切换，常用的cd和cd -已经不满足基本的开发环境要求了，于是借鉴了栈的思想，写了一个脚本，能够提高大家的开发效率
一、基于栈
我们知道栈的结构是先进后出，也就意味着越新的元素我们就越经常使用。这个概念恰好契合了我们在cd目录的场景上。所以我们切换目录如果是栈的形式保存了目录结构，这样就非常方便我们开发了。基于此思想，我开始了此工具的开发
二、pushd/popd
我们知道，linux有几个基本的命令叫做pushd和popd，这是以栈的思想打开文件目录。但是pushd和popd要经常配合dirs来运行，所以不是很方便，原因如下：
- 切换目录要敲很多字，
- 没有很好的提示告诉我们应该按照需要几来取出目录
- 取出元素需要+符号，打字不方便
pushd和popd以及dir的常用命令如下
pushd /tmp popd dirs pushd +1
三、自定义脚本使用指南
基于上述现状上，我没办法直接使用popd和pushd命令，所以我自己编写了一个较为易用的脚本，使用方法如下：
将脚本命名为p，放入/usr/local/bin/下，赋予执行权限，并在环境中设置如下：
alias p='source p'
3.1 将文件夹压入栈
p dir
例如：
# p /root/ [0]:~ [1]:~/tf/repo/rk3568/vendor/hihope/rk3568/hdf_config/khdf/hdf_test [2]:
3.2 将文件夹推出栈
p
例如：
root@chroot:~# p root@chroot:~/tf/repo/rk3568/vendor/hihope/rk3568/hdf_config/khdf/hdf_test#
3.3 查看目录栈的内容
p -h
例如
root@chroot:/sys# p -h [0]:/sys [1]:/tmp [2]:/root [3]:/root/tf/repo/rk3568/vendor/hihope/rk3568/hdf_config/khdf/hdf_test
3.3 在栈中选择某个目录
p 3
这里选择序号为3的目录栈进行推出
p 3
[0]:~/tf/repo/rk3568/vendor/hihope/rk3568/hdf_config/khdf/hdf_test [1]:/sys [2]:/tmp
3.4 清空栈目录
p -c
这样目录栈就没有其他文件夹了
四、脚本源码
#!/bin/bash dir=$1 BLK='\033[0;30m' # Black RED='\033[0;31m' # Red GRN='\033[0;32m' # Green BLU='\033[0;34m' # Blue CYA='\033[0;36m' # Cyan WHI='\033[0;37m' # White YEL='\033[0;33m' # Yellow PUR='\033[0;35m' # Purple NC='\033[0m' # No Color function fault_log() { echo -e "${RED}$1${NC}" } function info_log() { echo -e "${GRN}$1${NC}" } function dir_list() { array=() dir_name=$(dirs -l) dir_num=$(echo ${dir_name}| awk '{print NF}') i=0 for name in ${dir_name} do array[i]=$name let i=i+1 done output_message="" for i in ${!array[@]} do info_log "${RED}[${i}]${GRN}:${array[i]}" done } function help() { array=() dir_name=$(dirs) dir_num=$(echo ${dir_name}| awk '{print NF}') i=0 for name in ${dir_name} do array[i]=$name let i=i+1 done output_message="" #for i in ${!array[@]} for((i=0;i<3;i++)) do output_message="${output_message}${RED}[${i}]${GRN}:${array[i]} " done info_log "${output_message}" } function push_dir() { if [[ "$1" =~ "+" ]] then num=$(dirs -l | xargs | tr ' ' '\n' | wc -l) if [ ${num} == 1 ] then fault_log "pushd: 目录栈为空" return fi fi pushd $1 > /dev/null if [ $? -ne 0 ] then fault_log "pushd error" fi help } function pop_dir() { popd > /dev/null 2>&1 if [ $? == 1 ] then fault_log "popd: 目录栈为空" fi } case "${dir}" in "") pop_dir ;; "-h") dir_list ;; "-c") dirs -c ;; [0-9]) [ -d ${dir} ] && info_log "存在数字命名的文件夹" [ -d ${dir} ] && push_dir ${dir} [ ! -d ${dir} ] && push_dir "+${dir}" ;; *) [ ! -d ${dir} ] && info_log "没有这样的目录" [ -d ${dir} ] && push_dir ${dir} ;; esac
OH有两种类型的开发者，一个是应用开发者，一个是设备开发者，对于我们来说，我们既是应用开发者又是设备开发者
一、应用开发者
对于OH的应用开发者，目前逐渐推荐使用Stage模型开发程序。Stage的模型如下
根据文中意思：一个应用程序提供两种类型组件，1是UIAbility，2是ExtensionAbility。UI用作交互，Ex用作能力扩展。
这里ExAbility可以是OH默认提供的基本功能，也可以是自己封装的第三方库。
当然，OH的应用开发者默认要使用ArkTS来开发ArkUI，所以学习ArkTS应该是当前第一步骤
二、设备开发者
对于不同的设备，我们应该默认按照标准系统移植方式开发，一方面我们本身是Linux系统厂商，不会也没必要基于轻量（MCU）系统开发，和小型（嵌入式设备）系统开发。包括当前OH提供的api10，都是基于标准系统进行扩展的。这里可以大胆笃定OH默认的发展方向和市场前景在于Linux标准系统侧，与传统Linux桌面系统厂商竞争。
开发标准系统需要自行定义板级配置和为其编写HDF抽象层驱动，主要如文中介绍
标准驱动架构图如下
这里可以知道，标准系统长期应该仍基于Linux的LTS进行开发，OH做的是OSAL层抽象。相关具体的代码位置如下
所以我们的职责目前应该是在LTS的Linux版本，例如4.19和5.10上，搞定OH的OSAL层，这也就搞定了OH的底层
当然，OH的设备开发者默认需要在具体的硬件设备上支持，所以按照OH的SDK的编译构建流程来适配指定的开发板应该是第一步骤
三、其他开发者
根据OH的整体设计，可以发现不仅包括了应用层和内核层，还有框架层和系统服务层，这两层应该怎么办呢
首先，根据OH当前社区发展现状可以知道，OH目前大部分的代码仍是鸿蒙团队和鸿蒙扶持的相关团队在开发
其次，根据和鸿蒙沟通的情况，可以知道OH商务路线策略是扶持多个发行版厂商，而不是建立大一统的开源开放策略，目前鸿蒙内部团队的代码优于开发社区版本1个版本
并且，OH官网的适配样例绝大部分仍处于应用设计层次，并没有涉及系统的层次，参考《OpenHarmony样例展示视频合集》
根据上面两方面信息，可以知道，作为其他公司开发鸿蒙的框架层和系统服务层，有如下缺点
- 非鸿蒙原生团队故接触此两层技术难度较大，且我们非鸿蒙扶持的相关公司
- 代码不是最新的（开源落后鸿蒙团队1个版本）
- 这两个层的代码会经常修改（鸿蒙团队会完善框架）
Openharmony的boot_linux.img 是标准的ext2格式，他需要通过syslinux来标准启动，但是鉴于有些uboot并没有默认打开syslinux，而使用默认的fit格式启动，所以本文介绍将原来的ext2的boot.img转换成fit格式的boot，从而使得系统加载更兼容
一、什么是fit镜像
关于fit镜像的说明，可以参考如下文档FIT镜像说明
二、its设置
为了打包fit格式的boot镜像，我们需要编写its文件，本文给一个示例文件如下：
/dts-v1/; / { description = "U-Boot FIT source file for arm"; images { fdt { data = /incbin/("rk3568-evb1-ddr4-v10-linux.dtb"); type = "flat_dt"; arch = "arm64"; compression = "none"; load = <0xffffff00>; hash { algo = "sha256"; }; }; kernel { data = /incbin/("Image"); type = "kernel"; arch = "arm64"; os = "linux"; compression = "none"; entry = <0xffffff01>; load = <0xffffff01>; hash { algo = "sha256"; }; }; ramdisk { data = /incbin/("ramdisk.img"); type = "ramdisk"; arch = "arm64"; os = "linux"; compression = "none"; entry = <0x00000000>; load = <0x00000000>; hash { algo = "sha256"; }; }; resource { data = /incbin/("resource.img"); type = "multi"; arch = "arm64"; compression = "none"; hash { algo = "sha256"; }; }; }; configurations { default = "conf"; conf { rollback-index = <0x00>; fdt = "fdt"; kernel = "kernel"; multi = "resource"; ramdisk = "ramdisk"; signature { algo = "sha256,rsa2048"; padding = "pss"; key-name-hint = "dev"; sign-images = "fdt", "kernel", "multi", "ramdisk"; }; }; }; };
三、准备镜像
根据上述的its的描述，我们需要如下文件
# "rk3568-evb1-ddr4-v10-linux.dtb" # "Image" # "ramdisk.img" # "resource.img"
3.1 dtb
对于openharmony，我们需要找到的dtb的位置在如下
out/kernel/OBJ/linux-5.10/arch/arm64/boot/dts/rockchip/xxxx.dtb
此时我们复制文件即可
cp out/kernel/OBJ/linux-5.10/arch/arm64/boot/dts/rockchip/xxxx.dtb fit/
3.2 Image
对于openharmony，我们需要找到的image的位置如下
out/kernel/OBJ/linux-5.10/arch/arm64/boot/Image
此时我们复制文件即可
cp out/kernel/OBJ/linux-5.10/arch/arm64/boot/Image fit/
3.3 ramdisk
对于openharmony，我们需要找到ramdisk的位置如下
out/rk3568/packages/phone/images/ramdisk.img
此时我们复制文件即可
cp out/rk3568/packages/phone/images/ramdisk.img fit/
3.4 resource
对于openharmony，我们需要找到resource的位置如下
out/kernel/OBJ/linux-5.10/resource.img
此时我们复制文件即可
cp out/kernel/OBJ/linux-5.10/resource.img fit/
四、制作boot
根据上述操作，我们可以开始通过mkimage制作镜像，先安装mkimage命令
apt install u-boot-tools
此时系统具备mkimage二进制，开始制作命令如下
mkimage -f boot.its -E -p 0x800 boot.img
制作时的日志信息如下：
FIT description: U-Boot FIT source file for arm Created: Fri May 24 03:34:16 2024 Image 0 (fdt) Description: unavailable Created: Fri May 24 03:34:16 2024 Type: Flat Device Tree Compression: uncompressed Data Size: 143744 Bytes = 140.38 KiB = 0.14 MiB Architecture: AArch64 Load Address: 0xffffff00 Hash algo: sha256 Hash value: 9df414ede45c3a2417bbcc4b8de9510aba9e2600f5a160a6a3b721c761400e31 Image 1 (kernel) Description: unavailable Created: Fri May 24 03:34:16 2024 Type: Kernel Image Compression: uncompressed Data Size: 24385552 Bytes = 23814.02 KiB = 23.26 MiB Architecture: AArch64 OS: Linux Load Address: 0xffffff01 Entry Point: 0xffffff01 Hash algo: sha256 Hash value: 4f3ad02eb1c101976b8b3dea5bce379efb0fd00a61a646b336c725d388dd4bea Image 2 (ramdisk) Description: unavailable Created: Fri May 24 03:34:16 2024 Type: RAMDisk Image Compression: uncompressed Data Size: 2509910 Bytes = 2451.08 KiB = 2.39 MiB Architecture: AArch64 OS: Linux Load Address: 0x00000000 Entry Point: 0x00000000 Hash algo: sha256 Hash value: 027f5c7aa5ca3a2dde9d0bb744d3a508321308c1f47cb34b4053317e39fe6ecc Image 3 (resource) Description: unavailable Created: Fri May 24 03:34:16 2024 Type: Multi-File Image Compression: uncompressed Data Size: 12588544 Bytes = 12293.50 KiB = 12.01 MiB Hash algo: sha256 Hash value: bcd3ccc6ac2747de83f27d320bd3c3aed18762bb5f3045fa84ff926345e2a125 Default Configuration: 'conf' Configuration 0 (conf) Description: unavailable Kernel: kernel Init Ramdisk: ramdisk FDT: fdt
至此，我们可以获得boot.img用于fit启动
我们在调试openharmony内核的时候，通常来看编译速度比正常内核都慢，主要是btf配置的影响，这里记录此问题，在我们调试的时候，如果不需要btf，可以关掉CONFIG_DEBUG_INFO_BTF配置，这样内核编译速度快点
一、BTF是什么
BTF可能不熟悉的比较陌生，但是说起BPF就不陌生了，其实BTF是BPF的type format而已，而BPF一个工具，用于网络数据包过滤、性能监控、安全性应用等。BTF 格式的调试信息使得 BPF 程序可以轻松地获取内核数据结构的布局和类型信息，从而使 BPF 程序能够更深入地访问和操作内核数据
二、CONFIG_DEBUG_INFO_BTF
这个配置就是为内核添加btf信息，从而使得应用可以调用bpf程序来观测内核
三、pahole
pahole是一个工具，在内核编译的时候会使用pahole来打包btf。真正使得内核编译很慢的原因是pahole工具
四、禁用CONFIG_DEBUG_INFO_BTF
禁用CONFIG_DEBUG_INFO_BTF可以加快内核编译速度
开发Openharmony的设备开发第一步就是移植内核，本文基于openharmony的sdk角度介绍openharmony的内核编译方式和单独编译内核的命令
一、原始内核位置
这里内核有两个位置，一个是内核原始源码位置，这是oh标准内核，位置为/kernel/linux/linux-5.10/
在这个内核上，会添加如下几个依赖仓库的改动如下
"kernel/linux/build" # 编译相关脚本 "kernel/linux/linux-5.10" # 内核仓库 "kernel/linux/patches" # 内核相关补丁 "kernel/linux/config" # 内核的defconfig "kernel/linux/common_modules" # oh特性的内核驱动 "third_party/bounds_checking_function" # libboundscheck库，安全函数，带边界检查的标准函数 "device/soc/hisilicon/common/platform/wifi" # 海思wifi "third_party/FreeBSD/sys/dev/evdev" # evdev 头文件 "drivers/hdf_core" # hdf 核心驱动 "prebuilts/clang/ohos/linux-x86_64/llvm/bin" # llvm
这里值得注意的是，patch目录，它需要对内核合入hdf补丁，并且需要合入rk3568芯片的基础改动的patch，主要如下
└── rk3568_patch ├── kernel.patch # linux-5.10 rk3568 SOC patches └── hdf.patch # linux-5.10 rk3568 定制 HDF patches
我们通常做移植的后续工作是设配oh的硬件抽象层，主要如下
├── adapter ├── bundle.json ├── figures ├── framework ├── interfaces ├── LICENSE ├── OAT.xml ├── README.md └── README_zh.md
二、编译后内核位置
编译后的内核位置为/out/kernel/src_tmp/linux-5.10/， 编译后内核的中间文件位置为/out/kernel/OBJ/linux-5.10/
此时代码是已经合入补丁和相关oh特性功能的代码。
三、编译内核
编译内核可以分为最外层sdk模块编译，内核源码build_kernel.sh脚本编译（合并前），内核源码make-ohos.sh脚本编译（合并后），和内核分步骤编译，可以按需自行编译
3.1、sdk模块编译
对于内核而言，sdk模块编译目前默认不支持，但sdk外层编译有必要解释一下，所以编译内核的最外层sdk编译命令如下
./build.sh --product-name rk3568 --ccache
上述命令可以整体环境编译，故内核也编译了，但是缺点是编译一次时间太长。为了指定模块的单独编译，可以设置--build-target，如下是代码示例
group("make_images") group("eng_system_image") group("eng_chipset_image") group("chip_prod_image") group("sys_prod_image") group("system_image") group("userdata_image") group("vendor_image") group("ramdisk_image") group("updater_ramdisk_image") group("updater_image")
可以知道，通过如下参数指定编译
./build.sh --product-name rk3568 --ccache --build-target make_images ./build.sh --product-name rk3568 --ccache --build-target system_image ./build.sh --product-name rk3568 --ccache --build-target userdata_image
build-target还能通过指定gn路径+目标名指定模块编译，如下
./build.sh --product-name rk3568 --ccache --build-target commonlibrary/c_utils/base:util
这里commonlibrary/c_utils/base是BUILD.gn文件目录，util是BUILD.gn声明的模块名称。
虽然内核不能单独编译，但是执行全量编译只需要等待即可获得boot_linux.img文件
查看build-target支持的选项，如下命令
prebuilts/build-tools/linux-x86/bin/ninja -w dupbuild=warn -C out/rk3568/ -t targets
对于查出来的选项，可以直接用ninja编译模块，以内核举例
prebuilts/build-tools/linux-x86/bin/ninja -w dupbuild=warn -C out/rk3568/ kernel
如果使用hb命令，可以如下编译内核
hb build -T kernel
3.2、build_kernel.sh脚本编译
build_kernel.sh作为内核单模块BUILD.gn拉起的脚本，我们可以主动调用它来单独编译内核，但是前提是代码是全编过一次的，也就是out/rk3568目录存在。编译命令如下
`pwd`/../../device/board/hihope/rk3568/kernel/build_kernel.sh `pwd`/../../kernel/linux/linux-5.10 `pwd`/../../out/rk3568/packages/phone/images `pwd`/../../device/board/hihope/rk3568 vendor/hihope/rk3568 `pwd`/../../ rockchip rk3568 hihope root default disable_lto_O0 enable_ramdisk
这里解释如下
此命令需要绝对路径
build_kernel.sh需要11个形参分别如下 $1=../../kernel/linux/linux-5.10 # pushd 参数，切换目录到linux-5.10上 $2=out/rk3568/packages/phone/images # 镜像输出目录 $3=device/board/hihope/rk3568 # BUILD_SCRIPT_PATH变量 $4=vendor/hihope/rk3568 # PRODUCT_PATH变量 $5=`pwd` # ROOT_DIR变量 $6=rockchip # DEVICE_COMPANY变量 $7=rk3568 # DEVICE_NAME变量 $8=hihope # PRODUCT_COMPANY变量 $9=root # KERNEL_FORM变量 $10=default # KERNEL_PROD变量 $11=disable_lto_O0 # ENABLE_LTO_O0变量 $12=enable_ramdisk # 判断是否生成ramdisk
此命令如果是第一次运行，会自动打patch和复制oh特性驱动代码。如果不是第一次运行，则跳过不应用补丁，直接开始编译。此命令会主动拷贝文件到out/rk3568/packages/phone/images目录。
3.3、 make-ohos.sh脚本编译
根据对build_kernel.sh的解析，为了在代码目录out/kernel/src_tmp/linux-5.10直接编译，可以直接如下命令编译
KBUILD_OUTPUT=../../OBJ/linux-5.10 PRODUCT_PATH=vendor/hihope/rk3568 DEVICE_COMPANY=rockchip DEVICE_NAME=rk3568 PRODUCT_COMPANY=hihope GPUDRIVER=mali ./make-ohos.sh TB-RK3568X0 enable_ramdisk
对于参数解析如下：
KBUILD_OUTPUT：指定内核编译中间文件位置 PRODUCT_PATH：指定产品路径，khdf需要使用 GPUDRIVER: 指定显卡驱动，瑞芯微支持mali和panfrost两种驱动 TB-RK3568X0：指定开发板类型，当前oh的sdk只支持TB-RK3568X0和TB-RK3568X10两款开发板，两个开发板对应的设备树不一样而已，其他没区别 enable_ramdisk：指定生成ramdisk镜像
通过上述命令可以在源码目录生成boot_linux目录和boot_linux.img，注意，此时的boot_linux.img不会主动复制到out/rk3568/packages/phone/images目录。
3.4、内核分步骤编译
内核编译分三个步骤
编译defconfig 编译ko模块 编译image内核二进制
内核打包通过mke2fs打包ext2格式的镜像，通过make-boot.sh打包
涉及命令主要如下：
make KBUILD_OUTPUT=../../OBJ/linux-5.10 PRODUCT_PATH=vendor/hihope/rk3568 LLVM=1 LLVM_IAS=1 CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 rockchip_linux_defconfig make KBUILD_OUTPUT=../../OBJ/linux-5.10 PRODUCT_PATH=vendor/hihope/rk3568 LLVM=1 LLVM_IAS=1 CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 modules_prepare rm -rf ../../../kernel/vendor/hihope/rk3568/hdf_config/khdf/hdf_test/ make KBUILD_OUTPUT=../../OBJ/linux-5.10 PRODUCT_PATH=vendor/hihope/rk3568 LLVM=1 LLVM_IAS=1 CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 rk3568-toybrick-x0-linux.img -j96
这时候内核已经编译成Image文件，需要手动cp一下
cp ../../OBJ/linux-5.10/arch/arm64/boot/Image boot_linux/extlinux/Image
然后运行make-boot.sh脚本打包boot_linux.img
./make-boot.sh ../../../
此时boot_linux.img文件存放在/rk3568/packages/phone/images/内
3.4.1 hdf_hcs_hex.o重编译
默认的hdf_test在单编译的时候会报错如下：
ld.lld: error: drivers/built-in.a(../../../vendor/hihope/rk3568/hdf_config/khdf/hdf_test/hdf_hcs_hex.o): Invalid value (Producer: 'LLVM15.0.4' Reader: 'LLVM 12.0.1')
上述日志说明hdf_hcs_hex.o和当前单编的llvm版本不一样，所以删除.o即可，如下操作
rm -rf ../../../kernel/vendor/hihope/rk3568/hdf_config/khdf/hdf_test/
3.4.2 缺少包pahole工具
缺少工具是因为缺少包导致，错误信息如下
BTF: .tmp_vmlinux.btf: pahole (pahole) is not available
安装dwarves包即可
apt install dwarves
3.4.5 编译有不匹配的残留文件
如果编译环境出问题，如下命令清理一下
KBUILD_OUTPUT=../../OBJ/linux-5.10 make LLVM=1 LLVM_IAS=1 CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 PRODUCT_PATH=vendor/hihope/rk3568 DEVICE_COMPANY=rockchip mrproper
如果是误操作在out/kernel/src_tmp/linux-5.10编译了中间文件，则需要在本目录操作mrproper，如下
make LLVM=1 LLVM_IAS=1 CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 PRODUCT_PATH=vendor/hihope/rk3568 DEVICE_COMPANY=rockchip mrproper
