Hongmeng Hi3861 Learning Twenty-Compilation Structure

1. Introduction

        Before using the compilation to construct the subsystem, you should understand the following basic concepts:

        subsystem

        A subsystem is a logical concept that consists of one or more specific components . OpenHarmony follows a layered design as a whole, from bottom to top: kernel layer , system service layer , architecture layer , and application layer . The system functions are expanded step by step according to " system > subsystem > component ". In the multi-device deployment scenario,some non-essential subsystems or components are supported according to actual needs.

        components

The smallest reusable, configurable, and tailorable functional unit         of the system . Components have the characteristics of directory independence , parallel development , independent compilation , and independent testing .

        gn

        Abbreviation for Generate ninja, used to generate ninja files .

        ninja

ninja is a small build system         with a focus on speed

        hb

        OpenHarmony's command-line tool to execute compilation commands.

      Compile directory structure

build/lite
├── components                  # 组件描述文件
├── figure                     # readme中的图片
├── hb                          # hb pip安装包源码
├── make_rootfs                 # 文件系统镜像制作脚本
├── config                      # 编译配置项
│   ├── component               # 组件相关的模板定义
│   ├── kernel                  # 内核相关的编译配置
│   └── subsystem               # 子系统编译配置
├── platform                    # ld脚本
├── testfwk                     # 测试编译框架
└── toolchain                   # 编译工具链配置，包括：编译器路径、编译选项、链接选项等

2. Construction rules

        In order to realize that chip solutions, product solutions and OpenHarmony are decoupled and pluggable, the paths, directory trees and configurations of components, chip solutions and product solutions must follow certain rules, as follows:

      components

        The component source code path naming rule is: { domain } / { subsystem } / { component }, and the component directory tree rules are as follows;

        Note: The name of the component, source code path, function introduction, whether it is required, compilation target, RAM, ROM, compilation output, adapted kernel, configurable features and dependencies and other property definitions are in the build/lite/components directory In the json file of the corresponding subsystem, when adding a component, you need to add the corresponding component definition in the json file of the corresponding subsystem . The components configured by the product must have been defined in a certain subsystem, otherwise the verification will fail .

component
├── interfaces
│   ├── innerkits  # 系统内接口，组件间使用
│   └── kits       # 应用接口，应用开发者使用
├── frameworks     # framework实现
├── services       # service实现
└── BUILD.gn       # 组件编译脚本

 Take wifi_iot_sample_app in applications.json as an example:

    {
      "component": "wifi_iot_sample_app",  #组件名称
      "description": "Wifi iot samples.",    #组件功能描述
      "optional": "true",    #组件是否为最小系统必选
      "dirs": [    #组件源码路径
        "applications/sample/wifi-iot/app"
      ],
      "targets": [    #组件编译入口
        "//applications/sample/wifi-iot/app"
      ],
      "rom": "",    #组件ROM值
      "ram": "",    #组件RAM估值
      "output": [],    #组件编译输出
      "adapted_board": [ "hi3861v100" ],    #组件已适配的芯片
      "adapted_kernel": [ "liteos_m" ],    #组件已适配的内核
      "features": [],    #组件可适配的特性
      "deps": {
          "components": [    #组件依赖的其他组件
            "utils_base"
        ]
      }
    },

        Compilation recommendations for component BUILD.gn are as follows:

• Compile the target name to be consistent with the component
• The externally configurable feature variables of a component need to be declared in the BUILD.gn of the component. The feature variable naming rules: ohos_{subsystem}_{component}_{feature}. Features also need to be defined synchronously in the component description, and configured on demand in the product configuration file config.json.
• Macro definition rules: OHOS_{SUBSYSTEM}_{COMPONENT}_{FEATURE}

         

      chip solution

Chip solution refers to a complete solution         based on a certain development board , including drivers , device-side interface adaptation , development board SDK , etc.

        The chip solution is a special component , and the source code path rule is: device  / { chip solution manufacturer } / { development board }

        Chip solution components will be compiled by default with the development board selected by the product

        The chip solution directory tree rules are as follows:

device                                      
└── hisilicon                       # 芯片解决方案厂商（海思）
    ├── BUILD.gn                # 编译脚本
    ├── hals                    # OS南向接口适配
    ├── hispark_aries           # Hi3518
    ├── hispark_pegasus         # Hi3861
    ├── hispark_taurus          # Hi3516

       

      Product Solutions

        The product solution is a complete product based on the development board, which mainly includes product adaptation to the OS , component assembly configuration , startup configuration , and file system configuration . The source code path rule of the product solution is: vendor / { product solution vendor } / { product name }. Product solutions are also a special component .

        The directory tree rules for product solutions are as follows:

