LiteOS-M supports mainstream architectures, such as ARM Cortex-M3, ARM Cortex-M4, ARM Cortex-M7, ARM Cortex-M33, and RISC-V.
LiteOS-M supports mainstream architectures, such as RISC-V and ARM Cortex-M3, Cortex-M4, Cortex-M7, and Cortex-M33.
## Working Principles
In the **target\_config.h** file of the development board, configure the system clock and number of ticks per second, and configure the task, memory, inter-process communication (IPC), and exception handling modules based on service requirements. When the system boots, the modules are initialized based on the configuration. The kernel startup process includes peripheral initialization, system clock configuration, kernel initialization, and OS boot, as shown in the figure below.
In the **target_config.h** file of the development board, configure the system clock and number of ticks per second, and configure the task, memory, inter-process communication (IPC), and exception handling modules based on service requirements. When the system boots, the modules are initialized based on the configuration. The kernel startup process includes peripheral initialization, system clock configuration, kernel initialization, and OS boot, as shown in the figure below.
│ │ └── include # Directory of the common header files of the ARM architectures
│ ├── csky # Code of the C-SKY architecture
│ │ └── v2 # code of C-SKY v2
│ ├── include # APIs exposed externally
│ ├── risc-v # Code of the risc-v architecture
│ │ ├── nuclei # Code of the nuclei system technology risc-v architecture
│ │ └── riscv32 # Code of the risc-v architecture
│ └── xtensa # Code of the xtensa architecture
│ └── lx6 # Code of the lx6 xtensa architecture
│ ├── risc-v # Code of the RISC-V architecture
│ │ ├── nuclei # Code of RISC-V for Nuclei
│ │ └── riscv32 # Code of the official RISC-V architecture
│ └── xtensa # Code of the Xtensa architecture
│ └── lx6 # Code of Xtensa LX6
├── components # Optional components
│ ├── backtrace # Backtrace support
│ ├── backtrace # Backtrace
│ ├── cppsupport # C++ support
│ ├── cpup # CPU percent (CPUP)
│ └── cpup # CPU percent (CPUP)
│ ├── dynlink # Dynamic loading and linking
│ ├── exchook # Exception hooks
│ ├── fs # File systems
│ ├── lmk # Low memory killer functions
│ ├── lms # Lite memory sanitizer functions
│ ├── net # Networking functions
│ ├── power # Power management
│ ├── shell # Shell function
│ ├── fs # File systems
│ ├── lmk # Low memory killer mechanism
│ ├── lms # Lite memory sanitizer mechanism
│ └── net # Networking functions
│ ├── power # Power consumption management
│ ├── shell # Shell
│ └── trace # Trace tool
├── drivers # driver Kconfig
├── drivers # Driver framework Kconfig
├── kal # Kernel abstraction layer
│ ├── cmsis # CMSIS API support
│ └── posix # POSIX API support
├── kernel # Minimum kernel function set
│ ├── include # APIs exposed externally
│ └── src # Source code of the minimum kernel function set
├── testsuites # Kernel testsuites
├── testsuites # Kernel test cases
├── tools # Kernel tools
├── utils # Common directory
├── utils # Common code
```
## Constraints<a name="section119744591305"></a>
## Constraints
OpenHarmony LiteOS-M supports only C and C++.
Applicable architecture: See the directory structure for the arch layer.
OpenHarmony LiteOS-M applies only to the architectures in **arch**.
As for dynamic loading module, the shared library to be loaded needs signature verification or source restriction to ensure security.
For the shared library to be dynamically loaded, signature verification must be performed or the library source must be strictly controlled for security purposes.
## Usage<a name="section3732185231214"></a>
## Usage
The OpenHarmony LiteOS-M kernel build system is a modular build system based on Generate Ninja (GN) and Ninja. It supports module-based configuration, tailoring, and assembling, and helps you build custom products. This document describes how to build a LiteOS-M project based on GN and Ninja. For details about the methods such as GCC+gn, IAR, and Keil MDK, visit the community websites.
OpenHarmony
The OpenHarmony LiteOS-M kernel build system is a modular build system based on Generate Ninja (GN) and Ninja. It supports modular configuration, tailoring, and assembling, and helps you build custom products. This document describes how to build a LiteOS-M project based on GN and Ninja. For details about other building methods, such as GCC+gn, IAR, and Keil MDK, visit the related community websites.
### Setting Up the Environment
Before setting up the environment for a development board, you must set up the basic system environment for OpenHarmony first. The basic system environment includes the OpenHarmony build environment and development environment. For details, see [Quick Start Overview](../quick-start/quickstart-overview.md).
Before setting up the environment for a development board, you must set up the basic system environment for OpenHarmony first. The basic system environment refers to the OpenHarmony build environment and development environment. For details, see [Quick Start Overview](../quick-start/quickstart-overview.md).
### Obtaining the OpenHarmony Source Code
### Obtaining OpenHarmony Source Code
For details about how to obtain the source code, see [Source Code Acquisition](../get-code/sourcecode-acquire.md). This document assumes that the clone directory is `~/openHarmony` after the complete OpenHarmony repository code is obtained.
For details about how to obtain the source code, see [Obtaining Source Code](../get-code/sourcecode-acquire.md). The directory to clone is **~/openHarmony** after the OpenHarmony repository code is obtained.
### Example projects
### Supported Sample Projects
Qemu simulator: `arm_mps2_an386、esp32、riscv32_virt、SmartL_E802`. For details about how to compile and run, see [qemu guide](https://gitee.com/openharmony/device_qemu).
QEMU: **arm_mps2_an386**, **esp32**, **riscv32_virt**, and **SmartL_E802**. For details, see [QEMU](https://gitee.com/openharmony/device_qemu).
Bestechnic: `bes2600`. For details about how to compile and run, see [Bestechnic developer guide](https://gitee.com/openharmony/device_soc_bestechnic).
bestechnic: **bes2600**. For details, see [device_bestechnic](https://gitee.com/openharmony/device_soc_bestechnic).
### Community Porting Project Links
### Community Porting Project
The LiteOS-M kernel porting projects for specific development boards are provided by community developers. The following provides the links to these projects. If you have porting projects for more development boards, you can provide your links to share your projects.
The LiteOS-M kernel porting projects for specific development boards are provided by community developers. The following provides the links to these projects. You are also welcomed to share your porting projects.
- Cortex-M3:
...
...
@@ -123,22 +126,22 @@ The LiteOS-M kernel porting projects for specific development boards are provide
This repository provides the project code for porting the OpenHarmony LiteOS-M kernel to support the STM32F429IGTb development board. The code supports build in Ninja, GCC, and IAR modes.
@@ -122,7 +122,7 @@ You must install the software packages required for build. The command is as fol
# export PATH=~/.local/bin:$PATH
```
**NOTE**<br>The hb tool will be installed during the installation of ohos-build. If the hb installation fails, see [Installing hb](../../device-dev/quick-start/quickstart-pkg-install-tool.md).
**NOTE**<br>The hb tool will be installed during the installation of **ohos-build**. If hb tool fails to be installed, [install hb](../../device-dev/quick-start/quickstart-pkg-install-tool.md#hb-installation) again.
## Configuration Rules
...
...
@@ -143,28 +143,28 @@ To ensure that chipset and product solutions are decoupled from OpenHarmony, you
```shell
/build # Directory for build
/build # Directory for build
├── __pycache__
├── build_scripts/ # Python scripts for build
├── build_scripts/ # Python scripts for build
├── common/
├── config/ # Build-related configuration
├── config/ # Build-related configuration
├── core
│ └── gn/ # BUILD.gn configuration
│ └── gn/ # BUILD.gn configuration
└── build_scripts/
├── docs
gn_helpers.py*
lite/ # hb and preloader entry
lite/ # hb and preloader entry
misc/
├── ohos # Configuration of OpenHarmony building and packaging
│ ├── kits # Kits build and packaging templates and processing
│ ├── ndk # NDK templates and processing
│ ├── notice # Notice templates and processing
│ ├── packages # Distribution packaging templates and processing
│ ├── sa_profile # SA profiles and processing
│ ├── sdk # SDK templates and processing, which contains the module configuration in the SDK
│ └── testfwk # Testing-related processing
├── ohos.gni*# Common .gni files (facilitating one-time import of each module)
├── ohos # Configuration of OpenHarmony build and packaging
│ ├── kits # Kits build and packaging templates and processing
│ ├── ndk # NDK templates and processing
│ ├── notice # Notice templates and processing
│ ├── packages # Distribution packaging templates and processing
│ ├── sa_profile # SA profiles and processing
│ ├── sdk # SDK templates and processing, which contains the module configuration in the SDK
│ └── testfwk # Testing-related processing
├── ohos.gni*# Common .gni files (facilitating one-time import of each module)
├── ohos_system.prop
├── ohos_var.gni*
├── prebuilts_download.sh*
...
...
@@ -195,179 +195,171 @@ Then, run the build commands in command line (CLI) mode or hb mode.
1. Using the CLI
- Run the following command in the root directory of the source code to build a full distribution:
>Due to the limitation of the image size, the full build for the debug version may fail to be burnt. You are advised to build the binary file for each module separately. Run the following command to build a module separately:
-v, --verbose show all command lines while building
-shs, --sign_haps_by_server
sign haps by server
--patch apply product patch before compiling
--compact-mode compatible with standard build system set to false if we use build.sh as build entrance
--gn-args GN_ARGS specifies gn build arguments, eg: --gn-args="foo="bar" enable=true blah=7"
--keep-ninja-going keeps ninja going until 1000000 jobs fail
--build-only-gn only do gn parse, do not run ninja
--log-level LOG_LEVEL
specifies the log level during compilationyou can select three levels: debug, info and error
--fast-rebuild it will skip prepare, preloader, gn_gen steps so we can enable it only when there is no change
for gn related script
--device-type DEVICE_TYPE
specifies device type
--build-variant BUILD_VARIANT
specifies device operating mode
```
- If you run **hb build** with no argument, the previously configured code directory, product, and options are used for the build. The **-f** option deletes all products to be built. It is equivalent to running **hb clean** and **hb build**.
- You can run **hb build** *{component_name}* to build product components separately based on the development board and kernel set for the product, for example, **hb build kv_store**.
- You can run **hb build -p ipcamera@hisilicon** to skip the setting step and build the product directly.
- You can run **hb build** in **device/board/device_company** to select the kernel and build an image that contains the kernel and drivers only based on the current development board and the selected kernel.
**hb clean**
Deletes all the files except **args.gn** and **build.log** in the **out** directory (default). To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean out/board/product**.
> - For details about how to set up the build environment and perform the build, see the related topics in [Getting Started](../quick-start/Readme-EN.md).
> - OpenHarmony also provides the Docker environment, which spares the installation of the build tool. For details, see [Docker Environment](../get-code/gettools-acquire.md).
- Run the following command in the root directory of the source code to build a full distribution:
> Due to the limitation of the image size, the full build for the debug version may fail to be burnt. You are advised to build the binary file for each module separately. Run the following command to build a module separately:
-v, --verbose show all command lines while building
-shs, --sign_haps_by_server
sign haps by server
--patch apply product patch before compiling
--compact-mode compatible with standard build system set to false if we use build.sh as build entrance
--gn-args GN_ARGS specifies gn build arguments, eg: --gn-args="foo="bar" enable=true blah=7"
--keep-ninja-going keeps ninja going until 1000000 jobs fail
--build-only-gn only do gn parse, do not run ninja
--log-level LOG_LEVEL
specifies the log level during compilationyou can select three levels: debug, info and error
--fast-rebuild it will skip prepare, preloader, gn_gen steps so we can enable it only when there is no change
for gn related script
--device-type DEVICE_TYPE
specifies device type
--build-variant BUILD_VARIANT
specifies device operating mode
```
- If you run **hb build** with no argument, the previously configured code directory, product, and options are used for the build. The **-f** option deletes all products to be built. It is equivalent to running **hb clean** and **hb build**.
- You can run **hb build***{component_name}* to build product components separately based on the development board and kernel set for the product, for example, **hb build kv_store**.
- You can run **hb build -p ipcamera@hisilicon** to skip the setting step and build the product directly.
- You can run **hb build** in **device/board/device_company** to select the kernel and build an image that contains the kernel and drivers only based on the current development board and the selected kernel.
**hb clean**
Deletes all the files except **args.gn** and **build.log** in the **out** directory (default). To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean out/board/product**.
```shell
hb clean
usage: hb clean [-h][out_path]
positional arguments:
out_path clean a specified path.
optional arguments:
-h, --help show this help message and exit
```
> **NOTE**
>
> - For details about how to set up the build environment and perform the build, see the related topics in [Getting Started](../quick-start/quickstart-overview.md)
> - OpenHarmony also provides the Docker environment, which spares the installation of the build tool. For details, see [Docker Environment](../get-code/gettools-acquire.md)
### Building Procedures
...
...
@@ -389,3 +381,4 @@ You can add and build a product, component, chipset solution, and module. For de
-[Information Collected by the Open Source Software Notice](subsys-build-reference.md#information-collected-by-the-open-source-software-notice)
-[Parameters for Accelerating Local Build](subsys-build-reference.md#parameters-for-accelerating-local-build)
