RK3568------Openharmony 3.2-Release 启动引导组件init

前言

上一篇文章《RK3568------Openharmony 3.2-Release HDC调试工具》总结了一下HDC调试工具的使用及在使用过程中遇到的问题。随着调试阶段的推进，对于系统的启动阶段配置有了需求，例如需要在系统启动阶段配置网口IP，本篇文章介绍Openharmony-----启动恢复子系统。

一、启动恢复子系统概述

OHOS官网 启动恢复子系统概述已经详细介绍了，节省篇幅我不在此赘述。

二、init启动引导组件

这里我将官网中我认为比较重要的概念做详细描述

• Init配置文件基于JSON格式，用来配置系统启动时必要的命令和服务。Init在系统启动时解析配置文件，并根据配置文件执行对应的命令，启动相应的服务。
• 分组配置文件（device.xxxx.group.cfg）（标准系统支持），文件由jobs、services和groups组成。用来限制能够执行的jobs和service。根据cmdline中的bootgroup属性决定当前的分区。当前支持下列分组：
  ​device.boot.group 系统默认配置，触发执行配置文件中的所有的job和服务。
  device.charge.group charge模式，限制只启动改文件中允许的job和服务。
• 启动配置文件（init.cfg），文件由jobs、services和import组成。
  services（linux内核支持）， 用于配置系统支持的native服务，服务具体配置参考 服务管理。
  jobs， 配置等待执行命令集合，jobs具体参考 jobs管理。
  import（linux内核支持），import是导入cfg文件，目的是减少cfg大小，分离不同的功能。
• jobs是init组件下cfg文件中的一组命令构成的集合, 最多添加4096个job。 jobs可以在 cfg 文件中配置，通常在init启动过程中执行，服务于service的正常启动或特定基础功能的初始化。
• job可以在init.cfg中配置，也可以在模块的自定义cfg中配置。init解析程序会把相同名字job的命令合并到一个job中。同一名字的job只能保证init.cfg中的命令优先执行，其他cfg间的命令执行顺序不保证。

基本jobs

init启动的固定阶段，如“pre-init“，“init”，“post-init”，这类job在init启动的固定阶段执行。

pre-init：init前置阶段，其他服务所依赖的，类似于ueventd、watchdog、hilogd等的关键服务会在这一阶段启动，data分区的挂载也在这一阶段进行。

init：init进程的主要阶段，这一阶段除了大量命令的执行，同时也是init分组并行启动boot组（第一组）服务的启动阶段，一些关乎系统功能的重要服务会在这一阶段被拉起。

post-init：这一阶段主要是通过trigger命令触发其他阶段执行，可以把所有被触发的阶段看作一个个的小阶段，也可以把它们统一看作post-init阶段，这一阶段会执行大量命令，并且它还是init分组并行启动normal组（第二组）服务的启动阶段，cfg中配置的大部分服务都是在这一阶段被拉起的。

自定义jobs(仅标准系统以上提供)
这类job按照一定的规则进行触发，用户根据需要定义的命令集合，通过trigger命令触发执行。

条件jobs(仅标准系统以上提供)
用户通过在jobs中添加condition配置，在条件满足时触发命令执行。
条件是系统参数值的组合，支持&& 、||等操作, 并且支持*匹配任意值。

这里我要重点强调，init启动过程中3个阶段，这里非常重要。因为后面我们会根据自己的需求添加命令或服务，必须在合适的阶段添加才能不影响系统的正常启动，也才能不影响我们自定义的命令或服务！！！！！！！！！！！！！！！！！！！！。

• "name"和"cmds"是一个job中的必选项，并且"cmds"中应当包含系统支持的命令，否则就是浪费资源的无意义配置。
  这里我要重点强调，关于官网上描述的应当包含系统支持的命令，这里的系统支持的命令是指官网中的JOB命令集的命令！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！。

• "condition"是一个job中的可选属性，这一属性的配置代表着该job是一个条件触发的job，不通过代码或trigger命令在固定阶段触发执行，而是在condition中的条件满足后才被触发执行。

• job的命名需满足一定的规则，对于条件是系统参数的job，以"param:"为前缀。

• 一个新的job命名需要在其他可执行的job命令组中通过trigger命令触发才可执行，提供的默认trigger命令执行阶段是post-init阶段。
  这里我要重点强调，关于我们自定义的job_name，必须通过trigger触发，否则是不生效的！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！。

• 一个已经存在的job名称仍可以在不同文件中继续使用，相同名称的job将会被视为同一job，通过trigger触发时其中的命令合并执行。
  这里我要重点强调,如果你的自定义命令或者服务是一个已经存在的job_name，一定要注意顺序的问题，因为最后init会把同名的job_name放在一起，但是不保证顺序！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！。

• 条件执行job的condition配置通常是系统参数，可以指定某个系统参数被设定为某个值时该job触发执行，也可以使用"*"符号，代表只要该系统参数被设置，不论为何值，条件都满足，该job可以被触发执行。

• 在小型系统中，jobs中的post-init 部分不支持trigger命令。

三 、开发实例

下面根据我们的需求，开机自动配置网口IP，来介绍如何编写配置文件
因为我们是针对本板的配置，因此在工程中需要单独配置，推荐路径//vendor/hihope/rk3568 创建一个目录命名为board_ok3568。

• 编写构建文件BUILD.gn

ohos_prebuilt_etc("board_config") {
  source = "board_config.cfg" //这里是提供给init的启动配置文件
  part_name = "product_rk3568" //因为我们是板级配置，是放在ohos.build中的
  install_images = [ chipset_base_dir ] //安装的路径
  install_enable = true
}

• 编写配置文件board_config.cfg

{
    "jobs" : [{
            "name" : "board_config", //这里是我自定义的名称
            "cmds" : [
                "exec /system/bin/ifconfig eth0 192.168.1.101 netmask 255.255.255.0",
                "exec /system/bin/ifconfig eth1 192.168.2.101 netmask 255.255.255.0"
            ]
        }
    ]
}

1. 修改ohos.build
   

四、遇到的问题

1. 自定义job_name没有在init.cfg中定义，导致init无法查询到。
   init源码中//base/startup/init/services/etc/init.cfg引用我们自定义的配置
   
   具体路径根据上文BUILD.gn中安装路径填写。

2. 自定义job_name没有通过post-init阶段trigger触发，导致配置无法启动。
   init源码中//base/startup/init/services/etc/init.cfg触发我们自定义的配置
   

3. 自定义job_nmae的命令不是Job命令集中的命令，导致命令无法执行
   这里再次强调，cmd一定要是job命令集中的命令，否则是无效的
   
   我最开始使用的命令是ifconfig，导致命令没有执行。系统中是自带ifconfig，但是job命令集中是没有的

在概述中我为什么重点强调几个关键点，就是因为我犯了关键点中的全部错误，导致开机后没有达到我想要的预期结果

五、效果展示

总结

本人之前一直从事应用开发，借着这次电鸿的契机进行系统级开发的学习，将我在工作中的遇到的问题及解决思路记录并分享，希望可以与诸君共勉
目前网上技术讨论群大都是鸿蒙的应用开发，总结此类文章也是希望将同样进行鸿蒙设备开发的同僚召集到一起，一起讨论学习。如果有同样在进行鸿蒙设备开发的朋友，可以加我的联系方式，期待您的消息
个人微信