vendor                              
└── hisilicon                       # 产品解决方案厂商（海思）
    ├── hispark_aries               # 产品名称 Hi3518
    ├── hispark_pegasus             # 产品名称 Hi3861
    ├── hispark_taurus              # 产品名称 Hi3516
    │   ├── init_configs
    │   │     ├── etc               # init进程启动配置（可选，仅linux内核需要）
    │   │     └── init.cfg          # 系统服务启动配置
    │   ├── hals                    # 产品解决方案OS适配
    │   ├── BUILD.gn                # 产品编译脚本
    │   └── config.json             # 产品配置文件
    │   └── fs.yml                  # 文件系统打包配置
    └── ......

        Note: New products need to create directories and files according to the above rules , and the compilation and build system will scan the configured products according to the rules.

        The key directories and files are described in detail as follows:

        1.vendor / company / product / init_configs / etc

        This folder contains rcs scripts, Sxxx scripts and fstab scripts. The init process executes these scripts before starting system services. The execution process is " rcs -> fstab -> S00-xxx ". The content in the Sxxx script is related to the development board and product requirements, mainly including the creation of device nodes, creating directories, scanning device nodes, modifying file permissions, and so on. These files are copied to the product out directory as needed in the BUILD.gn compiled by the product, and finally packaged into the rootfs image .

        2.vendor / company / product / init_configs / init.cfg

        The configuration file for the init process to start the service. The currently supported commands for parsing are:

