Startup

• Introduction
• Directory Structure
• Constraints
• Usage Guidelines
• Repositories Involved

Introduction

The Startup subsystem provides the functions of starting key system processes and services after the kernel is started and before applications are started, and restoring the system to factory settings. The subsystem consists of the following modules:

• init_lite

  This module can be used on the Hi3516D V300 and Hi3518E V300 platforms powered by LiteOS Cortex-A.

  It starts system service processes from the time the kernel loads the first user-space process to the time the first application is started. In addition to loading key system processes, the module needs to configure their permissions during the startup and keep the specified process alive after sub-processes are started. If a process exits abnormally, the module needs to restart it, and to perform system reset for a special process.

• appspawn_lite

  This module can be used on the Hi3516D V300 and Hi3518E V300 platforms powered by LiteOS Cortex-A.

  This module spawns application processes upon receiving commands from the application framework, configures permissions for new processes, and calls the entry function of the application framework.

• bootstrap_lite

  This module can be used on the Hi3861 platform powered by LiteOS Cortex-M.

  This module provides entry identifiers for starting services and features. When Samgr starts, it will call the entry function identified by bootstrap_lite and start system services.

• syspara_lite

  This module obtains and sets system attributes.

  It can be used on the Hi3861, Hi3516D V300, and Hi3518E V300 platforms powered by LiteOS Cortex-M and LiteOS Cortex-A. Supported system attributes consist of default, OEM-specified, and custom system attributes. OEM-specified system attributes provide only default values. The specific values need to be adjusted as required. For details, see Usage Guidelines.

Directory Structure

Table 1 Directory structure of the source code for the startup subsystem

base/startup/
├── appspawn_standard         # appspawn_lite module for the standard system
│   ├── include               # Header files
│   ├── parameter             # System parameters
│   ├── src                   # Source files 
│   └── test                  # Test cases 
├── appspawn_lite             # appspawn_lite module for the mini system
│   └── services
│       ├── include           # Header files 
│       ├── src              # Source files 
│       └── test              # Test cases
├── bootstrap_lite           # bootstrap_lite module
│   └── services
│       └── source            # Source files 
├── init_lite                 # init_lite module
│   ├── initsync              # Source files
│   ├── interfaces            # External APIs
│   └── services
│       ├── include           # Header files 
│       ├── src               # Source files 
│       └── test              # Test cases
└── syspara_lite              # syspara_lite module
    ├── adapter               # Adaptation code
    ├── frameworks            # Source files
    ├── hals                  # Header files for the hardware abstraction layer (HAL)
    ├── interfaces            # External APIs
    └── simulator             # Simulator adaptation

Constraints

OEM-specified system attributes provide only default values. The specific values need to be adjusted as required.

Usage Guidelines

• Configuration file of the init_lite module

  The configuration file init.cfg of the init_lite module contains service names, executable file paths, permissions, and other attributes of all key system services that need to be started by the init process. The file is stored in /vendor/hisilicon/hispark_aries/init_configs/ under /etc/. It is in JSON format, and its size cannot exceed 100 KB.

  After the init process starts, it reads the /etc/init.cfg file, parses the JSON content, and loads system services in sequence based on the parsing result. The format and content of the configuration file are described as follows:

{
    "jobs" : [{
            "name" : "pre-init",      -------- Job executed before the initialization. It can be used to store some operations (for example, creating a directory) performed before the init process is started.
            "cmds" : [                -------- Commands supported by the current job. Currently, only start, mkdir, chmod, chown, and mount are currently supported.
                                      -------- The command name and the parameters (128 bytes or less) must be separated by only one space.
                 "mkdir /testdir",      -------- Command for creating a directory. mkdir and the target directory must be separated by only one space.
                "chmod 0700 /testdir", -------- Command for modifying the permission. chmod, permission, and the target directory must be separated by only one space. The permission must be in the 0xxx format.
                "chown 99 99 /testdir",-------- Command for modifying the owner group. chown, UID, GID, and the target directory must be separated by only one space.
                "mkdir /testdir2",
                "mount vfat /dev/mmcblk0p0 /testdir2 noexec nosuid" -------- mount command in the following format: mount file system type source target flags data
                                                                    -------- Supported flags include only nodev, noexec, nosuid, and rdonly, which are separated by a space.
            ]
        }, {
            "name" : "init",          -------- Job name, which currently supports only pre-init, init, and post-init.
            "cmds" : [                -------- A single job currently supports a maximum of 30 commands.
                "start service1",     -------- Service startup command 1.
                "start service2"      -------- Service startup command 2. The sequence of the commands in the array can be adjusted as required. The init process then executes the commands in the same sequence as they are parsed.
             ]
        }, {
             "name" : "post-init",    -------- Job executed after the initialization. It can be used to store some operations performed after the init process is started.
             "cmds" : []
        }
    ],
    "services" : [{                         -------- Service set (in an array), including all system services that need to be started by the init process. Currently, a maximum of 100 services are supported.
            "name" : "service1",            -------- Name of the current service. A maximum of 32 bytes must be specified for the name.
            "path" : "/bin/process1"        -------- Full path of the executable file of the current service. A maximum of 64 bytes must be specified for the path.
            "uid" : 1,                      -------- UID of the current service process.
            "gid" : 1,                      -------- GID of the current service process.
            "once" : 0,                     -------- Whether the current service process is a one-off process.
                                                     0 --- The current service process is not a one-off process. If the process exits for a certain reason, the init_lite module restarts the service process upon receiving the SIGCHLD signal.
                                                   non-0 --- The current service process is a one-off process. If the process exits for a certain reason, the init_lite module does not restart the service process.
            "importance" : 1,               -------- Whether the current service process is a key system process
                                                     0 --- The current service process is not a key system process. If the process exits due to any reason, the init_lite module does not reset the system.
                                                   non-0 --- The current service process is a key system process. If the process exits due to any reason, the init_lite module resets and restarts the system upon receiving the SIGCHLD signal.
            "caps" : [0, 1, 2, 5]           -------- Capabilities required by the current service. They are determined by the capabilities supported by the security subsystem and configured in accordance with the principle of least permission. (Currently, a maximum of 100 values can be configured.)
    }, {
            "name" : "service2",            -------- Next service that needs to be started by the init_lite module. The service sequence is irrelevant to the startup sequence, which is determined by the command sequence in the previous job.
            "path" : "/bin/process2",
            "uid" : 2,
            "gid" : 2,
            "once" : 1,
            "importance" : 0,
            "caps" : [ ]
        }
    ]
}

