一、产品配置

productdefine_common 官方 README

标准系统如何添加一个模块

一个完整的产品包括1.芯片组件在vendor/{company}/{product}/目录下定义适配芯片和硬件平台的组件，例如：内核驱动、硬件抽象、芯片相关库、固件及配置。也可能放在vendor、device/soc、device/board 和 kernel 等目录 2.系统组件，提供与具体芯片无关的通用系统能力，例如：文件系统、网络、应用框架、系统服务等。一个完整的系统组件包括部件列表、部件部署的指令集两部分。

• 部件列表（系统所包含的软件功能和部件）：系统组件支持的部件集合都在productdefine/common/products目录下通过系统组件形态配置文件xxx.json列举，该文件还可以配置部件的feature值。其中可以通过配置文件中的product_name字段值作为build.sh --product-name的参数来完成系统组件的编译。
• 部件部署的指令集（构建目标平台的设备信息）：指令集定义都在productdefine/common/device目录下通过arm64.json类文件来定义，products目录下的形态配置文件可以通过target_cpu来指定。

系统组件部件类表的生成：

先加载inherit中的部件列表；加载subsystems中的部件列表；部件配置安装上述顺序加载，后面加载的配置可覆盖前面已加载的同名配置。

部件组合的继承关系：

在productdefine/common/inherit目录下定义的部件模板，系统组件形态可以通过inherit继承该模版中包含的所有部件，每个部件包括部件名称以及feature信息，系统组件形态配置文件继承模版时会把这两个信息都继承下去。编译框架支持全量继承和部分继承

• 全量继承：系统组件形态配置文件直接inherit部件模版，则可完全继承模版中的部件以及部件的feature信息。
• 部分继承：feature重载，在系统组件形态配置文件中的重新定义部件的feature信息，此时会覆盖所继承模版中部件的配置。

查看一个指定产品的最终的部件列表：

在编译启动后，编译系统会解析配置文件，生成产品的全部的部件列表，输出为：out/preloader/{产品名}/parts.json

ohos.build 配置文件说明：

• subsystem 定义了子系统的名称；parts 定义了子系统包含的部件，parts 负责组织和描述部件，产品配置中的 components 负责选择部件二者属于同一个层级
• 一个部件包含部件名、部件包含的模块module_list、部件提供给其他部件的接口inner_kits和部件测试用例test_list,这些都需要添加到 ohos.build 文件中

标准系统添加一个模块：
1.在原有部件中添加一个模块

• 模块目录下新建 BUILD.gn，选择对应的模板
• 修改包含该模块所属部件的 ohos.build 配置文件

2.新建部件并添加一个模块

• 模块目录下新建 BUILD.gn，选择对应的模板，相较于原有模块中添加，要将 BUILD.gn 中的 part_name 改为新建的部件名
• 配置内容可以在该部件所属子系统原有的 ohos.build 文件中添加该部件，也可以在所属子系统所在的文件夹下新建一个 ohos.build 文件
• 在 productdefine/common/products 目录下的产品配置文件（json格式）中添加新建的部件，新建的模块直接添加到原有部件后即可

3.新建子系统并在该子系统下添加部件

• 在模块目录下配置BUILD.gn，根据类型选择对应的模板。这一步与新建部件并在其中添加模块中对应的步骤并无区别
• 在新建的子系统目录下每个部件对应的文件夹下创建 ohos.build 文件，定义部件信息。这一步与新建部件并在其中添加模块中对应的步骤并无区别
• 修改源码根目录下的build目录下的subsystem_config.json文件，该文件定义了有哪些子系统以及这些子系统所在的文件夹路径。添加子系统时需要说明子系统path与name，分别表示子系统路径和子系统名
• 在productdefine/common/products目录下的产品配置，如Hi3516DV300.json中添加对应的部件，直接添加到原有部件后即可

鸿蒙操作系统的配置文件主要有四个：

• product_name.json，指明了产品名，产品厂商，产品设备，版本，要编译的系统类型，以及产品包含的部件
• subsystem_config.json，该文件对子系统进行了说明，我们需要该子系统定义中的name与path，分别表示子系统的名称和所在文件夹路径
• ohos.build，子系统下部件的描述文件；在源码中或者官方文档中会看到bundle.json文件，其是用于描述子系统（或部件）中所包含的部件配置文件，在编译构建的过程中起到的作用应该是一样的，只是两种不同的表达方式，使用哪一种都是可以的，在上下级角度上看，bundle.json可能比ohos.build低一级，但是它们都是用于描述该软件包含的东西，提供的接口，测试的示例等，在源码中有的是用bundle.json描述，有的用ohos.build描述，所以我们在构建的时候使用谁都是OK的，还有的两个都用了
• BUILD.gn，每个模块对应的BUILD.gn文件

二、GN / Ninja 编译构建

OpenHarmony 编译构建子系统官方 README
编译构建指导

# 检查编译环境是否完善
hb env

device/board/hihope/${device_name}/config.gni内容为该开发板对应的编译环境及参数配置；device/board/hihope/${device_name}/device.gni内容为该开发板及平台设备配置
两篇文章主要写构建编译工具的使用过程，第一篇更详细，第二篇更完整

三、镜像生成与开发板烧录

OpenHarmony 标准系统移植指南
文章所在目录还有板商的porting案例包括注意事项

RK3568 开发板镜像烧录指南

OpenHarmony 的内核构建以 Linux 内核为基础，整体仍采用 Linux 原有的 Kconfig 和 Kbuild 构建机制。与普通 Linux 内核编译相比，主要增加了 OpenHarmony 相关的适配工作：首先，通过应用 HDF 补丁，使 Linux 内核适配 OpenHarmony 的硬件驱动框架；其次，通过软链接等方式，将 OpenHarmony 源码中芯片厂商及开发板相关的驱动代码引入 Linux 内核源码目录，并结合目标设备配置完成内核配置与编译。内核编译完成后，还需要整理内核镜像、设备树及相关启动资源。与此同时，OpenHarmony 构建系统通过 GN 和 Ninja 完成系统软件各部件的编译，并按照产品配置组织系统软件及相关文件，制作 system.img、vendor.img 等分区镜像。最后，产品构建流程将系统分区镜像、内核镜像及 U-Boot 等启动文件按照分区布局和启动要求进行整合与打包，生成可用于开发板烧录的系统固件