start：启动某个服务
mkdir：创建文件夹
chmod：修改指定路径/文件的权限
chown：修改指定路径/文件的属性
mount：挂在命令

        3.vendor / company / product / hals

        For the adaptation of the solution vendor to the OS , please refer to the readme documentation of each component for the interfaces that need to be implemented.

        4.vendor / company / product / config.json

        config.json is the main entry for compiling and constructing , including configuration information such as the development board, OS components, and kernel.

        Take hispark_pegasus as an example

    "product_name": "wifiiot_hispark_pegasus",    #产品名称
    "ohos_version": "OpenHarmony 1.0",    #选择的OS版本
    "device_company": "hisilicon",    #芯片厂商
    "board": "hispark_pegasus",    #开发板名称
    "kernel_type": "liteos_m",    #内核类型
    "kernel_version": "",    #内核版本
    "subsystems": [    #子系统
      {
        "subsystem": "applications",    #子系统名称
        "components": [    
          { "component": "wifi_iot_sample_app", "features":[] }    #选择的组件和组件的特性配置
        ]
      },

        5.vendor / company / product / BUILD.gn

        The entry for product compilation is mainly used to compile solution vendor source code and copy startup configuration files. If a product is selected as the product to be compiled, BUILD.gn under the corresponding product directory will be compiled by default. A typical product build BUILD.gn should look like this:

group("product") { # target名称需与product名称即三级目录名称一致
  deps = []
  # 拷贝init配置
  deps += [ "init_configs" ]
  # 其他
  ......
}

3. New components

        In the previous chapter, the hello_world project was added. Here's a recap. The directory structure is as follows:

applications/sample                              
└── wifi-iot                      
    └── app               
        ├── hello_world            
            ├── hello_world.c             
            ├── BUILD.gn
        └──BUILD.gn

        The content of BUILD.gn under hello_world is as follows:

static_library("hello_world") {
    sources = [
        "hello_world.c"
    ]
    include_dirs = [
        "//utils/native/lite/include",
        "//kernel/liteos_m/kal/cmsis",
    ]
}

        The content of hello_world.c is as follows:

int cnt = 0;

void HelloWorld(void)
{
    printf("[DEMO] Hello world.\n");
    while(1)
    {
        cnt++;
        osDelay(100);
        printf("[DEMO] Hello world.[%d]\n",cnt);
    }
}

APP_FEATURE_INIT(HelloWorld);

      Add hello world to the original component

        Modify the BUILD.gn file in the app directory as follows:

import("//build/lite/config/component/lite_component.gni")

lite_component("app") {
    features = [
        "hello_world:hello_world",
    ]
}

        Compile and download at this time.

        Look at the result:

         It can be seen that not only hello world is printed here, but also a lot of test codes are printed. This is because the SDK runs xts_test by default, and xts_test needs to be turned off .

        In vendor/hisilicon/hispark_pegasus/config.json, delete the subsystem "test". Note: This cannot be commented out, only deleted .

      {
       "subsystem": "test",
       "components": [
         { "component": "xts_acts", "features":[] },
         { "component": "xts_tools", "features":[] }
        ]
      }

         Recompile, it should be noted that the setting will take effect only after clean and rebuild .

         After re-clean, build, and Upload, it works normally.

      Create a new hello world component

        Do not use BUILD.gn in the app directory, the content is as follows:

import("//build/lite/config/component/lite_component.gni")

lite_component("app") {
    features = [

    ]
}

        As mentioned in the above article, the system comes through Domain -> Subsystem -> Component . Newly added components need to be declared in the json file of the corresponding subsystem in the build/lite/components directory .

        Then add the following code to the buld/lite/components/applications.json file:

    {
      "component": "hello_world",  
      "description": "hello world.",
      "optional": "true",
      "dirs": [
        "applications/sample/wifi-iot/app/hello_world"
      ],
      "targets": [
        "//applications/sample/wifi-iot/app/hello_world"
      ],
      "rom": "",
      "ram": "",
      "output": [],
      "adapted_board": [ "hi3861v100" ],
      "adapted_kernel": [ "liteos_m" ],
      "features": [],
      "deps": {
          "components": [
            "utils_base"
        ]
      }
    },

        After the declaration, it is also necessary to let the compilation system know that the component is to be compiled, so the subsystem to be compiled needs to be added to the main entry file of the compilation structure .

         Add the following code in vendor/hisilicon/hispark_tegasus/config.json :

{ "component": "hello_world", "features":[] }

        After the addition is complete, recompile and download.

 

        It can be seen that the Hello world component added by myself has been running normally.

4. New products

        Modify the vendor/hisilicon/hispark_pegasus/config.json file directly. Change " product_name " to "hello_world_test". The complete code is as follows:

  {
    "product_name": "hello_world_test",
    "ohos_version": "OpenHarmony 1.0",
    "device_company": "hisilicon",
    "board": "hispark_pegasus",
    "kernel_type": "liteos_m",
    "kernel_version": "",
    "subsystems": [
      {
        "subsystem": "applications",
        "components": [
          { "component": "hello_world", "features":[] }
        ]
      },
      {
        "subsystem": "iot_hardware",
        "components": [
          { "component": "iot_controller", "features":[] }
        ]
      },
      {
        "subsystem": "hiviewdfx",
        "components": [
          { "component": "hilog_lite", "features":[] },
          { "component": "hievent_lite", "features":[] }
        ]
      },
      {
        "subsystem": "distributed_schedule",
        "components": [
          { "component": "system_ability_manager", "features":[] }
        ]
      },
      {
        "subsystem": "security",
        "components": [
          { "component": "hichainsdk", "features":[] }
        ]
      },
      {
        "subsystem": "startup",
        "components": [
          { "component": "bootstrap", "features":[] },
          { "component": "syspara", "features":[] }
        ]
      },
      {
        "subsystem": "communication",
        "components": [
          { "component": "wlan", "features":[] },
          { "component": "soft_bus", "features":[] },
          { "component": "wifi_aware", "features":[]}
        ]
      },
      {
        "subsystem": "update",
        "components": [
          { "component": "hota", "features":[] }
        ]
      },
      {
        "subsystem": "iot",
        "components": [
          { "component": "iot_link", "features":[] }
        ]
      },
      {
        "subsystem": "utils",
        "components": [
          { "component": "file", "features":[] },
          { "component": "kv_store", "features":[] },
          { "component": "os_dump", "features":[] }
        ]
      },
      {
        "subsystem": "vendor",
        "components": [
          { "component": "hi3861_sdk", "target": "//device/hisilicon/hispark_pegasus/sdk_liteos:wifiiot_sdk", "features":[] }
        ]
      }
    ],
    "vendor_adapter_dir": "//device/hisilicon/hispark_pegasus/hi3861_adapter",
    "third_party_dir": "//device/hisilicon/hispark_pegasus/sdk_liteos/third_party",
    "product_adapter_dir": "//vendor/hisilicon/hispark_pegasus/hals",
    "ohos_product_type":"",
    "ohos_manufacture":"",
    "ohos_brand":"",
    "ohos_market_name":"",
    "ohos_product_series":"",
    "ohos_product_model":"",
    "ohos_software_model":"",
    "ohos_hardware_model":"",
    "ohos_hardware_profile":"",
    "ohos_serial":"",
    "ohos_bootloader_version":"",
    "ohos_secure_patch_level":"",
    "ohos_abi_list":""
  }

         At this point, you can view the product in DevEco .

         After creation, configure the relevant configuration of the product, including upload_port and upload_partitions . After completion, the toolbar of " hello_world_test " will also appear in the PROJECT TASKS on the left, which can be compiled and downloaded.

         The compilation and download process will not be introduced here.