Table 2 Supported commands

It is worth noting that the modified init.cfg file must be in JSON format. Otherwise, the init process fails to parse the file, and no service will be started. The configured service permission uid/gid/capability must meet the requirements imposed by the security subsystem and comply with the principle of least permission. In addition, if the values of once and importance of a service are both 0 and the service exits for more than four consecutive times within four minutes, the init process will stop restarting the service.

• System parameters

  • OEM-specific system attributes

    For Hi3516D V300 and Hi3518E V300 development boards, you need to modify the source files in the vendor/hisilicon/hispark_aries/hals/utils/sys_param directory.

    static const char HOS_PRODUCT_TYPE[] = {"****"};
    static const char HOS_MANUFACTURE[] = {"****"};
    static const char HOS_BRAND[] = {"****"};
    static const char HOS_MARKET_NAME[] = {"****"};
    static const char HOS_PRODUCT_SERIES[] = {"****"};
    static const char HOS_PRODUCT_MODEL[] = {"****"};
    static const char HOS_SOFTWARE_MODEL[] = {"****"};
    static const char HOS_HARDWARE_MODEL[] = {"****"};
    static const char HOS_HARDWARE_PROFILE[] = {"aout:true,display:true"};
    static const char HOS_BOOTLOADER_VERSION[] = {"bootloader"};
    static const char HOS_SECURE_PATCH_LEVEL[] = {"2020-6-5"};
    static const char HOS_ABI_LIST[] = {"****"};
    

    For Hi3861 development boards, you need to modify the source files in the vendor/hisilicon/hispark_pegasus/hals/utils/sys_param directory.

    static const char HOS_PRODUCT_TYPE[] = {"****"};
    static const char HOS_MANUFACTURE[] = {"****"};
    static const char HOS_BRAND[] = {"****"};
    static const char HOS_MARKET_NAME[] = {"****"};
    static const char HOS_PRODUCT_SERIES[] = {"****"};
    static const char HOS_PRODUCT_MODEL[] = {"****"};
    static const char HOS_SOFTWARE_MODEL[] = {"****"};
    static const char HOS_HARDWARE_MODEL[] = {"****"};
    static const char HOS_HARDWARE_PROFILE[] = {"aout:true,display:true"};
    static const char HOS_BOOTLOADER_VERSION[] = {"bootloader"};
    static const char HOS_SECURE_PATCH_LEVEL[] = {"2020-6-5"};
    static const char HOS_ABI_LIST[] = {"****"};
    

  • Obtaining default system attributes

    const char* value1 = GetProductType();
    printf("Product type =%s\n", value1);
    const char* value2 = GetManufacture();
    printf("Manufacture =%s\n", value2);
    const char* value3 = GetBrand();
    printf("GetBrand =%s\n", value3);
    

  • Obtaining custom system attributes

    const char* defSysParam = "data of sys param ***...";
    char key[] = "rw.parameter.key";
    char value[] = "OEM-hisi-10.1.0";
    int ret = SetParameter(key, value);
    char valueGet[128] = {0};
    ret = GetParameter(key, defSysParam, valueGet, 128);
    printf("value = %s\n", valueGet);
    

Repositories Involved

Startup subsystem

startup_syspara_lite

startup_appspawn_lite

startup_bootstrap_lite

startup_init_lite