@@ -15,7 +15,4 @@ The LTS version provides long-term kernel maintenance \(in fixing bugs and secur
## OpenHarmony Kernel Version Selection<a name="section2716416191715"></a>
You can select an appropriate LTS kernel version as the Linux kernel for OpenHarmony. Currently, LTS version 4.19 is used on most devices. LTS versions 4.4 to 4.14 are old and do not support new features. Additionally, these versions will no longer be maintained in 2023 as planned. In this regard, they can be adopted only by the systems for short-term use but are not suitable for the systems of the first release. The more up-to-date LTS version 5.4 has not been widely used in released products. In comparison, version 4.19 is more well-recognized and can shorten the kernel adaptation period. New versions will be released continuously.
In OpenHarmony, the Linux kernel is recommended for devices whose memory is greater than or equal to 128 MB.
Select an appropriate LTS kernel version as the Linux kernel for OpenHarmony. Currently, Linux-4.19 and Linux-5.10 are supported.
# Guidelines for Using Patches on OpenHarmony Development Boards<a name="EN-US_TOPIC_0000001081980461"></a>
# Applying Patches on OpenHarmony Development Boards<a name="EN-US_TOPIC_0000001081980461"></a>
The patch files are stored in the **kernel/linux/patches/linux-4.19** source code path of the project. You can obtain the driver patch of a specific chip architecture from this directory.
1. Apply HDF patches.
To use the patch of a specific chip platform driver, you need to merge the required kernel patch into the kernel code.
Apply the HDF kernel patches matching your kernel version. For details, see the method in **kernel.mk** in the **kernel/linux/build** repository.
Merge the corresponding patches for different chip platforms.
2. Apply the chip driver patches.
The following uses Hi3516D V300 as an example:
The following uses Hi3516D V300 as an example.
Place the patches for the chip component in the corresponding path based on the path and naming rules for the patches of the chip component in **kernel.mk** in the **kernel/linux/build** repository.
>Because patches are applied after the code environment of **kernel/linux-4.19** is copied during compilation and building of the OpenHarmony project, you must retain the original code environment of **kernel/linux-4.19** before running the OpenHarmony version-level build command.
Place the **config** file for the chip component in the corresponding path based on the path and naming rules of the chip component in **kernel.mk** in the **kernel/linux/build** repository.
>In the OpenHarmony project build process, patches are installed after **kernel/linux/linux-\*\.\*** is copied. Before using the version-level build command of OpenHarmony, ensure that the **kernel/linux/linux-\*\.\*** source code is available.
>
>The kernel built is generated in the **kernel** directory under the **out** directory. Modify the **config** file based on the kernel built, and copy the generated **.config** file to the corresponding path in the **config** repository. Then, the configuration takes effect.
|Version|Ubuntu 18.04 or later|libreadline-dev|3.7.5 or later|pyserial 3.3 or later, paramiko 2.7.1 or later, setuptools 40.8.0 or later, and rsa4.0 or later|haneWIN NFS Server 1.2.50 or later, or NFS v4 or later| 1.1.0 or later|
|Description|Provides code build environment.|Plug-in used to read commands.|Language used by the test framework.|pyserial: supports Python serial port communication. <br>paramiko: allows Python to use SSH. <br>setuptools: allows Python packages to be created and distributed easily. <br>rsa: implements RSA encryption in Python.|Enables devices to be connected through the serial port.| A tool that enables devices to be connected through the HarmonyOS Device Connector (HDC).|
|Version|Ubuntu 18.04 or later|libreadline-dev|3.7.5 or later|- pySerial 3.3 or later<br>- Paramiko 2.7.1 or later<br>- Setuptools 40.8.0 or later<br>- rsa4.0 or later|haneWIN NFS Server 1.2.50 or later, or NFS v4 or later| 1.1.0 or later|
|Description|Provides code build environment.|Plug-in used to read commands.|Language used by the test framework.|- pySerial: supports Python serial port communication. <br>- Paramiko: allows Python to use SSH. <br>- Setuptools: allows Python packages to be created and distributed easily. <br>- rsa: implements RSA encryption in Python.|Enables devices to be connected through the serial port.| A tool that enables devices to be connected through the HarmonyOS Device Connector (HDC).|
## Installation Process
1. Run the following command to install the Linux extended component libreadline:
...
...
@@ -21,7 +21,7 @@
libreadline-dev is already the newest version (7.0-3).
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
```
2. Run the following command to install the setuptools plug-in:
2. Run the following command to install the Setuptools plug-in:
```
pip3 install setuptools
```
...
...
@@ -29,7 +29,7 @@
```
Requirement already satisfied: setuptools in d:\programs\python37\lib\site-packages (41.2.0)
```
3. Run the following command to install the paramiko plug-in:
3. Run the following command to install the Paramiko plug-in:
```
pip3 install paramiko
```
...
...
@@ -47,7 +47,7 @@
Installing collected packages: pyasn1, rsa
Successfully installed pyasn1-0.4.8 rsa-4.7
```
5. Run the following command to install the pyserial plug-in:
5. Run the following command to install the pySerial plug-in:
```
pip3 install pyserial
```
...
...
@@ -80,4 +80,4 @@
| Check whether Python is installed successfully.|Run the **python --version** command.|The Python version is 3.7.5 or later.|
| Check whether Python plug-ins are successfully installed.|Go to the **test/developertest** directory and run **run.bat** or **run.sh**.| The **>>>** prompt is displayed.|
|Check the NFS server status (for the devices that support only serial port output).|Log in to the development board through the serial port and run the **mount** command to mount the NFS.|The file directory can be mounted.|
|Check whether the HDC is successfully installed.|Run the **hdc_std -v** command.|The HDC version is 1.1.0 or later.|
|Check whether the HDC tool is successfully installed.|Run the **hdc_std -v** command.|The HDC version is 1.1.0 or later.|
- The expected result of each test case must have an assertion.
- The test case level must be specified.
- It is recommended that the test be implemented step by step according to the template.
- The comment must contain the test case name, description, type, and requirement number. The test case description must be in the @tc.xxx format. The test case type @tc.type can be any of the following:
- The comment must contain the test case name, description, type, and requirement number, which are in the @tc.xxx: value format. The test case type @tc.type can be any of the following:
| Test Case Type|Function test|Performance test|Reliability test|Security test|Fuzz test|
>- **target_name** indicates the test suite name defined in the **BUILD.gn** file in the **test** directory.
>- **preparer** indicates the action to perform before the test suite is executed.
>- **src="res"** indicates that the test resources are in the **resource** directory under the **test** directory.
>- **src="out"** indicates that the test resources are in the **out/release/$(component)** directory.
>- **src="out"** indicates that the test resources are in the **out/release/$(part)** directory.
## Executing Test Cases
Before executing test cases, you need to modify the configuration based on the device used.
...
...
@@ -730,7 +730,7 @@ When the build is complete, the test cases are automatically saved in the **out/
3. Modify the **user_config.xml** file.
```
<build>
<!-- Because the test cases have been built, change the value to false -->.
<!-- Because the test cases have been built, change the value to false. -->
<testcase>false</testcase>
</build>
<test_cases>
...
...
@@ -757,16 +757,16 @@ When the build is complete, the test cases are automatically saved in the **out/
```
In the command:
```
-t [TESTTYPE]: specifies the test case type, which can be UT, MST, ST, or PERF. This parameter is mandatory.
-tp [TESTTYPE]: specifies a part, which can be used independently.
-tm [TESTTYPE]: specifies a module. This parameter must be specified together with -tp.
-ts [TESTTYPE]: specifies a test suite, which can be used independently.
-tc [TESTTYPE]: specifies a test case. This parameter must be specified together with -ts.
-t [TESTTYPE]: specifies the test type, which can be UT, MST, ST, or PERF. This parameter is mandatory.
-tp [TESTPART]: specifies the part to test. This parameter can be used independently.
-tm [TESTMODULE]: specifies the module to test. This parameter must be specified together with -tp.
-ts [TESTSUITE]: specifies the test suite. This parameter can be used independently.
-tc [TESTCASE]: specifies the test case. This parameter must be specified together with -ts.
You can run -h to display help information.
```
### Executing Test Cases on Linux
#### Mapping Remote Port
To enable test cases to be executed on a remote Linux server or a Linux VM, map the port to enable communication between the device and the remove server or VM. Configure port mapping as follows:
To enable test cases to be executed on a remote Linux server or a Linux VM, map the port to enable communication between the device and the remote server or VM. Configure port mapping as follows:
1. On the HDC server, run the following commands:
```
hdc_std kill
...
...
@@ -797,11 +797,11 @@ To enable test cases to be executed on a remote Linux server or a Linux VM, map
```
In the command:
```
-t [TESTTYPE]: specifies the test case type, which can be UT, MST, ST, or PERF. This parameter is mandatory.
-tp [TESTTYPE]: specifies a part, which can be used independently.
-tm [TESTTYPE]: specifies a module. This parameter must be specified together with -tp.
-ts [TESTTYPE]: specifies a test suite, which can be used independently.
-tc [TESTTYPE]: specifies a test case. This parameter must be specified together with -ts.
-t [TESTTYPE]: specifies the test type, which can be UT, MST, ST, or PERF. This parameter is mandatory.
-tp [TESTPART]: specifies the part to test. This parameter can be used independently.
-tm [TESTMODULE]: specifies the module to test. This parameter must be specified together with -tp.
-ts [TESTSUITE]: specifies the test suite. This parameter can be used independently.
-tc [TESTCASE]: specifies the test case. This parameter must be specified together with -ts.
OpenHarmony provides LiteOS and Linux for different levels of systems. LiteOS applies to mini and small systems. Linux applies to small and standard systems.
OpenHarmony LiteOS is a real-time OS kernel developed for IoT devices. It boasts lightweight features as the real-time operating system (RTOS) and is easy-to-use like Linux.
LiteOS provides basic kernel functions, such as process and thread scheduling, memory management, inter-process communication (IPC), and timer management.
The LiteOS source code is stored in **kernel\\_liteos\\_a** and **kernel\\_liteos\\_m** repositories. The **kernel\\_liteos\\_a** repository stores kernel code for small and standard systems. The **kernel\\_liteos\\_m** repository stores kernel code for mini systems. This document describes the **kernel\\_liteos\\_a** repository. Figure 1 shows the architecture of OpenHarmony LiteOS-A.
Evolved from the open-source Linux kernel LTS 4.19.y and 5.10.y, the OpenHarmony Linux kernel has incorporated CVE patches and OpenHarmony features as the OpenHarmony common kernel baseline. Vendors can complete the kernel adaptation by applying the driver patches for boards.
For more information about Linux LTS 4.19.y, visit the [official kernel website](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-4.19.y).
For more information about Linux LTS 5.10.y, visit the [official kernel website](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.10.y).
During the build process, you can merge the driver code based on the chip platform and build the kernel image. All patches are licensed under GNU General Public License (GPL) 2.0.
By default, the Hi3518E V300 uses the JFFS2 file system, and Hi3516D V300 uses the FAT file system. Adaptation must be performed if you want to use other file systems.
## Usage<a name="section1393789267"></a>
### LiteOS<a name="section118811457303"></a>
For details, see "Usage" in LiteOS-A Kernel [README](https://gitee.com/openharmony/kernel_liteos_a/blob/master/README.md) and LiteOS-M Kernel [README](https://gitee.com/openharmony/kernel_liteos_m/blob/master/README.md).
### Linux<a name="section1352114469620"></a>
1. Apply HDF patches.
Apply the HDF kernel patches matching your kernel version. For details, see the method in **kernel.mk** in the **kernel/linux/build** repository.
Place the patches for the chip component in the corresponding path based on the path and naming rules for the patches of the chip component in **kernel.mk** in the **kernel/linux/build** repository.
Place the **config** file for the chip component in the corresponding path based on the path and naming rules of the chip component in **kernel.mk** in the **kernel/linux/build** repository.
>In the OpenHarmony project build process, patches are installed after **kernel/linux/linux-\*\.\*** is copied. Before using the version-level build command of OpenHarmony, ensure that the **kernel/linux/linux-\*\.\*** source code is available.
>
>The kernel built is generated in the **kernel** directory under the **out** directory. Modify the **config** file based on the kernel built, and copy the generated **.config** file to the corresponding path in the **config** repository. Then, the configuration takes effect.
## Build<a name="section19369206113115"></a>
The following uses the Hi3516D V300 development board and Ubuntu x86 server as an example.
Perform a full build for the project to generate the **uImage** kernel image.
```
./build.sh --product-name Hi3516DV300 # Build the Hi3516D V300 image.
--build-target build_kernel # Build the uImage kernel image of Hi3516D V300.
--gn-args linux_kernel_version=\"linux-5.10\" # Build the specified kernel version.
