diff --git a/en/device-dev/overview.md b/en/device-dev/Readme-EN.md similarity index 90% rename from en/device-dev/overview.md rename to en/device-dev/Readme-EN.md index d8e511406ec63d9d17428a53e7ad9e60cf1a6448..cc51cf1ea93730d8daa02f6fe6964832566e65ee 100644 --- a/en/device-dev/overview.md +++ b/en/device-dev/Readme-EN.md @@ -1,4 +1,4 @@ -# Overview +# Overview - [System Types](#section767218232110) - [Document Outline](#section19810171681218) @@ -69,21 +69,21 @@ In addition, OpenHarmony provides a series of optional system components that ca

Using basic capabilities of OpenHarmony

- +

Advanced development

Developing smart devices based on system capabilities

- +

Porting and adaptation

- +

Contributing components

@@ -114,9 +114,9 @@ In addition, OpenHarmony provides a series of optional system components that ca -

About OpenHarmony

+

About OpenHarmony

-

Getting familiar with OpenHarmony

+

Getting familiar with OpenHarmony

@@ -137,28 +137,29 @@ In addition, OpenHarmony provides a series of optional system components that ca

Basic capabilities

-

Using basic capabilities of OpenHarmony

+

Using basic capabilities of OpenHarmony

- +

Advanced development

Developing smart devices based on system capabilities

- +

Porting and adaptation

Porting and adapting the OpenHarmony to a third-party library

-

Third-Party Library Porting Guide

+

Third-Party Library Porting Guide

+

Standard System SoC Porting Guide

Contributing components

-

Contributing components to OpenHarmony

+

Contributing components to OpenHarmony

diff --git a/en/device-dev/bundles/bundles-demo-devsample.md b/en/device-dev/bundles/bundles-demo-devsample.md index 4b896d4811456deb410fab4abbab7baac6e2493c..51b24597883c985b44ce7f06c8f17db36ebeec77 100644 --- a/en/device-dev/bundles/bundles-demo-devsample.md +++ b/en/device-dev/bundles/bundles-demo-devsample.md @@ -1,25 +1,25 @@ # Development Example -This following uses the Hi3861 platform as an example to describe how to install, compile, and package components by using HPM. +The following uses the Hi3861 platform as an example to describe how to install and build bundles by using the hpm. -1. Run the following commands to initialize the installation directory \(whose name can be customized\): +1. Run the following commands to create a directory \(its name can be customized\) and create a default project based on the dist template: ``` mkdir test3861 cd test3861 - hpm init -t dist + hpm init -t dist myproduct ``` - If the following information is displayed, the initialization is successful: + If the following information is displayed, the project is created: ``` Initialization finished. ``` -2. Run the following command to install the **wifi\_iot** distribution: +2. Run the following command to install the **hispark\_pegasus** distribution: ``` - hpm install @ohos/wifi_iot + hpm install @ohos/hispark_pegasus ``` If the following information is displayed, the installation is successful: @@ -29,16 +29,16 @@ This following uses the Hi3861 platform as an example to describe how to install ``` >![](../public_sys-resources/icon-note.gif) **NOTE:** - >Run the following command for the Hi3516 platform: + >If you are using the Hi3516 platform, run the following command: >``` - >hpm install @ohos/ip_camera_hi3516dv300 + >hpm install @ohos/hispark_taurus >``` - >Run the following command for the Hi3518 platform: + >If you are using the Hi3518 platform, run the following command: >``` - >hpm install @ohos/ip_camera_hi3518ev300 + >hpm install @ohos/hispark_aries >``` -3. Run the following command to build and package components: +3. Run the following command to build and package bundles: ``` hpm dist diff --git a/en/device-dev/bundles/bundles-demo-environment.md b/en/device-dev/bundles/bundles-demo-environment.md index 6780aa705ee1b918dd9f6d748c286b0deae34476..ac3cbf3b0b19c60d50d847b7cbe03e767663790e 100644 --- a/en/device-dev/bundles/bundles-demo-environment.md +++ b/en/device-dev/bundles/bundles-demo-environment.md @@ -1,15 +1,17 @@ -# Preparations +# Configuring the Compilation Environment - [Linux Server](#section20979554791) - [Node.js](#section9954105413153) -- [HPM](#section15937194904819) +- [Installing hpm-cli Tool](#section15937194904819) - [Python Environment](#section1621819180417) - [File Packaging Tool](#section77617165913) - [SCons](#section20558439191516) +![](figure/3516dv300.png) + ## Linux Server -Prepare a 64-bit Linux server running Ubuntu 16.04 or later. HPM supports Windows Server, but the open-source Hi3861, Hi3516, and Hi3518 solutions support only Ubuntu. +Prepare a 64-bit Linux server running Ubuntu 16.04 or later. \(Currently, the compilation in the Windows environment is not fully supported.\) Configure Ubuntu to use bash as the Linux system shell, by performing the following: @@ -26,7 +28,7 @@ ln -s bash /bin/sh ## Node.js >![](../public_sys-resources/icon-note.gif) **NOTE:** ->If the Node.js version of the source is outdated, run the following command before running **apt-get install**: +>If the **Node.js** version of the source is outdated, run the following command before running **apt-get install**: >``` >curl -L https://deb.nodesource.com/setup_12.x | bash >``` @@ -38,31 +40,31 @@ sudo apt-get install nodejs sudo apt-get install npm ``` -Run the following commands to view Node.js and NPM versions: +Run the following commands to view **Node.js** and npm versions: ``` node --version # Check the Node.js version. -npm --version # Check the NPM version. +npm --version # Check the npm version. ``` -## HPM +## Installing hpm-cli Tool -Install the **hpm-cli** command line tool by using the NPM \(default source: https://registry.npmjs.org/\) provided by the Node.js. +Install the **hpm-cli** command line tool by using the npm \(default source: https://registry.npmjs.org/\) provided by **Node.js**. ``` npm install -g @ohos/hpm-cli ``` -After **hpm-cli** is installed, run the following command to view default HPM configurations: +After **hpm-cli** is installed, run the following command to view the default hpm configurations: ``` hpm config ``` -You can modify the default configurations as required. The following lists common HPM configurations: +You can modify the default configurations as required. The following lists common hpm configurations: ``` -registry = https://hpm.harmonyos.com # Register with the HPM registration center. This is mandatory for downloading components. +registry = https://hpm.harmonyos.com # Address of the hpm registry. This is mandatory for downloading bundles. strictSsl = true # Enable strict SSL verification as HTTPS is used for connection. http_proxy = http://your-proxy-server:port # Configure the HTTP proxy. https_proxy = http://your-proxy-server:port # Configure the HTTPS proxy. @@ -124,14 +126,14 @@ sudo apt-get install mtools python3 -m pip install scons ``` -3. Run the following command to check whether SCons is successfully installed. If the installation is successful, the query result as shown in [Figure 1](#fig235815252492) is displayed. +3. Run the following command to check whether SCons is successfully installed. If the installation is successful, the query result shown in [Figure 1](#fig235815252492) is displayed. ``` scons -v ``` **Figure 1** Successful installation \(SCons version requirement: 3.0.4 or later\) - ![](figure/successful-installation-(scons-version-requirement-3-0-4-or-later)-25.png "successful-installation-(scons-version-requirement-3-0-4-or-later)-25") + ![](figure/successful-installation-(scons-version-requirement-3-0-4-or-later)-28.png "successful-installation-(scons-version-requirement-3-0-4-or-later)-28") >![](../public_sys-resources/icon-note.gif) **NOTE:** diff --git a/en/device-dev/bundles/bundles-demo-hpmdescription.md b/en/device-dev/bundles/bundles-demo-hpmdescription.md index a4ce85e870790e39e703212351167a84fc652166..da9a147ee4ba26955b73bb9ad8fec5e49b155c71 100644 --- a/en/device-dev/bundles/bundles-demo-hpmdescription.md +++ b/en/device-dev/bundles/bundles-demo-hpmdescription.md @@ -1,6 +1,6 @@ # Introduction -HarmonyOS Package Manager \(HPM\) manages and distributes OpenHarmony component packages. It offers you a tool set to obtain and customize OpenHarmony source code and perform operations such as installation, compilation, packaging, and upgrade. +HarmonyOS package manager \(hpm\) manages and distributes OpenHarmony bundles. It offers you a tool set to obtain and customize OpenHarmony source code and perform operations such as installation, building, packaging, and upgrade. -This document describes how to use HPM to install, compile, and package OpenHarmony components. +This document describes how to use the hpm to install, build, and package OpenHarmony bundles. diff --git a/en/device-dev/bundles/bundles-demo.md b/en/device-dev/bundles/bundles-demo.md index 846d6b1bde058051ef3212edb3596a2d7ec22396..b4ba3900262b936883a748ddfd385b6464de26e0 100644 --- a/en/device-dev/bundles/bundles-demo.md +++ b/en/device-dev/bundles/bundles-demo.md @@ -2,7 +2,7 @@ - **[Introduction](bundles-demo-hpmdescription.md)** -- **[Preparations](bundles-demo-environment.md)** +- **[Configuring the Compilation Environment](bundles-demo-environment.md)** - **[Development Example](bundles-demo-devsample.md)** diff --git a/en/device-dev/bundles/bundles-guide-develop.md b/en/device-dev/bundles/bundles-guide-develop.md index d7f0fdad1f664ab9f46ffbee7f40e07ae024dffb..a562a010d592217e9264cad36d5d1a36ee507893 100644 --- a/en/device-dev/bundles/bundles-guide-develop.md +++ b/en/device-dev/bundles/bundles-guide-develop.md @@ -1,130 +1,234 @@ -# Bundle Development +# Developing Bundles -- [Developing OpenHarmony Bundles](#section1976410130540) - [Creating a Bundle](#section717481119145) -- [Modifying a Bundle](#section102861955201410) -- [Using HPM-provided Template to Create a Bundle](#section15882846181510) -- [Building a Bundle](#section136732148541) -- [Defining the Building Script](#section10274147111610) -- [Executing the Building Script](#section879301916172) +- [Defining an Existing Project as a Bundle](#section102861955201410) +- [Releasing the Bundle on the HPM Platform](#section1318574233211) +- [Referencing a Bundle](#section19311124115315) +- [Installing a Bundle Globally](#section165131927192120) +- [Compiling a Bundle](#section136732148541) +- [Defining the Build Script](#section10274147111610) +- [Executing the Build Script](#section879301916172) - [Defining a Distribution](#section413216495619) - [Defining Scripts](#section11503171219190) -- [Distributing](#section4694125521912) -- [Burning](#section1746331545413) -- [Debugging](#section6742131615549) +- [Building a Distribution](#section4694125521912) -## Developing OpenHarmony Bundles +You can use any of the following methods to develop OpenHarmony bundles: -You have an option to use any of the following methods to develop OpenHarmony bundles: - -- Develop a brand new bundle from scratch. -- Rewrite code of an existing non-bundle to develop a bundle. -- Use HPM-provided bundle templates to quickly develop a bundle. +- Create a new bundle from scratch. +- Define an existing source code project as a bundle. ## Creating a Bundle -Generally, you can find commonly used bundles on the [HPM](https://hpm.harmonyos.com/#/en/home) website. If they cannot meet your requirements, you can develop your own bundles. +Generally, you can find commonly used bundles on the [HPM](https://hpm.harmonyos.com/#/en/home) website. If they cannot meet your requirements, you can develop a bundle on your own. -You can publish bundles in the HPM repository if you like, so that your peers have an option to use them. Assume that you want to create a bundle named **my-bundle** in the **D:/source** directory: +You can publish bundles in the HPM repository if you like, so that your peers have an option to use them. -Run the **hpm init** command to create the scaffold code for this bundle. For example, you can go to the **D:/source** directory and run the following command: +Assume that you are planning to create a new bundle **my-bundle** in **D:/source**. Run the **hpm init** command to create the scaffold code for this bundle. For example, you can go to **D:/source** and run the following command: ``` -hpm init -t default -d demo my-bundle +hpm init -t default -d demo mybundle ``` -The following files are generated in the **source** directory: +The **'default'** template will be used to create a bundle named **mybundle** in the **demo** directory in **D:/source**. ``` -mybundle -├── bundle.json # Metadata description file of the bundle -├── example # Example of testing bundle functions -│ └── main.c -├── include # Internal header files of the bundle -│ └── mybundle.h -├── README.md # Brief description of the bundle -└── src # Source code of the bundle - └─ mybundle.c +demo +├── headers # Header file (example) +│ └── main.h +└── src # Source code (example) +│ └─ main.c +├── bundle.json # Metadata declaration file +└── LICENSE # License agreement +└── Makefile # Compilation description file (example) +└── README.md # Readme file + ``` -Then, complete your coding based on service requirements. Finally, use **git** to commit your code \(including the **bundle.json** file\) to the code hosting repository, such as gitee. +Then, complete your coding based on service requirements and generate the build script. Finally, use **git** to commit your code \(including the **bundle.json** file\) to the code hosting repository, such as gitee. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>``` +>hpm init -t {templatename} -d {dir} {name} +>``` +>- **-t \{templatename\}** indicates the template name. +>- **-d \{dir\}** indicates the path for storing the bundle to be created. +>- **name** indicates the name of the bundle to be created. + +The hpm provides a few default templates. More templates are available on the HPM server. You can run the **hpm search -t template** command to search for a template stored on the server. + +![](figure/en-us_image_0000001134127844.png) -## Modifying a Bundle +## Defining an Existing Project as a Bundle -If you have code unqualified for the OpenHarmony bundle structure, modify your code to match an HPM bundle. In the code directory \(for example, **mybundle2**\) storing your code, run the following command with the bundle name and version specified: +If you have a code project and need to distribute it on the HPM platform, run the following command in the current project directory, for example, **mybundle2**: ``` hpm init ``` 1. Enter a bundle name \(**mybundle2** as an example\) and press **Enter**. -2. Enter the bundle version \(**1.0.0** as an example\) and press **Enter**. A **bundle.json** file is generated in the current bundle directory. -3. Add other descriptions in **bundle.json**, which is publishable. +2. Enter the version and description. A **bundle.json** file will be generated in the current directory. +3. Open the** bundle.json** file as you like. ``` $ hpm init - Your bundle will be created in dirname E:\demo\mybundle2 + Your bundle will be created in directory ~\demo\mybundle2 ? bundle name mybundel2 ? version 1.0.0 - Init finished! + ... + Initialization finished. ``` -1. Modify other information \(such as the author, code repository, code directory, command script, and dependent bundles\) in **bundle.json**. +1. Modify other information \(such as the author, code repository, code directory, command script, and dependent bundles\) in **bundle.json**. An example is shown below: ``` { "name": "mybundle2", "version": "1.0.0", - "publishAs": "source", + "publishAs": "code-segment", "dirs":{ - ".":[ - "README.md" - ], - "src":[ - "test.c" - ], - "header":[ - "header/test.h" - ], - "src/common":[ - "src/common/foobar.txt" - ] + ".":["README.md"], + "src":["test.c"], + "header":["header/test.h" ], + "src/common":["src/common/foobar.txt"] }, "scripts": { - "build": "make -${args}" + "build": "make -${args}" }, "dependencies": { - "@ohos/cjson": "^1.0.0", - "@ohos/": "^1.2.0" + "@ohos/cjson": "^1.0.0", + "@ohos/foobar": "^1.2.0" } } ``` -## Using HPM-provided Template to Create a Bundle +## Releasing the Bundle on the HPM Platform + +To release a bundle on the HPM platform, you need to obtain an account and create an organization \(or join an existing organization\). For details, see the online help on the [HPM](https://hpm.harmonyos.com/#/en/home) website. + +After that, generate a public key on the local PC based on your invitation code \(which can be obtained on the **My profile** page on the HPM website\), and configure the public key on the **My profile** page. + +``` +hpm config set loginUser {your-invitation-code} +hpm gen-keys +``` + +The generated file will be stored in **\~\\Users\\yourname\\.hpm\\key**. Copy the content in the public key file **publicKey\_your-account.pem** to the SSH public key on your **My profile** page. + +After finishing the preceding operations, you then have the permission to release bundles in your organization. + +In the directory where the bundle is located, run the following command to package and release the bundle: + +``` +hpm publish +``` + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- To avoid bundle name conflicts, name a released bundle in the format of **@org\_name/bundle\_name**. +>- Your account must also be a member of **org\_name** so that you can release or update bundles in the organization. +>- The released bundles take effect only after security and content reviews. + +## Referencing a Bundle + +Generally, when developing a project, you may need to reference other bundles in order to accelerate development of specific functions. Installing dependencies could be a good way. + +Go to the HPM website, search for bundles that meet your service requirements by keywords, and then introduce the bundles to your project. -The HPM provides **default** and **simple** templates as well as other templates that are stored on the server. +Run the following command in your bundle project. Make sure that the project directory contains the **bundle.json** file. -You can run the **hpm search -t template** command to search for a template stored on the server. +``` +$ hpm install @scope/the_bundle +``` + +The referenced bundle will be installed under **ohos\_bundle** in the directory where your project is located. The directory structure is as follows: + +``` +project +├── ohos_bundle +│ └── scope +│ └─ the_bundle # <--- Referenced bundle +└── src +│ └─ main.c +├── bundle.json # Metadata declaration file +└── LICENSE +└── Makefile +└── README.md +``` -![](figure/en-us_image_0000001051452177.png) +Open the **bundle.json** file. You will see that the bundle has been introduced to the dependencies of your project. + +``` +{ +"dependencies": { + "@scope/the_bundle": "^1.0.0" + } +} +``` -Then, select your desired template based on the information below **description**, use the selected template to quickly create the bundle scaffold, and run the following command with the **-t** and **-d** parameters specified: +You can also edit the dependencies of multiple bundles in this file at a time. ``` -hpm init -t {templatename} -d dir name +{ +"dependencies": { + "@scope/the_bundle1": "^1.0.0", + "@scope/the_bundle2": "^2.0.0", + "@scope/the_bundle3": "^3.0.0", + "@scope/the_bundle4": "^1.1.0" + } +} ``` -- **\{templatename\}** indicates the template name. -- **dir** indicates the path for storing the bundle to be created. -- **name** indicates the name of the bundle to be created. +Run the **hpm install** command again to download and install all bundles that have not been installed. + +## Installing a Bundle Globally -## Building a Bundle +If the referenced bundle is one shared by multiple projects, for example, the compiler toolchain, you can install it globally. -After completing code development, you need to build the bundle. The HPM supports command integration so that you can select any build tool \(such as **make**, **gcc**, and **gn**\) suitable for your project. You only need to define the **build** command in the **scripts** in the **bundle.json** file of your project, and then you run the hpm command **build** to perform building. +Run the following command in your bundle project. Make sure that the project directory contains the **bundle.json** file. -## Defining the Building Script +``` +$ hpm install -g @scope/the_tool +``` + +The referenced bundle will be installed in the directory specified by the **globalRepo** parameter of the **hpm config** command. + +``` +~\.hpm\global +│ └── scope +│ └─ the_tool # <--- Referenced bundle +``` + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- For a bundle installed in a project, you can reference it using the environment variable **DEP\_SCOPE\_bundle\_name** when running the hpm compilation command. +>For example, after you run **hpm i @opensource/gn** to install a bundle, you can edit the build script in the **bundle.json** file as follows: +>``` +>"scripts": { +> "build": "${DEP_OPENSOURCE_gn}/gn --version" +> }, +>``` +>Then, you can run the **hpm build** command to call GN functions. +>- For a globally installed bundle, you can directly call the bundle using an environment variable or reference the bundle using the **$\{key\}/tool\_name** parameter when running the **hpm config set key value** command. For example: +>``` +>hpm i -g @ohos/opensource/gn +>hpm config BUILD_SYS_GN ~/.hpm/global/ohos_bundles/opensource/gn +>``` +>You can edit the build script in the **bundle.json** file as follows: +>``` +>"scripts": { +> "build": "${BUILD_SYS_GN}/gn --version" +> }, +>``` +>Then, you can run the **hpm build** command to call GN functions. + +## Compiling a Bundle + +If the bundle code can be independently compiled once you finish coding, you can configure build tools and scripts to generate binary files. + +The hpm supports command integration so that you can select any build tool \(such as **make**, **gcc**, and **gn**\) suitable for your project. You only need to define the **build** command in the **scripts** in the **bundle.json** file of your project, and then you run the hpm command **build** to perform building. + +## Defining the Build Script This section uses how to build an executable file **helloworld** in the **app** directory as an example. @@ -162,7 +266,7 @@ executable("hello_world") { >- **executable** is a built-in template of **gn**. You can run the **gn help executable** command to view how to use this template. >- **sources** represents the source code path, and **include\_dirs** represents the header file path. -## Executing the Building Script +## Executing the Build Script Run the following command: @@ -176,41 +280,87 @@ After all building operations are complete, the message "build succeed" is displ ## Defining a Distribution -A distribution refers to an image file of an executable OpenHarmony solution composed of a group of bundles. It contains many dependent bundles and provides scripts to illustrate how to compile and link these bundles. +This process states the dependent bundles and how to compile and link the bundles to generate image files. + +This section uses the hb compilation framework as an example. ## Defining Scripts -Define scripts in **bundle.json** as follows: +An example definition in the **bundle.json** file is as follows: + +\{ + +"name": "@your/dist\_name", + +"version": "2.2.0", -``` -{ -"name": "my_dist", -"version": "1.0.0", "publishAs": "distribution", -"scripts": { -"dist": "make -${args}" - }, -"base": { -"name": "dist-bundle", -"version": "1.0.0" - }, -"envs": { -"args": "x86" - }, -"dependencies": { -} -} -``` -## Distributing +"description": "describe it", + +"scripts": \{ + +"config\_hb": "hb set -root $DEP\_BUNDLE\_BASE", + +"dist": "PATH=/root/.local/bin:$\{DEP\_OHOS\_gn\}:$\{DEP\_OHOS\_ninja\}/ninja:$\{DEP\_OHOS\_llvm\}/llvm/bin:$\{DEP\_OHOS\_hc\_gen\}/hc-gen:$\{PATH\} && ./scripts/dist.sh" + +\}, + +"envs": \{ + +"debug": false + +\}, + +"dirs": \{ + +"scripts": "scripts/\*" -Run the following command in the current distribution directory: +\}, + +"dependencies": \{ + +"@ohos/build\_lite": "2.2.0", + +"@ohos/gn": "1.1.1", + +"@ohos/llvm": "1.1.1", + +"@ohos/hc\_gen": "1.1.0", + +"@ohos/ninja": "1.1.0", + +... + +\}, + +"ohos": \{ + +"os": "2.2-Beta", + +"board": "hi3516", + +"kernel": "liteos-a" + +\}, + +"keywords": \[ "hispark", "hi3516" \], + +"repository": "https://gitee.com/openharmony/your-project", + +"license": "Apache V2" + +\} + +## Building a Distribution + +Run the following command in the root directory of the current distribution: ``` hpm dist ``` -The **hpm-cli** tool automatically performs compiling and packing, and generates an image file of the **dist** script defined based on **scripts**. The following is an example: +The **hpm-cli** tool automatically starts compilation. After the compilation is complete, an image file will be generated, as shown below: ``` out @@ -218,23 +368,23 @@ out |-xx.file ``` -## Burning +Burning -The building result of the distribution can be burnt into devices, for example, by using the **hiburn** tool. You need to configure burning parameters in the **bundle.json** file of the distribution. +The build result of the distribution can be burnt into devices, for example, by using the **hiburn** tool. You need to configure burning parameters in the **bundle.json** file of the distribution. ``` "scripts": { -"flash": "{$DEP_HIBURN}/hiburn" + "flash": "{$DEP_HIBURN}/hiburn" }, ``` -You should set burning parameters by referring to the specific guide on the burning tool you use. +Set the path of the **hiburn** tool and set burning parameters. For details, see the **hiburn** tool guide. ``` +hpm config set DEP_HIBURN {hiburn_path} hpm run flash ``` -## Debugging - -Start debugging after you have burnt the image file of the distribution into devices. The debugging process varies according to specific development boards and IDE debugging tools. +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>The preceding example describes only how to define the **bundle.json** file. The burning tool is subject to the actual development board. diff --git a/en/device-dev/bundles/bundles-guide-overview.md b/en/device-dev/bundles/bundles-guide-overview.md index a6d16e00da5e950294612bc72454fe531fa3bbdf..445312c962065ba5fc1a8f06e90f89dc1505caab 100644 --- a/en/device-dev/bundles/bundles-guide-overview.md +++ b/en/device-dev/bundles/bundles-guide-overview.md @@ -1,146 +1,41 @@ -# Bundle Development - -- [Overview](#section112136415486) -- [Preparations](#section12731192104816) - - [Hardware Requirements](#section71851750144814) - - [Installing Node.js and the hpm-cli Tool](#section675199493) - - [\(Optional\) Modifying HPM Configurations](#section1940205015499) - - [Downloading OpenHarmony Code](#section42591118155217) - - [Installing Dependent Bundles](#section644212530524) +# Overview -- [Bundle Development](#section15640113715318) +- [Bundle](#section196713235514) +- [Distribution](#section155387501033) -## Overview +This section describes the bundle-specific concepts in HarmonyOS. It uses an example to step you through how to create, develop, build, release, and install a bundle using the **hpm-cli** tool. -This document describes how to develop OpenHarmony bundles and distributions, and how to create, develop, and build code, as well as burn and debug devices by using a command line tool. +## Bundle -- A bundle usually maps onto a code repository, which is a code archive with the **bundle.json**, **README**, and **LICENSE** files. -- A distribution consists of multiple bundles. Each distribution integrates various bundles of a comprehensive system, such as the driver, kernel, framework, and applications. These bundles can be used for device burning. +A bundle is a term used in HarmonyOS to indicate a distribution. A bundle is equivalent to a package and it usually contains the following contents: -**Table 1** Differences between a bundle and a distribution +- Distributed binary file \(binary type\) +- Distributed source code file \(source code/code snippet type\) +- Build script \(distribution type\) +- Bundle description files: + - **bundle.json**: metadata declaration \(name, version, dependency, etc.\) + - **LICENSE**: license agreement + - **README.md**: readme file + - **CHANGELOG.md**: change log \(optional\) - - - - - - - - - - - - - - - - - - - - - - - -

Aspect

-

Bundle

-

Distribution

-

Application scenario

-

Feature-oriented

-

System-oriented

-

Content

-

Codes or a binary library for implementing features

-

List of dependent bundles as well as their compiling and building scripts

-

Integrity

-

A part of the operating system

-

An entire operating system

-

Compilation result

-

Bundles

-

System image

-
-**Figure 1** Composition of bundles and distributions +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>Bundles can be classified into the following types: binary, source code, code snippet, template, plug-in, distribution, and so on. A bundle can depend on other bundles. The dependency relationship can be represented by a directed acyclic graph \(DAG\). +After you release a bundle on the [HPM](https://hpm.harmonyos.com/#/en/home) platform, other developers can download, install, and use the bundle through the HarmonyOS Package Manager \(hpm\). -![](figure/组件0924.png) +A bundle must be uniquely named in the format **@scope/name** in the namespace. Independent evolution is supported for each bundle. -## Preparations +## Distribution -### Hardware Requirements +A distribution is a complete HarmonyOS release that integrates various bundles, including drivers, kernels, frameworks, and applications. A distribution can also be distributed on the [HPM](https://hpm.harmonyos.com/#/en/home) platform through bundles. -- Development boards \(examples: Hi3861, Hi3516D V300, and Hi3518E V300\) -- Host computer \(Windows workstation\) -- Linux server +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>The metadata of a distribution describes only the dependent bundles and build script compilation methods. It does not cover binary images of the distribution. When downloading a distribution, you also need to download the dependent bundles. You can obtain the system image file for burning only after finishing installation and compilation. +>A distribution is inheritable. Specifically, you can add bundles to or delete bundles from an existing distribution to create your own distribution. -**Figure 2** Hardware connections -![](figure/hardware-connections-23.png "hardware-connections-23") +**Figure 1** Relationship between bundles and a distribution -### Installing **Node.js** and the **hpm-cli** Tool -1. Install **Node.js**. - - Download **Node.js** from its official website and install it on your local PC. - - You are advised to install [Node.js](https://nodejs.org/) 12.x \(including npm 6.14.4\) or a later version \(12.13.0 or later is recommended\). - -2. Install the **hpm-cli** tool using **npm** delivered with **Node.js**. Run the following command: - - ``` - npm install -g @ohos/hpm-cli - ``` - -3. Run the following command to check whether the installation is successful. If an HPM version is displayed, the installation is successful. - - ``` - hpm -V or hpm --version - ``` - -4. \(Optional\) Run the following command to upgrade the HPM version if needed: - - ``` - npm update -g @ohos/hpm-cli - ``` - - -### \(Optional\) Modifying HPM Configurations - -After the **hpm-cli** tool is installed, run the following command to view HPM configurations: - -``` -hpm config -``` - -Default HPM configurations are displayed upon the command execution. You can modify the default configurations as required. The following lists common HPM configurations: - -``` -registry = https://hpm.harmonyos.com/hpm/registry/api # Configure the address of the HPM registry (mandatory for downloading bundles). -login = https://hpm.harmonyos.com/hpm/auth/pk # Configure the address for HPM login (mandatory for publishing bundles). -loginUser = {your-account} # Configure the account for HPM login (mandatory for publishing bundles). -shellPath = C:\WINDOWS\System32\cmd.exe # Configure the shell for running HPM commands. -globalRepo = C:\Users\yourname\.global # Configure the path for storing bundles that are installed globally. -http_proxy = http://your-proxy-server:port # Configure the HTTP proxy. -https_proxy = http://your-proxy-server:port # Configure the HTTPS proxy. -``` - -For details about **hpm-cli** commands, see [HPM Commands](bundles-guide-overview.md). - -### Downloading OpenHarmony Code - -For details, see [Source Code Acquisition](../get-code/sourcecode-acquire.md). - -### Installing Dependent Bundles - -The HPM publishes commonly used development tools \(such as those for burning, compiling, and compression\) as bundles. You can run the following command to install these tools. After the command is executed, the system automatically downloads and installs the tools, which need to be installed globally only once. - -``` -hpm i -g @ohos/llvm -hpm i -g @ohos/ninja -hpm i -g @ohos/gn -hpm i -g @ohos/hc_gen -hpm i -g @ohos/sysroot -``` - -These are a set of development tools \(such as **gn** and **ninja**\). With these tools, you can start your general bundle development based on source code. - -## Bundle Development +![](figure/组件和发行版的构成-英文.png) diff --git a/en/device-dev/bundles/bundles-guide-prepare.md b/en/device-dev/bundles/bundles-guide-prepare.md index f706e2c2f8ebf2c8307e60a5595d53eb9799d1c1..865279a0f1c34462045c70f2d405cd468f35e30a 100644 --- a/en/device-dev/bundles/bundles-guide-prepare.md +++ b/en/device-dev/bundles/bundles-guide-prepare.md @@ -1,21 +1,12 @@ -# Preparations +# Installing hpm-cli Tool -- [Hardware Requirements](#section98535485518) -- [Installing Node.js and the hpm-cli Tool](#section106591616205311) -- [\(Optional\) Modifying HPM Configurations](#section71821165412) +- [Installing Node.js and hpm](#section106591616205311) +- [\(Optional\) Configuring hpm](#section71821165412) - [Downloading OpenHarmony Code](#section102338221707) -- [Installing Dependent Bundles](#section19233183315020) -## Hardware Requirements +To develop a bundle, you first need to install the HarmonyOS Package Manager \(hpm\), a cross-platform command line tool developed based on Node.js. To run the hpm, you need to install Node.js, and then install the hpm using the Node Package Manager \(npm\). -- Development boards \(examples: Hi3861, Hi3516D V300, and Hi3518E V300\) -- Host computer \(Windows workstation\) -- Linux server - -**Figure 1** Hardware connections -![](figure/hardware-connections-24.png "hardware-connections-24") - -## Installing **Node.js** and the **hpm-cli** Tool +## Installing Node.js and hpm 1. Install **Node.js**. @@ -29,37 +20,49 @@ npm install -g @ohos/hpm-cli ``` -3. Run the following command to check whether the installation is successful. If an HPM version is displayed, the installation is successful. +3. Run the following command to check whether the installation is successful. If an hpm version is displayed, the installation is successful. ``` hpm -V or hpm --version ``` -4. \(Optional\) Run the following command to upgrade the HPM version if needed: +4. \(Optional\) Run the following command to upgrade the hpm version if needed: ``` npm update -g @ohos/hpm-cli ``` -## \(Optional\) Modifying HPM Configurations +## \(Optional\) Configuring hpm -After the **hpm-cli** tool is installed, run the following command to view HPM configurations: +After the **hpm-cli** tool is installed, run the following command to view the hpm configuration if you need to modify the configuration information, such as proxy and shell: ``` hpm config ``` -Default HPM configurations are displayed upon the command execution. You can modify the default configurations as required. The following lists common HPM configurations: +Default hpm configurations are displayed upon successful command execution. You can modify the default configurations as required. The following lists common hpm configurations: ``` -registry = https://hpm.harmonyos.com/hpm/registry/api # Configure the address of the HPM registry, mandatory for downloading bundles. -login = https://hpm.harmonyos.com/hpm/auth/pk # Configure the address for HPM login, mandatory for publishing bundles. -loginUser = {your-account} # Configure the account for HPM login, mandatory for publishing bundles. -shellPath = C:\WINDOWS\System32\cmd.exe # Configure the shell for running HPM commands. -globalRepo = C:\Users\yourname\.global # Configure the path for storing bundles that are installed globally. -http_proxy = http://your-proxy-server:port # Configure the HTTP proxy. -https_proxy = http://your-proxy-server:port # Configure the HTTPS proxy. +registry = https://hpm.harmonyos.com +### login Settings +# loginUser = invitation_code + +#### Path Settings +shellPath = C:\WINDOWS\System32\cmd.exe +# shellPath = C:\Program Files\Git\bin\sh.exe +# globalRepo = C:\Users\username\.hpm\global + +#### Network Settings +# no_proxy = *.server.com +# http_proxy = http://user:pwd@proxy_server:port +# https_proxy = http://user:pwd@proxy_server:port +# strictSsl = true + +#### Other Settings +# privateSupport = true|false +# ignoreBundles = @ohos/llvm,@ohos/gn, +# OSPlatform = Auto|linux|darwin|win32 ``` For details about **hpm-cli** commands, see [HPM Commands](bundles-guide-overview.md). @@ -68,17 +71,3 @@ For details about **hpm-cli** commands, see [HPM Commands](bundles-guide-over For details, see [Source Code Acquisition](../get-code/sourcecode-acquire.md). -## Installing Dependent Bundles - -The HPM publishes commonly used development tools \(such as those for burning, compiling, and compression\) as bundles. You can run the following command to install these tools. After the command is executed, the system automatically downloads and installs the tools, which need to be installed globally only once. - -``` -hpm i -g @ohos/llvm -hpm i -g @ohos/ninja -hpm i -g @ohos/gn -hpm i -g @ohos/hc_gen -hpm i -g @ohos/sysroot -``` - -These are a set of development tools \(such as **gn** and **ninja**\). With these tools, you can start your general bundle development based on source code. - diff --git a/en/device-dev/bundles/bundles-guide.md b/en/device-dev/bundles/bundles-guide.md index 162b7be93ab12c2b1da404fd0fca89f6a3b6e4d4..1a7510e16a3f1a15368544c060d0621c0eff7e05 100644 --- a/en/device-dev/bundles/bundles-guide.md +++ b/en/device-dev/bundles/bundles-guide.md @@ -1,9 +1,9 @@ # Development Guidelines -- **[Bundle Development](bundles-guide-overview.md)** +- **[Overview](bundles-guide-overview.md)** -- **[Preparations](bundles-guide-prepare.md)** +- **[Installing hpm-cli Tool](bundles-guide-prepare.md)** -- **[Bundle Development](bundles-guide-develop.md)** +- **[Developing Bundles](bundles-guide-develop.md)** diff --git a/en/device-dev/bundles/bundles-standard-rules.md b/en/device-dev/bundles/bundles-standard-rules.md index 8adaac0e618ca9b141d52d7a4683a8ba3fa086ae..cebbd0a3459341f6ff7770122774f188809a20a0 100644 --- a/en/device-dev/bundles/bundles-standard-rules.md +++ b/en/device-dev/bundles/bundles-standard-rules.md @@ -1,8 +1,8 @@ -# Development Specifications +# Bundle Development Specifications - [Overview](#section1725818533344) - [Definition](#section4821219183514) - - [Bundle Division Principles](#section1089794263513) + - [Bundle Division Rules](#section1089794263513) - [Bundle Dependency](#section25701647163710) - [Bundle Composition](#section185538333914) @@ -40,7 +40,7 @@ Bundles are designed for reuse purposes. Any reusable modules can be defined as - Code snippet - Distribution -### Bundle Division Principles +### Bundle Division Rules In principle, bundles should be grouped at a fine-grained granularity as much as possible to achieve maximum reuse. The following factors are taken into account regarding bundle division: @@ -59,7 +59,7 @@ A bundle dependency can be mandatory or optional. A bundle contains the following: -- **src** directory for storing code files or code library +- **src** directory for storing code files or code library of the bundle - **ohos\_bundles** folder for storing dependent bundles \(It is automatically generated during bundle installation, without the need to submit to the code library.\) - **README.md** file for describing the bundle - **bundle.json** file for declaring metadata of the bundle @@ -138,7 +138,7 @@ Each **bundle.json** file has the following fields: - **version**: a bundle version number, for example, 1.0.0. The version number must comply with the Semantic Versioning Specification \(SemVer\) standards. - **description**: a brief description of a bundle -- **dependencies**: bundles that a bundle depends on +- **dependencies**: bundles on which this bundle depends. - **envs**: parameters required for bundle compilation, including global parameters and dependency parameters. @@ -170,7 +170,7 @@ A basic **bundle.json** file needs to be enriched by bundle dependencies to im } ``` -In this example, **my-bundle** depends on **net 1.0.0**. After you globally install the hpm-cli tool, run the following command to obtain bundle dependencies from the remote repository: +In the preceding example, the **my-bundle** bundle depends on the **net 1.0.0** bundle. After you globally install the hpm-cli tool, run the following command to obtain bundle dependencies from the remote repository: ``` hpm install @@ -246,7 +246,7 @@ You can use the hpm-cli tool to manage the lifecycle of a bundle. The following

hpm init bundle

-

Creates a bundle project.

+

Create a bundle project.

hpm init -t template

@@ -472,7 +472,7 @@ As it is rather complex to redefine the functionality of a distribution, OpenHar } ``` -In this example, the current bundle inherits from the **dist-wifi-iot 1.0.0** bundle of the distribution. +In this example, the current bundle inherits from the **Bundledist-wifi-iot 1.0.0** bundle of the distribution. Each distribution consists of many dependent bundles, which are represented by the **dependencies** field in **bundle.json**. Some dependencies are mandatory, and others can be added or removed required. In the **bundle.json** file, bundle names prefixed with a question mark \(?\) represent optional dependent bundles. If you want to inherit from a distribution involving such bundles, you can remove them and then add other bundles. diff --git a/en/device-dev/bundles/bundles.md b/en/device-dev/bundles/bundles.md index 21586387bbddd35439986cadb9c812a6d0c58bc3..668b3d43e0ec27085952971fdd4512d53ba763e3 100644 --- a/en/device-dev/bundles/bundles.md +++ b/en/device-dev/bundles/bundles.md @@ -1,6 +1,6 @@ # Bundle Development -- **[Development Specifications](bundles-standard-rules.md)** +- **[Bundle Development Specifications](bundles-standard-rules.md)** - **[Development Guidelines](bundles-guide.md)** diff --git a/en/device-dev/bundles/figure/hardware-connections-23.png b/en/device-dev/bundles/figure/3516dv300.png similarity index 100% rename from en/device-dev/bundles/figure/hardware-connections-23.png rename to en/device-dev/bundles/figure/3516dv300.png diff --git a/en/device-dev/bundles/figure/en-us_image_0000001051452177.png b/en/device-dev/bundles/figure/en-us_image_0000001051452177.png deleted file mode 100644 index 1fb6e4a1742434b1151b428647a161f5107d244e..0000000000000000000000000000000000000000 Binary files a/en/device-dev/bundles/figure/en-us_image_0000001051452177.png and /dev/null differ diff --git a/en/device-dev/bundles/figure/en-us_image_0000001134127844.png b/en/device-dev/bundles/figure/en-us_image_0000001134127844.png new file mode 100644 index 0000000000000000000000000000000000000000..8988fc2cf8e2d7218a5812764e0022226fec4d53 Binary files /dev/null and b/en/device-dev/bundles/figure/en-us_image_0000001134127844.png differ diff --git a/en/device-dev/bundles/figure/hardware-connections-24.png b/en/device-dev/bundles/figure/hardware-connections-24.png deleted file mode 100755 index c4636401a20e37794d8ec28dc173e9308b2b72db..0000000000000000000000000000000000000000 Binary files a/en/device-dev/bundles/figure/hardware-connections-24.png and /dev/null differ diff --git a/en/device-dev/bundles/figure/successful-installation-(scons-version-requirement-3-0-4-or-later)-25.png b/en/device-dev/bundles/figure/successful-installation-(scons-version-requirement-3-0-4-or-later)-28.png similarity index 100% rename from en/device-dev/bundles/figure/successful-installation-(scons-version-requirement-3-0-4-or-later)-25.png rename to en/device-dev/bundles/figure/successful-installation-(scons-version-requirement-3-0-4-or-later)-28.png diff --git "a/en/device-dev/bundles/figure/\347\273\204\344\273\2660924.png" "b/en/device-dev/bundles/figure/\347\273\204\344\273\2660924.png" deleted file mode 100644 index cffe8ab030605165f23eb369be4eb37de7865edf..0000000000000000000000000000000000000000 Binary files "a/en/device-dev/bundles/figure/\347\273\204\344\273\2660924.png" and /dev/null differ diff --git "a/en/device-dev/bundles/figure/\347\273\204\344\273\266\345\222\214\345\217\221\350\241\214\347\211\210\347\232\204\346\236\204\346\210\220-\350\213\261\346\226\207.png" "b/en/device-dev/bundles/figure/\347\273\204\344\273\266\345\222\214\345\217\221\350\241\214\347\211\210\347\232\204\346\236\204\346\210\220-\350\213\261\346\226\207.png" new file mode 100644 index 0000000000000000000000000000000000000000..08d9dccdd2371b02f2732d0e4eb4ad9871dccdbe Binary files /dev/null and "b/en/device-dev/bundles/figure/\347\273\204\344\273\266\345\222\214\345\217\221\350\241\214\347\211\210\347\232\204\346\236\204\346\210\220-\350\213\261\346\226\207.png" differ diff --git a/en/device-dev/driver/Readme-EN.md b/en/device-dev/driver/Readme-EN.md index c82515419fece430b91c9846b2c4ecba1df5f1fd..f5533c8d3458f16d5d5b427f54820bd37a9a60ba 100644 --- a/en/device-dev/driver/Readme-EN.md +++ b/en/device-dev/driver/Readme-EN.md @@ -1,13 +1,13 @@ -# drivers +# Drivers - [HDF](driver-hdf.md) - [HDF Overview](driver-hdf-overview.md) - - [driverr Development](driver-hdf-development.md) - - [driverr Service Management](driver-hdf-servicemanage.md) - - [driverr Message Mechanism Management](driver-hdf-news.md) - - [driverr Configuration Management](driver-hdf-manage.md) + - [Driver Development](driver-hdf-development.md) + - [Driver Service Management](driver-hdf-servicemanage.md) + - [Driver Message Mechanism Management](driver-hdf-news.md) + - [Driver Configuration Management](driver-hdf-manage.md) - [HDF Development Example](driver-hdf-sample.md) -- [Platform driverrs](driver-platform.md) +- [Platform Drivers](driver-platform.md) - [GPIO](driver-platform-gpio-des.md) - [I2C](driver-platform-i2c-des.md) - [RTC](driver-platform-rtc-des.md) diff --git a/en/device-dev/driver/driver-hdf-development.md b/en/device-dev/driver/driver-hdf-development.md index 7d9e91390c07c54b069f1e396d245cb9381d3790..4f5d237341dbd143abfcaf257d995ba024c50861 100644 --- a/en/device-dev/driver/driver-hdf-development.md +++ b/en/device-dev/driver/driver-hdf-development.md @@ -66,7 +66,6 @@ Driver development based on the HDF consists of two parts: driver implementation HDF_INIT(g_sampleDriverEntry); ``` - 2. Compile the driver code. - Use the **Makefile** template provided by the HDF to compile the driver code. @@ -86,7 +85,6 @@ Driver development based on the HDF consists of two parts: driver implementation LIB_SUBDIRS += # Directory of Makefile ``` - 3. Configure the driver. HDF Configuration Source \(HCS\) is the source code that describes the configuration of the HDF. For details about the HCS, see [Driver Configuration Management](driver-hdf-manage.md). @@ -169,7 +167,7 @@ Driver development based on the HDF consists of two parts: driver implementation > DEVICE_PRELOAD_INVALID > } DevicePreload; > ``` -> When the **preload** field in the configuration file is set to **0** \(**DEVICE\_PRELOAD\_ENABLE**\), the driver is loaded by default during system startup. When this field is set to **1** \(**DEVICE\_PRELOAD\_ENABLE\_STEP2**\), the driver is loaded after system startup if quick start is enabled; it is loaded during system startup otherwise. When this field is set to **2** \(**DEVICE\_PRELOAD\_DISABLE**\), the driver is not loaded by default during system startup and can be dynamically loaded later. If the driver service does not exist when a user-level application obtains the driver service \(for details about how to obtain the driver service, see [Driver Message Mechanism Management](drive-hdf-news.md)\), the HDF attempts to dynamically load the driver. +> When the **preload** field in the configuration file is set to **0** \(**DEVICE\_PRELOAD\_ENABLE**\), the driver is loaded by default during system startup. When this field is set to **1** \(**DEVICE\_PRELOAD\_ENABLE\_STEP2**\), the driver is loaded after system startup if quick start is enabled; it is loaded during system startup otherwise. When this field is set to **2** \(**DEVICE\_PRELOAD\_DISABLE**\), the driver is not loaded by default during system startup and can be dynamically loaded later. If the driver service does not exist when a user-level application obtains the driver service \(for details about how to obtain the driver service, see [Driver Message Mechanism Management](driver-hdf-news.md)\), the HDF attempts to dynamically load the driver. >- Sequential loading \(drivers must be loaded by default\) > In the configuration file, the **priority** field \(the value is an integer ranging from 0 to 200\) indicates the priority of the host and driver. For drivers in different hosts, a smaller host priority value indicates a higher driver loading priority; for drivers in the same host, a smaller driver priority value indicates a higher driver loading priority. diff --git a/en/device-dev/driver/driver-hdf-news.md b/en/device-dev/driver/driver-hdf-news.md index 90f70d1aa93f3c0964e923e24b16c9b42c16171a..0ddcc4901fa34b10914b56d66268ad490491212e 100644 --- a/en/device-dev/driver/driver-hdf-news.md +++ b/en/device-dev/driver/driver-hdf-news.md @@ -49,7 +49,7 @@ The message mechanism provides the following features: ## How to Develop -1. Set the value of the **policy** field in the driver configuration information to **2** \(SERVICE\_POLICY\_CAPACITY, see [Driver Service Management](drive-hdf-servicemanage.md)\). +1. Set the value of the **policy** field in the driver configuration information to **2** \(SERVICE\_POLICY\_CAPACITY, see [Driver Service Management](driver-hdf-servicemanage.md)\). ``` device_sample :: Device { diff --git a/en/device-dev/driver/driver-hdf.md b/en/device-dev/driver/driver-hdf.md index cc7e51c2b541100f6d1109886b19bc9b1d9beb63..dd3d27b7a8da1298e142f822e2ad51738e19f691 100644 --- a/en/device-dev/driver/driver-hdf.md +++ b/en/device-dev/driver/driver-hdf.md @@ -2,13 +2,13 @@ - **[HDF Overview](driver-hdf-overview.md)** -- **[driverr Development](driver-hdf-development.md)** +- **[Driver Development](driver-hdf-development.md)** -- **[driverr Service Management](driver-hdf-servicemanage.md)** +- **[Driver Service Management](driver-hdf-servicemanage.md)** -- **[driverr Message Mechanism Management](driver-hdf-news.md)** +- **[Driver Message Mechanism Management](driver-hdf-news.md)** -- **[driverr Configuration Management](driver-hdf-manage.md)** +- **[Driver Configuration Management](driver-hdf-manage.md)** - **[HDF Development Example](driver-hdf-sample.md)** diff --git a/en/device-dev/driver/driver-peripherals-lcd-des.md b/en/device-dev/driver/driver-peripherals-lcd-des.md index 2b8dd1543a584339b768c9bc929ea4287ea43ab4..fb7eaec0acd0744f5e3ff2df836af5e43ea7b6af 100644 --- a/en/device-dev/driver/driver-peripherals-lcd-des.md +++ b/en/device-dev/driver/driver-peripherals-lcd-des.md @@ -10,7 +10,7 @@ ## Overview -The Liquid Crystal Display \(LCD\) driver powers on the LCD and initializes internal LCD registers through APIs to enable the LCD to work properly. The display driver is developed based on the hardware driver foundation \([HDF](drive-hdf-overview.md)\). It provides power-on, power-off, and sending of the initialization sequence for LCD hardware across OSs and platforms. The display driver model is shown in [Figure 1](#fig69138814229). +The Liquid Crystal Display \(LCD\) driver powers on the LCD and initializes internal LCD registers through APIs to enable the LCD to work properly. The display driver is developed based on the hardware driver foundation \([HDF](driver-hdf-overview.md)\). It provides power-on, power-off, and sending of the initialization sequence for LCD hardware across OSs and platforms. The display driver model is shown in [Figure 1](#fig69138814229). **Figure 1** Architecture of the display driver model ![](figure/architecture-of-the-display-driver-model.png "architecture-of-the-display-driver-model") @@ -66,7 +66,6 @@ The display driver model is developed based on the HDF, platform APIs, and APIs Based on the LCD hardware interfaces, use the I2C, SPI, and MIPI interfaces provided by the platform to download the LCD initialization sequence. For details, see the SPEC provided by the LCD supplier. - 4. Implement other HDF interfaces as required, for example, the **Release** interface. 5. Use the HDF to create other device nodes for implementing service logic or debugging as required. diff --git a/en/device-dev/driver/driver-peripherals-touch-des.md b/en/device-dev/driver/driver-peripherals-touch-des.md index f4bfd35be3cf06492694b92bf2b7711e703a409e..4298d466b0c44a026d117ec14d4aa0dc639b5de5 100644 --- a/en/device-dev/driver/driver-peripherals-touch-des.md +++ b/en/device-dev/driver/driver-peripherals-touch-des.md @@ -68,14 +68,13 @@ The interfaces shown in the figure are described as follows: Generally, the touchscreen driver IC is separated from the LCD driver IC. In this case, the touchscreen driver IC requires both 1.8 V and 3.3 V power supplies. Nowadays, the touchscreen driver IC and LCD driver IC can be integrated. Therefore, the touchscreen, requires only the 1.8 V power supply, and the 3.3 V power required internally is supplied by the LCD VSP power \(typical value: 5.5 V\) in the driver IC. - 2. **I/O control interfaces** - RESET: reset pin, which is used to reset the driver IC on the host when suspending or resuming the system. - INT: interrupt pin, which needs to be set to the input direction and pull-up status during driver initialization. After detecting an external touch signal, the driver triggers the interrupt by operating the interrupt pin. The driver reads the touch reporting data in the ISR function. 3. **Communications interfaces** - - I2C: Since only a small amount of touch data is reported by the touchscreen, I2C is used to transmit the reported data. For details about the I2C protocol and interfaces, see [I2C](drive-platform-i2c-des.md#section1695201514281). - - SPI: In addition to touch reporting data coordinates, some vendors need to obtain basic capacitance data. Therefore, Serial Peripheral Interface \(SPI\) is used to transmit such huge amount of data. For details about the SPI protocol and interfaces, see [SPI](drive-platform-spi-des.md#section71363452477). + - I2C: Since only a small amount of touch data is reported by the touchscreen, I2C is used to transmit the reported data. For details about the I2C protocol and interfaces, see [I2C](driver-platform-i2c-des.md#section1695201514281). + - SPI: In addition to touch reporting data coordinates, some vendors need to obtain basic capacitance data. Therefore, Serial Peripheral Interface \(SPI\) is used to transmit such huge amount of data. For details about the SPI protocol and interfaces, see [SPI](driver-platform-spi-des.md#section71363452477). ## Development Guidelines @@ -109,7 +108,7 @@ Regardless of the OS and system on a chip \(SoC\), the input driver is developed 3. Implement differentiated adaptation APIs of the touchscreen. - Use the platform APIs to perform operations for the reset pins, interrupt pins, and power based on the communications interfaces designed for boards. For details about the GPIO-related operations, see [GPIO](drive-platform-gpio-des.md#section259614242196). + Use the platform APIs to perform operations for the reset pins, interrupt pins, and power based on the communications interfaces designed for boards. For details about the GPIO-related operations, see [GPIO](driver-platform-gpio-des.md#section259614242196). ## Development Example diff --git a/en/device-dev/driver/driver-platform-gpio-des.md b/en/device-dev/driver/driver-platform-gpio-des.md index 045a23db3e998a174fd191525fd04742b9ca86a8..b18c31bf7b49ba9001b7013596f6f2e5fbfbd4c1 100644 --- a/en/device-dev/driver/driver-platform-gpio-des.md +++ b/en/device-dev/driver/driver-platform-gpio-des.md @@ -106,7 +106,7 @@ The method for converting GPIO pin numbers varies according to the GPIO controll A controller manages 12 groups of GPIO pins. Each group contains 8 GPIO pins. - GPIO pin number = GPIO group index \(0-11\) x Number of GPIO pins in each group \(8\) + Offset in the group + GPIO pin number = GPIO group index \(0–11\) x Number of GPIO pins in each group \(8\) + Offset in the group Example: GPIO number of GPIO10\_3 = 10 x 8 + 3 = 83 diff --git a/en/device-dev/driver/driver-platform-spi-des.md b/en/device-dev/driver/driver-platform-spi-des.md index b2c1b31147091e2d28ff902727f8ec7c1abfef80..28da985d3b9a955254e98ebc9f883802d915f2f5 100644 --- a/en/device-dev/driver/driver-platform-spi-des.md +++ b/en/device-dev/driver/driver-platform-spi-des.md @@ -132,7 +132,7 @@ Before performing SPI communication, obtain an SPI device handle by calling **S DevHandle SpiOpen\(const struct SpiDevInfo \*info\); -**Table 2** Description of **SpiOpen** +**Table 2** Description of SpiOpen

Parameter

@@ -185,7 +185,7 @@ After obtaining the SPI device handle, obtain the SPI device configuration param int32\_t SpiGetCfg\(DevHandle handle, struct SpiCfg \*cfg\); -**Table 3** Description of **SpiGetCfg** +**Table 3** Description of SpiGetCfg

Parameter

@@ -224,7 +224,7 @@ int32\_t SpiGetCfg\(DevHandle handle, struct SpiCfg \*cfg\); ``` int32_t ret; struct SpiCfg cfg = {0}; /* SPI configuration information */ -ret = SpiGetCfg(spiHandle, &cfg); /* Set SPI device configuration parameters. */ +ret = SpiGetCfg(spiHandle, &cfg); /* Obtain SPI device configuration parameters. */ if (ret != 0) { HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret); } @@ -236,7 +236,7 @@ After obtaining the SPI device handle, set SPI device configuration parameters b int32\_t SpiSetCfg\(DevHandle handle, struct SpiCfg \*cfg\); -**Table 4** Description of **SpiSetCfg** +**Table 4** Description of SpiSetCfg

Parameter

@@ -293,7 +293,7 @@ To write data into an SPI device only once, call the following function: int32\_t SpiWrite\(DevHandle handle, uint8\_t \*buf, uint32\_t len\); -**Table 5** Description of **SpiWrite** +**Table 5** Description of SpiWrite

Parameter

@@ -350,7 +350,7 @@ To read data from an SPI device only once, call the following function: int32\_t SpiRead\(DevHandle handle, uint8\_t \*buf, uint32\_t len\); -**Table 6** Description of **SpiRead** +**Table 6** Description of SpiRead

Parameter

@@ -407,7 +407,7 @@ To launch a custom transfer, call the following function: int32\_t SpiTransfer\(DevHandle handle, struct SpiMsg \*msgs, uint32\_t count\); -**Table 7** Description of **SpiTransfer** +**Table 7** Description of SpiTransfer -

Parameter

@@ -474,7 +474,7 @@ void SpiClose\(DevHandle handle\); This function will release the resources previously obtained. -**Table 8** Description of **SpiClose** +**Table 8** Description of SpiClose

Parameter

@@ -491,7 +491,7 @@ This function will release the resources previously obtained.
``` -PalHandleDestroy(spiHandle); /* Destroy the SPI device handle. */ +SpiClose(spiHandle); /* Destroy the SPI device handle. */ ``` ## Usage Example @@ -540,7 +540,7 @@ void SpiTestSample(void) HDF_LOGE("SpiWrite: failed, ret %d\n", ret); goto err; } - /* Read data of a specified length from an SPI device. */ + /* Read data of a specific length from an SPI device. */ ret = SpiRead(spiHandle, rbuff, 4); if (ret != 0) { HDF_LOGE("SpiRead: failed, ret %d\n", ret); diff --git a/en/device-dev/driver/driver-platform.md b/en/device-dev/driver/driver-platform.md index c15f954770c9b49ba191a50de133f954d0c63bcd..ddbfedc5a0e14056b2cbe96723c2fc71d174629f 100644 --- a/en/device-dev/driver/driver-platform.md +++ b/en/device-dev/driver/driver-platform.md @@ -1,4 +1,4 @@ -# Platform drivers +# Platform Drivers - **[GPIO](driver-platform-gpio-des.md)** diff --git a/en/device-dev/get-code/figure/3-22.png b/en/device-dev/get-code/figure/3-27.png similarity index 100% rename from en/device-dev/get-code/figure/3-22.png rename to en/device-dev/get-code/figure/3-27.png diff --git a/en/device-dev/get-code/gettools-acquire.md b/en/device-dev/get-code/gettools-acquire.md index e1654c255a4f54a49a35f9739413fc74b22e3ea4..b28068971ed0037d1336f15df5873c71e449765e 100644 --- a/en/device-dev/get-code/gettools-acquire.md +++ b/en/device-dev/get-code/gettools-acquire.md @@ -52,7 +52,7 @@ OpenHarmony provides the following two types of Docker environments for you to q

swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard

0.0.1

+

0.0.2

HPM-based Docker environment

@@ -287,9 +287,8 @@ Start building. Docker can be automatically installed only in Ubuntu. If you are hpm run docker ``` - This example uses the **@ohos/hispark\_taurus** solution for illustration. If the execution is successful, the output is as follows: - + ``` ... ohos ipcamera_hispark_taurus build success! diff --git a/en/device-dev/get-code/gettools-ide.md b/en/device-dev/get-code/gettools-ide.md index ec5de1cf9a48fb2b4039f55dbd702de396b4e2c0..73f534bb8ae3bf4e53c16e025f8df3d8883f30e8 100644 --- a/en/device-dev/get-code/gettools-ide.md +++ b/en/device-dev/get-code/gettools-ide.md @@ -9,7 +9,7 @@ HUAWEI DevEco Device Tool is a one-stop integrated development environment \(IDE The roadmap of Huawei DevEco Device Tool for supporting OpenHarmony device development is shown in the figure below. -![](figure/3-22.png) +![](figure/3-27.png) ## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\) diff --git a/en/device-dev/get-code/sourcecode-acquire.md b/en/device-dev/get-code/sourcecode-acquire.md index c581d9b3fba76ee42fa426bbb509ffeb5dc54b11..3560b5acc256540dda0ee2a60cc803f9b6ed540b 100644 --- a/en/device-dev/get-code/sourcecode-acquire.md +++ b/en/device-dev/get-code/sourcecode-acquire.md @@ -162,7 +162,6 @@ You must install **Node.js** and HPM on your local PC. The installation proced ![](figure/en-us_image_0000001119915556.png) - 2. Learn more about the distribution. 1. Read carefully the information about the distribution to learn its application scenarios, features, bundles, usage, and customization methods, as shown in the following figure. @@ -185,7 +184,6 @@ You must install **Node.js** and HPM on your local PC. The installation proced ![](figure/en-us_image_0000001166715379.png) - 4. Download and install bundles. 1. Decompress the downloaded file using the CLI tool CMD \(shell in Linux\). 2. In the generated directory, run the **hpm install** command. diff --git a/en/device-dev/glossary/public_sys-resources/icon-caution.gif b/en/device-dev/glossary/public_sys-resources/icon-caution.gif deleted file mode 100644 index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000 Binary files a/en/device-dev/glossary/public_sys-resources/icon-caution.gif and /dev/null differ diff --git a/en/device-dev/glossary/public_sys-resources/icon-danger.gif b/en/device-dev/glossary/public_sys-resources/icon-danger.gif deleted file mode 100644 index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000 Binary files a/en/device-dev/glossary/public_sys-resources/icon-danger.gif and /dev/null differ diff --git a/en/device-dev/glossary/public_sys-resources/icon-note.gif b/en/device-dev/glossary/public_sys-resources/icon-note.gif deleted file mode 100644 index 6314297e45c1de184204098efd4814d6dc8b1cda..0000000000000000000000000000000000000000 Binary files a/en/device-dev/glossary/public_sys-resources/icon-note.gif and /dev/null differ diff --git a/en/device-dev/glossary/public_sys-resources/icon-notice.gif b/en/device-dev/glossary/public_sys-resources/icon-notice.gif deleted file mode 100644 index 86024f61b691400bea99e5b1f506d9d9aef36e27..0000000000000000000000000000000000000000 Binary files a/en/device-dev/glossary/public_sys-resources/icon-notice.gif and /dev/null differ diff --git a/en/device-dev/glossary/public_sys-resources/icon-tip.gif b/en/device-dev/glossary/public_sys-resources/icon-tip.gif deleted file mode 100644 index 93aa72053b510e456b149f36a0972703ea9999b7..0000000000000000000000000000000000000000 Binary files a/en/device-dev/glossary/public_sys-resources/icon-tip.gif and /dev/null differ diff --git a/en/device-dev/glossary/public_sys-resources/icon-warning.gif b/en/device-dev/glossary/public_sys-resources/icon-warning.gif deleted file mode 100644 index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000 Binary files a/en/device-dev/glossary/public_sys-resources/icon-warning.gif and /dev/null differ diff --git a/en/device-dev/guide/Readme-EN.md b/en/device-dev/guide/Readme-EN.md index ca124ea327c8b4af4d22f6e6d462df5c6de5592b..73cd1dffd06b51cb71f228b95168196583b7d16a 100644 --- a/en/device-dev/guide/Readme-EN.md +++ b/en/device-dev/guide/Readme-EN.md @@ -1,8 +1,8 @@ # Development Examples - [WLAN-connected Products](device-wifi.md) - - [LED Peripheral Control](device-wifi-led-outcontrol.md) - - [Third-Party SDK Integration](device-wifi-sdk.md) + - [LED Peripheral Control](device-wlan-led-outcontrol.md) + - [Third-Party SDK Integration](device-wlan-sdk.md) - [Cameras Without a Screen](device-iotcamera.md) - [Camera Control](device-iotcamera-control.md) - [Overview](device-iotcamera-control-overview.md) @@ -22,11 +22,11 @@ - [Overview](device-camera-visual-overview.md) - [Preparations](device-camera-visual-prepare.md) - [Adding Pages](device-camera-visual-addpage.md) - - [Building the Home Page](device-camera-visual-first-page.md) + - [Building the Home Page](device-camera-visual-firstpage.md) - [Building the Details Page](device-camera-visual-details.md) - [Debugging and Packaging](device-camera-visual-debug.md) - [Running on the Device](device-camera-visual-run.md) - [FAQs](device-camera-visual-faqs.md) -- [Development Guidelines on Clock Apps](oem_device_clockapp_des.md) +- [Development Guidelines on Clock Apps](device-clock-guide.md) - [Development Example for Platform Drivers](device-driver-demo.md) - [Development Example for Peripheral Drivers](device-outerdriver-demo.md) \ No newline at end of file diff --git a/en/device-dev/guide/device-camera-visual-first-page.md b/en/device-dev/guide/device-camera-visual-firstpage.md similarity index 99% rename from en/device-dev/guide/device-camera-visual-first-page.md rename to en/device-dev/guide/device-camera-visual-firstpage.md index 5fe705f70f0dee725e2d4f485e7cf8652497b3b9..a610376cea65e108c28acfb8e25a22935fd7c6e5 100644 --- a/en/device-dev/guide/device-camera-visual-first-page.md +++ b/en/device-dev/guide/device-camera-visual-firstpage.md @@ -111,7 +111,6 @@ The following steps describe how to build the home page with a flexible layout t } ``` - - **index="\{\{swiperPage\}\}" duration="500" onchange="swiperChange"** sets the component attribute and event. **duration="500"** indicates that the duration of the swiping animation is 500 ms. - **index="\{\{swiperPage\}\}"** specifies the index of the child component of ****. **\{\{swiperPage\}\}** indicates that the index value is dynamically bound to the **swiperPage** variable in the JavaScript code. The index value changes with the **swiperPage** value. - **onchange="swiperChange"** binds the change event of the **** component to the **swiperChange** function. The JavaScript code is as follows: @@ -141,7 +140,6 @@ The following steps describe how to build the home page with a flexible layout t } ``` - 4. Set the information about a city to be displayed on a screen. On each screen, information of different types is displayed using different components. Add two **** as child components \(directional layout\) to ****. Add ****, ****, ****, and other components to each **** to display the information. The following example shows the page structure: diff --git a/en/device-dev/guide/device-camera-visual.md b/en/device-dev/guide/device-camera-visual.md index 183a3c5758f90bb42becc05c09e74379f53a9c28..223659e705eb9f4ba215c92237e631dcf31c3b7d 100644 --- a/en/device-dev/guide/device-camera-visual.md +++ b/en/device-dev/guide/device-camera-visual.md @@ -6,7 +6,7 @@ - **[Adding Pages](device-camera-visual-addpage.md)** -- **[Building the Home Page](device-camera-visual-first-page.md)** +- **[Building the Home Page](device-camera-visual-firstpage.md)** - **[Building the Details Page](device-camera-visual-details.md)** diff --git a/en/device-dev/guide/oem_device_clockapp_des.md b/en/device-dev/guide/device-clock-guide.md similarity index 96% rename from en/device-dev/guide/oem_device_clockapp_des.md rename to en/device-dev/guide/device-clock-guide.md index 5a7836cea35b322fb0bc27c81d4f7b371a97482f..9ddbe73f5d13658e0889e2135538a7caac6ed7f6 100644 --- a/en/device-dev/guide/oem_device_clockapp_des.md +++ b/en/device-dev/guide/device-clock-guide.md @@ -29,7 +29,7 @@ Download and install DevEco Studio. For details, see the [HUAWEI DevEco Studio The Clock app displays the current time through a clock face and numbers. -As shown in [Figure 1 Clock display effect](oem_device_clockapp_des.md#fig7763172132019), the UI consists of two parts: +As shown in [Figure 1 Clock display effect](#fig7763172132019), the UI consists of two parts: - Clock face area: displays a dynamic analog clock whose hands rotate accurately. - Digital time area: displays the current time in numerals. @@ -177,9 +177,8 @@ To build such an app, we can create a page that has a flexible layout with two r ``` - - **index.css** - + ``` .container { flex-direction: column; @@ -217,11 +216,10 @@ To build such an app, we can create a page that has a flexible layout with two r } ``` - - **index.js** - + A **.js** file is used to implement logic interactions of the clock app. The following **.js** file implements the function of periodically obtaining the system time. - + ``` export default { timer: undefined, @@ -263,7 +261,7 @@ After finishing writing the app code, you need to sign and package the app befor ## Running on the Real Device -Before you install the app and run it on the development board, install the DevEco Device Tool by following operations provided in [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/tool_install-0000001050164976). Burn OpenHarmony into the development board, and run it on the board. For details about how to build, burn, and run an image, see [Getting Started with Hi3516](../quick-start/quickstart-standard.md). After the image is running normally and the system is started properly, perform the following steps to install or uninstall the app: +Before you install the app and run it on the development board, install the DevEco Device Tool by following operations provided in [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905). Burn OpenHarmony into the development board, and run it on the board. For details about how to build, burn, and run an image, see . After the image is running normally and the system is started properly, perform the following steps to install or uninstall the app: 1. Obtain the HDC client from the following path: diff --git a/en/device-dev/guide/device-driver-demo.md b/en/device-dev/guide/device-driver-demo.md index 9415d5323083e8dd5780360956a864b46988aec0..88e2e5a1e6cd7d43b874021400630de571c68141 100644 --- a/en/device-dev/guide/device-driver-demo.md +++ b/en/device-dev/guide/device-driver-demo.md @@ -34,7 +34,7 @@ In this example, an I2C driver is used. [Figure 1](#fig148041484161) shows the ## Preparations -Follow the instructions in [Environment Setup for Standard System](../quick-start/quickstart-standard.md). +Follow the instructions in [Environment Setup for Standard System](../quick-start/quickstart-standard-description.md). >![](../public_sys-resources/icon-notice.gif) **NOTICE:** >This development example applies to standard, small, and mini OpenHarmony systems. The following sections use the standard system as an example. You can refer to the specific guide for your system to set up the environment. diff --git a/en/device-dev/guide/device-outerdriver-demo.md b/en/device-dev/guide/device-outerdriver-demo.md index 6ac02acd6475a8fd1e8ba6a7d20c421ad2b7351d..5ae984c6f5fbd954f55c4f8cca4e329cd26e0950 100644 --- a/en/device-dev/guide/device-outerdriver-demo.md +++ b/en/device-dev/guide/device-outerdriver-demo.md @@ -22,7 +22,7 @@ ## Overview -This document describes how to develop a touchscreen driver on the Hi3516D V300 development board using the HDF input driver model, helping you quickly get started with peripheral driver development. +This document describes how to develop a touchscreen driver on the Hi3516D V300 development board using the HDF input driver model, helping you quickly get started with OpenHarmony peripheral driver development. ### Hardware Resources @@ -40,7 +40,7 @@ The input driver model mainly consists of the device manager, common drivers, an In addition, the input driver model implements functions for reporting input data and parsing input device configurations. -For details about the input driver model, see [Touchscreen Overview](../driver/drive-peripherals-touch-des.md#section175431838101617). +For details about the input driver model, see [Touchscreen Overview](../driver/driver-peripherals-touch-des.md#section175431838101617). ## Setting Up the Environment diff --git a/en/device-dev/guide/device-wifi.md b/en/device-dev/guide/device-wifi.md index 73a5fc8cae7ea60dd1612b47fe8f8352688876db..791c0edb6895af3ebf0e6712799ce2a8459a5930 100644 --- a/en/device-dev/guide/device-wifi.md +++ b/en/device-dev/guide/device-wifi.md @@ -1,7 +1,7 @@ # WLAN-connected Products -- **[LED Peripheral Control](device-wifi-led-outcontrol.md)** +- **[LED Peripheral Control](device-wlan-led-outcontrol.md)** -- **[Third-Party SDK Integration](device-wifi-sdk.md)** +- **[Third-Party SDK Integration](device-wlan-sdk.md)** diff --git a/en/device-dev/guide/device-wifi-led-outcontrol.md b/en/device-dev/guide/device-wlan-led-outcontrol.md similarity index 100% rename from en/device-dev/guide/device-wifi-led-outcontrol.md rename to en/device-dev/guide/device-wlan-led-outcontrol.md diff --git a/en/device-dev/guide/device-wifi-sdk.md b/en/device-dev/guide/device-wlan-sdk.md similarity index 100% rename from en/device-dev/guide/device-wifi-sdk.md rename to en/device-dev/guide/device-wlan-sdk.md diff --git a/en/device-dev/guide/device.md b/en/device-dev/guide/device.md index bbce9d52a9d027aed593e2dbe2e7d7ad69a95405..894af2e23daf71222d293f844a2132856d49245b 100644 --- a/en/device-dev/guide/device.md +++ b/en/device-dev/guide/device.md @@ -6,7 +6,7 @@ - **[Cameras with a Screen](device-camera.md)** -- **[Development Guidelines on Clock Apps](oem_device_clockapp_des.md)** +- **[Development Guidelines on Clock Apps](device-clock-guide.md)** - **[Development Example for Platform Drivers](device-driver-demo.md)** diff --git a/en/device-dev/kernel/Readme-EN.md b/en/device-dev/kernel/Readme-EN.md index b8a0bb660407fe0500f9a7ca89d7c589d12a7852..90a193350373b0cce1373609398f2c2f3534eeba 100644 --- a/en/device-dev/kernel/Readme-EN.md +++ b/en/device-dev/kernel/Readme-EN.md @@ -1,86 +1,187 @@ # Kernel - [Kernel for Mini and Small Systems](kernel-lite.md) + - [Kernel for Mini Systems](kernel-lite-mini.md) + - [Kernel Overview](kernel-mini-overview.md) + - [Basic Kernel](kernel-mini-basic.md) + - [Interrupt Management](kernel-mini-basic-interrupt.md) + - [Basic Concepts](kernel-mini-basic-interrupt-concept.md) + - [Development Guidelines](kernel-mini-basic-interrupt-guide.md) + - [Task Management](kernel-mini-basic-task.md) + - [Basic Concepts](kernel-mini-basic-task-basic.md) + - [Development Guidelines](kernel-mini-basic-task-guide.md) + - [Memory Management](kernel-mini-basic-memory.md) + - [Basic Concepts](kernel-mini-basic-memory-basic.md) + - [Static Memory](kernel-mini-basic-memory-static.md) + - [Dynamic Memory](kernel-mini-basic-memory-dynamic.md) + - [Kernel Communication Mechanisms](kernel-mini-basic-ipc.md) + - [Event](kernel-mini-basic-ipc-event.md) + - [Basic Concepts](kernel-mini-basic-ipc-event-basic.md) + - [Development Guidelines](kernel-mini-basic-ipc-event-guide.md) + - [Mutex](kernel-mini-basic-ipc-mutex.md) + - [Basic Concepts](kernel-mini-basic-ipc-mutex-basic.md) + - [Development Guidelines](kernel-mini-basic-ipc-mutex-guide.md) + - [Queue](kernel-mini-basic-ipc-queue.md) + - [Basic Concepts](kernel-mini-basic-ipc-queue-basic.md) + - [Development Guidelines](kernel-mini-basic-ipc-queue-guide.md) + - [Semaphore](kernel-mini-basic-ipc-sem.md) + - [Basic Concepts](kernel-mini-basic-ipc-sem-basic.md) + - [Development Guidelines](kernel-mini-basic-ipc-sem-guide.md) + - [Time Management](kernel-basic-mini-time.md) + - [Basic Concepts](kernel-mini-basic-time-basic.md) + - [Development Guidelines](kernel-mini-basic-time-guide.md) + - [Software Timer](kernel-mini-basic-soft.md) + - [Basic Concepts](kernel-mini-basic-soft-basic.md) + - [Development Guidelines](kernel-mini-basic-soft-guide.md) + - [Extension Components](kernel-mini-extend.md) + - [C++ Support](kernel-mini-extend-support.md) + - [CPUP](kernel-mini-extend-cpup.md) + - [Basic Concepts](kernel-mini-extend-cpup-basic.md) + - [Development Guidelines](kernel-mini-extend-cpup-guide.md) + - [Dynamic Loading](kernel-mini-extend-dynamic-loading.md) + - [Basic Concepts](kernel-mini-extend-dynamic-loading-basic.md) + - [Development Guidelines](kernel-mini-extend-dynamic-loading-guide.md) + - [File System](kernel-mini-extend-file.md) + - [FAT](kernel-mini-extend-file-fat.md) + - [LittleFS](kernel-mini-extend-file-lit.md) + - [Basic Concepts](kernel-mini-extend-file-littlefs-basic.md) + - [Development Guidelines](kernel-mini-extend-file-littlefs-guide.md) + - [Kernel Debugging](kernel-memory-inner.md) + - [Memory Debugging](kernel-mini-memory-debug.md) + - [Memory Information Statistics](kernel-mini-memory-debug-mes.md) + - [Memory Leak Check](kernel-mini-imemory-debug-det.md) + - [Memory Corruption Check](kernel-mini-memory-debug-cet.md) + - [Exception Debugging](kernel-mini-memory-exception.md) + - [Trace Debugging](kernel-mini-memory-trace.md) + - [Appendix](kernel-mini-app.md) + - [Kernel Coding Specification](kernel-mini-appx-code.md) + - [Basic Data Structure](kernel-mini-appx-data.md) + - [Doubly Linked List](kernel-mini-appx-data-list.md) + - [Standard Libraries](kernel-mini-appx-lib.md) + - [CMSIS Support](kernel-mini-appx-lib-cmsis.md) + - [POSIX Support](kernel-mini-appx-lib-posix.md) - [Kernel for Small Systems](kernel-lite-small.md) - - [Basic Kernel](kernel-lite-small-basic.md) - - [Process](kernel-lite-small-process.md) - - [Thread](kernel-lite-small-thread.md) - - [Memory](kernel-lite-small-memory.md) - - [Network](kernel-lite-small-net.md) - - [File System](kernel-lite-small-file.md) - - [VFS](kernel-lite-small-file-vfs.md) - - [NFS](kernel-lite-small-file-nfs.md) - - [RAMFS](kernel-lite-small-file-ramfs.md) - - [FAT](kernel-lite-small-file-fat.md) - - [JFFS2](kernel-lite-small-file-jffs.md) - - [Standard Library](kernel-lite-small-lib.md) - - [Standard Library](kernel-lite-small-lib-standard.md) - - [Differences from the Linux Standard Library](kernel-lite-small-lib-differ.md) - - [Commissioning](kernel-lite-small-shell.md) - - [Introduction to the Shell](kernel-lite-small-shell-des.md) - - [Shell Command Development Guidelines](kernel-lite-small-shell-guide.md) - - [Shell Command Programming Example](kernel-lite-small-shell-sample.md) - - [Shell Command Reference](kernel-lite-small-shell-cmd.md) - - [System Commands](kernel-lite-small-shell-cmd-sys.md) - - [cpup](kernel-lite-small-shell-cmd-sys-cpup.md) - - [date](kernel-lite-small-shell-cmd-sys-date.md) - - [dmesg](kernel-lite-small-shell-cmd-sys-demsg.md) - - [exec](kernel-lite-small-shell-cmd-sys-exec.md) - - [free](kernel-lite-small-shell-cmd-sys-free.md) - - [help](kernel-lite-small-shell-cmd-sys-help.md) - - [hwi](kernel-lite-small-shell-cmd-sys-hwi.md) - - [kill](kernel-lite-small-shell-cmd-sys-kill.md) - - [log](kernel-lite-small-shell-cmd-sys-log.md) - - [memcheck](kernel-lite-small-shell-cmd-sys-mem.md) - - [oom](kernel-lite-small-shell-cmd-sys-oom.md) - - [pmm](kernel-lite-small-shell-cmd-sys-pmm.md) - - [reset](kernel-lite-small-shell-cmd-sys-reset.md) - - [sem](kernel-lite-small-shell-cmd-sys-sem.md) - - [stack](kernel-lite-small-shell-cmd-sys-stack.md) - - [su](kernel-lite-small-shell-cmd-sys-su.md) - - [swtmr](kernel-lite-small-shell-cmd-sys-swymr.md) - - [systeminfo](kernel-lite-small-shell-cmd-sys-sys.md) - - [task](kernel-lite-small-shell-cmd-sys-task.md) - - [uname](kernel-lite-small-shell-cmd-sys-uname.md) - - [vmm](kernel-lite-small-shell-cmd-sys-vmm.md) - - [watch](kernel-lite-small-shell-cmd-sys-watch.md) - - [File Commands](kernel-lite-small-shell-cmd-file.md) - - [cat](kernel-lite-small-shell-cmd-file-cat.md) - - [cd](kernel-lite-small-shell-cmd-file-cd.md) - - [chgrp](kernel-lite-small-shell-cmd-file-chgrp.md) - - [chmod](kernel-lite-small-shell-cmd-file-chmod.md) - - [chown](kernel-lite-small-shell-cmd-file-chown.md) - - [cp](kernel-lite-small-shell-cmd-file-cp.md) - - [format](kernel-lite-small-shell-cmd-file-format.md) - - [ls](kernel-lite-small-shell-cmd-file-is.md) - - [lsfd](kernel-lite-small-shell-cmd-file-isfd.md) - - [mkdir](kernel-lite-small-shell-cmd-file-mkdir.md) - - [mount](kernel-lite-small-shell-cmd-file-mount.md) - - [partinfo](kernel-lite-small-shell-cmd-file-part.md) - - [partition](kernel-lite-small-shell-cmd-file-partion.md) - - [pwd](kernel-lite-small-shell-cmd-file-pwd.md) - - [rm](kernel-lite-small-shell-cmd-file-rm.md) - - [rmdir](kernel-lite-small-shell-cmd-file-rmdir.md) - - [statfs](kernel-lite-small-shell-cmd-file-sta.md) - - [sync](kernel-lite-small-shell-cmd-file-sync.md) - - [touch](kernel-lite-small-shell-cmd-file-touch.md) - - [writeproc](kernel-lite-small-shell-cmd-file-write.md) - - [umount](kernel-lite-small-shell-cmd-file-umount.md) - - [Network Commands](kernel-lite-small-shell-cmd-net.md) - - [arp](kernel-lite-small-shell-cmd-net-arp.md) - - [dhclient](kernel-lite-small-shell-cmd-net-dh.md) - - [dns](kernel-lite-small-shell-cmd-net-dns.md) - - [ifconfig](kernel-lite-small-shell-cmd-net-ipc.md) - - [ipdebug](kernel-lite-small-shell-cmd-net-ipd.md) - - [netstat](kernel-lite-small-shell-cmd-net-net.md) - - [ntpdate](kernel-lite-small-shell-cmd-net-ntp.md) - - [ping](kernel-lite-small-shell-cmd-net-ping.md) - - [ping6](kernel-lite-small-shell-cmd-net-ping6.md) - - [telnet](kernel-lite-small-shell-cmd-net-tel.md) - - [tftp](kernel-lite-small-shell-cmd-net-tftp.md) - - [Magic Key Usage](kernel-lite-small-shell-cmd-mag.md) - - [User-Space Exception Information](kernel-lite-small-shell-cmd-abn.md) + - [Kernel Overview](kernel-small-overview.md) + - [Kernel Startup](kernel-small-start.md) + - [Startup in Kernel Space](kernel-small-start-kernel.md) + - [Startup in User Space](kernel-small-start-user.md) + - [Basic Kernel](kernel-small-basics.md) + - [Interrupt and Exception Handling](kernel-small-basic-interrupt.md) + - [Process Management](kernel-small-basic-process.md) + - [Process](kernel-small-basic-process-process.md) + - [Thread](kernel-small-basic-process-thread.md) + - [Scheduler](kernel-small-basic-process-scheduler.md) + - [Memory Management](kernel-small-basic-memory.md) + - [Heap Memory Management](kernel-small-basic-memory-heap.md) + - [Physical Memory Management](kernel-small-basic-memory-physical.md) + - [Virtual Memory Management](kernel-small-basic-memory-virtual.md) + - [Virtual-to-Physical Mapping](kernel-small-basic-inner-reflect.md) + - [Kernel Communication Mechanisms](kernel-small-basic-trans.md) + - [Event](kernel-small-basic-trans-event.md) + - [Semaphore](kernel-small-basic-trans-semaphore.md) + - [Mutex](kernel-small-basic-trans-mutex.md) + - [Queue](kernel-small-basic-trans-queue.md) + - [RW Lock](kernel-small-basic-trans-rwlock.md) + - [Futex](kernel-small-basic-trans-user-mutex.md) + - [Signal](kernel-small-basic-trans-user-signal.md) + - [Time Management](kernel-small-basic-time.md) + - [Software Timer](kernel-small-basic-softtimer.md) + - [Atomic Operation](kernel-small-basic-atomic.md) + - [Extension Components](kernel-small-bundles.md) + - [System Call](kernel-small-bundles-system.md) + - [Dynamic Loading and Linking](kernel-small-bundles-linking.md) + - [Virtual Dynamic Shared Object](kernel-small-bundles-share.md) + - [LiteIPC](kernel-small-bundles-ipc.md) + - [File Systems](kernel-small-bundles-fs.md) + - [Virtual File System](kernel-small-bundles-fs-virtual.md) + - [Supported File Systems](kernel-small-bundles-fs-support.md) + - [FAT](kernel-small-bundles-fs-support-fat.md) + - [JFFS2](kernel-small-bundles-fs-support-jffs2.md) + - [NFS](kernel-small-bundles-fs-support-nfs.md) + - [Ramfs](kernel-small-bundles-fs-support-ramfs.md) + - [procfs](kernel-small-bundles-fs-support-procfs.md) + - [File System Adaptation](kernel-small-bundles-fs-new.md) + - [Debugging and Tools](kernel-small-debug.md) + - [Shell](kernel-small-debug-shell.md) + - [Introduction to the Shell](kernel-small-debug-shell-overview.md) + - [Shell Command Development Guidelines](kernel-small-debug-shell-guide.md) + - [Shell Command Programming Example](kernel-small-debug-shell-build.md) + - [Shell Command Reference](kernel-small-debug-shell-details.md) + - [System Commands](kernel-small-debug-shell-cmd.md) + - [cpup](kernel-small-debug-shell-cmd-cpup.md) + - [date](kernel-small-debug-shell-cmd-date.md) + - [dmesg](kernel-small-debug-shell-cmd-dmesg.md) + - [exec](kernel-small-debug-shell-cmd-exec.md) + - [free](kernel-small-debug-shell-cmd-free.md) + - [help](kernel-small-debug-shell-cmd-help.md) + - [hwi](kernel-small-debug-shell-cmd-hwi.md) + - [kill](kernel-small-debug-shell-cmd-kill.md) + - [log](kernel-small-debug-shell-cmd-log.md) + - [memcheck](kernel-small-debug-shell-cmd-memcheck.md) + - [oom](kernel-small-debug-shell-cmd-oom.md) + - [pmm](kernel-small-debug-shell-cmd-pmm.md) + - [reset](kernel-small-debug-shell-cmd-reset.md) + - [sem](kernel-small-debug-shell-cmd-sem.md) + - [stack](kernel-small-debug-shell-cmd-stack.md) + - [su](kernel-small-debug-shell-cmd-su.md) + - [swtmr](kernel-small-debug-shell-cmd-swtmr.md) + - [systeminfo](kernel-small-debug-shell-cmd-sysinfo.md) + - [task](kernel-small-debug-shell-cmd-task.md) + - [uname](kernel-small-debug-shell-cmd-uname.md) + - [vmm](kernel-small-debug-shell-cmd-vmm.md) + - [watch](kernel-small-debug-shell-cmd-watch.md) + - [File Commands](kernel-small-debug-shell-file.md) + - [cat](kernel-small-debug-shell-file-cat.md) + - [cd](kernel-small-debug-shell-file-cd.md) + - [chgrp](kernel-small-debug-shell-file-chgrp.md) + - [chmod](kernel-small-debug-shell-file-chmod.md) + - [chown](kernel-small-debug-shell-file-chown.md) + - [cp](kernel-small-debug-shell-file-cp.md) + - [format](kernel-small-debug-shell-file-format.md) + - [ls](kernel-small-debug-shell-file-ls.md) + - [lsfd](kernel-small-debug-shell-file-lsfd.md) + - [mkdir](kernel-small-debug-shell-file-mkdir.md) + - [mount](kernel-small-debug-shell-file-mount.md) + - [partinfo](kernel-small-debug-shell-file-partinfo.md) + - [partition](kernel-small-debug-shell-file-partition.md) + - [pwd](kernel-small-debug-shell-file-pwd.md) + - [rm](kernel-small-debug-shell-file-rm.md) + - [rmdir](kernel-small-debug-shell-file-rmdir.md) + - [statfs](kernel-small-debug-shell-file-statfs.md) + - [sync](kernel-small-debug-shell-file-sync.md) + - [touch](kernel-small-debug-shell-file-touch.md) + - [writeproc](kernel-small-debug-shell-file-write.md) + - [umount](kernel-small-debug-shell-file-umount.md) + - [Network Commands](kernel-small-debug-shell-net.md) + - [arp](kernel-small-debug-shell-net-arp.md) + - [dhclient](kernel-small-debug-shell-net-dhclient.md) + - [dns](kernel-small-debug-shell-net-dns.md) + - [ifconfig](kernel-small-debug-shell-net-ifconfig.md) + - [ipdebug](kernel-small-debug-shell-net-ipdebug.md) + - [netstat](kernel-small-debug-shell-net-netstat.md) + - [ntpdate](kernel-small-debug-shell-net-ntpdate.md) + - [ping](kernel-small-debug-shell-net-ping.md) + - [ping6](kernel-small-debug-shell-net-ping6.md) + - [telnet](kernel-small-debug-shell-net-telnet.md) + - [tftp](kernel-small-debug-shell-net-tftp.md) + - [Magic Key](kernel-small-debug-shell-magickey.md) + - [User-Space Exception Information](kernel-small-debug-shell-error.md) + - [Trace](kernel-small-debug-trace.md) + - [Process Commissioning](kernel-small-debug-process.md) + - [CPUP](kernel-small-debug-process-cpu.md) + - [Memory Debugging](kernel-small-debug-memory.md) + - [Memory Information Statistics](kernel-small-debug-memory-info.md) + - [Memory Leak Check](kernel-small-debug-memory-leak.md) + - [Memory Corruption Check](kernel-small-debug-memory-corrupt.md) + - [Other Kernel Debugging Methods](kernel-small-debug-other.md) + - [Dying Gasp](kernel-small-debug-trace-other-lastwords.md) + - [Common Fault Locating Methods](kernel-small-debug-trace-other-faqs.md) + - [Appendix](kernel-small-apx.md) + - [Basic Data Structure](kernel-small-apx-structure.md) + - [Doubly Linked List](kernel-small-apx-dll.md) + - [Bitwise Operation](kernel-small-apx-bitwise.md) + - [Standard Library](kernel-small-apx-library.md) - [Kernel for Standard Systems](kernel-standard.md) - - [Linux Kernel Overview](kernel-standard-des.md) + - [Linux Kernel Overview](kernel-standard-overview.md) - [Guidelines for Using Patches on OpenHarmony Development Boards](kernel-standard-patch.md) - [Guidelines for Compiling and Building the Linux Kernel](kernel-standard-build.md) \ No newline at end of file diff --git a/en/device-dev/kernel/figure/directory-switching-result.png b/en/device-dev/kernel/figure/changing-the-directory.png similarity index 100% rename from en/device-dev/kernel/figure/directory-switching-result.png rename to en/device-dev/kernel/figure/changing-the-directory.png diff --git a/en/device-dev/kernel/figure/changing-the-permission-on-the-hello-harmony-txt-file-to-666.png b/en/device-dev/kernel/figure/changing-the-permission-for-the-hello-harmony-txt-file-to-666.png similarity index 100% rename from en/device-dev/kernel/figure/changing-the-permission-on-the-hello-harmony-txt-file-to-666.png rename to en/device-dev/kernel/figure/changing-the-permission-for-the-hello-harmony-txt-file-to-666.png diff --git a/en/device-dev/kernel/figure/command-output-19.png b/en/device-dev/kernel/figure/command-output-24.png similarity index 100% rename from en/device-dev/kernel/figure/command-output-19.png rename to en/device-dev/kernel/figure/command-output-24.png diff --git a/en/device-dev/kernel/figure/cpu-accessing-the-memory-or-peripheral.png b/en/device-dev/kernel/figure/cpu-accessing-the-memory-or-peripheral.png new file mode 100644 index 0000000000000000000000000000000000000000..557c335dae9a8974bc040a983c148043edde308d Binary files /dev/null and b/en/device-dev/kernel/figure/cpu-accessing-the-memory-or-peripheral.png differ diff --git a/en/device-dev/kernel/figure/cpu-accessing-the-memory.png b/en/device-dev/kernel/figure/cpu-accessing-the-memory.png new file mode 100644 index 0000000000000000000000000000000000000000..fdea5b831680b1e3b3b03b4aa6ba8584a43d29ac Binary files /dev/null and b/en/device-dev/kernel/figure/cpu-accessing-the-memory.png differ diff --git a/en/device-dev/kernel/figure/viewing-content-of-the-current-directory.png b/en/device-dev/kernel/figure/displaying-content-of-the-current-directory.png similarity index 100% rename from en/device-dev/kernel/figure/viewing-content-of-the-current-directory.png rename to en/device-dev/kernel/figure/displaying-content-of-the-current-directory.png diff --git a/en/device-dev/kernel/figure/viewing-content-of-the-hello-harmony-txt-file.png b/en/device-dev/kernel/figure/displaying-the-content-of-hello-harmony-txt.png similarity index 100% rename from en/device-dev/kernel/figure/viewing-content-of-the-hello-harmony-txt-file.png rename to en/device-dev/kernel/figure/displaying-the-content-of-hello-harmony-txt.png diff --git a/en/device-dev/kernel/figure/querying-the-current-path.png b/en/device-dev/kernel/figure/displaying-the-current-path.png similarity index 100% rename from en/device-dev/kernel/figure/querying-the-current-path.png rename to en/device-dev/kernel/figure/displaying-the-current-path.png diff --git a/en/device-dev/kernel/figure/dynamic-loading-process.png b/en/device-dev/kernel/figure/dynamic-loading-process.png new file mode 100644 index 0000000000000000000000000000000000000000..82fd2618ba2601ebf58a35de9f15783cfcf2f6f6 Binary files /dev/null and b/en/device-dev/kernel/figure/dynamic-loading-process.png differ diff --git a/en/device-dev/kernel/figure/dynamic-memory-core-algorithm.png b/en/device-dev/kernel/figure/dynamic-memory-core-algorithm.png new file mode 100644 index 0000000000000000000000000000000000000000..226466c21b0f7375c9ef70f340ad573f2916a674 Binary files /dev/null and b/en/device-dev/kernel/figure/dynamic-memory-core-algorithm.png differ diff --git a/en/device-dev/kernel/figure/dynamic-memory-management-structure-20.png b/en/device-dev/kernel/figure/dynamic-memory-management-structure-20.png new file mode 100644 index 0000000000000000000000000000000000000000..9d98f09b73bd77ef25c732a750611bb3fb3c6b65 Binary files /dev/null and b/en/device-dev/kernel/figure/dynamic-memory-management-structure-20.png differ diff --git a/en/device-dev/kernel/figure/dynamic-memory-management-structure.png b/en/device-dev/kernel/figure/dynamic-memory-management-structure.png new file mode 100644 index 0000000000000000000000000000000000000000..e67cd13c295d19b6ce45c4749644eea42ada7f05 Binary files /dev/null and b/en/device-dev/kernel/figure/dynamic-memory-management-structure.png differ diff --git a/en/device-dev/kernel/figure/elf-file-linking-process.png b/en/device-dev/kernel/figure/elf-file-linking-process.png new file mode 100644 index 0000000000000000000000000000000000000000..dc43aa951c78b8c9d495ab3aa6d8799309e103c9 Binary files /dev/null and b/en/device-dev/kernel/figure/elf-file-linking-process.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001127390512.png b/en/device-dev/kernel/figure/en-us_image_0000001127390512.png new file mode 100644 index 0000000000000000000000000000000000000000..e51374c3cdd50fa6b7375d70871407903a5ddb3d Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001127390512.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001127519136.png b/en/device-dev/kernel/figure/en-us_image_0000001127519136.png new file mode 100644 index 0000000000000000000000000000000000000000..35c9ac9964d62ec8633b843873a39491f33f0e8b Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001127519136.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001127520662.png b/en/device-dev/kernel/figure/en-us_image_0000001127520662.png new file mode 100644 index 0000000000000000000000000000000000000000..4b583a70058c965ebe857ef500343003375220af Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001127520662.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001132778524.png b/en/device-dev/kernel/figure/en-us_image_0000001132778524.png new file mode 100644 index 0000000000000000000000000000000000000000..4470c72ff135fb2be1c38f1fa21fd459d69fc030 Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001132778524.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001132935054.png b/en/device-dev/kernel/figure/en-us_image_0000001132935054.png new file mode 100644 index 0000000000000000000000000000000000000000..677d351338e6251a0e5a85b8ecc2cc883e9ba148 Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001132935054.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001052810304.png b/en/device-dev/kernel/figure/en-us_image_0000001133848164.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001052810304.png rename to en/device-dev/kernel/figure/en-us_image_0000001133848164.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001054624363.png b/en/device-dev/kernel/figure/en-us_image_0000001133848370.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001054624363.png rename to en/device-dev/kernel/figure/en-us_image_0000001133848370.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001052370303.png b/en/device-dev/kernel/figure/en-us_image_0000001133848906.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001052370303.png rename to en/device-dev/kernel/figure/en-us_image_0000001133848906.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001053710680.png b/en/device-dev/kernel/figure/en-us_image_0000001134008030.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001053710680.png rename to en/device-dev/kernel/figure/en-us_image_0000001134008030.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001052370307.png b/en/device-dev/kernel/figure/en-us_image_0000001134008686.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001052370307.png rename to en/device-dev/kernel/figure/en-us_image_0000001134008686.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001051690323.png b/en/device-dev/kernel/figure/en-us_image_0000001134008688.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001051690323.png rename to en/device-dev/kernel/figure/en-us_image_0000001134008688.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001173429547.png b/en/device-dev/kernel/figure/en-us_image_0000001173429547.png new file mode 100644 index 0000000000000000000000000000000000000000..1d8df5ef5d0f321e976008cbf382e228d12677d6 Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001173429547.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001173449871.png b/en/device-dev/kernel/figure/en-us_image_0000001173449871.png new file mode 100644 index 0000000000000000000000000000000000000000..5aa08f77f1a41d78efb3d9afc3b8b51fec497409 Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001173449871.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001176974089.png b/en/device-dev/kernel/figure/en-us_image_0000001176974089.png new file mode 100644 index 0000000000000000000000000000000000000000..83967213305fe3726cbdad83171ef5cd235640e1 Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001176974089.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001178856385.png b/en/device-dev/kernel/figure/en-us_image_0000001178856385.png new file mode 100644 index 0000000000000000000000000000000000000000..95559dc4ba466440f1ee1aa7a1d894ffa1dd78df Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001178856385.png differ diff --git a/en/device-dev/kernel/figure/en-us_image_0000001052530298.png b/en/device-dev/kernel/figure/en-us_image_0000001179847649.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001052530298.png rename to en/device-dev/kernel/figure/en-us_image_0000001179847649.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001052810300.png b/en/device-dev/kernel/figure/en-us_image_0000001179848349.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001052810300.png rename to en/device-dev/kernel/figure/en-us_image_0000001179848349.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001053224218.png b/en/device-dev/kernel/figure/en-us_image_0000001179848731.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001053224218.png rename to en/device-dev/kernel/figure/en-us_image_0000001179848731.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001053826366.png b/en/device-dev/kernel/figure/en-us_image_0000001179967527.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001053826366.png rename to en/device-dev/kernel/figure/en-us_image_0000001179967527.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001052370305.png b/en/device-dev/kernel/figure/en-us_image_0000001179967909.png similarity index 100% rename from en/device-dev/kernel/figure/en-us_image_0000001052370305.png rename to en/device-dev/kernel/figure/en-us_image_0000001179967909.png diff --git a/en/device-dev/kernel/figure/en-us_image_0000001191018697.png b/en/device-dev/kernel/figure/en-us_image_0000001191018697.png new file mode 100644 index 0000000000000000000000000000000000000000..9a59650368d40f7a2fdffeab84e844b0671c9906 Binary files /dev/null and b/en/device-dev/kernel/figure/en-us_image_0000001191018697.png differ diff --git a/en/device-dev/kernel/figure/event-working-mechanism-21.png b/en/device-dev/kernel/figure/event-working-mechanism-21.png new file mode 100644 index 0000000000000000000000000000000000000000..ff238b1b976f7e51f3f13d495be2a01f18b327f9 Binary files /dev/null and b/en/device-dev/kernel/figure/event-working-mechanism-21.png differ diff --git a/en/device-dev/kernel/figure/event-working-mechanism.png b/en/device-dev/kernel/figure/event-working-mechanism.png new file mode 100644 index 0000000000000000000000000000000000000000..ff238b1b976f7e51f3f13d495be2a01f18b327f9 Binary files /dev/null and b/en/device-dev/kernel/figure/event-working-mechanism.png differ diff --git a/en/device-dev/kernel/figure/exported-symbol-table-information.png b/en/device-dev/kernel/figure/exported-symbol-table-information.png new file mode 100644 index 0000000000000000000000000000000000000000..87d6aaf4a5f1d7f25c2ee2c964931c71388b043d Binary files /dev/null and b/en/device-dev/kernel/figure/exported-symbol-table-information.png differ diff --git a/en/device-dev/kernel/figure/futex-design.jpg b/en/device-dev/kernel/figure/futex-design.jpg new file mode 100644 index 0000000000000000000000000000000000000000..f6c83d6434f3c68d1baecbf42db9a3df21568b49 Binary files /dev/null and b/en/device-dev/kernel/figure/futex-design.jpg differ diff --git a/en/device-dev/kernel/figure/heap-memory-core-algorithm.png b/en/device-dev/kernel/figure/heap-memory-core-algorithm.png new file mode 100644 index 0000000000000000000000000000000000000000..8fa49b71f46505f335a5e782cbef362f7336fdaa Binary files /dev/null and b/en/device-dev/kernel/figure/heap-memory-core-algorithm.png differ diff --git a/en/device-dev/kernel/figure/kernel-architecture.png b/en/device-dev/kernel/figure/kernel-architecture.png new file mode 100644 index 0000000000000000000000000000000000000000..1e120a02344a848cc8b87b58f6c86a5f97e560c1 Binary files /dev/null and b/en/device-dev/kernel/figure/kernel-architecture.png differ diff --git a/en/device-dev/kernel/figure/kernel-startup-process.png b/en/device-dev/kernel/figure/kernel-startup-process.png new file mode 100644 index 0000000000000000000000000000000000000000..e20abdc4493bc503efab410f444135c48d0ec250 Binary files /dev/null and b/en/device-dev/kernel/figure/kernel-startup-process.png differ diff --git a/en/device-dev/kernel/figure/liteos-m-kernel-dynamic-loading-architecture.png b/en/device-dev/kernel/figure/liteos-m-kernel-dynamic-loading-architecture.png new file mode 100644 index 0000000000000000000000000000000000000000..a460e8dbf1953929bb31be3323fc716f2cdaf9ad Binary files /dev/null and b/en/device-dev/kernel/figure/liteos-m-kernel-dynamic-loading-architecture.png differ diff --git a/en/device-dev/kernel/figure/mapping-between-the-virtual-and-physical-memory-addresses.png b/en/device-dev/kernel/figure/mapping-between-the-virtual-and-physical-memory-addresses.png new file mode 100644 index 0000000000000000000000000000000000000000..cbd0d5b871519d388a07f2d20b655c2f42e2e384 Binary files /dev/null and b/en/device-dev/kernel/figure/mapping-between-the-virtual-and-physical-memory-addresses.png differ diff --git a/en/device-dev/kernel/figure/mutex-working-mechanism-23.png b/en/device-dev/kernel/figure/mutex-working-mechanism-23.png new file mode 100644 index 0000000000000000000000000000000000000000..870e3441f4988be3d73ac9a4f844dda8ecc0773c Binary files /dev/null and b/en/device-dev/kernel/figure/mutex-working-mechanism-23.png differ diff --git a/en/device-dev/kernel/figure/mutex-working-mechanism.png b/en/device-dev/kernel/figure/mutex-working-mechanism.png new file mode 100644 index 0000000000000000000000000000000000000000..870e3441f4988be3d73ac9a4f844dda8ecc0773c Binary files /dev/null and b/en/device-dev/kernel/figure/mutex-working-mechanism.png differ diff --git a/en/device-dev/kernel/figure/overall-file-system-architecture.png b/en/device-dev/kernel/figure/overall-file-system-architecture.png new file mode 100644 index 0000000000000000000000000000000000000000..07ca835af056e96dbbf0f08f9015eb2ea1c45380 Binary files /dev/null and b/en/device-dev/kernel/figure/overall-file-system-architecture.png differ diff --git a/en/device-dev/kernel/figure/physical-memory-usage-distribution.png b/en/device-dev/kernel/figure/physical-memory-usage-distribution.png new file mode 100644 index 0000000000000000000000000000000000000000..15f281d6d946cb9b02ebb3e98de983362bb41385 Binary files /dev/null and b/en/device-dev/kernel/figure/physical-memory-usage-distribution.png differ diff --git a/en/device-dev/kernel/figure/process-of-creating-a-vnode.png b/en/device-dev/kernel/figure/process-of-creating-a-vnode.png new file mode 100644 index 0000000000000000000000000000000000000000..196379c4e96421909b045bdfee66aad69ed09855 Binary files /dev/null and b/en/device-dev/kernel/figure/process-of-creating-a-vnode.png differ diff --git a/en/device-dev/kernel/figure/process-of-loading-an-elf-file.png b/en/device-dev/kernel/figure/process-of-loading-an-elf-file.png new file mode 100644 index 0000000000000000000000000000000000000000..23bc27b7de00aeb9d1ff9fa349c1be4fe4559b18 Binary files /dev/null and b/en/device-dev/kernel/figure/process-of-loading-an-elf-file.png differ diff --git a/en/device-dev/kernel/figure/process-of-locating-a-file.png b/en/device-dev/kernel/figure/process-of-locating-a-file.png new file mode 100644 index 0000000000000000000000000000000000000000..1f2a1adb1e33ba8847dfc45b1eb496bac7639d67 Binary files /dev/null and b/en/device-dev/kernel/figure/process-of-locating-a-file.png differ diff --git a/en/device-dev/kernel/figure/state-transition-of-a-process.png b/en/device-dev/kernel/figure/process-state-transition.png similarity index 100% rename from en/device-dev/kernel/figure/state-transition-of-a-process.png rename to en/device-dev/kernel/figure/process-state-transition.png diff --git a/en/device-dev/kernel/figure/process-tree.png b/en/device-dev/kernel/figure/process-tree.png new file mode 100644 index 0000000000000000000000000000000000000000..25dc996ca88dffc3128c89853f09caf585c4e7a9 Binary files /dev/null and b/en/device-dev/kernel/figure/process-tree.png differ diff --git a/en/device-dev/kernel/figure/program-execution-process.png b/en/device-dev/kernel/figure/program-execution-process.png new file mode 100644 index 0000000000000000000000000000000000000000..41e88e6c7eaa02179eb2f1f2637fc5c07cc3eb03 Binary files /dev/null and b/en/device-dev/kernel/figure/program-execution-process.png differ diff --git a/en/device-dev/kernel/figure/querying-information-about-a-specified-software-timer.png b/en/device-dev/kernel/figure/querying-information-about-software-timer-1.png similarity index 100% rename from en/device-dev/kernel/figure/querying-information-about-a-specified-software-timer.png rename to en/device-dev/kernel/figure/querying-information-about-software-timer-1.png diff --git a/en/device-dev/kernel/figure/reading-and-writing-data-in-a-queue.png b/en/device-dev/kernel/figure/reading-and-writing-data-in-a-queue.png new file mode 100644 index 0000000000000000000000000000000000000000..677d351338e6251a0e5a85b8ecc2cc883e9ba148 Binary files /dev/null and b/en/device-dev/kernel/figure/reading-and-writing-data-in-a-queue.png differ diff --git a/en/device-dev/kernel/figure/relationship-between-the-vfs-and-file-systems.png b/en/device-dev/kernel/figure/relationship-between-the-vfs-and-file-systems.png deleted file mode 100644 index e1f42cf60e872242c72175b91f2fe14404c439be..0000000000000000000000000000000000000000 Binary files a/en/device-dev/kernel/figure/relationship-between-the-vfs-and-file-systems.png and /dev/null differ diff --git a/en/device-dev/kernel/figure/releasing-memory.png b/en/device-dev/kernel/figure/releasing-memory.png new file mode 100644 index 0000000000000000000000000000000000000000..750f4a56f9fba8c2dc75bbd675b0934ccfd8987d Binary files /dev/null and b/en/device-dev/kernel/figure/releasing-memory.png differ diff --git a/en/device-dev/kernel/figure/requesting-memory.png b/en/device-dev/kernel/figure/requesting-memory.png new file mode 100644 index 0000000000000000000000000000000000000000..6899061a11a0653d0013d0ec89272713cc90cce4 Binary files /dev/null and b/en/device-dev/kernel/figure/requesting-memory.png differ diff --git a/en/device-dev/kernel/figure/semaphore-working-mechanism-22.png b/en/device-dev/kernel/figure/semaphore-working-mechanism-22.png new file mode 100644 index 0000000000000000000000000000000000000000..4981aad660fbc82d9ae016b27e2b50fff9f66eec Binary files /dev/null and b/en/device-dev/kernel/figure/semaphore-working-mechanism-22.png differ diff --git a/en/device-dev/kernel/figure/semaphore-working-mechanism.png b/en/device-dev/kernel/figure/semaphore-working-mechanism.png new file mode 100644 index 0000000000000000000000000000000000000000..4981aad660fbc82d9ae016b27e2b50fff9f66eec Binary files /dev/null and b/en/device-dev/kernel/figure/semaphore-working-mechanism.png differ diff --git a/en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-20.png b/en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-25.png similarity index 100% rename from en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-20.png rename to en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-25.png diff --git a/en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-21.png b/en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-26.png similarity index 100% rename from en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-21.png rename to en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-26.png diff --git a/en/device-dev/kernel/figure/stack-analysis-mechanism.png b/en/device-dev/kernel/figure/stack-analysis-mechanism.png new file mode 100644 index 0000000000000000000000000000000000000000..0c10e4285f0b2c1a992228770a49c497f5382725 Binary files /dev/null and b/en/device-dev/kernel/figure/stack-analysis-mechanism.png differ diff --git a/en/device-dev/kernel/figure/static-memory.png b/en/device-dev/kernel/figure/static-memory.png new file mode 100644 index 0000000000000000000000000000000000000000..1b116a8e0c8636dc0ebebbf0dc6bda44da14927d Binary files /dev/null and b/en/device-dev/kernel/figure/static-memory.png differ diff --git a/en/device-dev/kernel/figure/system-call.png b/en/device-dev/kernel/figure/system-call.png new file mode 100644 index 0000000000000000000000000000000000000000..df2b50e6f5b94e142197a43ebc25d854d279aadc Binary files /dev/null and b/en/device-dev/kernel/figure/system-call.png differ diff --git a/en/device-dev/kernel/figure/task-state-transition.png b/en/device-dev/kernel/figure/task-state-transition.png new file mode 100644 index 0000000000000000000000000000000000000000..efa7fbd8c7bf2705de70bb5d5c3fff332845f8aa Binary files /dev/null and b/en/device-dev/kernel/figure/task-state-transition.png differ diff --git a/en/device-dev/kernel/figure/state-transition-of-a-thread.png b/en/device-dev/kernel/figure/thread-state-transition.png similarity index 100% rename from en/device-dev/kernel/figure/state-transition-of-a-thread.png rename to en/device-dev/kernel/figure/thread-state-transition.png diff --git a/en/device-dev/kernel/figure/tree-structure-of-the-file-system.png b/en/device-dev/kernel/figure/tree-structure-of-the-file-system.png deleted file mode 100644 index 06eab22e518c211b23cc5f410c29643789057cef..0000000000000000000000000000000000000000 Binary files a/en/device-dev/kernel/figure/tree-structure-of-the-file-system.png and /dev/null differ diff --git a/en/device-dev/kernel/figure/vdso-system-design.jpg b/en/device-dev/kernel/figure/vdso-system-design.jpg new file mode 100644 index 0000000000000000000000000000000000000000..2fc9b66eb49cc4c0d5b1365c0807fd2496350a80 Binary files /dev/null and b/en/device-dev/kernel/figure/vdso-system-design.jpg differ diff --git a/en/device-dev/kernel/kernel-basic-mini-time.md b/en/device-dev/kernel/kernel-basic-mini-time.md new file mode 100644 index 0000000000000000000000000000000000000000..f529600d20d028ff8b37db064ac67b36feb0c0bd --- /dev/null +++ b/en/device-dev/kernel/kernel-basic-mini-time.md @@ -0,0 +1,7 @@ +# Time Management + +- **[Basic Concepts](kernel-mini-basic-time-basic.md)** + +- **[Development Guidelines](kernel-mini-basic-time-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-lite-mini.md b/en/device-dev/kernel/kernel-lite-mini.md index f87451dcc80d174191386a4112bd676fe6a9ab4b..c1bba9a66cf318508c21ddc058b81ea9d74bf26b 100644 --- a/en/device-dev/kernel/kernel-lite-mini.md +++ b/en/device-dev/kernel/kernel-lite-mini.md @@ -1,2 +1,13 @@ # Kernel for Mini Systems +- **[Kernel Overview](kernel-mini-overview.md)** + +- **[Basic Kernel](kernel-mini-basic.md)** + +- **[Extension Components](kernel-mini-extend.md)** + +- **[Kernel Debugging](kernel-memory-inner.md)** + +- **[Appendix](kernel-mini-app.md)** + + diff --git a/en/device-dev/kernel/kernel-lite-small-basic.md b/en/device-dev/kernel/kernel-lite-small-basic.md deleted file mode 100644 index d373831984d8fa1e3dd10572af268edf6444f4c1..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-basic.md +++ /dev/null @@ -1,11 +0,0 @@ -# Basic Kernel - -- **[Process](kernel-lite-small-process.md)** - -- **[Thread](kernel-lite-small-thread.md)** - -- **[Memory](kernel-lite-small-memory.md)** - -- **[Network](kernel-lite-small-net.md)** - - diff --git a/en/device-dev/kernel/kernel-lite-small-file-fat.md b/en/device-dev/kernel/kernel-lite-small-file-fat.md deleted file mode 100644 index 3f4cafec157cc64e575ce62e88bf75a84ea60c0a..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-file-fat.md +++ /dev/null @@ -1,108 +0,0 @@ -# FAT - -- [Overview](#section17906101815113) -- [Important Notes](#section781233610116) -- [Development Guidelines](#section26081559713) - -## Overview - -There are FAT12, FAT16, and FAT32. A FAT file system divides a hard disk into five areas: MBR, DBR, FAT, DIR, and DATA. - -FAT supports multiple media, especially removable storage media \(such as USB flash drives, SD cards, and portable hard disks\). In this way, embedded devices can be better compatible with desktop systems such as Windows and Linux, facilitating file management and operation. - -FAT in the OpenHarmony kernel features low code, less resource occupation, tailorability, and multiple physical media support. It is compatible with systems such as Windows and Linux, and provides functions such as identification of multiple devices and partitions. - -The OpenHarmony kernel supports multiple partitions on the hard disk. A FAT file system can be created on the primary or logical partition. The OpenHarmony kernel can also identify other types of file systems on the hard disk. - -## Important Notes - -- A maximum of 512 FATFS files or folders that can be opened simultaneously. - -- After a file is opened in writable mode, the file cannot be opened again before it is closed. To open a file for multiple times, the read-only attribute can be used only. If a file is opened for a long time and is not closed, data loss will occur. The file can be saved only after being closed. - -- The size of an individual FAT file cannot be greater than 4 GB. - -- When there are two SD card slots, the first card inserted is card 0, and that inserted later is card 1. - -- When multi-partition is enabled and there are multiple partitions, the device node **/dev/mmcblk0** \(primary device\) registered by card 0 and **/dev/mmcblk0p0** \(secondary device\) are the same device. In this case, you cannot perform operations on the primary device. - -- The read and write pointers are not separated. Therefore, after a file is opened in **O\_APPEND** mode, the read pointer is also at the end of the file. You must manually set the position of the read pointer before reading the file. - -- The file modification time is obtained by the **stat** and **lstat** functions. The creation time and last access time cannot be obtained. As limited by the FAT protocol, the time before 1980 is not supported. - -- When you use **open** with the parameter **O\_TRUNC** to open a file, the file content will be cleared. - -- You can perform the following operations on FAT files: **open**, **close**, **read**, **write**, **seek**, **sync**, **opendir**, **closedir**, **readdir**, **rewinddir**, **readdir\_r**, **statfs**, **remove**, **unlink**, **mkdir**, **rmdir**, **rename**, **stat**, **stat64**, **seek64**, **fallocate**, **fallocate64**, **truncate**, **truncate64**, **mount**, and **umount**. - -- To prevent SD card exceptions and memory leakage, opened files and directories must be closed and mounted nodes must be unmounted before an SD card is removed. - -- If a FAT file system has been mounted before the **format** operation, ensure that all directories and files are closed. Otherwise, the **format** operation will fail. - -- FAT supports mounting with the read-only attribute. - - - When **MS\_RDONLY** is carried in the **mount** function, the read-only attribute is enabled for the FAT file system. All APIs with the write attribute, such as **write**, **mkdir**, and **unlink**, and files that are opened not by using the attribute **O\_RDONLY** are rejected and the error code **EACCESS** is thrown. - - - When **MS\_NOSYNC** is carried in the **mount** function, FAT does not proactively write the content in the cache back to the storage device. The FAT-related APIs **open**, **close**, **unlink**, **rename**, **mkdir**, **rmdir**, and **truncate** do not automatically perform the **sync** operation, which improves the operation speed. However, the upper layer must actively invoke the **sync** operation to synchronize data. Otherwise, data may be lost after a power outage. - - -- The FAT file system supports periodical cache flushing. After **LOSCFG\_FS\_FAT\_CACHE\_SYNC\_THREAD** is enabled in **menuconfig**, the OpenHarmony kernel creates a task to flush the cache. By default, the OpenHarmony kernel checks the percentage of dirty data blocks in the cache every 5 seconds. If the percentage exceeds 80%, the OpenHarmony kernel performs the **sync** operation to write all dirty data in the cache back to the disk. The task priority, flush interval, and dirty data block percentage thresholds can be set by calling **LOS\_SetSyncThreadPrio**, **LOS\_SetSyncThreadInterval**, and **LOS\_SetDirtyRatioThreshold**, respectively. - -- The default cache size is 16 blocks, and each block has 256 sectors. - - -## Development Guidelines - -**Device Identification** - -- Multi-partition is enabled if **FF\_MULTI\_PARTITION** in the **ffconf.h** file is set to **1**. - -- Multi-device is enabled if **FF\_VOLUMES** in the **ffconf.h** file is greater than 2. - - -When multi-device and multi-partition are enabled, the system automatically identifies an inserted SD card and registers the device node. **mmcblk0** \(card 0\) and **mmcblk1** \(card 1\) are independent primary devices. **mmcblk0p0** and **mmcblk0p1** are two partitions of card 0 and can be used as partitions. Do not use the primary device if a partition exists. - -You can run the **partinfo** command to view information about identified partitions. - -``` -OHOS # partinfo /dev/mmcblk0p0 -part info : -disk id : 0 -part_id in system: 0 -part no in disk : 0 -part no in mbr : 1 -part filesystem : 0C -part dev name : mmcblk0p0 -part sec start : 8192 -part sec count : 31108096 -``` - -**FAT Mounting** - -Mount a FAT file system. - -``` -OHOS # mount /dev/mmcblk0p0 /vs/sd vfat -``` - -If the following information is displayed, the FAT file system is mounted: - -``` -OHOS # mount /dev/mmcblk0p0 /vs/sd vfat -mount ok -``` - -**FAT Unmounting** - -Unmount the FAT file system. - -``` -OHOS # umount /vs/sd -``` - -If the following information is displayed, the FAT file system is unmounted: - -``` -OHOS # umount /vs/sd -umount ok -``` - diff --git a/en/device-dev/kernel/kernel-lite-small-file-jffs.md b/en/device-dev/kernel/kernel-lite-small-file-jffs.md deleted file mode 100644 index 59ac9f446b92de500cb9301acc0defd6de4c9f60..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-file-jffs.md +++ /dev/null @@ -1,171 +0,0 @@ -# JFFS2 - -- [Overview](#section01261544730) -- [Important Notes](#section94343420) -- [Development Guidelines](#section14979101812411) - -## Overview - -JFFS2 is a journal-type file system implemented on MTDs. JFFS2 is mainly used in NOR flash memory. It is readable and writable, supports data compression and write leveling, and provides crash/power failure protection. - -There are many differences between flash memory and disk media. Therefore, running a disk file system directly on flash memory causes poor performance and security. JFFS2 is introduced as a file system specially designed for flash memory. - -JFFS2 in the OpenHarmony kernel is mainly used to manage files of the NOR flash memory and supports multiple partitions. - -## Important Notes - -- The JFFS2 file system is used for NOR flash memory, and NOR flash driver APIs are called. Therefore, before using the JFFS2 file system, ensure that the NOR flash memory is available on the hardware and the driver is initialized \(the return value of **spinor\_init\(\)** is **0**\). - -- The system automatically aligns the start address and partition size based on the block size. The valid partition number ranges from 0 to 19. - -- **mkfs.jffs2** is supported. You can change parameter values based on service requirements. - -- When you use **open** with the parameter **O\_TRUNC** to open a file, the file content will be cleared. - -- You can perform the following operation on JFFS2 files: **open**, **close**, **read**, **write**, **seek**, **opendir**, **closedir**, **readdir**, **readdir\_r**, **rewinddir**, **statfs**, **sync**, **remove**, **unlink**, **mkdir**, **rmdir**, **rename**, **stat**, **stat64**, **seek64**, **mmap**, **mount**, **umount**, **chmod**, and **chown**. - -- JFFS2 files can be mounted in the read-only attribute. When **MS\_RDONLY** is carried in the **mount** function, the read-only attribute is enabled. All APIs with the write attribute, such as **write**, **mkdir**, and **unlink**, and files that are opened not by using **O\_RDONLY**, are rejected and the error code **EACCESS** is returned. - - -## Development Guidelines - -**Adding a JFFS2 Partition** - -Call **add\_mtd\_partition** to add a JFFS2 partition. This function automatically names the device node in the format of **/dev/spinorblk** plus the partition number. - -The **add\_mtd\_partition** function has four parameters. The first parameter indicates the medium, which can be **nand** or **spinor**. A JFFS2 partition is used on **spinor**, whereas **nand** is provided for a YAFFS2 partition. - -The second parameter indicates the start address, and the third parameter indicates the partition size. Both parameters are transferred in hexadecimal format. - -The last parameter indicates the partition number, which ranges from 0 to 19. - -``` -INT32 uwRet; -if (uwRet = add_mtd_partition("spinor", 0x100000, 0x800000, 0) != 0) { - dprintf("add jffs2 partition failed, return %d\n", uwRet); -} else { - dprintf("Mount jffs2 on spinor.\n"); - uwRet = mount("/dev/spinorblk0", "/jffs0", "jffs2", 0, NULL); - if (uwRet) { - dprintf("mount jffs2 err %d\n", uwRet); - dprintf("Mount jffs2 on nor finished.\n"); - } -} - -if (uwRet = add_mtd_partition("spinor", 0x900000, 0x200000, 1) != 0) { - dprintf("add jffs2 partition failed, return %d\n", uwRet); -} -``` - -After the partition is added, you can run **partition spinor** in **shell** to view the information about the spinor flash partition. - -``` -OHOS # partition spinor -spinor partition num:0, dev name:/dev/spinorblk0, mountpt:/jffs0, startaddr:0x0100000,length:0x0800000 -spinor partition num:1, dev name:/dev/spinorblk1, mountpt:(null), startaddr:0x0900000,length:0x0200000 -``` - -**Mounting JFFS2** - -Call **mount\(\)** to mount a device node and mount point. - -This function has five parameters. The first parameter indicates the device node, which must match the **add\_mtd\_partition\(\)** function. The second parameter indicates the mount point. The third parameter indicates the file system type. - -The last two parameters indicate the mounting flag and data. The default values are **0** and **NULL**, respectively. This operation can also be implemented by running the **mount** command in **shell**. You do not need to specify the last two parameters. - -Mount a JFFS2 file system. - -``` -OHOS # mount /dev/spinorblk1 /jffs1 jffs2 -``` - -If the following information is displayed, the JFFS2 file system is mounted: - -``` -OHOS # mount /dev/spinorblk1 /jffs1 jffs2 -mount OK -``` - -Now, you can read and write the NOR flash memory. - -**Unmounting JFFS2** - -Call **umount\(\)** to unmount the partition. You only need to provide the correct mount point. - -Unmount JFFS2. - -``` -OHOS # umount /jffs1 -``` - -If the following information is displayed, the JFFS2 file system is unmounted: - -``` -OHOS # umount /jffs1 -umount ok -``` - -**Deleting a JFFS2 Partition** - -Call **delete\_mtd\_partition** to delete an unmounted partition. - -This function has two parameters. The first parameter is the partition number, and the second parameter is the medium type. This function corresponds to the **add\_mtd\_partition\(\)** function. - -``` -INT32 uwRet; -uwRet = delete_mtd_partition(1,"spinor"); -if(uwRet != 0) { - printf("delete jffs2 error\n"); -} else { - printf("delete jffs2 ok\n"); -} - -OHOS # partition spinor -spinor partition num:0, dev name:/dev/spinorblk0, mountpt:/jffs0, startaddr:0x0100000,length:0x0800000 -``` - -**Creating a JFFS2 File System Image** - -Use the **mkfs.jffs2** tool to create an image. The default page size is 4 KiB, and the default eraseblock size is 64 KiB. The image size adapts to the source directory and is filled with 0xFF, which is an integer multiple of the eraseblock size. The default command is as follows. If the actual parameters are different from the following parameters, use the actual parameters. - -``` -./mkfs.jffs2 -d rootfs/ -o rootfs.jffs2 -``` - -**Table 1** Commands - - - - - - - - - - - - - - - - - - - - - - -

Command

-

Description

-

-s

-

Page size. If this parameter is not specified, the default value 4KiB is used.

-

-e

-

eraseblock size. If this parameter is not specified, the default value 64KiB is used.

-

-p

-

Image size. If this parameter is not specified, the source directory is used by default, and 0xFF is filled as an integer multiple of the eraseblock size.

-

-d

-

Source directory of the file system image.

-

-o

-

Image name.

-
- diff --git a/en/device-dev/kernel/kernel-lite-small-file-nfs.md b/en/device-dev/kernel/kernel-lite-small-file-nfs.md deleted file mode 100644 index 7b93df28d139c1347f291481370518c7ccb3bbb1..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-file-nfs.md +++ /dev/null @@ -1,163 +0,0 @@ -# NFS - -- [Overview](#section18322139164413) -- [Important Notes](#section532912331467) -- [Development Guidelines](#section166873374711) - -## Overview - -NFS allows you to share files across hosts and OSs over a network. You can treat NFS as a file system service, which is equivalent to folder sharing in the Windows OS to some extent. - -An NFS client can mount a directory shared by a remote NFS server to the local host to run programs and share files without occupying the current system resources. The directory of the remote server is like a disk to the local host. - -## Important Notes - -- NFS files do not support permissions control. Use file permission **777** when creating NFS directories and files. - -- NFS files do not support read or write blocking. - -- NFS files do not support the signal function. - -- In NFS, the path length \(excluding the IP address\) in a **mount** operation cannot exceed 255 characters. If the maximum length is exceeded, the error code **ENAMETOOLONG** error is returned. - -- You can perform the following operation on NFS files: **open**, **close**, **read**, **write**, **seek**, **dup**, **dup2**, **sync**, **opendir**, **closedir**, **readdir**, **readdir\_r**, **rewinddir**, **scandir**, **statfs**, **remove**, **unlink**, **mkdir**, **rmdir**, **rename**, **stat**, **stat64**, **seek64**, **mmap**, **mount**, and **umount**. - -- Two transport layer protocols are supported in NFS: TCP \(default\) and UDP. - -- When you use **open** with the parameter **O\_TRUNC** to open a file, the file content will be cleared only when you have the write permission on the file. - -- When file A is not closed and the **rename\(\)** function renames file A as B, the fd is not changed. - -- The NFS feature is currently in the beta test and may be unstable. You are advised not to use the feature in commercial products. - - -## Development Guidelines - -1. **Create an NFS server.** - - This section uses the Ubuntu operating system \(OS\) as an example to describe how to configure an NFS server. - - 1. Install the NFS server software. - - Set the download source of the Ubuntu OS when the network connection is normal. - - ``` - sudo apt-get install nfs-kernel-server - ``` - - 2. Create a directory for mounting and set full permissions for the directory. - - ``` - mkdir /home/sqbin/nfs - sudo chmod 777 /home/sqbin/nfs - ``` - - 3. Configure and start the NFS server. - - Append the following line in the **/etc/exports** file: - - ``` - /home/sqbin/nfs *(rw,no_root_squash,async) - ``` - - **/home/sqbin/nfs** is the root directory shared by the NFS server. - - Start the NFS server. - - ``` - sudo /etc/init.d/nfs-kernel-server start - ``` - - Restart the NFS server. - - ``` - sudo /etc/init.d/nfs-kernel-server restart - ``` - - -2. **Configure a board as the NFS client.** - - In this section, the NFS client is a device running the OpenHarmony kernel. - - 1. Set the hardware connection. - - Connect the OpenHarmony kernel device to the NFS server. Set their IP addresses in the same network segment. For example, set the IP address of the NFS server to **10.67.212.178/24** and set the IP address of the OpenHarmony kernel device to **10.67.212.3/24**. Note that the preceding IP addresses are private IP addresses used as examples. You need to use your actual IP addresses. - - You can run the **ifconfig** command to view the device's IP address. - - 2. Start the network and ensure that the network between the board and NFS server is normal. - - Start the Ethernet or another type of network, and then run **ping** to check whether the network connection to the server is normal. - - ``` - OHOS # ping 10.67.212.178 - [0]Reply from 10.67.212.178: time=1ms TTL=63 - [1]Reply from 10.67.212.178: time=0ms TTL=63 - [2]Reply from 10.67.212.178: time=1ms TTL=63 - [3]Reply from 10.67.212.178: time=1ms TTL=63 - --- 10.67.212.178 ping statistics --- - 4 packets transmitted, 4 received, 0 loss - ``` - - Initialize the NFS client. - - ``` - OHOS # mkdir /nfs - OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000 - ``` - - If the following information is displayed, the NFS client is initialized. - - ``` - OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000 - Mount nfs on 10.67.212.178:/home/sqbin/nfs, uid:1011, gid:1000 - Mount nfs finished. - ``` - - This command mounts the **/home/sqbin/nfs** directory on the NFS server whose IP address is 10.67.212.178 to the **/nfs** directory on the device. - - >![](../public_sys-resources/icon-note.gif) **NOTE:** - >This section assumes that the NFS server is available, that is, the **/home/sqbin/nfs** directory on the NFS server 10.67.212.178 is accessible. - - The **mount** command format is as follows: - - ``` - mount nfs - ``` - - In this command, **SERVER\_IP** indicates the IP address of the NFS server, **SERVER\_PATH** indicates the path of the shared directory on the NFS server, and **CLIENT\_PATH** indicates the NFS path on the device. - - If you do not want to restrict the NFS access permission, set the permission of the NFS root directory to **777** on the Linux CLI. - - ``` - chmod -R 777 /home/sqbin/nfs - ``` - - The NFS client setting is complete, and the NFS file system has been mounted. - - -3. **Share files using NFS.** - - Create the **dir** directory on the NFS server and save the directory. Run the **ls** command in the OpenHarmony kernel. - - ``` - OHOS # ls /nfs - ``` - - The following information is returned from the serial port: - - ``` - OHOS # ls /nfs - Directory /nfs: - drwxr-xr-x 0 u:0 g:0 dir - ``` - - The **dir** directory created on the NFS server has been synchronized to the **/nfs** directory on the device. - - Similarly, you can create files and directories on the device and access them on the NFS server. - - **Platform differences:** - - Currently, the NFS client supports some NFS v3 specifications. Therefore, the NFS client is not fully compatible with all types of NFS servers. During the development and test, you are advised to use the Linux NFS server. - - diff --git a/en/device-dev/kernel/kernel-lite-small-file-ramfs.md b/en/device-dev/kernel/kernel-lite-small-file-ramfs.md deleted file mode 100644 index 7dfad727c5ae2abe47e9e7582995b5221e8f268b..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-file-ramfs.md +++ /dev/null @@ -1,90 +0,0 @@ -# RAMFS - -- [Overview](#section7216205735619) -- [Important Notes](#section970375615711) -- [Development Guidelines](#section18433111125812) - -## Overview - -RAMFS is a RAM-based file system whose size can be dynamically adjusted. RAMFS does not have a backup storage source. Directory entries and page caches are allocated when files are written into RAMFS. However, data is not written back to any other storage medium, and data is lost after a power outage. - -RAMFS stores all files in RAM, and read/write operations are performed in RAM. RAMFS is generally used to store temporary data or data that needs to be frequently modified, such as the **/tmp** and **/var** directories. Using RAMFS reduces the read/write loss of the memory and improves the data read/write speed. - -RAMFS in the OpenHarmony kernel is a simple file system and provides a storage buffer for RAM-based dynamic file systems. - -RAMFS in the OpenHarmony kernel is based on VFS and cannot be formatted. - -## Important Notes - -- The read and write pointers of RAMFS are not separated. Therefore, after a file is opened in **O\_APPEND** mode, the read pointer is also at the end of the file. You must manually set the position of the read pointer before reading the file. - -- A RAMFS file system can be mounted only once. After it is mounted to a directory, it cannot be mounted to other directories. - -- The number of RAMFS files is restricted by semaphore resources and cannot exceed the value of **LOSCFG\_BASE\_IPC\_SEM\_LIMIT**. - -- When you use **open** with the parameter **O\_TRUNC** to open a file, the file content will be cleared. - - -- You can perform the following operation on RAMFS files: **open**, **close**, **read**, **write**, **seek**, **opendir**, **closedir**, **readdir**, **readdir\_r**, **rewinddir**, **sync**, **statfs**, **remove**, **unlink**, **mkdir**, **rmdir**, **rename**, **stat**, **stat64**, **seek64**, **mmap**, **mount**, and **umount**. - - -- RAMFS is under debugging and disabled by default. Do not use it in formal products. - - -## Development Guidelines - -You can mount or unmount RAMFS using either of the following methods: - -- Using code: - 1. Call the **mount** function to mount the RAMFS file system. - - ``` - void ram_fs_init(void) { - int swRet; - swRet = mount(NULL, RAMFS_DIR, "ramfs", 0, NULL); - if (swRet != 0) { - dprintf("mount ramfs err %d\n", swRet); - return; - } - dprintf("Mount ramfs finished.\n"); - } - ``` - - If the following information is displayed during the startup of the OpenHarmony kernel, the RAMFS file system is successfully mounted: - - ``` - Mount ramfs finished - ``` - - 2. Call the **umount** function to unmount the RAMFS file system. The following information will be displayed in the OpenHarmony kernel if the RAMFS file system is successfully unmounted. - - ``` - void ram_fs_uninit(void) { - int swRet; - swRet = umount(RAMFS_DIR); - if (swRet != 0) { - dprintf("Umount ramfs err %d\n", swRet); - return; - } - dprintf("Umount ramfs finished.\n"); - } - ``` - - -- Using commands: - 1. Run the **mount** command to mount the RAMFS file system. If the following information is displayed, the RAMFS file system is successfully mounted: - - ``` - OHOS # mount 0 /ramfs ramfs - mount ok - ``` - - 2. Run the **umount** command to unmount the RAMFS file system. If the following information is displayed, the RAMFS file system is successfully unmounted: - - ``` - OHOS # umount /ramfs - umount ok - ``` - - - diff --git a/en/device-dev/kernel/kernel-lite-small-file-vfs.md b/en/device-dev/kernel/kernel-lite-small-file-vfs.md deleted file mode 100644 index 8634d9cf6c751e8ef23ce6a2b304c36f40fe9e35..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-file-vfs.md +++ /dev/null @@ -1,171 +0,0 @@ -# VFS - -- [Overview](#section132540468341) -- [Basic Concepts](#section229417111227) -- [Working Principles](#section18114182834215) -- [Important Notes](#section18311145173712) -- [Development Guidelines](#section422619258380) -- [Use Code](#section180311121420) -- [Result Verification](#section16772334714) - -## Overview - -## Basic Concepts - -In essence, VFS is not a real file system. It is an abstract layer on top of a heterogeneous file system and provides you with a unified Unix-like file operation interface. - -Different types of file systems provide different interfaces. If there are multiple types of file systems in the system, different and non-standard interfaces are required for accessing these file systems. The VFS can be introduced as an abstract layer in the system to harmonize the differences between these heterogeneous file systems. In this way, the system does not need to care about the storage medium and file system type at the bottom layer when accessing a file system. The figure below illustrates the relationship between the VFS and file systems. - -**Figure 1** Relationship between the VFS and file systems -![](figure/relationship-between-the-vfs-and-file-systems.png "relationship-between-the-vfs-and-file-systems") - -In the OpenHarmony kernel, the VFS framework is implemented using the tree structure in the memory. Each node in the tree is an **inode** structure. After a device is registered and a file system is mounted, the corresponding node is generated in the tree based on the path. VFS provides the following functions: - -- Node query -- Unified file system invoking \(standard\) - -## Working Principles - -At the VFS layer, standard Unix file operation functions \(such as **open**, **read**, and **write**\) can be used to access different file systems on different media. - -There are three types of **inode** tree nodes in the VFS framework memory: - -- Virtual node: virtual file of the VFS framework, for example, **/usr** and **/usr/bin**, which ensures the continuity of the tree -- Device node: mapping to a device in the **/dev** directory, for example, **/dev/mmcblk0** -- Mount point: used to mount a specific file system, for example, **/vs/sd** or **/mnt** - -**Figure 2** Tree structure of the file system -![](figure/tree-structure-of-the-file-system.png "tree-structure-of-the-file-system") - -## Important Notes - -- For all file systems in VFS, the name of a directory or file can contain a maximum of 255 bytes, and the maximum length of a full path is 259 bytes. Directories or files whose length exceeds the maximum length cannot be created. - -- Currently, only the JFFS2 file system supports complete permission control. - -- After the **inode\_find\(\)** function is called, the number of found **inode** connections is incremented by 1. After the call is complete, the **inode\_release\(\)** function is called to decrease the number of **inode** connections by 1. Therefore, the two functions must be used together. - -- Devices are classified into character devices and block devices. To ensure data security of the file system on a block device, mount the file system and then operate data through the file system interface. - -- The **los\_vfs\_init\(\)** function can be called only once. Multiple calls cause exceptions to the file system. - -- The file names and directory names in all file systems of the OpenHarmony kernel can contain only hyphens \(-\) and underscores \(\_\), but no other special characters. If other special characters are used, unpredictable errors may occur. - -- The OpenHarmony kernel supports the **open\(\)+O\_DIRECTORY** method to obtain directory data. - -- The mount point must be an empty directory. A file system cannot be mounted to the same mount point or to a directory or file under another mount point. Otherwise, the device or system may be damaged. - -- Only one of the **O\_RDWR**, **O\_WRONLY**, and **O\_RDONLY** parameters can be used with **open** to open a file. If two or more of them are used, the file read or write operation is rejected, and the error code **EACCESS** is returned. - -- Before unmounting a file system in the OpenHarmony kernel, ensure that all directories and files are closed. Otherwise, unmounting fails. Forcible unmounting may cause problems such as file system and file damage. - -- Before removing an SD card, ensure that all directories and files are closed and unmounting is performed. Forcible removal may cause problems such as SD card data loss and SD card damage. - - -## Development Guidelines - -**How to Develop** - -It is recommended that driver developers use the VFS framework to register or uninstall devices \(that is, call **register\_driver\(\)** and **register\_blockdriver\(\)** to obtain device nodes\) and the application layer use **open\(\)** and **read\(\)** to operate character device files to invoke drivers. - -**File Descriptor** - -A process can have a maximum of 256 file descriptors \(including file and socket descriptors\). The system can have a maximum of 640 file descriptors, where there can be a maximum of - -- 512 file descriptors - -- 128 socket descriptors - - -**Operations Supported by VFS** - -open, close, read, write, seek, ioctl, fcntl, mmap, sync, dup, dup2, truncate, opendir, closedir, readdir, rewinddir, mount, umount, statfs, unlink, remove, mkdir, rmdir, rename, stat, utime, seek64, fallocate, fallocate64, truncate64, chmod, and chown - ->![](../public_sys-resources/icon-note.gif) **NOTE:** ->- Currently, only the interfaces for modifying the attributes of JFFS2 files and VFS device nodes are provided. Each system has its own processing mode for attributes such as read-only. ->- In the OpenHarmony kernel, the attributes do not conflict with each other, and they can be modified randomly. ->- A read-only file or directory in the OpenHarmony kernel cannot be deleted. ->- A read-only file or directory in the OpenHarmony kernel can be renamed. ->- A read-only file cannot be opened in **O\_CREAT**, **O\_TRUNC**, or other modes with the write permission. ->- If the hidden attribute is added to a system file in the OpenHarmony kernel, the system file can be found only on the command line interface \(CLI\) in the Windows OS. \(This system file cannot be viewed regardless of whether **Show hidden files, folders, and drivers** is selected.\) - -## Use Code - -``` -/* The following code shows how to create and traverse directories. */ -#include -#include -#include -#include -#include -#include - -int main() -{ - int ret; - char *dirname = "/test"; - char *pathname0 = "/test/test0"; - char *pathname1 = "/test/test1"; - char *pathname2 = "/test/test2"; - struct dirent **namelist; - int num; - - ret = mkdir(dirname, 0777); - if ((ret < 0) && (errno != EEXIST)) { - printf("mkdir failed. path=%s, errno=%d\n", dirname, errno); - goto EXIT; - } - - ret = mkdir(pathname0, 0777); - if ((ret < 0) && (errno != EEXIST)) { - printf("mkdir failed. path=%s, errno=%d\n", pathname0, errno); - goto EXIT0; - } - - ret = mkdir(pathname1, 0777); - if ((ret < 0) && (errno != EEXIST)) { - printf("mkdir failed. path=%s, errno=%d\n", pathname1, errno); - goto EXIT1; - } - - ret = mkdir(pathname2, 0777); - if ((ret < 0) && (errno != EEXIST)) { - printf("mkdir failed. path=%s, errno=%d\n", pathname2, errno); - goto EXIT2; - } - - num = scandir(dirname, &namelist, NULL, alphasort); - if (num < 0) { - perror("scandir"); - } else { - while (num--) { - printf("%s\n", namelist[num]->d_name); - free(namelist[num]); - } - free(namelist); - } - - printf("fs_demo exit.\n"); - return 0; - -EXIT2: - remove(pathname2); -EXIT1: - remove(pathname1); -EXIT0: - remove(pathname0); -EXIT: - remove(dirname); - return 0; -} -``` - -## Result Verification - -``` -OHOS # test2 -test1 -test0 -fs_demo exit. -``` - diff --git a/en/device-dev/kernel/kernel-lite-small-file.md b/en/device-dev/kernel/kernel-lite-small-file.md deleted file mode 100644 index 4a1e2be2e6b70eb7d6e18e123e6678de49b0ef30..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-file.md +++ /dev/null @@ -1,54 +0,0 @@ -# File System - -The OpenHarmony lite kernel supports the following file systems: Virtual File System \(VFS\), Network File System \(NFS\), RAM File System \(RAMFS\), File Allocation Table \(FAT\), and Journalling Flash File System Version 2 \(JFFS2\). - -The table below describes the functions of these file systems. - -**Table 1** File system functions - - - - - - - - - - - - - - - - - - - - - - -

File System

-

Function

-

VFS

-

In essence, VFS is not a real file system. It is an abstract layer on top of a heterogeneous file system and provides you with a unified Unix-like file operation interface.

-

NFS

-

NFS allows you to share files across hosts and OSs over a network.

-

RAMFS

-

RAMFS is a RAM-based file system. All files are stored in the RAM, and file read/write operations are performed in the RAM, which reduces the read/write loss of the memory and improves the data read/write speed. It provides a RAM-based storage buffer for dynamic file systems.

-

FAT

-

There are FAT12, FAT16, and FAT32. FAT is often used on removable storage media (such as USB flash drives, SD cards, and portable hard disks) to provide better compatibility between devices and desktop systems such as Windows and Linux.

-

JFFS2

-

JFFS2 is a journal-type file system implemented on Memory Technology Devices (MTDs). It is mainly used to manage files of the NOR flash memory. JFFS2 used in the OpenHarmony kernel supports multiple partitions.

-
- -- **[VFS](kernel-lite-small-file-vfs.md)** - -- **[NFS](kernel-lite-small-file-nfs.md)** - -- **[RAMFS](kernel-lite-small-file-ramfs.md)** - -- **[FAT](kernel-lite-small-file-fat.md)** - -- **[JFFS2](kernel-lite-small-file-jffs.md)** - - diff --git a/en/device-dev/kernel/kernel-lite-small-lib-differ.md b/en/device-dev/kernel/kernel-lite-small-lib-differ.md deleted file mode 100644 index aa315d3b074a730b5bd0b87c3ecfcc8bb4326f9e..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-lib-differ.md +++ /dev/null @@ -1,96 +0,0 @@ -# Differences from the Linux Standard Library - -- [Process](#section249218475301) -- [Memory](#section55731513163117) -- [Differences from Linux mmap](#section1943551142314) -- [Code Example](#section16947155092514) -- [File System](#section1746965493115) -- [Signal](#section1198254310333) -- [Time](#section0833419133414) - -This section describes the key differences between the standard library carried by the OpenHarmony kernel and the Linux standard library. For more information, see the API document of the C library. - -## Process - -1. Only the static priority is supported by OpenHarmony user-level processes. The priority ranges from 10 \(highest priority\) to 31 \(lowest priority\). -2. Only the static priority is supported by OpenHarmony user-level threads. The priority ranges from 0 \(highest priority\) to 31 \(lowest priority\). -3. OpenHarmony process scheduling policy can only be **SCHED\_RR**, and the thread scheduling policy can be **SCHED\_RR** or **SCHED\_FIFO**. - -## Memory - -## Differences from Linux mmap - -mmap prototype: void \*mmap \(void \*addr, size\_t length, int prot, int flags, int fd, off\_t offset\) - -The lifecycle implementation of **fd** is different from that of Linux glibc. To be specific, the glibc can release the **fd** handle immediately after successfully invoking the mmap for mapping. In the OpenHarmony kernel, you are not allowed to close **fd** immediately after the mapping is successful. You can close **fd** only after the munmap is canceled. If you do not close the **fd**, the operating system reclaims it when the process exits. - -## Code Example - -For Linux OS: - -``` -int main(int argc, char *argv[]) -{ - int fd; - void *addr = NULL; - ... - fd = open(argv[1], O_RDONLY); - if (fd == -1){ - perror("open"); - exit(EXIT_FAILURE); - } - addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, offset); - if (addr == MAP_FAILED) { - perror("mmap"); - exit(EXIT_FAILURE); - } - close(fd); /* OpenHarmony does not support closing fd immediately after the mapping is successful. */ - ... - exit(EXIT_SUCCESS); -} -``` - -For OpenHarmony: - -``` -int main(int argc, char *argv[]) -{ - int fd; - void *addr = NULL; - ... - fd = open(argv[1], O_RDONLY); - if (fd == -1) { - perror("open"); - exit(EXIT_FAILURE); - } - addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, offset); - if (addr == MAP_FAILED) { - perror("mmap"); - exit(EXIT_FAILURE); - } - ... - munmap(addr, length); - close(fd); /* Close fd after the munmap is canceled. */ - exit(EXIT_SUCCESS); -} -``` - -## File System - -**System directories**: include **/dev**, **/proc**, **/app**, **/bin**, **/data**, **/etc**, **/lib**, **/system** and **/usr**. Users do not have the permission to modify the directories and mount devices. - -**User directory**: refers to **/storage**. Users can create, read, and write files in this directory, but cannot mount devices. - -In addition to the system and user directories, you can create folders to mount devices. Note that a mounted folder and its subfolders cannot be mounted repeatedly or in nested mode. A non-empty folder cannot be mounted. - -## Signal - -- The default behavior for signals does not include **STOP**, **CONTINUE**, and **COREDUMP**. -- A sleeping process \(for example, a process enters the sleeping status by calling the **sleep** function\) cannot be woken up by a signal. Cause: The signal mechanism does not support wakeup. The behavior for a signal can be processed only when the process is scheduled by the CPU. -- After a process exits, **SIGCHLD** is sent to its parent process. The sending action cannot be canceled. -- Only signals 1 to 30 are supported. If the receiver receives the same signal multiple times, the callback function is executed only once. - -## Time - -The time precision of OpenHarmony is tick, with the default value of 10 ms/tick. The discrepancy of the **sleep** and **timeout** functions is less than or equal to 2 ticks. - diff --git a/en/device-dev/kernel/kernel-lite-small-lib-standard.md b/en/device-dev/kernel/kernel-lite-small-lib-standard.md deleted file mode 100644 index c617ebcef2bccda9d515a7e88a5a39cd1605cfac..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-lib-standard.md +++ /dev/null @@ -1,197 +0,0 @@ -# Standard Library - -- [Framework](#section1247343413257) -- [Development Example](#section4807125622614) -- [FAQs](#section1219455217277) - -The OpenHarmony kernel uses the **musl libc** library that supports the Portable Operating System Interface \(POSIX\). You can develop components and applications working on the kernel based on the POSIX. - -## Framework - -**Figure 1** POSIX framework -![](figure/posix-framework.png "posix-framework") - -When a system invokes an interface, the OpenHarmony kernel is adapted to provide the interface's external features. - -For details about the APIs supported by the standard library, see the API document of the C library, which also covers the differences between the standard library and the POSIX standard. - -## Development Example - -In this example, the main thread creates **THREAD\_NUM** child threads. Once a child thread is started, it enters the standby state. After the main thread successfully wakes up all child threads, they continue to execute until the lifecycle ends. The main thread uses the **pthread\_join** method to wait until all child threads are executed. - -``` -#include -#include -#include - -#ifdef __cplusplus -#if __cplusplus -extern "C" { -#endif /* __cplusplus */ -#endif /* __cplusplus */ - -#define THREAD_NUM 3 -int g_startNum = 0; /* Number of started threads */ -int g_wakenNum = 0; /* Number of wakeup threads */ - -struct testdata { - pthread_mutex_t mutex; - pthread_cond_t cond; -} g_td; - -/* - * Entry function of child threads. - */ -static void *ChildThreadFunc(void *arg) -{ - int rc; - pthread_t self = pthread_self(); - - /* Locks a mutex. */ - rc = pthread_mutex_lock(&g_td.mutex); - if (rc != 0) { - printf("ERROR:take mutex lock failed, error code is %d!\n", rc); - goto EXIT; - } - - /* The value of g_startNum is increased by 1. The value indicates the number of child threads that have locked a mutex. */ - g_startNum++; - - /* Wait for the condition variable. */ - rc = pthread_cond_wait(&g_td.cond, &g_td.mutex); - if (rc != 0) { - printf("ERROR: pthread condition wait failed, error code is %d!\n", rc); - (void)pthread_mutex_unlock(&g_td.mutex); - goto EXIT; - } - - /* Attempt to lock a mutex, which is failed in normal cases. */ - rc = pthread_mutex_trylock(&g_td.mutex); - if (rc == 0) { - printf("ERROR: mutex gets an abnormal lock!\n"); - goto EXIT; - } - - /* The value of g_wakenNum is increased by 1. The value indicates the number of child threads that have been woken up by the condition variable. */ - g_wakenNum++; - - /* Unlock a mutex. */ - rc = pthread_mutex_unlock(&g_td.mutex); - if (rc != 0) { - printf("ERROR: mutex release failed, error code is %d!\n", rc); - goto EXIT; - } -EXIT: - return NULL; -} - -static int testcase(void) -{ - int i, rc; - pthread_t thread[THREAD_NUM]; - - /* Initialize a mutex. */ - rc = pthread_mutex_init(&g_td.mutex, NULL); - if (rc != 0) { - printf("ERROR: mutex init failed, error code is %d!\n", rc); - goto ERROROUT; - } - - /* Initialize the condition variable. */ - rc = pthread_cond_init(&g_td.cond, NULL); - if (rc != 0) { - printf("ERROR: pthread condition init failed, error code is %d!\n", rc); - goto ERROROUT; - } - - /* Create child threads in batches. The number is specified by THREAD_NUM. */ - for (i = 0; i < THREAD_NUM; i++) { - rc = pthread_create(&thread[i], NULL, ChildThreadFunc, NULL); - if (rc != 0) { - printf("ERROR: pthread create failed, error code is %d!\n", rc); - goto ERROROUT; - } - } - - /* Wait until all child threads lock a mutex. */ - while (g_startNum < THREAD_NUM) { - usleep(100); - } - - /* Lock a mutex and block all threads using pthread_cond_wait. */ - rc = pthread_mutex_lock(&g_td.mutex); - if (rc != 0) { - printf("ERROR: mutex lock failed, error code is %d\n", rc); - goto ERROROUT; - } - - /* Unlock a mutex. */ - rc = pthread_mutex_unlock(&g_td.mutex); - if (rc != 0) { - printf("ERROR: mutex unlock failed, error code is %d!\n", rc); - goto ERROROUT; - } - - for (int j = 0; j < THREAD_NUM; j++) { - /* Broadcast signals on the condition variable. */ - rc = pthread_cond_signal(&g_td.cond); - if (rc != 0) { - printf("ERROR: pthread condition failed, error code is %d!\n", rc); - goto ERROROUT; - } - } - - sleep(1); - - /* Check whether all child threads are woken up. */ - if (g_wakenNum != THREAD_NUM) { - printf("ERROR: not all threads awaken, only %d thread(s) awaken!\n", g_wakenNum); - goto ERROROUT; - } - - /* Wait for all threads to terminate. */ - for (i = 0; i < THREAD_NUM; i++) { - rc = pthread_join(thread[i], NULL); - if (rc != 0) { - printf("ERROR: pthread join failed, error code is %d!\n", rc); - goto ERROROUT; - } - } - - /* Destroy the condition variable. */ - rc = pthread_cond_destroy(&g_td.cond); - if (rc != 0) { - printf("ERROR: pthread condition destroy failed, error code is %d!\n", rc); - goto ERROROUT; - } - return 0; -ERROROUT: - return -1; -} - -/* - * Sample code main function - */ -int main(int argc, char *argv[]) -{ - int rc; - - /* Start the test function. */ - rc = testcase(); - if (rc != 0) { - printf("ERROR: testcase failed!\n"); - } - - return 0; -} -#ifdef __cplusplus -#if __cplusplus -} -#endif /* __cplusplus */ -#endif /* __cplusplus */ -``` - -## FAQs - -None - diff --git a/en/device-dev/kernel/kernel-lite-small-lib.md b/en/device-dev/kernel/kernel-lite-small-lib.md deleted file mode 100644 index 7b82773508bebc7f6f2b519897411f9a26df1bc4..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-lib.md +++ /dev/null @@ -1,7 +0,0 @@ -# Standard Library - -- **[Standard Library](kernel-lite-small-lib-standard.md)** - -- **[Differences from the Linux Standard Library](kernel-lite-small-lib-differ.md)** - - diff --git a/en/device-dev/kernel/kernel-lite-small-memory.md b/en/device-dev/kernel/kernel-lite-small-memory.md deleted file mode 100644 index 7e5191df7b4d967ad5d879522e4a9c372f2a9e2f..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-memory.md +++ /dev/null @@ -1,353 +0,0 @@ -# Memory - -- [Basic Concepts](#section1392116583424) -- [When to Use](#section159581619194319) -- [API Description](#section114001032104317) - -## Basic Concepts - -Memory management is an important procedure in software development, including memory allocation, usage, and reclamation. - -Sound memory management approaches and strategies help you improve software performance and reliability. - -## When to Use - -For user-space development, the OpenHarmony kernel provides a set of APIs for you to perform memory-related operations, such as memory application, release, remapping, and attribute setting, in addition to standard APIs provided by the C library. - -## API Description - -**Table 1** Standard APIs in the C library - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Header File

-

Function

-

Description

-

strings.h

-

int bcmp(const void *s1, const void *s2, size_t n)

-

Compares byte sequences.

-

strings.h

-

void bcopy(const void *src, void *dest, size_t n)

-

Copies byte sequences.

-

strings.h

-

void bzero(void *s, size_t n)

-

Sets byte sequences to zero.

-

string.h

-

void *memccpy(void *dest, const void *src, int c, size_t n)

-

Copies the first n bytes from the source memory area pointed to by src to the destination memory area pointed to by dest. The copy checks whether a character specified by c is found. If c is found, this function returns the next character of character c in the destination memory area.

-

string.h

-

void *memchr(const void *s, int c, size_t n)

-

Searches for the first occurrence of the character specified by c in the n-byte memory area pointed to by s.

-

string.h

-

int memcmp(const void *s1, const void *s2, size_t n)

-

Compares two memory areas.

-

string.h

-

void *memcpy(void *dest, const void *src, size_t n)

-

Copies n bytes from the source memory area pointed to by src to the destination memory area pointed to by dest.

-

string.h

-

void *memmem(const void *haystack, size_t haystacklen, const void *needle, size_t needlelen)

-

Searches for a needle string in its haystack string.

-

string.h

-

void *memmove(void *dest, const void *src, size_t n)

-

Copies n bytes from the source memory area pointed to by src to the destination memory area pointed to by dest.

-

string.h

-

void *mempcpy(void *dest, const void *src, size_t n)

-

Copies n bytes from the source memory area pointed to by src to the destination memory area pointed to by dest.

-

string.h

-

void *memset(void *s, int c, size_t n)

-

Copies a character to the specified memory area.

-

stdlib.h

-

void *malloc(size_t size)

-

Dynamically allocates a memory block of size.

-

stdlib.h

-

void *calloc(size_t nmemb, size_t size)

-

Dynamically allocates nmemb memory blocks of size.

-

stdlib.h

-

void *realloc(void *ptr, size_t size)

-

Changes the size of the memory block pointed to by ptr to size bytes.

-

stdlib.h/malloc.h

-

void *valloc(size_t size)

-

Allocates a block of memory with the specified size and aligns the allocated memory by page size.

-

stdlib.h

-

void free(void *ptr)

-

Releases the memory space pointed to by ptr.

-

malloc.h

-

size_t malloc_usable_size(void *ptr)

-

Obtains the size of the memory block pointed to by ptr.

-

unistd.h

-

int getpagesize(void)

-

Obtains the page size.

-

unistd.h

-

void *sbrk(intptr_t increment)

-

Changes the data segment size.

-
- -Details on API differences: - -- **mmap** - - **Function prototype:** - - void \*mmap\(void \*addr, size\_t length, int prot, int flags, int fd, off\_t offset\); - - **Function description:** applies for virtual memory. - - **Parameter description:** - - - - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

addr

-

Indicates the pointer to the start address of the mapping between the virtual address space of the calling process and a file or device. If this parameter is NULL, the kernel determines the address to start (recommended). Otherwise, the portability of the program will deteriorate, because the available addresses vary depending on the OS.

-

length

-

Indicates the length of the mapping.

-

prot

-

Indicates the permission to be granted on the mapping area. The options are as follows:

-
  • PROT_READ: The mapping area is readable.
  • PROT_WRITE: The mapping area is writable.
  • PROT_EXEC: The mapping area is executable.
  • PROT_NONE: The mapping area cannot be accessed.
-

flags

-

Specifies whether updates are visible to other processes mapping the same segment. The options are as follows:

-
  • MAP_PRIVATE: The mapping area is private, and updates to the mapping are invisible to other processes mapping the same segment.
  • MAP_SHARED: Updates to the mapping are visible to other processes mapping the same segment, and are stored to the disk file.
-

fd

-

Indicates the file descriptor.

-

offset

-

Indicates the offset into the file where the mapping will start.

-
- - >![](../public_sys-resources/icon-note.gif) **NOTE:** - >For details about the implementation differences between **mmap** and Linux function, see [Differences from the Linux Standard Library](kernel-lite-small-lib-differ.md). - - **Return values:** - - - Returns the pointer to the page-aligned address where the mapping is placed if the operation is successful. - - Returns **\(void \*\)-1** if the operation fails. - - -- **munmap** - - **Function prototype:** - - int munmap\(void \*addr, size\_t length\); - - **Function description:** releases virtual memory. - - **Parameter description:** - - - - - - - - - - - - - -

Parameter

-

Description

-

addr

-

Indicates the pointer to the start address of the memory region to unmap.

-

length

-

Indicates the length of the address range to unmap.

-
- - **Return values:** - - - Returns **0** if the operation is successful. - - Returns **-1** if the operation fails. - - -- **mprotect** - - **Function prototype:** - - int mprotect\(void \*addr, size\_t length, int prot\); - - **Function description:** modifies the access permission on a memory region. - - **Parameter description:** - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

addr

-

Indicates the pointer to the start address of the memory region to modify, which must be a multiple of the page size. If the access permission is abnormal, the kernel throws an exception and kills the process rather than send SIGSEGV signals to the current process.

-

length

-

Indicates the length of the memory region to modify.

-

prot

-

Indicates the permission of the memory region to modify. The options are as follows:

-
  • PROT_READ: The memory region is readable.
  • PROT_WRITE: The memory region is writable.
  • PROT_EXEC: The memory region is executable.
  • PROT_NONE: The memory region cannot be accessed.
-
- - **Return values:** - - - Returns **0** if the operation is successful. - - Returns **-1** if the operation fails. - - -- **mremap** - - **Function prototype:** - - void \*mremap\(void \*old\_address, size\_t old\_size, size\_t new\_size, int flags, void new\_address\); - - **Function description:** remaps the virtual memory address. - - **Parameter description:** - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

old_address

-

Indicates the old address of the virtual memory block that needs to be expanded or shrunk. The old_address must be page-aligned.

-

old_size

-

Indicates the old size of the virtual memory block.

-

new_size

-

Indicates the new size of the virtual memory block.

-

flags

-

Indicates the flags to control the remapping. If there is no sufficient space to expand the mapping in the current location, the operation will fail.

-
  • MREMAP_MAYMOVE: allows the kernel to relocate the mapping to a new virtual address.
  • MREMAP_FIXED: enables the mremap() function to accept the fifth parameter void *new_address, which specifies that the mapping address must be page-aligned. All previous mappings within the address range specified by new_address and new_size are unmapped. If MREMAP_FIXED is specified, MREMAP_MAYMOVE must also be specified.
-
- - **Return values:** - - - Returns the pointer to the new virtual memory area if the operation is successful. - - Returns **\(void \*\)-1** if the operation fails. - - diff --git a/en/device-dev/kernel/kernel-lite-small-net.md b/en/device-dev/kernel/kernel-lite-small-net.md deleted file mode 100644 index 0f542fa52928ae3748dc0a6f51bb24a028dda547..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-net.md +++ /dev/null @@ -1,303 +0,0 @@ -# Network - -- [Basic Concepts](#section9840143083510) -- [When to Use](#section1575885183516) -- [API Description](#section16351198193614) - -## Basic Concepts - -The network module implements basic functions of the TCP/IP protocol stack and provides the standard POSIX socket interfaces. - ->![](../public_sys-resources/icon-note.gif) **NOTE:** ->Currently, the OS uses **lwIP** to provide network capabilities. - -## When to Use - -For user-space development, the OpenHarmony kernel provides a set of APIs for you to implement network functionalities, including creating and disabling sockets, transmitting and receiving data, and setting network attributes, in addition to standard POSIX socket functions provided by the C library. - -## API Description - -**Table 1** Standard APIs in the C library - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Header File

-

Function

-

Description

-

sys/socket.h

-

int accept(int socket, struct sockaddr *address, socklen_t *address_len)

-

Accepts incoming connection requests.

-

sys/socket.h

-

int bind(int s, const struct sockaddr *name, socklen_t namelen)

-

Binds an IP address to a socket.

-

sys/socket.h

-

int shutdown(int socket, int how)

-

Shuts down a socket.

-

sys/socket.h

-

int getpeername(int s, struct sockaddr *name, socklen_t *namelen)

-

Retrieves the peer address of the specified socket.

-

sys/socket.h

-

int getsockname(int s, struct sockaddr *name, socklen_t *namelen)

-

Retrieves the local address of the specified socket.

-

sys/socket.h

-

int getsockopt(int s, struct sockaddr *name, socklen_t *namelen)

-

Retrieves the socket options.

-

sys/socket.h

-

int setsockopt(int sockfd, int level, int optname, void *optval, socklen_t *optlen)

-

Sets the socket options.

-

unistd.h

-

int close(int s)

-

Closes a socket.

-

sys/socket.h

-

int connect(int s, const struct sockaddr *name, socklen_t namelen)

-

Initiates a connection to a socket.

-

sys/socket.h

-

int listen(int sockfd, int backlog)

-

Listens for network connections.

-

sys/socket.h

-

ssize_t recv(int socket, void *buffer, size_t length, int flags)

-

Receives data from another socket.

-

sys/socket.h

-

ssize_t recvmsg(int s, struct msghdr *message, int flags)

-

Receives data from a specified socket based on the input parameters.

-

sys/socket.h

-

ssize_t recvfrom(int socket, void *buffer, size_t length, int flags, struct sockaddr *address, socklen_t *address_len)

-

Receives data from a specified socket and obtains the IP address of the data source.

-

sys/socket.h

-

ssize_t send(int s, const void *dataptr, size_t size, int flags)

-

Sends data to another socket.

-

sys/socket.h

-

ssize_t sendmsg(int s, const struct msghdr *message, int flags)

-

Sends data to another socket based on the input parameters.

-

sys/socket.h

-

ssize_t sendto(int s, const void *dataptr, size_t size, int flags, const struct sockaddr *to, socklen_t tolen)

-

Sends data to another socket at the specified destination IP address.

-

sys/socket.h

-

int socket(int domain, int type, int protocol)

-

Creates a socket.

-

sys/select.h

-

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout)

-

Monitors the I/O events of multiple file descriptors.

-

sys/ioctl.h

-

int ioctl(int s, int request, ...)

-

Obtains and sets socket options.

-

arpa/inet.h

-

const char *inet_ntop(int af, const void *src, char *dst, socklen_t size)

-

Converts an IP address in binary format to a string.

-

arpa/inet.h

-

int inet_pton(int af, const char *src, void *dst)

-

Converts a string to an IP address in binary format.

-
- -Details on API differences: - -- **sendmsg** - - **Function prototype:** - - ssize\_t sendmsg\(int s, const struct msghdr \*message, int flags\) - - **Function description:** sends a message on a socket. - - **Parameter description:** - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

s

-

Indicates the socket descriptor.

-

message

-

Indicates the pointer to the message to be sent. The ancillary message is not supported.

-

flags

-

Indicates the socket flags for sending the message. The options are as follows:

-
  • MSG_MORE: allows messages that have been sent for multiple times to be packaged and sent at a time.
  • MSG_DONTWAIT: enables a non-blocking operation.
-
- - **Return values:** - - - Returns the number of bytes that have been sent if the operation is successful. - - Returns **-1** and sets **errno** if the operation fails. - - -- **recvmsg** - - **Function prototype:** - - ssize\_t recvmsg\(int s, struct msghdr \*message, int flags\) - - **Function description:** receives a message from a socket. - - **Parameter description:** - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

s

-

Indicates the socket descriptor.

-

message

-

Indicates the pointer to the address to receive the message. The ancillary message is not supported.

-

flags

-

Indicates the socket flags for receiving the message. The options are as follows:

-
  • MSG_PEEK: allows the message to be read without being removed.
  • MSG_DONTWAIT: enables a non-blocking operation.
-
- - **Return values:** - - - Returns the number of bytes that have been received if the operation is successful. - - Returns **-1** and sets **errno** if the operation fails. - - -- **ioctl** - - **Function prototype:** - - int ioctl\(int s, int request, ...\) - - **Function description:** obtains or sets socket options. - - **Parameter description:** - - - - - - - - - - - - - -

Parameter

-

Description

-

s

-

Indicates the socket descriptor.

-

request

-

Indicates the operation to perform on the socket options. The options are as follows:

-
  • FIONREAD: obtains the number of bytes of the data that can be read from the socket.
  • FIONBIO: sets whether the socket is non-blocked.
-
- - **Return values:** - - - Returns **0** if the operation is successful. - - Returns **-1** and sets **errno** if the operation fails. - - diff --git a/en/device-dev/kernel/kernel-lite-small-process.md b/en/device-dev/kernel/kernel-lite-small-process.md deleted file mode 100644 index 4ce3abc48b9d4c97f222aa495ec7167a00974567..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-process.md +++ /dev/null @@ -1,301 +0,0 @@ -# Process - -- [Basic Concepts](#section29197338383) -- [When to Use](#section85513272398) -- [API Description](#section4517119124015) - -## Basic Concepts - -Processes are resource management units in the OS. They can use or wait to use CPUs and use system resources such as memory. They run independently from one another. - -The OpenHarmony kernel allows multiple processes to run simultaneously, switch, and communicate, facilitating your management over service programs. In this regard, you will have more time to devote to the implementation of service functionalities. - -Processes in the OpenHarmony kernel use the preemptive scheduling mechanism, round-robin \(RR\) scheduling. - -These processes are assigned 32 priorities \(**0** to **31**\). Among them, user processes can be configured with 22 priorities from **10** \(highest\) to **31** \(lowest\). - -A high-priority process can preempt the resources of a low-priority process. The low-priority process can be scheduled only after the high-priority process is blocked or terminated. - -Each user-space process has its own memory space, which is invisible to other processes. In this way, processes are isolated from each other. - -The user-space root process init is started by the kernel. Then other user-space processes are created by the init process via the **fork** call. - -**A process may have the following states:** - -- **Init**: The process is being created. - -- **Ready**: The process is in the ready list and waits for being scheduled by the CPU. - -- **Running**: The process is running. - -- **Pending**: The process is blocked and suspended. When all threads in a process are blocked, the process is blocked and suspended. - -- **Zombies**: The process stops running and waits for the parent process to reclaim its control block resources. - - -**Figure 1** State transition of a process -![](figure/state-transition-of-a-process.png "state-transition-of-a-process") - -**Description of the process state transition:** - -- Init→Ready: - - When a process is created, the process enters the **Init** state to start initialization after obtaining the process control block. After the process is initialized, the process is inserted into the scheduling queue and therefore enters the **Ready** state. - -- Ready→Running: - - When a process switchover is triggered, the process with the highest priority in the ready list is executed and enters the **Running** state. If this process has no thread in the **Ready** state, the process is deleted from the ready list and resides only in the **Running** state. However, if it has threads in the **Ready** state, the process still stays in the ready list. In this case, the process is in both the **Ready** and **Running** states. - -- Running→Pending: - - If all threads in a process are entering the **Pending** state, the process will enter the **Pending** state together with its last thread. Then, a process switchover is triggered. - -- Pending→Ready: - - When any thread in a **Pending** process restores to the **Ready** state, the process is added to the ready list and changes to the **Ready** state. - -- Ready→Pending: - - When the last ready thread in a process enters the **Pending** state, the process is deleted from the ready list, and the process changes from the **Ready** state to the **Pending** state. - -- Running→Ready: - - A process may change from the **Running** state to the **Ready** state in either of the following scenarios: - - 1. After a process with a higher priority is created or restored, processes will be scheduled. The process with the highest priority in the ready list will change to the **Running** state, and the originally running process will change from the **Running** state to the **Ready** state. - 2. If a process has the **SCHED\_RR** scheduling policy and shares the same priority with another process in the **Ready** state, this process will change from the **Running** state to the **Ready** state after its time slices are used up, and the other process with the same priority will change from the **Ready** state to the **Running** state. - -- Running→Zombies: - - After the main thread or all threads of a process are stopped, the process changes from the **Running** state to the **Zombies** state and waits for the parent process to reclaim resources. - - -## When to Use - -After processes are created, you can operate the resources only in your own process space, except shared resources. In user space, processes can be suspended, restored, and delayed. In addition, you can set and obtain the scheduling priority and scheduling policy of processes. When a process is terminated, it proactively releases its resources. However, the PID resources of the process are reclaimed by the parent process via **wait**/**waitpid** or when the parent process exits. - -## API Description - -The following table describes the APIs provided by the process management module of the OpenHarmony kernel. - -**Table 1** APIs provided by the process management module - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Category

-

Function

-

Description

-

Remarks

-

Process

-

fork

-

Creates a new process.

-

N/A

-

exit

-

Exits the process.

-

N/A

-

atexit

-

Registers the callback that will be called when the process is terminated normally.

-

N/A

-

abort

-

Terminates the process.

-

N/A

-

getpid

-

Obtains the process ID.

-

N/A

-

getppid

-

Obtains the parent process ID.

-

N/A

-

getpgrp

-

Obtains the ID of the process group of the calling process.

-

N/A

-

getpgid

-

Obtains the process group ID of the process identified by pid.

-

N/A

-

setpgrp

-

Sets the process group ID of the calling process.

-

N/A

-

setpgid

-

Sets the process group ID of the process identified by pid.

-

N/A

-

kill

-

Sends a signal to a specified process.

-
  • Only signals 1 to 30 can be sent.
  • The default behavior for signals does not include STOP and CONTINUE and terminates the process without a core dump.
  • SIGSTOP, SIGKILL, and SIGCONT cannot be masked.
  • After an asynchronous signal is sent to a process, the signal callback is invoked only after the process is scheduled. For the sake of security, the process can be killed only by itself, and the kernel cannot forcibly kill the process by sending signals.
  • After the process is killed, SIGCHLD is sent to its parent process. The sending action cannot be canceled.
  • A sleeping process cannot be woken up by a signal.
-

wait

-

Waits for any child process to terminate and reclaims its resources.

-

The status value is defined by the following macros:

-
  • WIFEXITED(status): If the child process terminates normally, true is returned. Otherwise, false is returned.
  • WEXITSTATUS(status): If WIFEXITED(status) is true, this macro can be used to obtain the exit code that the child process passed to exit().
  • WTERMSIG(status): If a child process terminates abnormally, the child process exit code obtained by the parent process through WTERMSIG is always SIGUSR2. This is the only case supported.
  • The following operations are not supported: WIFSTOPPED, WSTOPSIG, WCOREDUMP, and WIFCONTINUED.
-

waitpid

-

Waits for a specified child process to terminate and reclaims its resources.

-

The options to control the function behavior do not support WUNTRACED and WCONTINUED.

-

The status value is defined by the following macros:

-
  • WIFEXITED(status): If the child process terminates normally, true is returned. Otherwise, false is returned.
  • WEXITSTATUS(status): If WIFEXITED(status) is true, this macro can be used to obtain the exit code that the child process passed to exit().
  • WTERMSIG(status): If a child process terminates abnormally, the child process exit code obtained by the parent process through WTERMSIG is always SIGUSR2. This is the only case supported.
  • The following operations are not supported: WIFSTOPPED, WSTOPSIG, WCOREDUMP, and WIFCONTINUED.
-

Scheduling

-

getpriority

-

Obtains the static priority of a specified ID.

-
  • PRIO_PGRP and PRIO_USER are not supported.
-
  • The priority to obtain and set refers to the static priority. The dynamic priority is not involved.
-

setpriority

-

Sets the static priority of a specified ID.

-

sched_rr_get_interval

-

Obtains the execution time limit of a process.

-

N/A

-

sched_yield

-

Yields the running process.

-

N/A

-

sched_get_priority_max

-

Obtains the maximum static priority that can be used for a process.

-

The scheduling policy can only be SCHED_RR.

-

sched_get_priority_min

-

Obtains the minimum static priority that can be used for a process.

-

sched_getscheduler

-

Obtains the scheduling policy of a process.

-

sched_setscheduler

-

Sets a scheduling policy for a process.

-

sched_getparam

-

Obtains scheduling parameters of a process.

-

N/A

-

sched_setparam

-

Sets scheduling parameters related to a scheduling policy for a process.

-

N/A

-

exec

-

execl

-

Executes a specified user program file in ELF format.

-

N/A

-

execle

-

Executes a specified user program file in ELF format.

-

N/A

-

execlp

-

Executes a specified user program file in ELF format.

-

N/A

-

execv

-

Executes a specified user program file in ELF format.

-

N/A

-

execve

-

Executes a specified user program file in ELF format.

-

N/A

-

execvp

-

Executes a specified user program file in ELF format.

-

N/A

-
- diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file.md deleted file mode 100644 index b47f48fbebd91c9f0edb883f48aa53b360100b46..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file.md +++ /dev/null @@ -1,45 +0,0 @@ -# File Commands - -- **[cat](kernel-lite-small-shell-cmd-file-cat.md)** - -- **[cd](kernel-lite-small-shell-cmd-file-cd.md)** - -- **[chgrp](kernel-lite-small-shell-cmd-file-chgrp.md)** - -- **[chmod](kernel-lite-small-shell-cmd-file-chmod.md)** - -- **[chown](kernel-lite-small-shell-cmd-file-chown.md)** - -- **[cp](kernel-lite-small-shell-cmd-file-cp.md)** - -- **[format](kernel-lite-small-shell-cmd-file-format.md)** - -- **[ls](kernel-lite-small-shell-cmd-file-is.md)** - -- **[lsfd](kernel-lite-small-shell-cmd-file-isfd.md)** - -- **[mkdir](kernel-lite-small-shell-cmd-file-mkdir.md)** - -- **[mount](kernel-lite-small-shell-cmd-file-mount.md)** - -- **[partinfo](kernel-lite-small-shell-cmd-file-part.md)** - -- **[partition](kernel-lite-small-shell-cmd-file-partion.md)** - -- **[pwd](kernel-lite-small-shell-cmd-file-pwd.md)** - -- **[rm](kernel-lite-small-shell-cmd-file-rm.md)** - -- **[rmdir](kernel-lite-small-shell-cmd-file-rmdir.md)** - -- **[statfs](kernel-lite-small-shell-cmd-file-sta.md)** - -- **[sync](kernel-lite-small-shell-cmd-file-sync.md)** - -- **[touch](kernel-lite-small-shell-cmd-file-touch.md)** - -- **[writeproc](kernel-lite-small-shell-cmd-file-write.md)** - -- **[umount](kernel-lite-small-shell-cmd-file-umount.md)** - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-mag.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-mag.md deleted file mode 100644 index 9bcfa88de03da750fda2be03b4ef15505a27c91f..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-mag.md +++ /dev/null @@ -1,40 +0,0 @@ -# Magic Key Usage - -- [When to Use](#section2350114718546) -- [How to Use](#section3305151511559) - -## When to Use - -When the system does not respond, you can use the magic key function to check whether the system is locked and interrupted \(the magic key also does not respond\) or view the system task running status. - -If the interrupt is responded, you can use the magic key to check the CPU usage \(**cpup**\) in the task information to find out the task that occupies the CPU for a long period of time and causes other tasks in the system not to respond. \(Generally, the high-priority tasks always preempt the CPU and cause the low-priority tasks not to respond.\) - -## How to Use - -1. Configure macro **LOSCFG\_ENABLE\_MAGICKEY**. - -The magic key depends on the **LOSCFG\_ENABLE\_MAGICKEY** macro. To use the magic key, enable the **Enable MAGIC KEY** configuration item using **menuconfig**. - -Debug ---\> Enable MAGIC KEY - -If this configuration item is disabled, the magic key is invalid. - ->![](../public_sys-resources/icon-note.gif) **NOTE:** ->1. In **menuconfig**, you can move the cursor to **LOSCFG\_ENABLE\_MAGICKEY** and enter a question mark \(?\) to view the help information. - -2. Press **Ctrl+R** to enable the magic key detection function. - -When the UART or USB-to-virtual serial port is connected, press **Ctrl+R** to enable the magic key detection function. The message "Magic key on" is displayed. After you press **Ctrl+R** again, the magic key detection function is disabled, and message "Magic key off" is displayed. The functions of the magic key are as follows: - -- **Ctrl+Z**: help key, which is used to display the brief introduction to related magic keys. - -- **Ctrl+T**: displays task information. - -- **Ctrl+P**: The system proactively enters the panic state. After the panic-related information is printed, the system is suspended. - -- **Ctrl+E**: The system checks the integrity of the memory pool. If an error is detected, the system displays an error message. If no error is detected, the system displays "system memcheck over, all passed!". - - ->![](../public_sys-resources/icon-notice.gif) **NOTICE:** ->When the magic key detection function is enabled and special characters need to be entered through the UART or USB-to-virtual serial port, ensure that the special characters are not the same as the magic key values. Otherwise, the magic key may be triggered by mistake, which may cause errors in the original design. - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net.md deleted file mode 100644 index 68d76bf26eccdeef28fa67938389cdae428d81f4..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net.md +++ /dev/null @@ -1,25 +0,0 @@ -# Network Commands - -- **[arp](kernel-lite-small-shell-cmd-net-arp.md)** - -- **[dhclient](kernel-lite-small-shell-cmd-net-dh.md)** - -- **[dns](kernel-lite-small-shell-cmd-net-dns.md)** - -- **[ifconfig](kernel-lite-small-shell-cmd-net-ipc.md)** - -- **[ipdebug](kernel-lite-small-shell-cmd-net-ipd.md)** - -- **[netstat](kernel-lite-small-shell-cmd-net-net.md)** - -- **[ntpdate](kernel-lite-small-shell-cmd-net-ntp.md)** - -- **[ping](kernel-lite-small-shell-cmd-net-ping.md)** - -- **[ping6](kernel-lite-small-shell-cmd-net-ping6.md)** - -- **[telnet](kernel-lite-small-shell-cmd-net-tel.md)** - -- **[tftp](kernel-lite-small-shell-cmd-net-tftp.md)** - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-uname.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-uname.md deleted file mode 100644 index 7a9a79658247b8bbc3a97978aa945ed5182b4837..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-uname.md +++ /dev/null @@ -1,72 +0,0 @@ -# uname - -- [Command Function](#section107697383115) -- [Syntax](#section162824341116) -- [Usage](#section2652124861114) -- [Example](#section0107995132) -- [Output](#section1215113245511) - -## Command Function - -This command is used to display the name, version creation time, system name, and version information of the current OS. - -## Syntax - -uname \[_-a | -s | -t | -v | --help_\] - -**Table 1** Parameters - - - - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

No parameter

-

Displays the OS name by default.

-

-a

-

Displays all information.

-

-t

-

Displays the time when the version is created.

-

-s

-

Displays the OS name.

-

-v

-

Displays the version information.

-

--help

-

Displays the help information.

-
- -## Usage - -The **uname** command displays the name of the current OS by default. The **uname -a | -t| -s| -v** command displays the name of the in-use OS in the standard output. These parameters are mutually exclusive. - -## Example - -Enter **uname -a**. - -## Output - -Querying system information - -![](figure/en-us_image_0000001052370305.png) - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys.md deleted file mode 100644 index 5549fe5c32bd6c2660afc196b0061d88cf8f8b70..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys.md +++ /dev/null @@ -1,47 +0,0 @@ -# System Commands - -- **[cpup](kernel-lite-small-shell-cmd-sys-cpup.md)** - -- **[date](kernel-lite-small-shell-cmd-sys-date.md)** - -- **[dmesg](kernel-lite-small-shell-cmd-sys-demsg.md)** - -- **[exec](kernel-lite-small-shell-cmd-sys-exec.md)** - -- **[free](kernel-lite-small-shell-cmd-sys-free.md)** - -- **[help](kernel-lite-small-shell-cmd-sys-help.md)** - -- **[hwi](kernel-lite-small-shell-cmd-sys-hwi.md)** - -- **[kill](kernel-lite-small-shell-cmd-sys-kill.md)** - -- **[log](kernel-lite-small-shell-cmd-sys-log.md)** - -- **[memcheck](kernel-lite-small-shell-cmd-sys-mem.md)** - -- **[oom](kernel-lite-small-shell-cmd-sys-oom.md)** - -- **[pmm](kernel-lite-small-shell-cmd-sys-pmm.md)** - -- **[reset](kernel-lite-small-shell-cmd-sys-reset.md)** - -- **[sem](kernel-lite-small-shell-cmd-sys-sem.md)** - -- **[stack](kernel-lite-small-shell-cmd-sys-stack.md)** - -- **[su](kernel-lite-small-shell-cmd-sys-su.md)** - -- **[swtmr](kernel-lite-small-shell-cmd-sys-swymr.md)** - -- **[systeminfo](kernel-lite-small-shell-cmd-sys-sys.md)** - -- **[task](kernel-lite-small-shell-cmd-sys-task.md)** - -- **[uname](kernel-lite-small-shell-cmd-sys-uname.md)** - -- **[vmm](kernel-lite-small-shell-cmd-sys-vmm.md)** - -- **[watch](kernel-lite-small-shell-cmd-sys-watch.md)** - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd.md deleted file mode 100644 index ca4697ae096f4b8bd08daaa2de56f60b00c77a59..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd.md +++ /dev/null @@ -1,13 +0,0 @@ -# Shell Command Reference - -This chapter describes the functions, syntax, parameter ranges, usages, and examples of key system commands. - -For details about the commands that are not described in this document, see the output of the [help](kernel-lite-small-shell-cmd-sys-help.md) command. You can also use the **-h | --help** option of a command to view the help information about the command. - -- **[System Commands](kernel-lite-small-shell-cmd-sys.md)** - -- **[File Commands](kernel-lite-small-shell-cmd-file.md)** - -- **[Network Commands](kernel-lite-small-shell-cmd-net.md)** - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell.md b/en/device-dev/kernel/kernel-lite-small-shell.md deleted file mode 100644 index e780951cf490b49819a1bdb13d33a3753a1f10cf..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-shell.md +++ /dev/null @@ -1,15 +0,0 @@ -# Commissioning - -- **[Introduction to the Shell](kernel-lite-small-shell-des.md)** - -- **[Shell Command Development Guidelines](kernel-lite-small-shell-guide.md)** - -- **[Shell Command Programming Example](kernel-lite-small-shell-sample.md)** - -- **[Shell Command Reference](kernel-lite-small-shell-cmd.md)** - -- **[Magic Key Usage](kernel-lite-small-shell-cmd-mag.md)** - -- **[User-Space Exception Information](kernel-lite-small-shell-cmd-abn.md)** - - diff --git a/en/device-dev/kernel/kernel-lite-small-thread.md b/en/device-dev/kernel/kernel-lite-small-thread.md deleted file mode 100644 index d1d04cc376ee7a85153d5bafadc003999109e932..0000000000000000000000000000000000000000 --- a/en/device-dev/kernel/kernel-lite-small-thread.md +++ /dev/null @@ -1,702 +0,0 @@ -# Thread - -- [Basic Concepts](#section1179311337405) -- [When to Use](#section44877547404) -- [API Description](#section2069477134115) - -## Basic Concepts - -Threads are the minimum running units that compete for system resources. They can use or wait to use CPUs and use system resources such as memory. They run independently from one another. - -Threads in each process of the OpenHarmony kernel run and are scheduled independently. The scheduling of threads in a process is not affected by threads in other processes. - -Threads in the OpenHarmony kernel use the preemptive scheduling mechanism, either round-robin \(RR\) scheduling or First In First Out \(FIFO\) scheduling. - -Threads in the OpenHarmony kernel are assigned 32 priorities, ranging from **0** \(highest\) to **31** \(lowest\). - -A high-priority thread in a process can preempt the resources of a low-priority thread in this process. The low-priority thread can be scheduled only after the high-priority thread is blocked or terminated. - -**A thread may have the following states:** - -- **Init**: The thread is being created. - -- **Ready**: The thread is in the ready list and waits for being scheduled by the CPU. - -- **Running**: The thread is running. - -- **Blocked**: The thread is blocked and suspended. The **Blocked** states include **pending** \(blocked due to lock, event, or semaphore issues\), **suspended** \(active pending\), **delay** \(blocked due to delays\), and **pendtime** \(blocked by waiting timeout of locks, events, or semaphores\). - -- **Exit**: The thread stops running and waits for the parent thread to reclaim its control block resources. - - -**Figure 1** State transition of a thread -![](figure/state-transition-of-a-thread.png "state-transition-of-a-thread") - -**Description of the thread state transition:** - -- Init→Ready: - - When a thread is created, the thread enters the **Init** state to start initialization after obtaining the control block. After the thread is initialized, the thread is inserted into the scheduling queue and therefore enters the **Ready** state. - -- Ready→Running: - - When a thread switchover is triggered, the thread with the highest priority in the ready list is executed and enters the **Running** state. This thread will be deleted from the ready list. - -- Running→Blocked: - - When a running thread is blocked \(for example, is pended, delayed, or reading semaphores\), its state changes from **Running** to **Blocked**. Then, a thread switchover is triggered to run the thread with the highest priority in the ready list. - -- Blocked→Ready: - - After the blocked thread is restored \(the thread is restored, the delay times out, the semaphore reading times out, or the semaphore is read\), the thread is added to the ready list and changes from the **Blocked** state to the **Ready** state. - -- Ready→Blocked: - - A thread may also be blocked \(suspended\) in the **Ready** state. The blocked thread will change from the **Ready** state to the **Blocked** state and is deleted from the ready list. In this case, the thread will not be scheduled until it is restored. - -- Running→Ready: - - After a thread with a higher priority is created or restored, threads will be scheduled. The thread with the highest priority in the ready list will change to the **Running** state. The originally running thread will change from the **Running** state to the **Ready** state and be added to the ready list. - -- Running→Exit: - - When a running thread is terminated, its state changes from **Running** to **Exit**. The thread without the **PTHREAD\_CREATE\_DETACHED** attribute will present the **Exit** state after being terminated. - - -## When to Use - -After a thread is created, it can be scheduled, suspended, restored, and delayed in user space. In addition, you can set and obtain the scheduling priority and scheduling policy of the thread. - -## API Description - -The following table describes the APIs provided by the thread management module of the OpenHarmony kernel. - -**Table 1** APIs provided by the thread management module - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Header File

-

Function

-

Description

-

Remarks

-

pthread.h

-

pthread_attr_destroy

-

Destroys a thread attribute object.

-

N/A

-

pthread.h

-

pthread_attr_getinheritsched

-

Obtains inherit scheduler attributes of a thread attribute object.

-

N/A

-

pthread.h

-

pthread_attr_getschedparam

-

Obtains scheduling parameter attributes of a thread attribute object.

-

N/A

-

pthread.h

-

pthread_attr_getschedpolicy

-

Obtains scheduling policy attributes of a thread attribute object.

-

OpenHarmony supports the SCHED_FIFO and SCHED_RR scheduling policies.

-

pthread.h

-

pthread_attr_getstacksize

-

Obtains the stack size of a thread attribute object.

-

N/A

-

pthread.h

-

pthread_attr_init

-

Initializes a thread attribute object.

-

N/A

-

pthread.h

-

pthread_attr_setdetachstate

-

Sets the detach state for a thread attribute object.

-

N/A

-

pthread.h

-

pthread_attr_setinheritsched

-

Sets inherit scheduler attributes for a thread attribute object.

-

N/A

-

pthread.h

-

pthread_attr_setschedparam

-

Sets scheduling parameter attributes for a thread attribute object.

-

A larger value represents a higher priority of the thread in the system.

-

Note: The inheritsched field of the pthread_attr_t attribute must be set to PTHREAD_EXPLICIT_SCHED. Otherwise, the configured thread scheduling priority does not take effect. The default value is PTHREAD_INHERIT_SCHED.

-

pthread.h

-

pthread_attr_setschedpolicy

-

Sets scheduling policy attributes for a thread attribute object.

-

OpenHarmony supports the SCHED_FIFO and SCHED_RR scheduling policies.

-

pthread.h

-

pthread_attr_setstacksize

-

Sets the stack size for a thread attribute object.

-

N/A

-

pthread.h

-

pthread_getattr_np

-

Obtains the attributes of a created thread.

-

N/A

-

pthread.h

-

pthread_cancel

-

Sends a cancellation request to a thread.

-

N/A

-

pthread.h

-

pthread_testcancel

-

Requests delivery of any pending cancellation request.

-

N/A

-

pthread.h

-

pthread_setcanceltype

-

Sets the cancelability type for the calling thread.

-

N/A

-

pthread.h

-

pthread_setcancelstate

-

Sets the cancelability state for the calling thread.

-

N/A

-

pthread.h

-

pthread_create

-

Creates a thread.

-

N/A

-

pthread.h

-

pthread_detach

-

Detaches a thread.

-

N/A

-

pthread.h

-

pthread_equal

-

Compares whether two thread IDs are equal.

-

N/A

-

pthread.h

-

pthread_exit

-

Terminates the calling thread.

-

N/A

-

pthread.h

-

pthread_getschedparam

-

Obtains the scheduling policy and parameters of a thread.

-

OpenHarmony supports the SCHED_FIFO and SCHED_RR scheduling policies.

-

pthread.h

-

pthread_join

-

Waits for a thread to terminate.

-

N/A

-

pthread.h

-

pthread_self

-

Obtains the ID of the calling thread.

-

N/A

-

pthread.h

-

pthread_setschedprio

-

Sets a static scheduling priority for a thread.

-

N/A

-

pthread.h

-

pthread_kill

-

Sends a signal to a thread.

-

N/A

-

pthread.h

-

pthread_once

-

Enables the initialization function to be called only once.

-

N/A

-

pthread.h

-

pthread_atfork

-

Registers a fork handler to be called before and after fork().

-

N/A

-

pthread.h

-

pthread_cleanup_pop

-

Removes the routine at the top of the clean-up handler stack.

-

N/A

-

pthread.h

-

pthread_cleanup_push

-

Pushes the routine to the top of the clean-up handler stack.

-

N/A

-

pthread.h

-

pthread_barrier_destroy

-

Destroys a barrier (an advanced real-time thread).

-

N/A

-

pthread.h

-

pthread_barrier_init

-

Initializes a barrier (an advanced real-time thread).

-

N/A

-

pthread.h

-

pthread_barrier_wait

-

Synchronizes participating threads at a barrier.

-

N/A

-

pthread.h

-

pthread_barrierattr_destroy

-

Destroys a barrier attribute object.

-

N/A

-

pthread.h

-

pthread_barrierattr_init

-

Initializes a barrier attribute object.

-

N/A

-

pthread.h

-

pthread_mutex_destroy

-

Destroys a mutex.

-

N/A

-

pthread.h

-

pthread_mutex_init

-

Initializes a mutex.

-

N/A

-

pthread.h

-

pthread_mutex_lock

-

Locks a mutex.

-

N/A

-

pthread.h

-

pthread_mutex_trylock

-

Attempts to lock a mutex.

-

N/A

-

pthread.h

-

pthread_mutex_unlock

-

Unlocks a mutex.

-

N/A

-

pthread.h

-

pthread_mutexattr_destroy

-

Destroys a mutex attribute object.

-

N/A

-

pthread.h

-

pthread_mutexattr_gettype

-

Obtains the mutex type attribute.

-

N/A

-

pthread.h

-

pthread_mutexattr_init

-

Initializes a mutex attribute object.

-

N/A

-

pthread.h

-

pthread_mutexattr_settype

-

Sets the mutex type attribute.

-

N/A

-

pthread.h

-

pthread_mutex_timedlock

-

Blocks the calling thread to lock a mutex.

-

N/A

-

pthread.h

-

pthread_rwlock_destroy

-

Destroys a read-write lock.

-

N/A

-

pthread.h

-

pthread_rwlock_init

-

Initializes a read-write lock.

-

N/A

-

pthread.h

-

pthread_rwlock_rdlock

-

Applies a read lock to a read-write lock.

-

N/A

-

pthread.h

-

pthread_rwlock_timedrdlock

-

Blocks the calling thread to lock a read-write lock for reading.

-

N/A

-

pthread.h

-

pthread_rwlock_timedwrlock

-

Blocks the calling thread to lock a read-write lock for writing.

-

N/A

-

pthread.h

-

pthread_rwlock_tryrdlock

-

Attempts to apply a read lock to a read-write lock.

-

N/A

-

pthread.h

-

pthread_rwlock_trywrlock

-

Attempts to apply a write lock to a read-write lock.

-

N/A

-

pthread.h

-

pthread_rwlock_unlock

-

Unlocks a read-write lock.

-

N/A

-

pthread.h

-

pthread_rwlock_wrlock

-

Applies a write lock to a read-write lock.

-

N/A

-

pthread.h

-

pthread_rwlockattr_destroy

-

Destroys a read-write lock attribute object.

-

N/A

-

pthread.h

-

pthread_rwlockattr_init

-

Initializes a read-write lock attribute object.

-

N/A

-

pthread.h

-

pthread_cond_broadcast

-

Unblocks all threads that are currently blocked on the condition variable cond.

-

N/A

-

pthread.h

-

pthread_cond_destroy

-

Destroys a condition variable.

-

N/A

-

pthread.h

-

pthread_cond_init

-

Initializes a condition variable.

-

N/A

-

pthread.h

-

pthread_cond_signal

-

Unblocks a thread.

-

N/A

-

pthread.h

-

pthread_cond_timedwait

-

Blocks the calling thread to wait for the condition set by pthread_con_signal() for a period of time specified by ts.

-

N/A

-

pthread.h

-

pthread_cond_wait

-

Blocks the calling thread to wait for the condition set by pthread_con_signal().

-

N/A

-

semaphore.h

-

sem_destroy

-

Destroys a specified anonymous semaphore that is no longer used.

-

N/A

-

semaphore.h

-

sem_getvalue

-

Obtains the count value of a specified semaphore.

-

N/A

-

semaphore.h

-

sem_init

-

Creates and initializes an anonymous semaphore.

-

N/A

-

semaphore.h

-

sem_post

-

Increments the semaphore count by 1.

-

N/A

-

semaphore.h

-

sem_timedwait

-

Obtains the semaphore, with a timeout period specified.

-

N/A

-

semaphore.h

-

sem_trywait

-

Attempts to obtain the semaphore.

-

N/A

-

semaphore.h

-

sem_wait

-

Obtains the semaphore.

-

N/A

-
- diff --git a/en/device-dev/kernel/kernel-lite-small.md b/en/device-dev/kernel/kernel-lite-small.md index 7964a667d365b26721febc5fcb5e8cd169f1b73c..c742df10d58bbb358e29957b613433b800238219 100644 --- a/en/device-dev/kernel/kernel-lite-small.md +++ b/en/device-dev/kernel/kernel-lite-small.md @@ -1,11 +1,15 @@ # Kernel for Small Systems -- **[Basic Kernel](kernel-lite-small-basic.md)** +- **[Kernel Overview](kernel-small-overview.md)** -- **[File System](kernel-lite-small-file.md)** +- **[Kernel Startup](kernel-small-start.md)** -- **[Standard Library](kernel-lite-small-lib.md)** +- **[Basic Kernel](kernel-small-basics.md)** -- **[Commissioning](kernel-lite-small-shell.md)** +- **[Extension Components](kernel-small-bundles.md)** + +- **[Debugging and Tools](kernel-small-debug.md)** + +- **[Appendix](kernel-small-apx.md)** diff --git a/en/device-dev/kernel/kernel-lite.md b/en/device-dev/kernel/kernel-lite.md index 523555a5f4ec2692c5493bcbe08624a9f545812f..78ab36575118374840a0211296b1ebf9b6bf83e9 100644 --- a/en/device-dev/kernel/kernel-lite.md +++ b/en/device-dev/kernel/kernel-lite.md @@ -1,5 +1,7 @@ # Kernel for Mini and Small Systems +- **[Kernel for Mini Systems](kernel-lite-mini.md)** + - **[Kernel for Small Systems](kernel-lite-small.md)** diff --git a/en/device-dev/kernel/kernel-memory-inner.md b/en/device-dev/kernel/kernel-memory-inner.md new file mode 100644 index 0000000000000000000000000000000000000000..fe608e0da41f86333c18f5937f916f0257e812c8 --- /dev/null +++ b/en/device-dev/kernel/kernel-memory-inner.md @@ -0,0 +1,9 @@ +# Kernel Debugging + +- **[Memory Debugging](kernel-mini-memory-debug.md)** + +- **[Exception Debugging](kernel-mini-memory-exception.md)** + +- **[Trace Debugging](kernel-mini-memory-trace.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-app.md b/en/device-dev/kernel/kernel-mini-app.md new file mode 100644 index 0000000000000000000000000000000000000000..024612639051cffe49bceedb36cbbf21993e5c4f --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-app.md @@ -0,0 +1,9 @@ +# Appendix + +- **[Kernel Coding Specification](kernel-mini-appx-code.md)** + +- **[Basic Data Structure](kernel-mini-appx-data.md)** + +- **[Standard Libraries](kernel-mini-appx-lib.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-appx-code.md b/en/device-dev/kernel/kernel-mini-appx-code.md new file mode 100644 index 0000000000000000000000000000000000000000..7892f4823b55a50d68bdeb9cf931ed66b1012de3 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-appx-code.md @@ -0,0 +1,332 @@ +# Kernel Coding Specification + +- [Principle](#section9512812145915) +- [Directory Structure](#section1355317267017) +- [Naming](#section1375364815017) +- [Comments](#section1692516179119) +- [Format](#section10888536113) +- [Macros](#section12276501124) +- [Header Files](#section158507231319) +- [Data Types](#section91351731446) +- [Variables](#section575493915417) +- [Assertions](#section13864440410) +- [Functions](#section671919481745) + +This kernel coding specification is developed based on the general programming specifications in the industry. It defines the programming styles for kernel developers to follow. + +## Principle + +Overall principle: + +- Clear: The code should be easy to understand, maintain, and rebuilt. Avoid obscure syntax. +- Simple: Use short names and compact functions. +- Efficient: Improve program efficiency by using algorithms, compiler optimization options, or hardware resources. +- Concise: The code is reasonable and consistent. + +Comply with this specification in most cases. When third-party open-source code needs to modified or a large number of open-source code APIs are used, follow the specifications applied to the third-party open-source code. Flexibly use this specification based on general principles. + +## Directory Structure + +You are advised to divide directories by function module and then define the header file directory and source file directory for each module. + +Unless otherwise specified, use lowercase letters separated by underscores \(\_\) for directory names and file names. + +## **Naming** + +The CamelCase style is recommended. The rules are as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Type

+

Naming Style

+

Format

+

Function, struct, enumeration, union, and typedef

+

Upper camel case, or upper camel case prefixed with the module name

+

AaaBbb

+

XXX_AaaBbb

+

Local variables, function parameters, macro parameters, structure fields, and union members

+

Lower camel case

+

aaaBBB

+

Global variables

+

Lower camel case prefixed with g_

+

g_aaaBBB

+

Macros (excluding function-like macros), enumerated values, goto tags

+

All uppercase letters separated with underscores (_)

+

AAA_BBB

+

Function-like macros

+

Uppercase letters separated with underscores (_), upper camel case, or upper camel case prefixed with the module name

+

AAA_BBB

+

AaaBbb

+

XXX_AaaBbb

+

Header file names

+

Starts with an underscore (_) and ends with H. The middle part is the file name in all caps and is separated by underscores (_).

+

_AAA_H

+
+ +The **LOS\_**_ModuleFunc_ format is recommended for external APIs of the kernel. Preposition the object if there is any. Example: + +``` +LOS_TaskCreate +LOS_MuxLock +``` + +The APIs between internal modules in the kernel directory are in the **Os**_ModuleFunc_ format. For example: + +``` +OsTaskScan +OsMuxInit +``` + +## Comments + +Generally, clear software architecture and appropriate symbol naming improve code readability. + +Comments are added to make the source code easier for humans to understand. Therefore, add comments only when necessary, from the perspective of the readers. + +Comments must be concise, clear, and unambiguous. The information must be complete and not redundant. + +Comments must be added to the file header. It is recommended that the comments include the copyright description, file function description, author, creation date, and precautions. + +Use a consistent style for comments. The use of /\* and \*/ as block comment delimiters is recommended. There must be a space between the comment characters and the comment. Comment single-line and multi-line comments are as follows: + +``` +/* Single-line comment */ +// Single-line comment +/* + * Multi-line comment + * Second line + */ +// Multi-line comment +// Another line +``` + +Place the code comment above or to the right of the code. + +Leave no blank line between the code and the comment, and indent the comment the same way as the code. + +Leave at least one space between the code and the comment on the right. + +You are advised to align multiple consecutive comments on the right. For example: + +``` +#define CONST_A 100 /* Const A */ +#define CONST_B 2000 /* Const B */ +``` + +## **Format** + +Indent code of each level with four spaces rather than tabs \('\\t'\) for a better readability. + +While wrapping a line, the left brace of the function starts a new line and takes a single line. Other left braces are placed at the end of the line along with the statement. The right brace occupies one line unless followed by the remaining part of the same statement, for example, while in the do statement, else/else if in the if statement, or a comma or semicolon. + +Write only one statement in one line. + +Example: + +``` +struct MyType { // Add a comment here, and leave a space between the comment sign (//) and the comment. + ... +}; // The right brace is followed by a semicolon (;). +int Foo(int a) {// The left brace of the function is placed at the beginning of a line and occupies one line. + if (a > 0) { + Foo(); // There is only one statement in a line. + Bar(); + } else { // The right brace, else, and the subsequent left brace are in the same line. + ... + } // The right brace occupies one line exclusively. + ... +} +``` + +Avoid lines longer than 120 characters. When starting a new line, place the operator at the end of the line, indent the new line or align the lines of the same type, and place the operator indicating not end or connection sign at the end of the line. + +``` +// Assume that the first line below does not fit on a single line. +if (currentValue > MIN && // Good: Place the Boolean operator at the end of the new line. + currentValue < MAX) { // Good: Align with the two operands of the (&&) operator. + DoSomething(); + ... +} +flashPara.flashEndAddr = flashPara.flashBaseAddr + // Good: Place the plus sign at the end of the line. + flashPara.flashSize; // Good: Align the two operands. + +// Good: Place function parameters in one line. +ReturnType result = FunctionName(paramName1, paramName2); +ReturnType result = FunctionName(paramName1, + paramName2, + paramName3); // Good: Align with the preceding parameters. +ReturnType result = FunctionName(paramName1, paramName2, + paramName3, paramName4, paramName5); // Good: Place the parameters in a new line, with an indentation of 4 spaces. +ReturnType result = VeryVeryVeryLongFunctionName( // Start a new line because the first parameter does not fit on a single line. + paramName1, paramName2, paramName3); // Indent the new line 4 spaces. + +// Good: Place a group of data structures with strong correlation in a line for easy understanding. +int result = DealWithStructLikeParams(left.x, left.y, // Indicates a group of related parameters. + right.x, right.y); // Indicates another group of related parameters. +``` + +Use braces, that is, compound statements for **if**, **for**, **while**, and **do-while** statements. + +``` +while (condition) {} // Good: Use braces even if the loop body is empty. +while (condition) { + continue; // Good: continue indicates empty logic. Use braces. +} +``` + +Indent the **case** or **default** statement as follows compared with the **switch** statement: + +``` +switch (var) { + case 0: // Good: Indent + DoSomething1(); // Good: indent + break; + case 1: { // Good: with braces + DoSomething2(); + break; + } + default: + break; +} +``` + +The pointer "\*" follows a variable or function name, for example: + +``` +int *p1; // OK +int* p2; // Bad: The pointer * follows a data type. +int*p3; // Bad: There is no space on both sides of *. +int * p4; // Bad: There is a space on both sides of *. +struct Foo *CreateFoo(void); // OK: The pointer * follows a function name. +Exception: +char * const VERSION = "V100"; // OK: When there is the const modifier, a space is required on both sides of *. +int Foo(const char * restrict p); // OK: When there is the restrict modifier, a space is required on both sides of *. +sz = sizeof(int*); // OK: There is no variable on the right, and * follows the data type. +``` + +## Macros + +If a function-like macro can be replaced by a function, use a function instead. Use inline functions for performance-critical scenarios. + +When defining a macro, use complete parentheses \(round brackets\). For example: + +``` +#define SUM(a, b) ((a) + (b)) // Complies with this specification. +#define SOME_CONST 100 // Good: No parentheses are required for a single number. +#define ANOTHER_CONST (-1) // Good: Parentheses are required for a negative number. +#define THE_CONST SOME_CONST // Good: No parentheses are required for a single identifier. +``` + +Pay attention to the following: + +- Do not add parentheses for macro parameters used in \# or \#\# operations. +- Do not add parentheses for macro parameters used in string concatenation. +- If a macro parameter is used as a separate part in one side of an assignment operation\(including += and -=\), parentheses can be omitted. +- If a macro parameter is used as a separate part in a comma expression, function, or macro call list, parentheses can be omitted. + +``` +// Do not enclose x in parentheses. +#define MAKE_STR(x) #x + +// Do not enclose obj in parentheses. +#define HELLO_STR(obj) "Hello, " obj + +// Parentheses are required for a and b, but not for value. +#define UPDATE_VALUE(value, a, b) (value = (a) + (b)) + +// Parentheses are required for a, but not for b. +#define FOO(a, b) Bar((a) + 1, b) +``` + +The statement used to implement the function-like macros that contain multiple statements must be placed in **do-while\(0\)**. + +Do not pass expressions with side effects, such as **a++**, to function-like macros as parameters. + +Exercise caution when using the statements such as **return**, **goto**, **continue**, and **break** in the function-like macro definition. + +Do not use preprocessor directives, such as **\#include**, **\#define**, and **\#ifdef**, in arguments for macro calling. Otherwise, undefined behavior may occur. + +Do not end macro definitions with a semicolon \(;\). + +## Header Files + +A header file should have a single responsibility. + +Generally, each .c file should have a .h file \(the file name may not be the same\) to store the function declaration, macro definition, and type definition provided externally. If no external API is provided, the .h file can be skipped. + +Avoid circular dependency between header files. For example, **a.h** contains **b.h**, **b.h** contains **c.h**, and **c.h** contains **a.h**. + +Header files should be self-contained \(compile on their own\). + +Protect header files by **\#define**, **\#ifndef**, and **\#endif** to prevent repeated inclusion. Do not use **\#pragma once**. + +Do not reference external function APIs or variables in declaration mode. Use the APIs provided by other modules or files only by including header files. + +It is recommended that header files be included by stability in the following sequence: header file corresponding to the source code, C standard library, operating system library, platform library, project public library, and other dependencies. + +## Data Types + +You are advised to use the basic data types defined in **los\_compiler.h**. For example, define the 32-bit unsigned integer as **UINT32**. + +## Variables + +Avoid large stack allocations, such as large local arrays. + +Use global variables with caution. Do not use or reduce global variables if possible. + +Variables must be initialized before being used. + +Do not return the address of a local variable outside its scope. + +A variable that points to a resource handle or descriptor is assigned a new value immediately after the resource is released. If the scope of the variable ends immediately, no new value needs to be assigned. Variables that point to resource handles or descriptors include pointers, file descriptors, socket descriptors, and other variables that point to resources. + +## Assertions + +Assertions must be defined using macros and take effect only in the debugging version. + +Assertions should be considered as design constraints. Do not use assertions to detect errors that may occur during program running. Use error processing code to handle possible errors. + +Do not change the running environment in an assertion. + +An assertion is used to check only one error. + +## Functions + +The validity of data sent from a process to another process and data sent from an application to the kernel must be verified. The verification includes but is not limited to the following: + +- Data length +- Data range +- Data type and format +- Input that contains only acceptable characters \(in a trustlist\) + +Do not use global variables, static local variables, or direct I/O operations in functions. If such operations are inevitable, encapsulate read and write operations. + diff --git a/en/device-dev/kernel/kernel-mini-appx-data-list.md b/en/device-dev/kernel/kernel-mini-appx-data-list.md new file mode 100644 index 0000000000000000000000000000000000000000..c99d45cbe43c3aa7ef73a00cfd834a84d5455707 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-appx-data-list.md @@ -0,0 +1,191 @@ +# Doubly Linked List + +- [Basic Concepts](#section1990715203418) +- [Available APIs](#section848334511411) +- [How to Develop](#section01781261552) +- [Development Example](#section67569495514) + - [Example Description](#section48761994551) + - [Sample Code](#section1280202685519) + - [Verification](#section5811249105512) + + +## Basic Concepts + +A doubly linked list is a linked data structure that consists of a set of sequentially linked records called nodes. Each node contains a pointer to the previous node and a pointer to the next node in the sequence of nodes. The pointer head is unique. + +A doubly linked list allows access from a list node to its next node and also the previous node on the list. This data structure facilitates data search, especially traversal of a large amount of data. The symmetry of the doubly linked list also makes operations, such as insertion and deletion, easy. However, pay attention to the pointer direction when performing operations. + +## Available APIs + +The doubly linked list module provides the following APIs. For more details about the APIs, see the API reference. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Initializing a linked list

+

LOS_ListInit

+

Initializes a specified doubly linked list node as a doubly linked list.

+

LOS_DL_LIST_HEAD

+

Defines a doubly linked list node and initializes the node as a doubly linked list.

+

Adding a node

+

LOS_ListAdd

+

Inserts the specified node to the head of a doubly linked list.

+

LOS_ListTailInsert

+

Inserts the specified node to the end of a doubly linked list.

+

Deleting a node

+

LOS_ListDelete

+

Deletes the specified node from a doubly linked list.

+

LOS_ListDelInit

+

Deletes the specified node from the linked list and uses the node to initialize the linked list.

+

Checking whether a doubly linked list is empty

+

LOS_ListEmpty

+

Checks whether a linked list is empty.

+

Obtaining structure information

+

LOS_DL_LIST_ENTRY

+

Obtains the address of the structure that contains the linked list. The first input parameter of the API indicates a node in the list, the second input parameter indicates the name of the structure to be obtained, and the third input parameter indicates the name of the linked list in the structure.

+

LOS_OFF_SET_OF

+

Obtains the offset of a member in a specified structure relative to the start address of the structure.

+

Traversing a doubly linked list

+

LOS_DL_LIST_FOR_EACH

+

Traverses a doubly linked list.

+

LOS_DL_LIST_FOR_EACH_SAFE

+

Traverses a doubly linked list, and stores the next node of the current node for security verification.

+

Traversing the structure that contains the doubly linked list

+

LOS_DL_LIST_FOR_EACH_ENTRY

+

Traverses the specified doubly linked list and obtains the address of the structure that contains the linked list node.

+

LOS_DL_LIST_FOR_EACH_ENTRY_SAFE

+

Traverses the specified doubly linked list, obtains the structure address of the node that contains the linked list, and stores the structure address that contains the next node of the current node.

+
+ +## How to Develop + +The typical development process of the doubly linked list is as follows: + +1. Call **LOS\_ListInit/LOS\_DL\_LIST\_HEAD** to initialize a doubly linked list. +2. Call **LOS\_ListAdd** to insert a node to the list. +3. Call **LOS\_ListTailInsert** to insert a node to the end of the list. +4. Call **LOS\_ListDelete** to delete the specified node. +5. Call **LOS\_ListEmpty** to check whether a linked list is empty. +6. Call **LOS\_ListDelInit** to delete a specified node, and initialize the linked list based on this node. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- Pay attention to the operations of the front and back pointer of the node. +>- The linked list operation APIs are underlying APIs and do not check whether the input parameters are empty. You must ensure that the input parameters are valid. +>- If the memory of a linked list node is dynamically requested, release the memory after deleting the node. + +## Development Example + +### Example Description + +This example implements the following: + +1. Initialize a doubly linked list. +2. Add nodes. +3. Delete a node. +4. Check whether the operation is performed successfully. + +### Sample Code + +The sample code is as follows: + +``` +#include "stdio.h" +#include "los_list.h" + +static UINT32 ListSample(VOID) +{ + LOS_DL_LIST listHead = {NULL,NULL}; + LOS_DL_LIST listNode1 = {NULL,NULL}; + LOS_DL_LIST listNode2 = {NULL,NULL}; + + // Initialize the linked list. + printf("Initial head\n"); + LOS_ListInit(&listHead); + + // Add node 1 and node 2 and verify their relationship. + LOS_ListAdd(&listHead, &listNode1); + if (listNode1.pstNext == &listHead && listNode1.pstPrev == &listHead) { + printf("Add listNode1 success\n"); + } + + LOS_ListTailInsert(&listHead, &listNode2); + if (listNode2.pstNext == &listHead && listNode2.pstPrev == &listNode1) { + printf("Tail insert listNode2 success\n"); + } + + // Delete the two nodes. + LOS_ListDelete(&listNode1); + LOS_ListDelete(&listNode2); + + // Check that the linked list is empty. + if (LOS_ListEmpty(&listHead)) { + printf("Delete success\n"); + } + + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +Initial head +Add listNode1 success +Tail insert listNode2 success +Delete success +``` + diff --git a/en/device-dev/kernel/kernel-mini-appx-data.md b/en/device-dev/kernel/kernel-mini-appx-data.md new file mode 100644 index 0000000000000000000000000000000000000000..d58ec79bc4eb24810ae0e36432ae7c33f1c73cad --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-appx-data.md @@ -0,0 +1,5 @@ +# Basic Data Structure + +- **[Doubly Linked List](kernel-mini-appx-data-list.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-appx-lib-cmsis.md b/en/device-dev/kernel/kernel-mini-appx-lib-cmsis.md new file mode 100644 index 0000000000000000000000000000000000000000..a30a1367739582eb1c8a2313ec189f7750d7877f --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-appx-lib-cmsis.md @@ -0,0 +1,487 @@ +# CMSIS Support + +- [Basic Concepts](#section131091144111615) +- [Development Guidelines](#section57653573161) + - [Available APIs](#section1795910417173) + - [How to Develop](#section48301225131720) + - [Development Example](#section524434761713) + + +## Basic Concepts + +The Cortex Microcontroller Software Interface Standard \([CMSIS](https://developer.arm.com/tools-and-software/embedded/cmsis)\) is a vendor-independent hardware abstraction layer for microcontrollers based on Arm Cortex processors. Of the CMSIS components, the Real Time Operating System \(RTOS\) defines a set of universal and standardized APIs to reduce the dependency of application developers on specific RTOS and facilitate software porting and reuse. The CMSIS provides CMSIS-RTOS v1 and CMSIS-RTOS v2. The OpenHarmony LiteOS-M supports only the implementation of CMSIS-RTOS v2. + +## Development Guidelines + +### Available APIs + +The following table describes CMSIS-RTOS v2 APIs. For more details about the APIs, see the API reference. + +**Table 1** CMSIS-RTOS v2 APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Kernel information and control

+

osKernelGetInfo

+

Obtains RTOS kernel information.

+

osKernelGetState

+

Obtains the current RTOS kernel status.

+

osKernelGetSysTimerCount

+

Obtains the RTOS kernel system timer count.

+

osKernelGetSysTimerFreq

+

Obtains the RTOS kernel system timer frequency.

+

osKernelInitialize

+

Initializes the RTOS kernel.

+

osKernelLock

+

Locks the RTOS kernel scheduler.

+

osKernelUnlock

+

Unlocks the RTOS kernel scheduler.

+

osKernelRestoreLock

+

Restores the RTOS kernel scheduler to the locked state.

+

osKernelResume

+

Restores the RTOS kernel scheduler. (not implemented yet)

+

osKernelStart

+

Starts the RTOS kernel scheduler.

+

osKernelSuspend

+

Suspends the RTOS kernel scheduler. (not implemented yet)

+

osKernelGetTickCount

+

Obtains the RTOS kernel tick count.

+

osKernelGetTickFreq

+

Obtains the RTOS kernel tick frequency.

+

Thread management

+

osThreadDetach

+

Detaches a thread (thread storage can be reclaimed when the thread terminates). (not implemented yet)

+

osThreadEnumerate

+

Enumerates active threads. (not implemented yet)

+

osThreadExit

+

Terminates execution of the thread that is currently running.

+

osThreadGetCount

+

Obtains the number of active threads.

+

osThreadGetId

+

Returns the ID of the thread that is running.

+

osThreadGetName

+

Obtains the name of a thread.

+

osThreadGetPriority

+

Obtains the current priority of a thread.

+

osThreadGetStackSize

+

Obtains the stack size of a thread.

+

osThreadGetStackSpace

+

Obtains the available stack space of a thread based on the stack waterline record during execution.

+

osThreadGetState

+

Obtains the current status of a thread.

+

osThreadJoin

+

Waits for the specified thread to terminate. (not implemented yet)

+

osThreadNew

+

Creates a thread and add it to active threads.

+

osThreadResume

+

Resumes the execution of a thread.

+

osThreadSetPriority

+

Changes the priority of a thread.

+

osThreadSuspend

+

Suspends the execution of a thread.

+

osThreadTerminate

+

Terminates the execution of a thread.

+

osThreadYield

+

Passes control to the next thread in the ready state.

+

Thread flag

+

osThreadFlagsSet

+

Sets the specified thread flags for a thread. (not implemented yet)

+

osThreadFlagsClear

+

Clears the specified thread flags of the thread that is running. (not implemented yet)

+

osThreadFlagsGet

+

Obtains the current thread flags of the thread that is running. (not implemented yet)

+

osThreadFlagsWait

+

Waits for one or more thread flags of the currently running thread to emit a signal. (not implemented yet)

+

Event flag

+

osEventFlagsGetName

+

Obtains the name of an event flag object. (not implemented yet)

+

osEventFlagsNew

+

Creates and initializes an event flag object.

+

osEventFlagsDelete

+

Deletes an event flag object.

+

osEventFlagsSet

+

Sets the specified event flag.

+

osEventFlagsClear

+

Clears the specified event flag.

+

osEventFlagsGet

+

Obtains the current event flag.

+

osEventFlagsWait

+

Waits for one or more event flags to be signaled.

+

General wait function

+

osDelay

+

Waits for timeout (time delay).

+

osDelayUntil

+

Waits until the specified time.

+

Timer management

+

osTimerDelete

+

Deletes a timer.

+

osTimerGetName

+

Obtains the name of a timer. (not implemented yet)

+

osTimerIsRunning

+

Check whether a timer is running.

+

osTimerNew

+

Creates and initializes a timer.

+

osTimerStart

+

Starts or restarts a timer.

+

osTimerStop

+

Stops a timer.

+

Mutex management

+

osMutexAcquire

+

Acquires a mutex or waits for timeout (if locked).

+

osMutexDelete

+

Deletes a mutex object.

+

osMutexGetName

+

Obtains the name of a mutex object. (not implemented yet)

+

osMutexGetOwner

+

Obtains the thread that has a mutex object.

+

osMutexNew

+

Creates and initializes a mutex object.

+

osMutexRelease

+

Releases the mutex obtained by calling osMutexAcquire.

+

Semaphore

+

osSemaphoreAcquire

+

Obtains a semaphore token or waits for timeout if no token is available.

+

osSemaphoreDelete

+

Deletes a semaphore object.

+

osSemaphoreGetCount

+

Obtains the number of tokens of the current semaphore.

+

osSemaphoreGetName

+

Obtains the name of a semaphore object. (not implemented yet)

+

osSemaphoreNew

+

Creates and initializes a semaphore object.

+

osSemaphoreRelease

+

Releases a semaphore token till the initial maximum count.

+

Memory pool

+

osMemoryPoolAlloc

+

Allocates a memory block from the memory pool.

+

osMemoryPoolDelete

+

Deletes a memory pool object.

+

osMemoryPoolFree

+

Releases the allocated memory block to the memory pool.

+

osMemoryPoolGetBlockSize

+

Obtains the memory block size in the memory pool.

+

osMemoryPoolGetCapacity

+

Obtains the maximum number of memory blocks in the memory pool.

+

osMemoryPoolGetCount

+

Obtains the number of memory blocks used in the memory pool.

+

osMemoryPoolGetName

+

Obtains the name of a memory pool object.

+

osMemoryPoolGetSpace

+

Obtains the number of available memory blocks in the memory pool.

+

osMemoryPoolNew

+

Creates and initializes a memory pool object.

+

Message queue

+

osMessageQueueDelete

+

Deletes a message queue object.

+

osMessageQueueGet

+

Obtains a message from the queue or waits for timeout if the queue is empty.

+

osMessageQueueGetCapacity

+

Obtains the maximum number of messages in a message queue.

+

osMessageQueueGetCount

+

Obtains the number of queued messages in a message queue.

+

osMessageQueueGetMsgSize

+

Obtains the maximum size of the message in the memory pool.

+

osMessageQueueGetName

+

Obtains the name of a message queue object. (not implemented yet)

+

osMessageQueueGetSpace

+

Obtains the number of available slots for messages in a message queue.

+

osMessageQueueNew

+

Creates and initializes a message queue object.

+

osMessageQueuePut

+

Puts the message into the queue or waits till timeout if the queue is full.

+

osMessageQueueReset

+

Resets the message queue to its initial empty state. (not implemented yet)

+
+ +### How to Develop + +The CMSIS-RTOS v2 component can be provided as a library \(shown in the figure\) or source code. By adding the CMSIS-RTOS v2 component \(typically configuration files\), you can implement RTOS capabilities on CMSIS-based applications. You only need to include the **cmsis\_os2.h** header file. RTOS APIs can then be called to process RTOS kernel-related events. You do not need to recompile the source code when the kernel is replaced. + +The RTOS object control block definition needs to be called for static object allocation. The implementation-specific header file \(**os\_xx.h** in the following figure\) provides access to such control block definitions. In the OpenHarmony LiteOS-M kernel, the header files whose names start with **los\_** provide the definitions of the kernel. + +![](figure/en-us_image_0000001132778524.png) + +### Development Example + +``` +#include ... +#include "cmsis_os2.h" + +/*---------------------------------------------------------------------------- + * Application main thread + *---------------------------------------------------------------------------*/ +void app_main (void *argument) { + // ... + for (;;) {} +} + +int main (void) { + // Initialize the system. + MySystemInit(); + // ... + + osKernelInitialize(); // Initialize CMSIS-RTOS. + osThreadNew(app_main, NULL, NULL); // Create the main thread of the application. + osKernelStart(); // Start to execute the thread. + for (;;) {} +} +``` + diff --git a/en/device-dev/kernel/kernel-mini-appx-lib-posix.md b/en/device-dev/kernel/kernel-mini-appx-lib-posix.md new file mode 100644 index 0000000000000000000000000000000000000000..ebed9d85d51bb803ee54a998d7e944afd9621f5b --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-appx-lib-posix.md @@ -0,0 +1,1637 @@ +# POSIX Support + +- [Basic Concepts](#section1757915134139) +- [Development Guidelines](#section1573664211318) + - [Available APIs](#section10429150121317) + - [Important Notes](#section109174418147) + - [Development Example](#section206149278155) + + +## Basic Concepts + +The OpenHarmony kernel uses the **musl libc** library and self-developed APIs and supports the Portable Operating System Interface \(POSIX\). You can develop components and applications working on the kernel based on the POSIX. + +## Development Guidelines + +### Available APIs + +**Table 1** Available APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Type

+

Header File

+

API

+

Description

+

process

+

#include <stdlib.h>

+

void abort(void);

+

Terminates the execution of a thread.

+

#include <assert.h>

+

void assert(scalar expression);

+

Terminates the thread if the assertion is false.

+

#include <pthread.h>

+

int pthread_cond_destroy(pthread_cond_t *cond);

+

Destroys a condition variable.

+

#include <pthread.h>

+

int pthread_cond_init(pthread_cond_t *restrict cond, const pthread_condattr_t *restrict attr);

+

Initializes a condition variable.

+

#include <pthread.h>

+

int pthread_cond_timedwait(pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex, const struct timespec *restrict abstime);

+

Waits for the condition.

+

#include <pthread.h>

+

int pthread_condattr_init(pthread_condattr_t *attr);

+

Initializes a condition variable attribute object.

+

#include <pthread.h>

+

int pthread_mutex_unlock(pthread_mutex_t *mutex);

+

Unlocks a mutex.

+

#include <pthread.h>

+

int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg);

+

Creates a thread.

+

#include <pthread.h>

+

int pthread_join(pthread_t thread, void **retval);

+

Waits for a thread to terminate.

+

#include <pthread.h>

+

pthread_t pthread_self(void);

+

Obtains the ID of the current thread.

+

#include <pthread.h>

+

int pthread_getschedparam(pthread_t thread, int *policy, struct sched_param *param);

+

Obtains the scheduling policy and parameters of a thread.

+

#include <pthread.h>

+

int pthread_setschedparam(pthread_t thread, int policy, const struct sched_param *param);

+

Sets a scheduling policy and parameters for a thread.

+

#include <pthread.h>

+

int pthread_mutex_init(pthread_mutex_t *__restrict m, const pthread_mutexattr_t *__restrict a);

+

Initializes a mutex.

+

#include <pthread.h>

+

int pthread_mutex_lock(pthread_mutex_t *m);

+

Locks a mutex.

+

#include <pthread.h>

+

int pthread_mutex_trylock(pthread_mutex_t *m);

+

Attempts to lock a mutex.

+

#include <pthread.h>

+

int pthread_mutex_destroy(pthread_mutex_t *m);

+

Destroys a mutex.

+

#include <pthread.h>

+

int pthread_attr_init(pthread_attr_t *attr);

+

Initializes a thread attribute object.

+

#include <pthread.h>

+

int pthread_attr_destroy(pthread_attr_t *attr);

+

Destroys a thread attribute object.

+

#include <pthread.h>

+

int pthread_attr_getstacksize(const pthread_attr_t *attr, size_t *stacksize);

+

Obtains the stack size of a thread attribute object.

+

#include <pthread.h>

+

int pthread_attr_setstacksize(pthread_attr_t *attr, size_t stacksize);

+

Sets the stack size for a thread attribute object.

+

#include <pthread.h>

+

int pthread_attr_getschedparam(const pthread_attr_t *attr, struct sched_param *param);

+

Obtains scheduling parameter attributes of a thread attribute object.

+

#include <pthread.h>

+

int pthread_attr_setschedparam(pthread_attr_t *attr, const struct sched_param *param);

+

Sets scheduling parameter attributes for a thread attribute object.

+

#include <pthread.h>

+

int pthread_getname_np(pthread_t pthread, char *name, size_t len);

+

Obtains the name of a thread.

+

#include <pthread.h>

+

int pthread_setname_np(pthread_t pthread, const char *name);

+

Set the thread name.

+

#include <pthread.h>

+

int pthread_cond_broadcast(pthread_cond_t *c);

+

Unblocks the threads that are currently blocked on the condition variable.

+

#include <pthread.h>

+

int pthread_cond_signal(pthread_cond_t *c);

+

Unblocks a thread.

+

#include <pthread.h>

+

int pthread_cond_wait(pthread_cond_t *__restrict c, pthread_mutex_t *__restrict m);

+

Waits for the condition.

+

fs

+

+

#include <libgen.h>

+

char *dirname(char *path);

+

Obtains the folder name.

+

#include <dirent.h>

+

struct dirent *readdir(DIR *dirp);

+

Reads a directory.

+

#include <sys/stat.h>

+

int stat(const char *restrict path, struct stat *restrict buf);

+

Obtains file information.

+

#include <unistd.h>

+

int unlink(const char *pathname);

+

Deletes a file.

+

#include <fcntl.h

+

int open(const char *path, int oflags, ...);

+

Opens a file. If the file does not exist, create a file and open it.

+

#include <nistd.h>

+

int close(int fd);

+

Closes a file.

+

#include <stdio.h>

+

int rename(const char *oldpath, const char *newpath);

+

Rename the specified file.

+

#include <dirent.h>

+

DIR *opendir(const char *dirname);

+

Opens the specified directory.

+

#include <dirent.h>

+

int closedir(DIR *dir);

+

Closes the specified directory.

+

#include <sys/mount.h>

+

int mount(const char *source, const char *target, const char *filesystemtype, unsigned long mountflags, const void *data);

+

Mounts a file system.

+

#include <sys/mount.h>

+

int umount(const char *target);

+

Unmounts a file system.

+

#include <sys/mount.h>

+

int umount2(const char *target, int flag);

+

Unmounts a file system.

+

#include <sys/stat.h>

+

int fsync(int fd);

+

Synchronizes the files associated with a specified file descriptor to a storage device.

+

#include <sys/stat.h>

+

int mkdir(const char *pathname, mode_t mode);

+

Creates a directory.

+

#include <unistd.h>

+

int rmdir(const char *path);

+

Deletes a directory.

+

#include <sys/stat.h>

+

int fstat(int fd, struct stat *buf);

+

Obtains file status information.

+

#include <sys/statfs.h>

+

int statfs(const char *path, struct statfs *buf);

+

Obtains the file system information of a file in the specified path.

+

time

+

#include <sys/time.h>

+

int gettimeofday(struct timeval *tv, struct timezone *tz);

+

Obtains the time. Time zone is not supported. The return value of tz is empty.

+

#include <time.h>

+

struct tm *gmtime(const time_t *timep);

+

Converts a date and time to broken-down time or ASCII.

+

#include <time.h>

+

struct tm *localtime(const time_t *timep);

+

Obtains the time.

+

#include <time.h>

+

struct tm *localtime_r(const time_t *timep, struct tm *result);

+

Obtains the time.

+

#include <time.h>

+

time_t mktime(struct tm *tm);

+

Converts a date and time to broken-down time or ASCII.

+

#include <time.h>

+

size_t strftime(char *s, size_t max, const char *format,const struct tm *tm);

+

Formats the date and time string.

+

#include <time.h>

+

time_t time(time_t *tloc);

+

Obtains the calendar time.

+

#include <sys/times.h>

+

clock_t times(struct tms *buf);

+

Obtains the thread time.

+

#include <unistd.h>

+

int usleep(useconds_t usec);

+

Goes to hibernation (in μs).

+

#include <time.h>

+

int nanosleep(const struct timespec *tspec1, struct timespec *tspec2);

+

Pauses the calling thread till the specified time.

+

#include <time.h>

+

int clock_gettime(clockid_t id, struct timespec *tspec);

+

Obtains the clock time.

+

#include <time.h>

+

int timer_create(clockid_t id, struct sigevent *__restrict evp, timer_t *__restrict t);

+

Creates a timer for a thread.

+

#include <time.h>

+

int timer_delete(timer_t t);

+

Deletes a thread timer.

+

#include <time.h>

+

int timer_settime(timer_t t, int flags, const struct itimerspec *__restrict val, struct itimerspec *__restrict old);

+

Sets a timer for a thread.

+

#include <time.h>

+

time_t time (time_t *t);

+

Obtains the time.

+

#include <time.h>

+

char *strptime(const char *s, const char *format, struct tm *tm);

+

Converts the time string into the time tm structure.

+

util

+

#include <stdlib.h>

+

int atoi(const char *nptr);

+

Converts the character string into an integer (int).

+

#include <stdlib.h>

+

long atol(const char *nptr);

+

Converts the character string into an integer (long).

+

#include <stdlib.h>

+

long long atoll(const char *nptr);

+

Converts the character string into an integer (long long).

+

#include <ctype.h>

+

int isalnum(int c);

+

Checks for alphanumeric characters.

+

#include <ctype.h>

+

int isascii(int c);

+

Checks for ASCII.

+

#include <ctype.h>

+

int isdigit(int c);

+

Checks for numeric characters.

+

#include <ctype.h>

+

int islower(int c);

+

Checks for lowercase letters.

+

#include <ctype.h>

+

int isprint(int c);

+

Checks for printable characters, including spaces.

+

#include <ctype.h>

+

int isspace(int c);

+

Checks for a space.

+

#include <ctype.h>

+

int isupper(int c);

+

Checks for uppercase letters.

+

#include <ctype.h>

+

int isxdigit(int c);

+

Checks for hexadecimal digits.

+

#include <stdlib.h>

+

long int random (void);

+

Generates a random number.

+

#include <stdlib.h>

+

void srandom(unsigned int seed);

+

Initializes the random number generator.

+

#include <ctype.h>

+

int tolower(int c);

+

Converts letters to lowercase letters.

+

#include <ctype.h>

+

int toupper(int c);

+

Converts letters to uppercase letters.

+

#include <stdarg.h>

+

type va_arg(va_list ap, type);

+

Obtains the current parameter of a variable parameter, returns the value of the specified type, and moves the pointer to the next parameter.

+

#include <stdarg.h>

+

void va_copy(va_list dest, va_list src);

+

Copies parameters.

+

#include <stdarg.h>

+

void va_end(va_list ap);

+

Clears the va_list variable parameter list.

+

#include <stdarg.h>

+

void va_start(va_list ap, last);

+

Defines the start position of the variable-length parameter list.

+

#include <string.h>

+

char *strchr(const char *s, int c);

+

Locates the last occurrence of a character in a string.

+

#include <string.h>

+

int strcmp(const char *s1, const char *s2);

+

Compares strings.

+

#include <string.h>

+

size_t strcspn(const char *s, const char *reject);

+

Obtains the length of the initial segment of a string.

+

#include <string.h>

+

char *strdup(const char *s);

+

Copies a string to a new position.

+

#include <string.h>

+

size_t strlen(const char *s);

+

Calculates the length of a string.

+

#include <strings.h>

+

int strncasecmp(const char *s1, const char *s2, size_t n);

+

Compares fixed-length strings (case-insensitive).

+

#include <strings.h>

+

int strcasecmp(const char *s1, const char *s2);

+

Compares strings (case-insensitive).

+

#include <string.h>

+

int strncmp(const char *s1, const char *s2, size_t n);

+

Compares strings of the specified length.

+

#include <string.h>

+

char *strrchr(const char *s, int c);

+

Locates the last occurrence of a character in a string.

+

#include <string.h>

+

char *strstr(const char *haystack, const char *needle);

+

Searches for the specified string needle.

+

#include <stdlib.h>

+

long int strtol(const char *nptr, char **endptr, int base);

+

Converts a string into a long int value.

+

#include <stdlib.h>

+

unsigned long int strtoul(const char *nptr, char **endptr, int base);

+

Converts a string into an unsigned long int value.

+

#include <stdlib.h>

+

unsigned long long int strtoull(const char *nptr, char **endptr,int base);

+

Converts a string into an unsigned long long int value.

+

#include <regex.h>

+

int regcomp(regex_t *preg, const char *regex, int cflags);

+

Compiles a regular expression.

+

#include <regex.h>

+

int regexec(const regex_t *preg, const char *string, size_t nmatch,regmatch_t pmatch[], int eflags);

+

Matches a regular expression.

+

#include <regex.h>

+

void regfree(regex_t *preg);

+

Releases a regular expression.

+

#include <string.h>

+

char *strerror(int errnum);

+

Returns an error description string of the specified error code.

+

math

+

#include <stdlib.h>

+

int abs(int i);

+

Returns the absolute value.

+

#include <math.h>

+

double log(double x);

+

Returns the natural logarithm (base-e logarithm) of x.

+

#include <math.h>

+

double pow(double x, double y);

+

Returns x raised to the power of y.

+

#include <math.h>

+

double round(double x);

+

Rounds off the value from zero to the nearest integer.

+

#include <math.h>

+

double sqrt(double x);

+

Returns the square root of x.

+

IO

+

#include <stdio.h>

+

void clearerr(FILE *stream);

+

Clears the file end and error indication of a stream.

+

#include <stdio.h>

+

int fclose(FILE *stream);

+

Closes a file stream.

+

#include <stdio.h>

+

FILE *fdopen(int fd, const char *mode);

+

Opens a file stream by using a file descriptor.

+

#include <stdio.h>

+

int feof(FILE *stream);

+

Tests the end-of-file indicator for the specified stream.

+

#include <stdio.h>

+

int fflush(FILE *stream);

+

Refreshes a stream.

+

#include <stdio.h>

+

char *fgets(char *s, int size, FILE *stream);

+

Reads the next line of the stream.

+

#include <stdio.h>

+

int fileno(FILE *stream);

+

Returns the file descriptor of a stream.

+

#include <stdio.h>

+

FILE *fopen(const char *path, const char *mode);

+

Open a stream.

+

#include <stdio.h>

+

int fputs(const char *s, FILE *stream);

+

Writes a line to a specified stream.

+

#include <stdio.h>

+

size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);

+

Reads a stream.

+

#include <stdio.h>

+

int fseek(FILE *stream, long offset, int whence);

+

Sets the position of a stream pointer.

+

#include <stdio.h>

+

long ftell(FILE *stream);

+

Obtains the position of a stream pointer.

+

#include <stdio.h>

+

size_t fwrite(const void *ptr, size_t size, size_t nmemb,FILE *stream);

+

Writes data to a stream.

+

#include <stdio.h>

+

void perror(const char *s);

+

Prints system error information.

+

#include <stdio.h>

+

void rewind(FILE *stream);

+

Re-positions a stream.

+

#include <unistd.h>

+

ssize_t write(int fd, const void *buf, size_t size);

+

Writes data to a file.

+

#include <unistd.h>

+

ssize_t read(int fd, void *buf, size_t size);

+

Reads data from a file.

+

net

+

#include <sys/socket.h>

+

void freeaddrinfo(struct addrinfo *res);

+

Releases the dynamic memory allocated by calling getaddrinfo.

+

#include <sys/socket.h>

+

int getaddrinfo(const char *restrict nodename,const char *restrict servname,const struct addrinfo *restrict hints,struct addrinfo **restrict res);

+

Performs network address translation.

+

#include <sys/socket.h>

+

int getnameinfo(const struct sockaddr *restrict sa, socklen_t salen,char *restrict node, socklen_t nodelen, char *restrict service,socklen_t servicelen, int flags);

+

Performs address-to-name translation in a protocol-independent manner.

+

#include <net/if.h>

+

unsigned int if_nametoindex(const char *ifname);

+

Obtains the index based on the network interface name.

+

#include <arpa/inet.h>

+

in_addr_t inet_addr(const char *cp);

+

Converts the network host address from dotted decimal notation to binary format.

+

#include <arpa/inet.h>

+

char *inet_ntoa(struct in_addr in);

+

Converts the network host address from binary format to dotted decimal notation.

+

#include <arpa/inet.h>

+

const char *inet_ntop(int af, const void *src,char *dst, socklen_t size);

+

Performs network address translation.

+

#include <arpa/inet.h>

+

int inet_pton(int af, const char *src, void *dst);

+

Performs network address translation.

+

#include <sys/socket.h>

+

int listen(int sockfd, int backlog);

+

Listens for sockets.

+

#include <sys/socket.h>

+

ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);

+

Receives a message from a socket. Note that the IOV size can be 1 only, and the ancillary message is not supported.

+

#include <sys/socket.h>

+

ssize_t send(int sockfd, const void *buf, size_t len, int flags);

+

Sends messages from a socket.

+

#include <sys/socket.h>

+

ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);

+

Sends messages from a socket. Ancillary messages are not supported.

+

#include <sys/socket.h>

+

ssize_t sendto(int sockfd, const void *buf, size_t len, int flags,const struct sockaddr *dest_addr, socklen_t addrlen);

+

Sends messages from a socket.

+

#include <sys/socket.h>

+

int setsockopt(int sockfd, int level, int optname,const void *optval, socklen_t optlen);

+

Sets the options associated with a socket.

+

mem

+

#include <string.h>

+

int memcmp(const void *s1, const void *s2, size_t n);

+

Compares memory areas.

+

#include <string.h>

+

void *memcpy(void *dest, const void *src, size_t n);

+

Copies memory content.

+

#include <string.h>

+

void *memset(void *s, int c, size_t n);

+

Initializes memory.

+

#include <stdlib.h>

+

void *realloc(void *ptr, size_t size);

+

Reallocates memory.

+

#include <stdlib.h>

+

void *malloc(size_t size);

+

Dynamically allocates memory blocks.

+

#include <stdlib.h>

+

void free(void *ptr);

+

Releases the memory space to which the PTR pointer points.

+

IPC

+

#include <semaphore.h>

+

int sem_timedwait(sem_t *sem, const struct timespec *abs_timeout);

+

Locks a semaphore for a specified period of time.

+

#include <semaphore.h>

+

int sem_destroy(sem_t *sem);

+

Destroys a specified anonymous semaphore.

+

#include <semaphore.h>

+

int sem_init(sem_t *sem, int pshared, unsigned int value);

+

Creates and initializes an anonymous semaphore.

+

#include <semaphore.h>

+

int sem_post(sem_t *sem);

+

Increments the semaphore count.

+

#include <semaphore.h>

+

int sem_wait(sem_t *sem);

+

Obtains the semaphore.

+

#include <mqueue.h>

+

mqd_t mq_open(const char *mqName, int openFlag, ...);

+

Opens an existing message queue with the specified name or creates a message queue.

+

#include <mqueue.h>

+

int mq_close(mqd_t personal);

+

Closes the message queue with the specified descriptor.

+

#include <mqueue.h>

+

int mq_unlink(const char *mqName);

+

Deletes a specified message queue.

+

#include <mqueue.h>

+

int mq_send(mqd_t personal, const char *msg, size_t msgLen, unsigned int msgPrio);

+

Puts a message with the specified content and length into a message queue with the specified descriptor.

+

#include <mqueue.h>

+

ssize_t mq_receive(mqd_t personal, char *msg, size_t msgLen, unsigned int *msgPrio);

+

Deletes the oldest message from the message queue with the specified descriptor and places it in the buffer pointed to by msg_ptr.

+

#include <mqueue.h>

+

int mq_timedsend(mqd_t personal, const char *msg, size_t msgLen, unsigned int msgPrio, const struct timespec *absTimeout)

+

Puts a message with the specified content and length into a message queue identified by the specified descriptor within specified time.

+

#include <mqueue.h>

+

ssize_t mq_timedreceive(mqd_t personal, char *msg, size_t msgLen, unsigned int *msgPrio, const struct timespec *absTimeout);

+

Obtains a message with the specified content and length from a message queue specified by the descriptor.

+

#include <mqueue.h>

+

int mq_setattr(mqd_t mqdes, const struct mq_attr *__restrict newattr, struct mq_attr *__restrict oldattr);

+

Sets the attributes of the message queue specified by the descriptor.

+

version

+

#include <libc.h>

+

const char *libc_get_version_string(void);

+

Obtains the libc version string.

+

#include <libc.h>

+

int libc_get_version(void);

+

Obtains the libc version.

+
+ +### Important Notes + +Error codes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

C Name

+

Value

+

Description

+

Description

+

ENOERR

+

0

+

Success

+

Successful

+

EPERM

+

1

+

Operation not permitted

+

The operation is not allowed.

+

ENOENT

+

2

+

No such file or directory

+

The file or directory does not exist.

+

ESRCH

+

3

+

No such process

+

There is no such process (not supported currently).

+

EINTR

+

4

+

Interrupted system call

+

The system call is interrupted.

+

EIO

+

5

+

I/O error

+

An I/O error occurs.

+

ENXIO

+

6

+

No such device or address

+

The device or address does not exist.

+

E2BIG

+

7

+

Arg list too long

+

The parameter list is too long.

+

ENOEXEC

+

8

+

Exec format error

+

The execution format is incorrect.

+

EBADF

+

9

+

Bad file number

+

The file descriptor is invalid.

+

ECHILD

+

10

+

No child processes

+

There is no child process (not supported currently).

+

EAGAIN

+

11

+

Try again

+

The resource is temporarily unavailable.

+

ENOMEM

+

12

+

Out of memory

+

The memory overflows.

+

EACCES

+

13

+

Permission denied

+

The permission is rejected.

+

EFAULT

+

14

+

Bad address

+

The address is incorrect.

+

ENOTBLK

+

15

+

Block device required

+

A block device is required.

+

EBUSY

+

16

+

Device or resource busy

+

The device or resource is engaged.

+

EEXIST

+

17

+

File exists

+

The file already exists.

+

EXDEV

+

18

+

Cross-device link

+

The cross-device link is invalid.

+

ENODEV

+

19

+

No such device

+

The device does not exist.

+

ENOTDIR

+

20

+

Not a directory

+

It is not a directory.

+

EISDIR

+

21

+

Is a directory

+

It is a directory.

+

EINVAL

+

22

+

Invalid argument

+

The parameter is invalid.

+

ENFILE*

+

23

+

File table overflow

+

The number of file systems opened exceeds the limit.

+

EMFILE

+

24

+

Too many open files

+

The number of files opened exceeds the limit.

+

EFBIG

+

27

+

File too large

+

The file is too large.

+

ENOSPC

+

28

+

No space left on device

+

There is no space on the device.

+

ESPIPE

+

29

+

Illegal seek

+

Illegal shift

+

EROFS

+

30

+

Read-only file system

+

The file system is read-only.

+

EMLINK

+

31

+

Too many links

+

There are too many links.

+

EDOM

+

33

+

Math argument out of domain

+

The value is out of range.

+

ERANGE

+

34

+

Math result not representable

+

The result is not representative.

+

EDEADLK

+

35

+

Resource deadlock would occur

+

Resource deadlock occurs.

+

ENAMETOOLONG

+

36

+

Filename too long

+

The file name is too long.

+

ENOLCK

+

37

+

No record locks available

+

There is no lock available.

+

ENOSYS

+

38

+

Function not implemented

+

The function is not implemented.

+

ENOTEMPTY

+

39

+

Directory not empty

+

The directory is not empty.

+

ELOOP

+

40

+

Too many symbolic links encountered

+

There are too many symbolic link layers.

+

ENOMSG

+

42

+

No message of desired type

+

There is no message of the expected type.

+

EIDRM

+

43

+

Identifier removed

+

The identifier is removed.

+

ELNRNG

+

48

+

Link number out of range

+

The number of links exceeds the limit.

+

EBADR

+

53

+

Invalid request descriptor

+

The requested descriptor is invalid.

+

EBADRQC

+

56

+

Invalid request code

+

The requested code is invalid.

+

ENOSTR

+

60

+

Device not a stream

+

The device is not a character stream.

+

ENODATA

+

61

+

No data available

+

No data is available.

+

ETIME

+

62

+

Timer expired

+

The timer has expired.

+

EPROTO

+

71

+

Protocol error

+

Protocol error.

+

EBADMSG

+

74

+

Not a data message

+

It is not a data message.

+

EOVERFLOW

+

75

+

Value too large for defined data type

+

The value is too large for the data type.

+

EMSGSIZE

+

90

+

Message too long

+

The message is too long.

+
+ +### Development Example + +Demo: + +Creates a thread, transfers the information in the parent thread to the child thread, and prints the transferred information and the thread ID in the child thread. + +``` +#include +#include + +pthread_t ntid; + +void *ThreadFn(void *arg) +{ + pthread_t tid; + while(1) { + tid = pthread_self(); + printf("\n++++++++++++++ %s %s tid = %d ++++++++++++++\n", (char*)arg, __FUNCTION__, tid); + } + return ((void *)0); +} + +void DemoForTest() +{ + int err; + char* str = "Hello world"; + err = pthread_create(&ntid, NULL, ThreadFn, (void*)str); + if(err != 0) { + printf("can't create thread\n"); + } +} + +``` + +The execution result of **DemoForTest** is as follows: + +``` +++++++++++++++ Hello world ThreadFn tid = 48 ++++++++++++++ + +++++++++++++++ Hello world ThreadFn tid = 48 ++++++++++++++ + +++++++++++++++ Hello world ThreadFn tid = 48 ++++++++++++++ +``` + diff --git a/en/device-dev/kernel/kernel-mini-appx-lib.md b/en/device-dev/kernel/kernel-mini-appx-lib.md new file mode 100644 index 0000000000000000000000000000000000000000..6c475ca705488930f46a6a80ae82ae05529a0323 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-appx-lib.md @@ -0,0 +1,7 @@ +# Standard Libraries + +- **[CMSIS Support](kernel-mini-appx-lib-cmsis.md)** + +- **[POSIX Support](kernel-mini-appx-lib-posix.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-interrupt-concept.md b/en/device-dev/kernel/kernel-mini-basic-interrupt-concept.md new file mode 100644 index 0000000000000000000000000000000000000000..658ff6c4be5115799eb21fbf26883baa480b53e1 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-interrupt-concept.md @@ -0,0 +1,37 @@ +# Basic Concepts + +An interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention. An interrupt alerts the processor to a high-priority condition requiring the interruption of the current code being executed by the processor. When a hardware interrupt is triggered, the interrupt handler is located based on the interrupt ID and then executed to handle the interrupt. + +By using the interrupt mechanism, the CPU responds to the interrupt request from a peripheral only when required, and execute other tasks when the peripherals do not require the CPU. In this way, the CPU does not need to spend a lot of time in waiting and querying the peripheral status, which effectively improves the real-time performance and execution efficiency of the system. + +The following describes the concepts related to interrupts: + +- Interrupt ID + + Identifies an interrupt request signal. The computer locates the device that sends the interrupt request based on the interrupt ID. + +- Interrupt request + + A process in which an electrical pulse signal is sent to the CPU, alerting the CPU to a high-priority event requiring the interruption of the current code being executed by the CPU. + +- Interrupt priority + + Prioritizes the sources that trigger interrupts based on the importance and urgency of interrupt events, so that the CPU can respond to and handle all interrupts in a timely manner. + +- Interrupt handler + + A program executed by the CPU to respond to the interrupt request from a peripheral. Each device that triggers an interrupt has its own interrupt handler. + +- Interrupt triggering + + The interrupt source sends an interrupt signal to the interrupt controller. The interrupt controller arbitrates all pending interrupts, determines the priority, and sends the interrupt signal to the CPU. When an interrupt source generates an interrupt signal, the interrupt trigger is set to **1**, alerting the CPU to respond to the interrupt. + +- Interrupt vector + + Entry address of an interrupt handler. + +- Interrupt vector table + + An area for storing interrupt vectors. It stores the mapping between interrupt vectors and interrupt IDs. + + diff --git a/en/device-dev/kernel/kernel-mini-basic-interrupt-guide.md b/en/device-dev/kernel/kernel-mini-basic-interrupt-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..b1b66d320fef87738c93177aeaa3f35b488dd17b --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-interrupt-guide.md @@ -0,0 +1,130 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section11841123033618) +- [Development Example](#section460018317164) + - [Verification](#section1048572415182) + + +When an interrupt request is generated by a peripheral, the CPU suspends the current task and responds to the interrupt request. You need to register the interrupt handler and specify the operation to be performed by the CPU. + +## Available APIs + +The following table describes APIs available for the OpenHarmony LiteOS-M interrupt module. For more details about the APIs, see the API reference. + +**Table 1** APIs of the interrupt module + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting interrupts

+

HalHwiCreate

+

Creates an interrupt and registers the interrupt ID, interrupt triggering mode, interrupt priority, and interrupt handler. When an interrupt is triggered, the interrupt handler will be called.

+

HalHwiDelete

+

Deletes an interrupt based on the specified interrupt ID.

+

Enabling or disabling interrupts

+

LOS_IntUnLock

+

Enables the CPU to respond to all interrupt requests.

+

LOS_IntLock

+

Disables the CPU from responding to interrupt requests.

+

LOS_IntRestore

+

Restores the interrupt status before the LOS_IntLock and LOS_IntUnLock operations are performed.

+
+ +## How to Develop + +1. Create an interrupt by calling **HalHwiCreate**. +2. Call **TestHwiTrigger** to trigger the specified interrupt. \(This API is defined in the test suite. It simulates an external interrupt by writing the related register of the interrupt controller. Skip this step for common peripheral devices.\) +3. Call **HalHwiDelete** to delete the specified interrupt. Use this API based on actual requirements. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- Configure the maximum number of interrupts supported and the number of configurable interrupt priorities based on the specific hardware. +>- If the interrupt handler takes long time, the CPU cannot respond to interrupt requests in a timely manner. +>- Functions that trigger **LOS\_Schedule** cannot be directly or indirectly executed during interrupt response process. +>- The input parameter of **LOS\_IntRestore\(\)** must be the return value of **LOS\_IntLock\(\)**, that is, the current program status register \(CPSR\) value before the interrupt is disabled. Interrupts 0 to 15 in the Cortex-M series processors are for internal use. You are advised not to apply for or create interrupts 0 to 15. + +## Development Example + +This example implements the following: + +1. Create an interrupt. +2. Trigger an interrupt. +3. Delete an interrupt. + +The following sample code shows how to create and delete an interrupt. When the interrupt **HWI\_NUM\_TEST** is generated, the interrupt handler function will be called. + +``` +#include "los_interrupt.h" + +/* Create an interrupt.*/ +#define HWI_NUM_TEST 7 + +STATIC VOID HwiUsrIrq(VOID) +{ + printf("in the func HwiUsrIrq \n"); +} + +static UINT32 Example_Interrupt(VOID) +{ + UINT32 ret; + HWI_PRIOR_T hwiPrio = 3; + HWI_MODE_T mode = 0; + HWI_ARG_T arg = 0; + + /* Create an interrupt. */ + ret = HalHwiCreate(HWI_NUM_TEST, hwiPrio, mode, (HWI_PROC_FUNC)HwiUsrIrq, arg); + if(ret == LOS_OK){ + printf("Hwi create success!\n"); + } else { + printf("Hwi create failed!\n"); + return LOS_NOK; + } + + /* Delay 50 ticks. When a hardware interrupt occurs, the HwiUsrIrq function will be called.*/ + LOS_TaskDelay(50); + + /* Delete an interrupt./ + ret = HalHwiDelete(HWI_NUM_TEST); + if(ret == LOS_OK){ + printf("Hwi delete success!\n"); + } else { + printf("Hwi delete failed!\n"); + return LOS_NOK; + } + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +Hwi create success! +Hwi delete success!. +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic-interrupt.md b/en/device-dev/kernel/kernel-mini-basic-interrupt.md new file mode 100644 index 0000000000000000000000000000000000000000..3f7c1ac22f23b082d84f0cdb3ccaa484909d20e3 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-interrupt.md @@ -0,0 +1,7 @@ +# Interrupt Management + +- **[Basic Concepts](kernel-mini-basic-interrupt-concept.md)** + +- **[Development Guidelines](kernel-mini-basic-interrupt-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-event-basic.md b/en/device-dev/kernel/kernel-mini-basic-ipc-event-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..3ac227417f069d380e96193b178d8ed33328e98e --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-event-basic.md @@ -0,0 +1,50 @@ +# Basic Concepts + +- [Working Principles](#section1735611583011) + - [Event Control Block](#section1161415384467) + - [Working Principles](#section187761153144617) + + +An event is a mechanism for communication between tasks. It can be used to synchronize tasks. The events have the following features: + +- Events can be synchronized in one-to-many or many-to-many mode. In one-to-many mode, a task can wait for multiple events. In many-to-many mode, multiple tasks can wait for multiple events. However, a write event wakes up only one task from the block. +- Event read timeout mechanism is used. +- Events are used only for task synchronization, but not for data transmission. + +APIs are provided to initialize, read/write, clear, and destroy events. + +## Working Principles + +### Event Control Block + +``` +/** +* Event control block data structure + */ +typedef struct tagEvent { + UINT32 uwEventID; /* Event set, which is a collection of events processed (written and cleared).*/ + LOS_DL_LIST stEventList; /* List of tasks waiting for specific events*/ +} EVENT_CB_S, *PEVENT_CB_S; +``` + +### Working Principles + +**Initializing an event**: An event control block is created to maintain a collection of processed events and a linked list of tasks waiting for specific events. + +**Writing an event**: When a specified event is written to the event control block, the event control block updates the event set, traverses the task linked list, and determines whether to wake up related task based on the task conditions. + +**Reading an event**: If the read event already exists, it is returned synchronously. In other cases, the return time is determined based on the timeout period and event triggering status. If the wait event condition is met before the timeout period expires, the blocked task will be directly woken up. Otherwise, the blocked task will be woken up only after the timeout period has expired. + +The input parameters **eventMask** and **mode** determine whether the condition for reading an event is met. **eventMask** indicates the mask of the event. **mode** indicates the handling mode, which can be any of the following: + +- **LOS\_WAITMODE\_AND**: Event reading is successful only when all the events corresponding to **eventMask** occur. Otherwise, the task will be blocked, or an error code will be returned. +- **LOS\_WAITMODE\_OR**: Event reading is successful when any of the events corresponding to **eventMask** occur. Otherwise, the task will be blocked, or an error code will be returned. +- **LOS\_WAITMODE\_CLR**: This mode must be used with **LOS\_WAITMODE\_AND** or **LOS\_WAITMODE\_OR** \(LOS\_WAITMODE\_AND | LOS\_WAITMODE\_CLR or LOS\_WAITMODE\_OR | LOS\_WAITMODE\_CLR\). In this mode, if **LOS\_WAITMODE\_AND** or **LOS\_WAITMODE\_OR** is successful, the corresponding event type bit in the event control block will be automatically cleared. + +**Clearing event**: Clear the event set of the event control block based on the specified mask. If the mask is **0**, the event set will be cleared. If the mask is **0xffff**, no event will be cleared, and the event set remains unchanged. + +**Destroying an event**: Destroy the specified event control block. + +**Figure 1** Event working mechanism +![](figure/event-working-mechanism.png "event-working-mechanism") + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-event-guide.md b/en/device-dev/kernel/kernel-mini-basic-ipc-event-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..6a6fe2e2cf8b10ca670d291180a38f7392a0e721 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-event-guide.md @@ -0,0 +1,194 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section783435801510) +- [Development Example](#section460018317164) + - [Example Description](#section896412438910) + - [Sample Code](#section149077554912) + - [Verification](#section4461439172017) + + +## Available APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Checking events

+

LOS_EventPoll

+

Checks whether the expected event occurs based on eventID, eventMask, and mode.

+
NOTICE:

If mode contains LOS_WAITMODE_CLR and the expected event occurs, the event that meets the requirements in eventID will be cleared. In this case, eventID is an input parameter and an output parameter. In other cases, eventID is used only as an input parameter.

+
+

Initializing events

+

LOS_EventInit

+

Initializes an event control block.

+

Reading events

+

LOS_EventRead

+

Reads an event (wait event). The task is blocked to wait based on the timeout period (in ticks).

+

If no event is read, 0 is returned.

+

If an event is successfully read, a positive value (event set) is returned.

+

In other cases, a specific error code is returned.

+

Writing events

+

LOS_EventWrite

+

Writes a specific event to the event control block.

+

Clearing events

+

LOS_EventClear

+

Clears an event in the event control block based on the event mask.

+

Destroying events

+

LOS_EventDestroy

+

Destroys an event control block.

+
+ +## How to Develop + +The typical event development process is as follows: + +1. Initialize an event control block. +2. Block a read event control block. +3. Write related events. +4. Wake up a blocked task, read the event, and check whether the event meets conditions. +5. Handle the event control block. +6. Destroy an event control block. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- When an event is read or written, the 25th bit of the event is reserved and cannot be set. +>- Repeated writes of the same event are treated as one write. + +## Development Example + +### Example Description + +In this example, run the **Example\_TaskEntry** task to create the **Example\_Event** task. Run the **Example\_Event** task to read an event to trigger task switching. Run the **Example\_TaskEntry** task to write an event. You can understand the task switching during event operations based on the sequence in which logs are recorded. + +1. Create the **Example\_Event** task in the **Example\_TaskEntry** task with a higher priority than the **Example\_TaskEntry** task. +2. Run the **Example\_Event** task to read event **0x00000001**. Task switching occurs to execute the **Example\_TaskEntry** task. +3. Run the **Example\_TaskEntry** task to write event **0x00000001**. Task switching occurs to execute the **Example\_Event** task. +4. The **Example\_Event** task is executed. +5. The **Example\_TaskEntry** task is executed. + +### Sample Code + +The sample code is as follows: + +``` +#include "los_event.h" +#include "los_task.h" +#include "securec.h" + +/* Task ID*/ +UINT32 g_testTaskId; + +/* Event control structure*/ +EVENT_CB_S g_exampleEvent; + +/* Type of the wait event*/ +#define EVENT_WAIT 0x00000001 + +/* Example task entry function*/ +VOID Example_Event(VOID) +{ + UINT32 ret; + UINT32 event; + + /* Set a timeout period for event reading to 100 ticks. If the specified event is not read within 100 ticks, the read operation times out and the task is woken up.*/ + printf("Example_Event wait event 0x%x \n", EVENT_WAIT); + + event = LOS_EventRead(&g_exampleEvent, EVENT_WAIT, LOS_WAITMODE_AND, 100); + if (event == EVENT_WAIT) { + printf("Example_Event,read event :0x%x\n", event); + } else { + printf("Example_Event,read event timeout\n"); + } +} + +UINT32 Example_TaskEntry(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S task1; + + /* Initialize the event.*/ + ret = LOS_EventInit(&g_exampleEvent); + if (ret != LOS_OK) { + printf("init event failed .\n"); + return -1; + } + + /* Create a task.*/ + (VOID)memset_s(&task1, sizeof(TSK_INIT_PARAM_S), 0, sizeof(TSK_INIT_PARAM_S)); + task1.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_Event; + task1.pcName = "EventTsk1"; + task1.uwStackSize = OS_TSK_DEFAULT_STACK_SIZE; + task1.usTaskPrio = 5; + ret = LOS_TaskCreate(&g_testTaskId, &task1); + if (ret != LOS_OK) { + printf("task create failed.\n"); + return LOS_NOK; + } + + /* Write the task wait event (g_testTaskId). */ + printf("Example_TaskEntry write event.\n"); + + ret = LOS_EventWrite(&g_exampleEvent, EVENT_WAIT); + if (ret != LOS_OK) { + printf("event write failed.\n"); + return LOS_NOK; + } + + /* Clear the flag.*/ + printf("EventMask:%d\n", g_exampleEvent.uwEventID); + LOS_EventClear(&g_exampleEvent, ~g_exampleEvent.uwEventID); + printf("EventMask:%d\n", g_exampleEvent.uwEventID); + + /* Delete the task.*/ + ret = LOS_TaskDelete(g_testTaskId); + if (ret != LOS_OK) { + printf("task delete failed.\n"); + return LOS_NOK; + } + + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +Example_Event wait event 0x1 +Example_TaskEntry write event. +Example_Event,read event :0x1 +EventMask:1 +EventMask:0 +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-event.md b/en/device-dev/kernel/kernel-mini-basic-ipc-event.md new file mode 100644 index 0000000000000000000000000000000000000000..1693a5bc36dbac72b9d37ae62aba6756a428e8d6 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-event.md @@ -0,0 +1,7 @@ +# Event + +- **[Basic Concepts](kernel-mini-basic-ipc-event-basic.md)** + +- **[Development Guidelines](kernel-mini-basic-ipc-event-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-mutex-basic.md b/en/device-dev/kernel/kernel-mini-basic-ipc-mutex-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..827323f9101f1eef40a20883adc561238a8e53b7 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-mutex-basic.md @@ -0,0 +1,19 @@ +# Basic Concepts + +- [Working Principles](#section115161649726) + +A mutual exclusion \(mutex\) is a special binary semaphore used for exclusive access to shared resources. + +A mutex can be unlocked or locked. When a mutex is held by a task, the mutex is locked and the task obtains the ownership of the mutex. When the task releases the mutex, the mutex is unlocked and the task will lose the ownership of the mutex. When a task holds a mutex, other tasks cannot unlock or hold the mutex. + +In an environment where multiple tasks compete for shared resources, the mutex can protect the shared resources via exclusive access. In addition, the mutex can prevent semaphore priority inversion, which occurs when a low-priority task holds a semaphore but a high-priority task has to wait until the low-priority task releases it. + +## Working Principles + +In a multi-task environment, multiple tasks may access the same shared resources. However, certain shared resources are not shared, and can only be accessed exclusively by tasks. A mutex can be used to address this issue. + +When non-shared resources are accessed by a task, the mutex is locked. Other tasks will be blocked until the mutex is released by the task. The mutex allows only one task to access the shared resources at a time, ensuring integrity of operations on the shared resources. + +**Figure 1** Mutex working mechanism +![](figure/mutex-working-mechanism.png "mutex-working-mechanism") + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-mutex-guide.md b/en/device-dev/kernel/kernel-mini-basic-ipc-mutex-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..664e6e9214b7012d87442a1f417b1e60ce4764d7 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-mutex-guide.md @@ -0,0 +1,205 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section783435801510) +- [Development Example](#section1426719434114) + - [Example Description](#section896412438910) + - [Sample Code](#section149077554912) + - [Verification](#section2059413981311) + + +## Available APIs + +**Table 1** APIs of the mutex module + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting a mutex

+

LOS_MuxCreate

+

Creates a mutex.

+

LOS_MuxDelete

+

Deletes the specified mutex.

+

Requesting or releasing a mutex

+

LOS_MuxPend

+

Requests the specified mutex.

+

LOS_MuxPost

+

Releases the specified mutex.

+
+ +## How to Develop + +The typical mutex development process is as follows: + +1. Call **LOS\_MuxCreate** to create a mutex. +2. Call **LOS\_MuxPend** to request a mutex. + + The following modes are available: + + - Non-block mode: A task acquires the mutex if the requested mutex is not held by any task or the task holding the mutex is the same as the task requesting the mutex. + - Permanent block mode: A task acquires the mutex if the requested mutex is not occupied. If the mutex is occupied, the task will be blocked and the task with the highest priority in the ready queue will be executed. The blocked task can be unlocked and executed only when the mutex is released. + - Scheduled block mode: A task acquires the mutex if the requested mutex is not occupied. If the mutex is occupied, the task will be blocked and the task with the highest priority in the ready queue will be executed. The blocked task can be executed only when the mutex is released within the specified timeout period or when the specified timeout period expires. + +3. Call **LOS\_MuxPost** to release a mutex. + - If tasks are blocked by the specified mutex, the task with a higher priority will be unblocked when the mutex is released. The unblocked task changes to the Ready state and is scheduled. + - If no task is blocked by the specified mutex, the mutex is released successfully. + +4. Call **LOS\_MuxDelete** to delete a mutex. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- Two tasks cannot lock the same mutex. If a task attempts to lock a mutex held by another task, the task will be blocked until the mutex is unclocked. +>- Mutexes cannot be used in the interrupt service program. +>- When using the LiteOS-M kernel, OpenHarmony must ensure real-time task scheduling and avoid long-time task blocking. Therefore, a mutex must be released as soon as possible after use. +>- When a mutex is held by a task, the task priority cannot be changed by using APIs such as **LOS\_TaskPriSet**. + +## Development Example + +### Example Description + +This example implements the following: + +1. Create the **Example\_TaskEntry** task. In this task, create a mutex, lock task scheduling, create two tasks **Example\_MutexTask1** \(with a lower priority\) and **Example\_MutexTask2** \(with a higher priority\), and unlock task scheduling. +2. When being scheduled, **Example\_MutexTask2** requests a mutex in permanent block mode. After acquiring the mutex, **Example\_MutexTask2** enters the sleep mode for 100 ticks. **Example\_MutexTask2** is suspended, and **Example\_MutexTask1** is woken up. +3. **Example\_MutexTask1** requests a mutex in scheduled block mode, and waits for 10 ticks. Because the mutex is still held by **Example\_MutexTask2**, **Example\_MutexTask1** is suspended. After 10 ticks, **Example\_MutexTask1** is woken up and attempts to request a mutex in permanent block mode. **Example\_MutexTask1** is suspended because the mutex is still held by **Example\_MutexTask2**. +4. After 100 ticks, **Example\_MutexTask2** is woken up and releases the mutex, and then **Example\_MutexTask1** is woken up. **Example\_MutexTask1** acquires the mutex and then releases the mutex. At last, the mutex is deleted. + +### Sample Code + +The sample code is as follows: + +``` +#include +#include "los_mux.h" + +/* Mutex handler ID*/ +UINT32 g_testMux; +/* Task ID*/ +UINT32 g_testTaskId01; +UINT32 g_testTaskId02; + +VOID Example_MutexTask1(VOID) +{ + UINT32 ret; + + printf("task1 try to get mutex, wait 10 ticks.\n"); + /* Request a mutex.*/ + ret = LOS_MuxPend(g_testMux, 10); + + if (ret == LOS_OK) { + printf("task1 get mutex g_testMux.\n"); + /*Release the mutex.*/ + LOS_MuxPost(g_testMux); + return; + } + if (ret == LOS_ERRNO_MUX_TIMEOUT ) { + printf("task1 timeout and try to get mutex, wait forever.\n"); + /* Request a mutex.*/ + ret = LOS_MuxPend(g_testMux, LOS_WAIT_FOREVER); + if (ret == LOS_OK) { + printf("task1 wait forever, get mutex g_testMux.\n"); + /*Release the mutex.*/ + LOS_MuxPost(g_testMux); + /* Delete the mutex. */ + LOS_MuxDelete(g_testMux); + printf("task1 post and delete mutex g_testMux.\n"); + return; + } + } + return; +} + +VOID Example_MutexTask2(VOID) +{ + printf("task2 try to get mutex, wait forever.\n"); + /* Request a mutex.*/ + (VOID)LOS_MuxPend(g_testMux, LOS_WAIT_FOREVER); + + printf("task2 get mutex g_testMux and suspend 100 ticks.\n"); + + /* Enable the task to enter sleep mode for 100 ticks.*/ + LOS_TaskDelay(100); + + printf("task2 resumed and post the g_testMux\n"); + /* Release the mutex.*/ + LOS_MuxPost(g_testMux); + return; +} + +UINT32 Example_TaskEntry(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S task1; + TSK_INIT_PARAM_S task2; + + /* Create a mutex.*/ + LOS_MuxCreate(&g_testMux); + + /* Lock task scheduling.*/ + LOS_TaskLock(); + + /* Create task 1.*/ + memset(&task1, 0, sizeof(TSK_INIT_PARAM_S)); + task1.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_MutexTask1; + task1.pcName = "MutexTsk1"; + task1.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task1.usTaskPrio = 5; + ret = LOS_TaskCreate(&g_testTaskId01, &task1); + if (ret != LOS_OK) { + printf("task1 create failed.\n"); + return LOS_NOK; + } + + /* Create task 2.*/ + memset(&task2, 0, sizeof(TSK_INIT_PARAM_S)); + task2.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_MutexTask2; + task2.pcName = "MutexTsk2"; + task2.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task2.usTaskPrio = 4; + ret = LOS_TaskCreate(&g_testTaskId02, &task2); + if (ret != LOS_OK) { + printf("task2 create failed.\n"); + return LOS_NOK; + } + + /* Unlock task scheduling.*/ + LOS_TaskUnlock(); + + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +task2 try to get mutex, wait forever. +task2 get mutex g_testMux and suspend 100 ticks. +task1 try to get mutex, wait 10 ticks. +task1 timeout and try to get mutex, wait forever. +task2 resumed and post the g_testMux +task1 wait forever, get mutex g_testMux. +task1 post and delete mutex g_testMux. +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-mutex.md b/en/device-dev/kernel/kernel-mini-basic-ipc-mutex.md new file mode 100644 index 0000000000000000000000000000000000000000..15585c6ed432edbf4e141f8b810f0eba7970cb7a --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-mutex.md @@ -0,0 +1,7 @@ +# Mutex + +- **[Basic Concepts](kernel-mini-basic-ipc-mutex-basic.md)** + +- **[Development Guidelines](kernel-mini-basic-ipc-mutex-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-queue-basic.md b/en/device-dev/kernel/kernel-mini-basic-ipc-queue-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..509a08916b0d0ccf382d47bb104d344811322815 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-queue-basic.md @@ -0,0 +1,67 @@ +# Basic Concepts + +- [Working Principles](#section1582619446311) + - [Queue Control Block](#section1648304614720) + - [Working Principles](#section15384012164811) + + +A queue, also called a message queue, is a data structure used for communication between tasks. The queue receives messages of unfixed length from tasks or interrupts, and determines whether to store the transferred messages in the queue based on different APIs. + +Tasks can read messages from a queue. When the queue has no messages, the tasks are suspended. When the queue has a new message, the suspended tasks are woken up and process the new message. Tasks can also write messages to the queue. When the queue is full, the write task is suspended. When there is an available message node in the queue, the suspended write task is woken up and writes a message. + +You can adjust the timeout period of the read queue and write queue to adjust the block mode of the read and write APIs. If the timeout period is set to **0** for the read queue and write queue, tasks will not be suspended and the API directly returns. This is the non-block mode. If the timeout period is greater than **0**, block mode is used. + +An asynchronous processing mechanism is provided to allows messages in a queue not to be processed immediately. In addition, queues can be used to buffer messages and implement asynchronous task communication. Queues have the following features: + +- Messages are queued in first-in-first-out \(FIFO\) mode and can be read and written asynchronously. +- Both the read queue and write queue support the timeout mechanism. +- Each time a message is read, the message node becomes available. +- The types of messages to be sent are determined by the parties involved in communication. Messages of different lengths \(not exceeding the message node size of the queue\) are allowed. +- A task can receive messages from and send messages to any message queue. +- Multiple tasks can receive messages from and send messages to the same queue. +- When a queue is created, the required dynamic memory space is automatically allocated in the queue API. + +## Working Principles + +### Queue Control Block + +``` +/** + * Data structure of the queue control block + */ +typedef struct +{ + UINT8 *queue; /* Pointer to the memory space of queue messages */ + UINT16 queueState; /* Queue status*/ + UINT16 queueLen; /* Number of message nodes in a queue, that is, the queue length */ + UINT16 queueSize; /* Size of a message node */ + UINT16 queueID; /*Queue ID */ + UINT16 queueHead; /* Position of the message head node (array subscript)*/ + UINT16 queueTail; /* Position of the message tail node (array subscript) */ + UINT16 readWriteableCnt[OS_READWRITE_LEN];/* The array element with subscript 0 indicates the number of readable messages in a queue. + The element with subscript 1 indicates the number of writable messages in a queue. */ + LOS_DL_LIST readWriteList[OS_READWRITE_LEN]; /* A linked list of tasks waiting to read or write messages. + Subscript 0: list of tasks waiting to read messages. Subscript 1: list of tasks waiting to write messages.*/ + LOS_DL_LIST memList; /* A linked list of memory blocks*/ +} LosQueueCB; +``` + +Each queue control block contains information about the queue status. + +- **OS\_QUEUE\_UNUSED**: The queue is not in use. +- **OS\_QUEUE\_INUSED**: The queue is in use. + +### Working Principles + +- The queue ID is returned if a queue is created successfully. +- The queue control block contains **Head** and **Tail**, which indicate the storage status of messages in a queue. **Head** indicates the start position of occupied message nodes in the queue. **Tail** indicates the end position of the occupied message nodes and the start position of idle message nodes. When a queue is created, **Head** and **Tail** point to the start position of the queue. +- When data is to be written to a queue, **readWriteableCnt\[1\]** is used to determine whether data can be written to the queue. If **readWriteableCnt\[1\]** is **0**, the queue is full and data cannot be written to it. Data can be written to the head node or tail node of a queue. To write data to the tail node, locate the start idle message node based on **Tail** and write data to it. If **Tail** is pointing to the tail of the queue, the rewind mode is used. To write data to the head node, locate previous node based on **Head** and write data to it. If **Head** is pointing to the start position of the queue, the rewind mode is used. +- When a queue is to be read, **readWriteableCnt\[0\]** is used to determine whether the queue has messages to read. Reading an idle queue \(**readWriteableCnt\[0\]** is** 0**\) will cause task suspension. If the queue has messages to read, the system locates the first node to which data is written based on **Head** and read the message from the node. If **Head** is pointing to the tail of the queue, the rewind mode is used. +- When a queue is to be deleted, the system locates the queue based on the queue ID, sets the queue status to **OS\_QUEUE\_UNUSED**, sets the queue control block to the initial state, and releases the memory occupied by the queue. + +Figure 1 Reading and writing data in a queue + +![](figure/en-us_image_0000001132935054.png) + +The preceding figure illustrates how to write data to the tail node only. Writing data to the head node is similar. + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-queue-guide.md b/en/device-dev/kernel/kernel-mini-basic-ipc-queue-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..8a40c65f3f3e938f5c3ec2ed92ab830eaada5b69 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-queue-guide.md @@ -0,0 +1,199 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section783435801510) +- [Development Example](#section460018317164) + - [Example Description](#section2148236125814) + - [Sample Code](#section121451047155716) + - [Verification](#section2742182082117) + + +## Available APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting a message queue

+

LOS_QueueCreate

+

Creates a message queue. The system dynamically allocates the queue space.

+

LOS_QueueDelete

+

Deletes the specified queue based on the queue ID.

+

Reading or writing data in a queue (without the content contained in the address)

+

LOS_QueueRead

+

Reads data in the head node of the specified queue. The data in the queue node is an address.

+

LOS_QueueWrite

+

Writes the value of the input parameter bufferAddr (buffer address) to the tail node of the specified queue.

+

LOS_QueueWriteHead

+

Writes the value of the input parameter bufferAddr (buffer address) to the head node of the specified queue.

+

Reading or writing in a queue (with the content contained in the address)

+

LOS_QueueReadCopy

+

Reads data from the head node of the specified queue.

+

LOS_QueueWriteCopy

+

Writes the data saved in the input parameter bufferAddr to the tail node of the specified queue.

+

LOS_QueueWriteHeadCopy

+

Writes the data saved in the input parameter bufferAddr to the head node of the specified queue.

+

Obtaining queue information

+

LOS_QueueInfoGet

+

Obtains information about the specified queue, including the queue ID, queue length, message node size, head node, tail node, number of readable nodes, number of writable nodes, tasks waiting for read operations, and tasks waiting for write operations.

+
+ +## How to Develop + +1. Call **LOS\_QueueCreate** to create a queue. The queue ID is returned when the queue is created. +2. Call **LOS\_QueueWrite** or **LOS\_QueueWriteCopy** to write messages to the queue. +3. Call **LOS\_QueueRead** or **LOS\_QueueReadCopy** to read messages from the queue. +4. Call **LOS\_QueueInfoGet** to obtain queue information. +5. Call **LOS\_QueueDelete** to delete the queue. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The maximum number of queues supported by the system is the total number of queue resources of the system, not the number of queue resources available to users. For example, if the system software timer occupies one more queue resource, the number of queue resources available to users decreases by one. +>- The input parameters queue name and flags passed when a queue is created are reserved for future use. +>- The input parameter **timeOut** in the queue interface function is relative time. +>- **LOS\_QueueReadCopy**, **LOS\_QueueWriteCopy**, and **LOS\_QueueWriteHeadCopy** are a group of APIs that must be used together. **LOS\_QueueRead**, **LOS\_QueueWrite**, and **LOS\_QueueWriteHead** are a group of APIs that must be used together. +>- As **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are used to manage data addresses, you must ensure that the memory directed by the pointer obtained by calling **LOS\_QueueRead** is not modified or released abnormally when the queue is being read. Otherwise, unpredictable results may occur. +>- **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are called to manage data addresses, which means that the actual data read or written is pointer data. Therefore, before using these APIs, ensure that the message node size is the pointer length during queue creation, to avoid waste and read failures. + +## Development Example + +### Example Description + +Create a queue and two tasks. Enable task 1 to call the queue write API to send messages, and enable task 2 to receive messages by calling the queue read API. + +1. Create task 1 and task 2 by calling **LOS\_TaskCreate**. +2. Create a message queue by calling **LOS\_QueueCreate**. +3. Enable messages to be sent in task 1 by calling **SendEntry**. +4. Enable messages to be received in task 2 by calling **RecvEntry**. +5. Delete the queue by calling **LOS\_QueueDelete**. + +### Sample Code + +The sample code is as follows: + +``` +#include "los_task.h" +#include "los_queue.h" +static UINT32 g_queue; +#define BUFFER_LEN 50 + +VOID SendEntry(VOID) +{ + UINT32 ret = 0; + CHAR abuf[] = "test message"; + UINT32 len = sizeof(abuf); + + ret = LOS_QueueWriteCopy(g_queue, abuf, len, 0); + if(ret != LOS_OK) { + printf("send message failure, error: %x\n", ret); + } +} + +VOID RecvEntry(VOID) +{ + UINT32 ret = 0; + CHAR readBuf[BUFFER_LEN] = {0}; + UINT32 readLen = BUFFER_LEN; + + // Sleep for 1s. + usleep(1000000); + ret = LOS_QueueReadCopy(g_queue, readBuf, &readLen, 0); + if(ret != LOS_OK) { + printf("recv message failure, error: %x\n", ret); + } + + printf("recv message: %s\n", readBuf); + + ret = LOS_QueueDelete(g_queue); + if(ret != LOS_OK) { + printf("delete the queue failure, error: %x\n", ret); + } + + printf("delete the queue success!\n"); +} + +UINT32 ExampleQueue(VOID) +{ + printf("start queue example\n"); + UINT32 ret = 0; + UINT32 task1, task2; + TSK_INIT_PARAM_S initParam = {0}; + + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)SendEntry; + initParam.usTaskPrio = 9; + initParam.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + initParam.pcName = "SendQueue"; + + LOS_TaskLock(); + ret = LOS_TaskCreate(&task1, &initParam); + if(ret != LOS_OK) { + printf("create task1 failed, error: %x\n", ret); + return ret; + } + + initParam.pcName = "RecvQueue"; + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)RecvEntry; + ret = LOS_TaskCreate(&task2, &initParam); + if(ret != LOS_OK) { + printf("create task2 failed, error: %x\n", ret); + return ret; + } + + ret = LOS_QueueCreate("queue", 5, &g_queue, 0, 50); + if(ret != LOS_OK) { + printf("create queue failure, error: %x\n", ret); + } + + printf("create the queue success!\n"); + LOS_TaskUnlock(); + return ret; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +start test example +create the queue success! +recv message: test message +delete the queue success! +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-queue.md b/en/device-dev/kernel/kernel-mini-basic-ipc-queue.md new file mode 100644 index 0000000000000000000000000000000000000000..221b182a2b62106db46277f134a7fc8fb5fef314 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-queue.md @@ -0,0 +1,7 @@ +# Queue + +- **[Basic Concepts](kernel-mini-basic-ipc-queue-basic.md)** + +- **[Development Guidelines](kernel-mini-basic-ipc-queue-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-sem-basic.md b/en/device-dev/kernel/kernel-mini-basic-ipc-sem-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..3c3d3a19ac5c62552e8fee72021f784e1d8b0d53 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-sem-basic.md @@ -0,0 +1,53 @@ +# Basic Concepts + +- [Working Principles](#section1794010261861) + - [Semaphore control block](#section11372149164815) + - [Working Principles](#section139726510491) + + +Semaphore is a mechanism for implementing inter-task communication. It implements synchronization between tasks or exclusive access to shared resources. + +In the data structure of a semaphore, there is a value indicating the number of shared resources available. The value can be: + +- **0**: The semaphore is unavailable. Tasks waiting for the semaphore may exist. +- Positive number: The semaphore is available. + +The semaphore for synchronization is different from the semaphore for mutex: + +- Semaphore used for exclusive access: The initial semaphore counter value is not 0, indicating the number of shared resources available. The semaphore counter value must be acquired before a shared resource is used, and released after the resource is used. When all shared resources are used, the semaphore counter is reduced to 0 and the tasks that need to obtain the semaphores will be blocked. This ensures exclusive access to shared resources. In addition, when the number of shared resources is 1, a binary semaphore \(similar to the mutex mechanism\) is recommended. +- Semaphore used for synchronization: The initial semaphore counter value is 0. Task 1 cannot acquire the semaphore and is blocked. Task 1 enters Ready or Running state only when the semaphore is released by task 2. In this way, task synchronization is implemented. + +## Working Principles + +### Semaphore control block + +``` +/** + * Data structure of the semaphore control block + */ +typedef struct { + UINT16 semStat; /* Semaphore status */ + UINT16 semType; /* Semaphore type*/ + UINT16 semCount; /* Semaphore count*/ + UINT16 semId; /* Semaphore index*/ + LOS_DL_LIST semList; /* Mount the task blocked by the semaphore.*/ +} LosSemCB; +``` + +### Working Principles + +Semaphore initialization: The system allocates memory for the semaphores configured \(you can configure the number of semaphores using the **LOSCFG\_BASE\_IPC\_SEM\_LIMIT** macro\), initializes all semaphores to be unused semaphores, and adds them to a linked list for the system to use. + +Semaphore creation: The system obtains a semaphore from the linked list of unused semaphores and assigns an initial value to the semaphore. + +Semaphore request: If the counter value is greater than 0, the system allocates a semaphore, decreases the value by 1, and returns a success message. Otherwise, the system blocks the task and adds the task to the end of a task queue waiting for semaphores. The wait timeout period can be set. + +Semaphore release: When a semaphore is released, if there is no task waiting for it, the counter is increased by 1. Otherwise, the first task in the wait queue is woken up. + +Semaphore deletion: The system sets a semaphore in use to unused state and inserts it to the linked list of unused semaphores. + +Semaphore allows only a specified number of tasks to access a shared resource at a time. When the number of tasks accessing the resource reaches the limit, other tasks will be blocked until the semaphore is released. + +**Figure 1** Semaphore working mechanism +![](figure/semaphore-working-mechanism.png "semaphore-working-mechanism") + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-sem-guide.md b/en/device-dev/kernel/kernel-mini-basic-ipc-sem-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..a9c14c93dd84828a8f3915972bb0f8fcbc058898 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-sem-guide.md @@ -0,0 +1,206 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section783435801510) +- [Development Example](#section460018317164) + - [Example Description](#section22061718111412) + - [Sample Code](#section1775922321416) + - [Verification](#section160404016213) + + +## Available APIs + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting a semaphore

+

LOS_SemCreate

+

Creates a semaphore and returns the semaphore ID.

+

LOS_BinarySemCreate

+

Creates a binary semaphore. The maximum counter value is 1.

+

LOS_SemDelete

+

Deletes a semaphore.

+

Requesting or releasing a semaphore

+

LOS_SemPend

+

Requests a specified semaphore and sets the timeout period.

+

LOS_SemPost

+

Posts (releases) a semaphore.

+
+ +## How to Develop + +1. Call **LOS\_SemCreate** to create a semaphore. To create a binary semaphore, call **LOS\_BinarySemCreate**. +2. Call **LOS\_SemPend** to request a semaphore. +3. Call **LOS\_SemPost** to release a semaphore. +4. Call **LOS\_SemDelete** to delete a semaphore. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>As interrupts cannot be blocked, semaphores cannot be requested in block mode for interrupts. + +## Development Example + +### Example Description + +This example implements the following: + +1. Create a semaphore in task **ExampleSem** and lock task scheduling. Create two tasks **ExampleSemTask1** and **ExampleSemTask2** \(with higher priority\). Enable the two tasks to request the same semaphore. Unlock task scheduling. Enable task **ExampleSem** to enter sleep mode for 400 ticks. Release the semaphore in task **ExampleSem**. +2. Enable** ExampleSemTask2** to enter sleep mode for 20 ticks after acquiring the semaphore. \(When **ExampleSemTask2** is delayed, **ExampleSemTask1** is woken up.\) +3. Enable **ExampleSemTask1** to request the semaphore in scheduled block mode, with a wait timeout period of 10 ticks. \(Because the semaphore is still held by **ExampleSemTask2**, **ExampleSemTask1** is suspended. **ExampleSemTask1** is woken up after 10 ticks.\) Enable **ExampleSemTask1** to request the semaphore in permanent block mode after it is woken up 10 ticks later. \(Because the semaphore is still held by **ExampleSemTask2**, **ExampleSemTask1** is suspended.\)** ** +4. After 20 ticks, **ExampleSemTask2** is woken up and releases the semaphore. **ExampleSemTask1** acquires the semaphore and is scheduled to run. When **ExampleSemTask1** is complete, it releases the semaphore. +5. Task **ExampleSem** is woken up after 400 ticks and deletes the semaphore. + +### Sample Code + +The sample code is as follows: + +``` +#include "los_sem.h" +#include "securec.h" + +/* Task ID*/ +static UINT32 g_testTaskId01; +static UINT32 g_testTaskId02; + +/* Task priority */ +#define TASK_PRIO_TEST 5 + +/* Semaphore structure ID*/ +static UINT32 g_semId; + +VOID ExampleSemTask1(VOID) +{ + UINT32 ret; + + printf("ExampleSemTask1 try get sem g_semId, timeout 10 ticks.\n"); + + /* Request the semaphore in scheduled block mode, with a wait timeout period of 10 ticks.*/ + ret = LOS_SemPend(g_semId, 10); + + /* The semaphore is acquired.*/ + if (ret == LOS_OK) { + LOS_SemPost(g_semId); + return; + } + /* The semaphore is not acquired when the timeout period has expired.*/ + if (ret == LOS_ERRNO_SEM_TIMEOUT) { + printf("ExampleSemTask1 timeout and try get sem g_semId wait forever.\n"); + + /* Request the semaphore in permanent block mode.*/ + ret = LOS_SemPend(g_semId, LOS_WAIT_FOREVER); + printf("ExampleSemTask1 wait_forever and get sem g_semId.\n"); + if (ret == LOS_OK) { + LOS_SemPost(g_semId); + return; + } + } +} + +VOID ExampleSemTask2(VOID) +{ + UINT32 ret; + printf("ExampleSemTask2 try get sem g_semId wait forever.\n"); + + /* Request the semaphore in permanent block mode.*/ + ret = LOS_SemPend(g_semId, LOS_WAIT_FOREVER); + + if (ret == LOS_OK) { + printf("ExampleSemTask2 get sem g_semId and then delay 20 ticks.\n"); + } + + /* Enable the task to enter sleep mode for 20 ticks.*/ + LOS_TaskDelay(20); + + printf("ExampleSemTask2 post sem g_semId.\n"); + /* Release the semaphore.*/ + LOS_SemPost(g_semId); + return; +} + +UINT32 ExampleSem(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S task1; + TSK_INIT_PARAM_S task2; + + /* Create a semaphore.*/ + LOS_SemCreate(0, &g_semId); + + /* Lock task scheduling.*/ + LOS_TaskLock(); + + /* Create task 1.*/ + (VOID)memset_s(&task1, sizeof(TSK_INIT_PARAM_S), 0, sizeof(TSK_INIT_PARAM_S)); + task1.pfnTaskEntry = (TSK_ENTRY_FUNC)ExampleSemTask1; + task1.pcName = "TestTask1"; + task1.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task1.usTaskPrio = TASK_PRIO_TEST; + ret = LOS_TaskCreate(&g_testTaskId01, &task1); + if (ret != LOS_OK) { + printf("task1 create failed.\n"); + return LOS_NOK; + } + + /* Create task 2.*/ + (VOID)memset_s(&task2, sizeof(TSK_INIT_PARAM_S), 0, sizeof(TSK_INIT_PARAM_S)); + task2.pfnTaskEntry = (TSK_ENTRY_FUNC)ExampleSemTask2; + task2.pcName = "TestTask2"; + task2.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task2.usTaskPrio = (TASK_PRIO_TEST - 1); + ret = LOS_TaskCreate(&g_testTaskId02, &task2); + if (ret != LOS_OK) { + printf("task2 create failed.\n"); + return LOS_NOK; + } + + /* Unlock task scheduling.*/ + LOS_TaskUnlock(); + + ret = LOS_SemPost(g_semId); + + /* Enable the task to enter sleep mode for 400 ticks.*/ + LOS_TaskDelay(400); + + /* Delete the semaphore. */ + LOS_SemDelete(g_semId); + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +ExampleSemTask2 try get sem g_semId wait forever. +ExampleSemTask2 get sem g_semId and then delay 20 ticks. +ExampleSemTask1 try get sem g_semId, timeout 10 ticks. + +ExampleSemTask1 timeout and try get sem g_semId wait forever. +ExampleSemTask2 post sem g_semId. +ExampleSemTask1 wait_forever and get sem g_semId. +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc-sem.md b/en/device-dev/kernel/kernel-mini-basic-ipc-sem.md new file mode 100644 index 0000000000000000000000000000000000000000..602aedfb3c9d13912f007047ce421bb3276dcac0 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc-sem.md @@ -0,0 +1,7 @@ +# Semaphore + +- **[Basic Concepts](kernel-mini-basic-ipc-sem-basic.md)** + +- **[Development Guidelines](kernel-mini-basic-ipc-sem-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-ipc.md b/en/device-dev/kernel/kernel-mini-basic-ipc.md new file mode 100644 index 0000000000000000000000000000000000000000..f18d6b58f05842f0bb145cf43a0c8c888e3ca119 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-ipc.md @@ -0,0 +1,11 @@ +# Kernel Communication Mechanisms + +- **[Event](kernel-mini-basic-ipc-event.md)** + +- **[Mutex](kernel-mini-basic-ipc-mutex.md)** + +- **[Queue](kernel-mini-basic-ipc-queue.md)** + +- **[Semaphore](kernel-mini-basic-ipc-sem.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-memory-basic.md b/en/device-dev/kernel/kernel-mini-basic-memory-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..2e48ff75659f96f4e4c7bdd88d82e5baabd2faf1 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-memory-basic.md @@ -0,0 +1,17 @@ +# Basic Concepts + +Memory management, one of the core modules of the OS, manages the memory resources of the system. Memory management primarily involves initializing, allocating, and releasing memory. + +While the OS is running, the memory management module manages the memory usage of users and the OS by allocating and releasing memory. This helps achieve the optimal memory usage and usage efficiency and minimize memory fragments. + +The OpenHarmony LiteOS-M kernel memory management involves static and dynamic memory management, and provides functions such as memory initialization, allocation, and release. + +- Dynamic memory: memory blocks of user-specified size allocated in the dynamic memory pool. + - Advantage: Resources are allocated on demand. + - Disadvantage: Fragments may occur in the memory pool. + +- Static memory: memory blocks of the fixed size \(preset during initialization\) allocated in the static memory pool. + - Advantage: Memory is allocated and released efficiently, and there is no fragment in the static memory pool. + - Disadvantage: Only the memory blocks of the fixed size can be allocated. Memory cannot be allocated on demand. + + diff --git a/en/device-dev/kernel/kernel-mini-basic-memory-dynamic.md b/en/device-dev/kernel/kernel-mini-basic-memory-dynamic.md new file mode 100644 index 0000000000000000000000000000000000000000..cd9379dc05b2417bc77c026aa74ecb40663db2eb --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-memory-dynamic.md @@ -0,0 +1,227 @@ +# Dynamic Memory + +- [Working Principles](#section328282013571) +- [Development Guidelines](#section7921151015814) + - [When to Use](#section326917198583) + - [Available APIs](#section1032331584) + - [How to Develop](#section07271773592) + - [Development Example](#section84931234145913) + - [Verification](#section165233233917) + + +## Working Principles + +Dynamic memory management allows memory blocks of any size to be allocated from a large contiguous memory \(memory pool or heap memory\) configured in the system based on user demands when memory resources are sufficient. The memory block can be released for further use when not required. Compared with static memory management, dynamic memory management allows memory allocation on demand but causes fragmentation of memory. + +The dynamic memory of the OpenHarmony LiteOS-M has optimized the memory space partitioning based on the Two-Level Segregate Fit \(TLSF\) algorithm to achieve higher performance and minimize fragmentation. [Figure 1](#fig14558185217397) shows the core algorithm of the dynamic memory. + +**Figure 1** Dynamic memory core algorithm +![](figure/dynamic-memory-core-algorithm.png "dynamic-memory-core-algorithm") + +Multiple free lists are used for management based on the size of the free memory block. The free memory blocks are divided into two parts: \[4, 127\] and \[27, 231\], as indicated by the size class in [Figure 1](#fig14558185217397). + +1. The memory in the range of \[4, 127\] \(lower part in [Figure 1](#fig14558185217397)\) is divided into 31 parts. The size of the memory block corresponding to each part is a multiple of 4 bytes. Each part corresponds to a free list and a bit that indicates whether the free list is empty. The value **1** indicates that the free list is not empty. There are 31 bits corresponding to the 31 memory parts in the range of \[4, 127\]. +2. The memory greater than 127 bytes is managed in power of two increments. The size of each range is \[2^n, 2^\(n+1\)-1\], where n is an integer in \[7, 30\]. This range is divided into 24 parts, each of which is further divided into 8 second-level \(L2\) ranges, as shown in Size Class and Size SubClass in the upper part of [Figure 1](#fig14558185217397). Each L2 range corresponds to a free list and a bit that indicates whether the free list is empty. There are a total of 192 \(24 x 8\) L2 ranges, corresponding to 192 free lists and 192 bits. + +For example, insert 40-byte free memory to a free list. The 40-byte free memory corresponds to the 10th free list in the range of \[40, 43\], and the 10th bit indicates the use of the free list. The system inserts the 40-byte free memory to the 10th free list and determines whether to update the bitmap flag. When 40-byte memory is requested, the system obtains the free list corresponding to the memory block of the requested size based on the bitmap flag, and then obtains a free memory node from the free list. If the size of the allocated node is greater than the memory requested, the system splits the node and inserts the remaining node to the free list. If 580-byte free memory needs to be inserted to a free list, the 580-byte free memory corresponds to the 47th \(31 + 2 x 8\) free list in L2 range \[2^9, 2^9+2^6\], and the 47th bit indicates the use of the free list. The system inserts the 580-byte free memory to the 47th free list and determines whether to update the bitmap flag. When 580-byte memory is requested, the system obtains the free list corresponding to the memory block of the requested size based on the bitmap flag, and then obtains a free memory node from the free list. If the size of the allocated node is greater than the memory requested, the system splits the node and inserts the remaining node to the free list. If the corresponding free list is empty, the system checks for a free list meeting the requirements in a larger memory range. In actual application, the system can locate the free list that meets the requirements at a time. + +[Figure 2](#fig5395115964114) shows the memory management structure. + +**Figure 2** Dynamic memory management structure +![](figure/dynamic-memory-management-structure.png "dynamic-memory-management-structure") + +- Memory pool header + + The memory pool header contains the memory pool information, bitmap flag array, and free list array. The memory pool information includes the start address of the memory pool, total size of the heap memory, and attributes of the memory pool. The bitmap flag array consists of seven 32-bit unsigned integers. Each bit indicates whether the free list is inserted with free memory block nodes. The free list contains information about 223 free memory head nodes. The free memory head node information contains a memory node header and information about the previous and next nodes in the free list. + +- Memory pool nodes + + There are three types of nodes: free node, used node, and end node. Each memory node maintains the size and use flag of the memory node and a pointer to the previous memory node in the memory pool. The free nodes and used nodes have a data area, but the end node has no data area. + + +## Development Guidelines + +### When to Use + +Dynamic memory management allocates and manages memory resources requested by users dynamically. It is a good choice when users need memory blocks of different sizes. You can call the dynamic memory allocation function of the OS to request a memory block of the specified size. You can call the dynamic memory release function to release the memory at any time. + +### Available APIs + +The following table describes APIs available for OpenHarmony LiteOS-M dynamic memory management. For more details about the APIs, see the API reference. + +**Table 1** APIs of the dynamic memory module + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Initializing or deleting a memory pool

+

LOS_MemInit

+

Initializes a dynamic memory pool of the specified size.

+

LOS_MemDeInit

+

Deletes a memory pool. It is valid only when LOSCFG_MEM_MUL_POOL is enabled.

+

Allocating or releasing dynamic memory

+

LOS_MemAlloc

+

Allocates memory of the specified size from the dynamic memory pool.

+

LOS_MemFree

+

Releases the memory allocated from the specified dynamic memory.

+

LOS_MemRealloc

+

Re-allocates a memory block of the required size and copies data from the original block to the newly allocated bock. If the new memory block is successfully allocated, the original memory block will be released.

+

LOS_MemAllocAlign

+

Allocates the memory of the specified size and aligned based on the specified bytes from a dynamic memory pool.

+

Obtaining memory pool information

+

LOS_MemPoolSizeGet

+

Obtains the total size of the specified dynamic memory pool.

+

LOS_MemTotalUsedGet

+

Obtains the total memory usage of the specified dynamic memory pool.

+

LOS_MemInfoGet

+

Obtains the memory structure information of the specified memory pool, including the free memory, used memory, number of free memory blocks, number of used memory blocks, and maximum size of the free memory block.

+

LOS_MemPoolList

+

Prints information about all initialized memory pools in the system, including the start address, size, total free memory, used memory, maximum size of the free memory block, number of free memory blocks, and number of used memory blocks of each memory pool. It is valid only when LOSCFG_MEM_MUL_POOL is enabled.

+

Obtaining memory block information

+

LOS_MemFreeNodeShow

+

Prints the size and number of free memory blocks in the specified memory pool.

+

LOS_MemUsedNodeShow

+

Prints the size and number of used memory blocks in the specified memory pool.

+

Checking memory pool integrity

+

LOS_MemIntegrityCheck

+

Checks the integrity of the specified memory pool. It is valid only when LOSCFG_BASE_MEM_NODE_INTEGRITY_CHECK is enabled.

+
+ +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The dynamic memory module manages memory through control block structures, which consume extra memory. Therefore, the actual memory space available to users is less than the value of **OS\_SYS\_MEM\_SIZE**. +>- The **LOS\_MemAllocAlign** and **LOS\_MemMallocAlign** APIs consume extra memory for memory alignment, which may cause memory loss. When the memory used for alignment is freed up, the lost memory will be reclaimed. + +### How to Develop + +The typical development process of dynamic memory is as follows: + +1. Call the **LOS\_MemInit** API to initialize a memory pool. + + After a memory pool is initialized, a memory pool control header and end node will be generated, and the remaining memory is marked as free nodes. The end node is the last node in the memory pool, and its size is **0**. + + +1. Call the **LOS\_MemAlloc** API to allocate dynamic memory of any size. + + The system checks whether the dynamic memory pool has free memory blocks greater than the requested size. If yes, the system allocates a memory block and returns the pointer to the memory block. If no, the system returns NULL. If the memory block allocated is greater than the requested size, the system splits the memory block and inserts the remaining memory block to the free list. + + +1. Call the **LOS\_MemFree** API to release dynamic memory. + + The released memory block can be reused. When **LOS\_MemFree** is called, the memory block will be reclaimed and marked as free nodes. When memory blocks are reclaimed, adjacent free nodes are automatically merged. + + +### Development Example + +The example below implements the following: + +1. Initialize a dynamic memory pool. +2. Allocate a memory block from the dynamic memory pool. +3. Store a piece of data in the memory block. +4. Print the data in the memory block. +5. Release the memory block. + +The sample code is as follows: + +``` +#include "los_memory.h" + +VOID Example_DynMem(VOID) +{ + UINT32 *mem = NULL; + UINT32 ret; + + /* Initialize the memory pool. */ + ret = LOS_MemInit(g_testPool, TEST_POOL_SIZE); + if (LOS_OK == ret) { + printf("Mem init success!\n"); + } else { + printf("Mem init failed!\n"); + return; + } + + /* Allocate memory.*/ + mem = (UINT32 *)LOS_MemAlloc(g_testPool, 4); + if (NULL == mem) { + printf("Mem alloc failed!\n"); + return; + } + printf("Mem alloc success!\n"); + + /* Assign a value.*/ + *mem = 828; + printf("*mem = %d\n", *mem); + + /* Release memory.*/ + ret = LOS_MemFree(g_testPool, mem); + if (LOS_OK == ret) { + printf("Mem free success!\n"); + } else { + printf("Mem free failed!\n"); + } + + return; +} +``` + +### Verification + +The output is as follows: + +``` +Mem init success! +Mem alloc success! +*mem = 828 +Mem free success! +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic-memory-static.md b/en/device-dev/kernel/kernel-mini-basic-memory-static.md new file mode 100644 index 0000000000000000000000000000000000000000..1d35df912f478c2c8eab8e38fe50a9c679219ae9 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-memory-static.md @@ -0,0 +1,182 @@ +# Static Memory + +- [Working Principles](#section165473517522) +- [Development Guidelines](#section57511620165218) + - [When to Use](#section215474911529) + - [Available APIs](#section79231214539) + - [How to Develop](#section1388511316548) + - [Development Example](#section17801515105519) + - [Verification](#section11818154112319) + + +## Working Principles + +The static memory is a static array. The block size in the static memory pool is set during initialization and cannot be changed after initialization. + +The static memory pool consists of a control block **LOS\_MEMBOX\_INFO** and several memory blocks **LOS\_MEMBOX\_NODE** of the same size. The control block is located at the head of the memory pool and used for memory block management. It contains the memory block size \(**uwBlkSize**\), number of memory blocks \(**uwBlkNum**\), number of allocated memory blocks \(**uwBlkCnt**\), and free list \(**stFreeList**\). Memory is allocated and released by block size. Each memory block contains the pointer **pstNext** that points to the next memory block. + +**Figure 1** Static memory +![](figure/static-memory.png "static-memory") + +## Development Guidelines + +### When to Use + +Use static memory allocation to obtain memory blocks of the fixed size. When the memory is no longer required, release the static memory. + +### Available APIs + +The following table describes APIs available for OpenHarmony LiteOS-M static memory management. For more details about the APIs, see the API reference. + +**Table 1** APIs of the static memory module + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Initializing the static memory pool

+

LOS_MemboxInit

+

Initialize a static memory pool and sets the start address, total size, and size of each memory block based on the input parameters.

+

Clearing static memory blocks

+

LOS_MemboxClr

+

Clears the memory blocks allocated from the static memory pool.

+

Allocating or releasing static memory

+

LOS_MemboxAlloc

+

Allocates a memory block from a specified static memory pool.

+

LOS_MemboxFree

+

Releases a memory block allocated from the static memory pool.

+

Obtaining or printing static memory pool information

+

LOS_MemboxStatisticsGet

+

Obtains information about a specified static memory pool, including the total number of memory blocks in the memory pool, number of allocated memory blocks, and size of each memory block.

+

LOS_ShowBox

+

Prints information about all nodes in a specified static memory pool (the print level is LOS_INFO_LEVEL). The information includes the start address of the memory pool, memory block size, total number of memory blocks, start address of each idle memory block, and start addresses of all memory blocks.

+
+ +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>The number of memory blocks in the memory pool after initialization is not equal to the total memory size divided by the memory block size. The reason is the control block of the memory pool and the control header of each memory block have memory overheads. When setting the total memory size, you need to consider these factors. + +### How to Develop + +The typical development process of static memory is as follows: + +1. Plan a memory space as the static memory pool. +2. Call the **LOS\_MemboxInit** API to initialize the static memory pool. + + During initialization, the memory space specified by the input parameter is divided into multiple blocks \(the number of blocks depends on the total static memory size and the block size\). Insert all memory blocks to the free list, and place the control header at the beginning of the memory. + +3. Call the **LOS\_MemboxAlloc** API to allocate static memory. + + The system allocates the first free memory block from the free list and returns the start address of this memory block. + +4. Call the **LOS\_MemboxClr** API. + + Clear the memory block corresponding to the address contained in the input parameter. + +5. Call the **LOS\_MemboxFree** API. + + Add the memory block to the free list. + + +### Development Example + +The example below implements the following: + +1. Initialize a static memory pool. +2. Allocate a memory block from the static memory pool. +3. Store a piece of data in a memory block. +4. Print the data in the memory block. +5. Clear the data in the memory block. +6. Release the memory block. + + The sample code is as follows: + + +``` +#include "los_membox.h" + +VOID Example_StaticMem(VOID) +{ + UINT32 *mem = NULL; + UINT32 blkSize = 10; + UINT32 boxSize = 100; + UINT32 boxMem[1000]; + UINT32 ret; + + /* Initialize the memory pool.*/ + ret = LOS_MemboxInit(&boxMem[0], boxSize, blkSize); + if(ret != LOS_OK) { + printf("Membox init failed!\n"); + return; + } else { + printf("Membox init success!\n"); + } + + /* Request a memory block.*/ + mem = (UINT32 *)LOS_MemboxAlloc(boxMem); + if (NULL == mem) { + printf("Mem alloc failed!\n"); + return; + } + printf("Mem alloc success!\n"); + + /* Assign a value.*/ + *mem = 828; + printf("*mem = %d\n", *mem); + + /* Clear data in the memory block. */ + LOS_MemboxClr(boxMem, mem); + printf("Mem clear success \n *mem = %d\n", *mem); + + /* Release the memory.*/ + ret = LOS_MemboxFree(boxMem, mem); + if (LOS_OK == ret) { + printf("Mem free success!\n"); + } else { + printf("Mem free failed!\n"); + } + + return; +} +``` + +### Verification + +The output is as follows: + +``` +Membox init success! +Mem alloc success! +*mem = 828 +Mem clear success +*mem = 0 +Mem free success! +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic-memory.md b/en/device-dev/kernel/kernel-mini-basic-memory.md new file mode 100644 index 0000000000000000000000000000000000000000..a473de6739f423492580dec911faa48d298aaaea --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-memory.md @@ -0,0 +1,9 @@ +# Memory Management + +- **[Basic Concepts](kernel-mini-basic-memory-basic.md)** + +- **[Static Memory](kernel-mini-basic-memory-static.md)** + +- **[Dynamic Memory](kernel-mini-basic-memory-dynamic.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-soft-basic.md b/en/device-dev/kernel/kernel-mini-basic-soft-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..e799f434a366a8c2b9037d29fcf770a8b917a8cc --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-soft-basic.md @@ -0,0 +1,54 @@ +# Basic Concepts + +- [Working Principles](#section070665816719) + - [Timer States](#section115453813506) + - [Timer Modes](#section137521353175010) + + +The software timer is a software-simulated timer based on system tick interrupts. When the preset tick counter value has elapsed, the user-defined callback will be invoked. The timing precision is related to the cycle of the system tick clock. + +Due to the limitation in hardware, the number of hardware timers cannot meet users' requirements. Therefore, the OpenHarmony LiteOS-M kernel provides the software timer function. The software timer allows more timing services to be created, increasing the number of timers. + +The software timer supports the following functions: + +- Disabling the software timer using a macro +- Creating a software timer +- Starting a software timer +- Stopping a software timer +- Deleting a software timer +- Obtaining the number of remaining ticks of a software timer + +## Working Principles + +The software timer is a system resource. When modules are initialized, a contiguous section of memory is allocated for software timers. The maximum number of timers supported by the system is configured by the **LOSCFG\_BASE\_CORE\_SWTMR\_LIMIT** macro in **los\_config.h**. + +Software timers use a queue and a task resource of the system. The software timers are triggered based on the First In First Out \(FIFO\) rule. A timer with a shorter value is always closer to the queue head than a timer with a longer value, and is preferentially triggered. + +The software timer counts time in ticks. When a software timer is created and started, the OpenHarmony LiteOS-M kernel determines the timer expiry time based on the current system time \(in ticks\) and the timing interval set by the user, and adds the timer control structure to the global timing list. + +When a tick interrupt occurs, the tick interrupt handler scans the global timing list for expired timers. If such timers are found, the timers are recorded. + +When the tick interrupt handling function is complete, the software timer task \(with the highest priority\) is woken up. In this task, the timeout callback function for the recorded timer is called. + +### Timer States + +- OS\_SWTMR\_STATUS\_UNUSED + +The timer is not in use. When the timer module is initialized, all timer resources in the system are set to this state. + +- OS\_SWTMR\_STATUS\_CREATED + +The timer is created but not started or the timer is stopped. When **LOS\_SwtmrCreate** is called for a timer that is not in use or **LOS\_SwtmrStop** is called for a newly started timer, the timer changes to this state. + +- OS\_SWTMR\_STATUS\_TICKING + +The timer is running \(counting\). When **LOS\_SwtmrStart** is called for a newly created timer, the timer enters this state. + +### Timer Modes + +The OpenHarmony LiteOS-M kernel provides three types of software timers: + +- One-shot timer: Once started, the timer is automatically deleted after triggering only one timer event. +- Periodic timer: This type of timer periodically triggers timer events until it is manually stopped. +- One-shot timer deleted by calling an API + diff --git a/en/device-dev/kernel/kernel-mini-basic-soft-guide.md b/en/device-dev/kernel/kernel-mini-basic-soft-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..41d1077832d0d7984f9ad7ad1dda3e385f1cfd1e --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-soft-guide.md @@ -0,0 +1,218 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section783435801510) +- [Development Example](#section460018317164) + - [Example Description](#section3741753191918) + - [Sample Code](#section20760101182016) + - [Verification](#section11244112818172) + + +## Available APIs + +The following table describes APIs available for the OpenHarmony LiteOS-M software timer module. For more details about the APIs, see the API reference. + +**Table 1** Software timer APIs + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting timers

+

LOS_SwtmrCreate

+

Creates a software timer.

+

LOS_SwtmrDelete

+

Deletes a software timer.

+

Starting or stopping timers

+

LOS_SwtmrStart

+

Starts a software timer.

+

LOS_SwtmrStop

+

Stop a software timer.

+

Obtaining remaining ticks of a software timer

+

LOS_SwtmrTimeGet

+

Obtains the number of remaining ticks of a software timer.

+
+ +## How to Develop + +The typical development process of software timers is as follows: + +1. Configure the software timer. + - Check that **LOSCFG\_BASE\_CORE\_SWTMR** and **LOSCFG\_BASE\_IPC\_QUEUE** are set to **1**. + - Configure **LOSCFG\_BASE\_CORE\_SWTMR\_LIMIT** \(maximum number of software timers supported by the system\). + - Configure **OS\_SWTMR\_HANDLE\_QUEUE\_SIZE** \(maximum length of the software timer queue\). + +2. Call **LOS\_SwtmrCreate** to create a software timer. + - Create a software timer with the specified timing duration, timeout handling function, and triggering mode. + - Return the function execution result \(success or failure\). + +3. Call **LOS\_SwtmrStart** to start the software timer. +4. Call **LOS\_SwtmrTimeGet** to obtain the remaining number of ticks of the software timer. +5. Call **LOS\_SwtmrStop** to stop the software timer. +6. Call **LOS\_SwtmrDelete** to delete the software timer. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- Avoid too many operations in the callback function of the software timer. Do not use APIs or perform operations that may cause task suspension or blocking. +>- The software timers use a queue and a task resource of the system. The priority of the software timer tasks is set to **0** and cannot be changed. +>- The number of software timer resources that can be configured in the system is the total number of software timer resources available to the entire system, not the number of software timer resources available to users. For example, if the system software timer occupies one more resource, the number of software timer resources available to users decreases by one. +>- If a one-shot software timer is created, the system automatically deletes the timer and reclaims resources after the timer times out and the callback function is executed. +>- For a one-shot software timer that will not be automatically deleted after expiration, you need to call **LOS\_SwtmrDelete** to delete it and reclaim the timer resource to prevent resource leakage. + +## Development Example + +### Example Description + +The following programming example demonstrates how to: + +1. Create, start, delete, pause, and restart a software timer. +2. Use a one-shot software timer and a periodic software timer + +### Sample Code + +Prerequisites + +- In **los\_config.h**, **LOSCFG\_BASE\_CORE\_SWTMR** is enabled. +- In **los\_config.h**, **LOSCFG\_BASE\_CORE\_SWTMR\_ALIGN** is disabled. The sample code does not involve timer alignment. +- The maximum number of software timers supported by the system \(**LOSCFG\_BASE\_CORE\_SWTMR\_LIMIT**\) is configured. +- The maximum length of the software timer queue \(OS\_SWTMR\_HANDLE\_QUEUE\_SIZE\) is configured. + +The sample code is as follows: + +``` +#include "los_swtmr.h" + +/* Timer count */ +UINT32 g_timerCount1 = 0; +UINT32 g_timerCount2 = 0; + +/* Task ID*/ +UINT32 g_testTaskId01; + +void Timer1_Callback(UINT32 arg) //Callback function 1 +{ + UINT32 tick_last1; + g_timerCount1++; + tick_last1=(UINT32)LOS_TickCountGet(); //Obtain the current number of ticks. + printf("g_timerCount1=%d, tick_last1=%d\n", g_timerCount1, tick_last1); +} + +void Timer2_Callback(UINT32 arg) //Callback function 2 +{ + UINT32 tick_last2; + tick_last2=(UINT32)LOS_TickCountGet(); + g_timerCount2++; + printf("g_timerCount2=%d tick_last2=%d\n", g_timerCount2, tick_last2); +} + +void Timer_example(void) +{ + UINT32 id1; // timer id + UINT32 id2; // timer id + UINT32 uwTick; + + /* Create a one-shot software timer, with the number of ticks set to 1000. When the number of ticks reaches 1000, callback function 1 is executed. */ + LOS_SwtmrCreate (1000, LOS_SWTMR_MODE_ONCE, Timer1_Callback, &id1, 1); + + /* Create a periodic software timer and execute callback function 2 every 100 ticks. */ + LOS_SwtmrCreate(100, LOS_SWTMR_MODE_PERIOD, Timer2_Callback, &id2, 1); + printf("create Timer1 success\n"); + + LOS_SwtmrStart (id1); // Start the one-shot software timer. + printf("start Timer1 sucess\n"); + + LOS_TaskDelay(200); // Delay 200 ticks. + LOS_SwtmrTimeGet(id1, &uwTick); // Obtain the number of remaining ticks of the one-short software timer. + printf("uwTick =%d\n", uwTick); + + LOS_SwtmrStop(id1); // Stop the software timer. + printf("stop Timer1 sucess\n"); + + LOS_SwtmrStart(id1); + LOS_TaskDelay(1000); + + LOS_SwtmrDelete(id1); // Delete the software timer. + printf("delete Timer1 sucess\n"); + + LOS_SwtmrStart(id2); // Start the periodic software timer. + printf("start Timer2\n"); + + LOS_TaskDelay(1000); + LOS_SwtmrStop(id2); + LOS_SwtmrDelete(id2); +} + +UINT32 Example_TaskEntry(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S task1; + + /* Lock task scheduling.*/ + LOS_TaskLock(); + + /* Create task 1.*/ + memset(&task1, 0, sizeof(TSK_INIT_PARAM_S)); + task1.pfnTaskEntry = (TSK_ENTRY_FUNC)Timer_example; + task1.pcName = "TimerTsk"; + task1.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task1.usTaskPrio = 5; + ret = LOS_TaskCreate(&g_testTaskId01, &task1); + if (ret != LOS_OK) { + printf("TimerTsk create failed.\n"); + return LOS_NOK; + } + + /* Unlock task scheduling.*/ + LOS_TaskUnlock(); + + return LOS_OK; +} +``` + +### Verification + +The output is as follows: + +``` +create Timer1 success +start Timer1 sucess +uwTick =798 +stop Timer1 sucess +g_timerCount1=1, tick_last1=1208 +delete Timer1 sucess +start Timer2 +g_timerCount2=1 tick_last2=1313 +g_timerCount2=2 tick_last2=1413 +g_timerCount2=3 tick_last2=1513 +g_timerCount2=4 tick_last2=1613 +g_timerCount2=5 tick_last2=1713 +g_timerCount2=6 tick_last2=1813 +g_timerCount2=7 tick_last2=1913 +g_timerCount2=8 tick_last2=2013 +g_timerCount2=9 tick_last2=2113 +g_timerCount2=10 tick_last2=2213 +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic-soft.md b/en/device-dev/kernel/kernel-mini-basic-soft.md new file mode 100644 index 0000000000000000000000000000000000000000..73dc746166fdf57f2c07024403c74745f2af28cd --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-soft.md @@ -0,0 +1,7 @@ +# Software Timer + +- **[Basic Concepts](kernel-mini-basic-soft-basic.md)** + +- **[Development Guidelines](kernel-mini-basic-soft-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-task-basic.md b/en/device-dev/kernel/kernel-mini-basic-task-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..0f3d463a36c052bb432d048716ad7d5c556ff92c --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-task-basic.md @@ -0,0 +1,96 @@ +# Basic Concepts + +- [Task-related Concepts](#section673132352511) +- [Task Running Mechanism](#section176294469251) + +From the perspective of the operating system, tasks are the minimum running units that compete for system resources. They can use or wait for CPUs, use system resources such as memory, and run independently. + +The task module of the OpenHarmony LiteOS-M provides multiple tasks and supports switching between tasks, helping users manage business process procedures. The task module has the following features: + +- Multiple tasks are supported. +- A task represents a thread. +- The preemptive scheduling mechanism is used for tasks. High-priority tasks can interrupt low-priority tasks. Low-priority tasks can be scheduled only after high-priority tasks are blocked or complete. +- Time slice round-robin is used to schedule tasks with the same priority. +- A total of 32 \(**0** to **31**\) priorities are defined. **0** is the highest priority, and **31** is the lowest. + +## Task-related Concepts + +**Task States** + +A task has multiple states. After the system initialization is complete, the created tasks can compete for certain resources in the system according to the scheduling procedure regulated by the kernel. + +A task can be in any of the following states: + +- Ready: The task is in the ready queue, waiting for execution by a CPU. +- Running: The task is being executed. +- Blocked: The task is not in the ready queue. The task may be suspended, delayed, waiting for a semaphore, waiting to read from or write into a queue, or reading from or writing into an event. +- Dead: The task execution is complete and waiting for the system to reclaim resources. + +**Task State Transition** + +**Figure 1** Task state transition +![](figure/task-state-transition.png "task-state-transition") + +The task transition process is as follows: + +- Ready → Running + + A task enters Ready state once created. When task switching occurs, the task with the highest priority in the Ready queue will be executed. The task being executed enters the Running state and is removed from the Ready queue. + +- Running → Blocked + + When a running task is blocked \(suspended, delayed, or reading semaphores\), it will be deleted from the Ready queue and changes from the Running state to the Blocked state. Then, task switching is triggered to run the task with the highest priority in the Ready queue. + +- Blocked → Ready \(Blocked → Running\) + + When a blocked task is recovered \(for example, the task is resumed, the delay period or semaphore read period times out, or the task successfully reads a semaphore\), the task will be added to the Ready queue and change from the Blocked state to the Ready state. If the priority of the recovered task is higher than that of the running task, task switching will be triggered to run the recovered task. Then, the task changes from the Ready state to the Running state. + +- Ready → Blocked + + When a task in the Ready state is blocked \(suspended\), the task changes to the Blocked state and is deleted from the Ready queue. The blocked task will not be scheduled until it is recovered. + +- Running → Ready + + When a task with a higher priority is created or recovered, tasks will be scheduled. The task with the highest priority in the Ready queue changes to the Running state. The originally running task changes to the Ready state and remains in the Ready queue. + +- Running → Dead + + When a running task is complete, it changes to the Dead state. The Dead state includes normal exit state as the task is complete and the Invalid state. For example, if a task is complete but is not automatically deleted, the task is in the Invalid state. + +- Blocked → Dead + + If an API is called to delete a blocked task, the task state change from Blocked to Dead. + + +**Task ID** + +You will receive a task ID after successfully creating a task. The task IDs are unique in the operating system. You can suspend, restore, or query tasks by task ID. + +**Task Priority** + +Tasks are executed based on their priority. When task switching occurs, the task with the highest priority in the Ready queue will be executed. + +**Task Entry Function** + +Function to be executed when a task is scheduled. This function is implemented by users and set in the task creation structure when a task is created. + +**Task Stack** + +An independent memory space for each task. The stack stores information such as local variables, registers, function parameters, and function return addresses. + +**Task Context** + +Resources, such as registers, used during the running of a task. When a task is suspended, other running tasks might modify the register values of the suspended task. If the original task context is not saved when task switching occurs, an unknown error may occur when the task is recovered. The context information of switched-out tasks is saved into their own task stacks so that the context information can be resumed along with tasks and the system can start from the interrupted code after the tasks are resumed. + +**Task Control Block** + +Each task has a task control block \(TCB\). A TCB contains task information, such as context stack pointer, state, priority, ID, name, and stack size. The TCB reflects the running status of a task. + +**Task Switching** + +Task switching involves actions, such as obtaining the task with the highest priority in the Ready queue, saving the context of the switched-out task, and restoring the context of the switched-in task. + +## Task Running Mechanism + +When a task is created, the system initializes the task stack and presets the context. The system places the task entry function in the corresponding position so that the function will be executed when the task enters the Running state for the first time. + diff --git a/en/device-dev/kernel/kernel-mini-basic-task-guide.md b/en/device-dev/kernel/kernel-mini-basic-task-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..3b810a99972bd43d5824fe0afc4d147f7983973f --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-task-guide.md @@ -0,0 +1,306 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section783435801510) +- [Development Example](#section460018317164) + - [Verification](#section189023104457) + + +When a task is created, the OpenHarmony LiteOS-M kernel can perform operations, such as locking or unlocking task scheduling, suspending, restoring, and delaying the task, and setting or obtaining the task priority. + +## Available APIs + +The following table describes APIs available for the OpenHarmony LiteOS-M task module. For more details about the APIs, see the API reference. + +**Table 1** APIs of the task management module + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting a task

+

LOS_TaskCreateOnly

+

Creates a task and suspends the task to disable scheduling of the task. To enable scheduling of the task, call LOS_TaskResume to make the task enter the Ready state.

+

LOS_TaskCreate

+

Creates a task and places the task in the Ready state. If there is no task with a higher priority in the Ready queue, the task will be executed.

+

LOS_TaskDelete

+

Deletes the specified task.

+

Controlling task status

+

LOS_TaskResume

+

Resumes a suspended task to place the task in the Ready state.

+

LOS_TaskSuspend

+

Suspends the specified task and performs task switching.

+

LOS_TaskDelay

+

Makes a task wait for a period of time (in ticks) and releases CPU resources. When the delay time expires, the task enters the Ready state again. The input parameter is the number of ticks.

+

LOS_Msleep

+

Converts the input parameter number of milliseconds into number of ticks, and use the result to calls LOS_TaskDelay.

+

LOS_TaskYield

+

Sets the time slice of the current task to 0 to release CPU resources and schedule the task with the highest priority in the Ready queue to run.

+

Control task scheduling

+

LOS_TaskLock

+

Locks task scheduling. However, tasks can still be interrupted.

+

LOS_TaskUnlock

+

Unlocks task scheduling.

+

LOS_Schedule

+

Triggers task scheduling

+

Controlling task priority

+

LOS_CurTaskPriSet

+

Sets the priority for the current task.

+

LOS_TaskPriSet

+

Sets the priority for a specified task.

+

LOS_TaskPriGet

+

Obtains the priority of a specified task.

+

Obtaining task information

+

LOS_CurTaskIDGet

+

Obtains the ID of the current task.

+

LOS_NextTaskIDGet

+

Obtains the ID of the task with the highest priority in the Ready queue.

+

LOS_NewTaskIDGet

+

Same as LOS_NextTaskIDGet.

+

LOS_CurTaskNameGet

+

Obtains the name of the current task.

+

LOS_TaskNameGet

+

Obtains the name of a specified task.

+

LOS_TaskStatusGet

+

Obtains the state of a specified task.

+

LOS_TaskInfoGet

+

Obtains information about a specified task, including the task state, priority, stack size, stack pointer (SP), task entry function, and used stack space.

+

LOS_TaskIsRunning

+

Checks whether the task module has started scheduling.

+

Maintaining and testing task information

+

LOS_TaskSwitchInfoGet

+

Obtains task switching information. The macro LOSCFG_BASE_CORE_EXC_TSK_SWITCH must be enabled.

+
+ +## How to Develop + +The typical development process of the task module is as follows: + +1. Use **LOS\_TaskLock** to lock task scheduling and prevent high-priority tasks from being scheduled. +2. Use **LOS\_TaskCreate** to create a task. +3. Use **LOS\_TaskUnlock** to unlock task scheduling so that tasks can be scheduled by priority. +4. Use **LOS\_TaskDelay** to delay a task. +5. Use **LOS\_TaskSuspend** to suspend a task. +6. Use **LOS\_TaskResume** to resume the suspended task. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- Running idle tasks reclaims the TCBs and stacks in the to-be-recycled linked list. +>- The task name is a pointer without memory space allocated. When setting the task name, do not assign the local variable address to the task name pointer. +>- The task stack size is 8-byte aligned. Follow the "nothing more and nothing less" principle while determining the task stack size. +>- A running task cannot be suspended if task scheduling is locked. +>- Idle tasks and software timer tasks cannot be suspended or deleted. +>- In an interrupt handler or when a task is locked, the operation of calling **LOS\_TaskDelay** fails. +>- Locking task scheduling does not disable interrupts. Tasks can still be interrupted while task scheduling is locked. +>- Locking task scheduling must be used together with unlocking task scheduling. +>- Task scheduling may occur while a task priority is being set. +>- The maximum number of tasks that can be set for the operating system is the total number of tasks of the operating system, not the number of tasks available to users. For example, if the system software timer occupies one more task resource, the number of task resources available to users decreases by one. +>- **LOS\_CurTaskPriSet** and **LOS\_TaskPriSet** cannot be used in interrupts or used to modify the priorities of software timer tasks. +>- If the task corresponding to the task ID sent to **LOS\_TaskPriGet** has not been created or the task ID exceeds the maximum number of tasks, **-1** will be returned. +>- Resources such as a mutex or a semaphore allocated to a task must have been released before the task is deleted. + +## Development Example + +This example describes the priority-based task scheduling and use of task-related APIs, including creating, delaying, suspending, and resuming two tasks with different priorities, and locking/unlocking task scheduling. The sample code is as follows: + +``` +UINT32 g_taskHiId; +UINT32 g_taskLoId; +#define TSK_PRIOR_HI 4 +#define TSK_PRIOR_LO 5 + +UINT32 Example_TaskHi(VOID) +{ + UINT32 ret; + + printf("Enter TaskHi Handler.\n"); + + /* Delay the task for 100 ticks. The task is then suspended, and the remaining task with the highest priority (TaskLo) will be executed.*/ + ret = LOS_TaskDelay(100); + if (ret != LOS_OK) { + printf("Delay TaskHi Failed.\n"); + return LOS_NOK; + } + + /*After 100 ticks elapse, the task is resumed.*/ + printf("TaskHi LOS_TaskDelay Done.\n"); + + /* Suspend the task.*/ + ret = LOS_TaskSuspend(g_taskHiId); + if (ret != LOS_OK) { + printf("Suspend TaskHi Failed.\n"); + return LOS_NOK; + } + printf("TaskHi LOS_TaskResume Success.\n"); + return ret; +} + +/* Entry function of low-priority tasks */ +UINT32 Example_TaskLo(VOID) +{ + UINT32 ret; + + printf("Enter TaskLo Handler.\n"); + + /* Delay the task for 100 ticks. The task is then suspended, and the remaining task with the highest priority will be executed.*/ + ret = LOS_TaskDelay(100); + if (ret != LOS_OK) { + printf("Delay TaskLo Failed.\n"); + return LOS_NOK; + } + + printf("TaskHi LOS_TaskSuspend Success.\n"); + + /* Resume the suspended task g_taskHiId.*/ + ret = LOS_TaskResume(g_taskHiId); + if (ret != LOS_OK) { + printf("Resume TaskHi Failed.\n"); + return LOS_NOK; + } + return ret; +} + +/* Task entry function used to create two tasks with different priorities */ +UINT32 Example_TskCaseEntry(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S initParam; + + /* Lock task scheduling to prevent newly created tasks from being scheduled prior to this task due to higher priority.*/ + LOS_TaskLock(); + + printf("LOS_TaskLock() Success!\n"); + + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_TaskHi; + initParam.usTaskPrio = TSK_PRIOR_HI; + initParam.pcName = "TaskHi"; + initParam.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + + /* Create a high-priority task. The task will not be executed immediately after being created, because task scheduling is locked.*/ + ret = LOS_TaskCreate(&g_taskHiId, &initParam); + if (ret != LOS_OK) { + LOS_TaskUnlock(); + + printf("Example_TaskHi create Failed!\n"); + return LOS_NOK; + } + + printf("Example_TaskHi create Success!\n"); + + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_TaskLo; + initParam.usTaskPrio = TSK_PRIOR_LO; + initParam.pcName = "TaskLo"; + initParam.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + + /*Create a low-priority task. The task will not be executed immediately after being created, because task scheduling is locked.*/ + ret = LOS_TaskCreate(&g_taskLoId, &initParam); + if (ret != LOS_OK) { + LOS_TaskUnlock(); + printf("Example_TaskLo create Failed!\n"); + return LOS_NOK; + } + + printf("Example_TaskLo create Success!\n"); + + /* Unlock task scheduling. The task with the highest priority in the Ready queue will be executed.*/ + LOS_TaskUnlock(); + + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +LOS_TaskLock() Success! +Example_TaskHi create Success! +Example_TaskLo create Success! +Enter TaskHi Handler. +Enter TaskLo Handler. +TaskHi LOS_TaskDelay Done. +TaskHi LOS_TaskSuspend Success. +TaskHi LOS_TaskResume Success. +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic-task.md b/en/device-dev/kernel/kernel-mini-basic-task.md new file mode 100644 index 0000000000000000000000000000000000000000..9c9c0db330425f93aebab7ab0ed6ec75537e217b --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-task.md @@ -0,0 +1,7 @@ +# Task Management + +- **[Basic Concepts](kernel-mini-basic-task-basic.md)** + +- **[Development Guidelines](kernel-mini-basic-task-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-basic-time-basic.md b/en/device-dev/kernel/kernel-mini-basic-time-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..b8a2b749f8dd2ea955f15427cf02549640e2841a --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-time-basic.md @@ -0,0 +1,23 @@ +# Basic Concepts + +- [Time Unit](#section97172532397) + +Time management provides all time-related services for applications based on the system clock. + +The system clock is generated by the interrupts triggered by the output pulse of a timer or counter. The system clock is generally defined as an integer or a long integer. The period of an output pulse is a "clock tick". The system clock is also called time scale or tick. + +People use second or millisecond as the time unit, while the operating system uses tick. When operations such as suspending a task or delaying a task are performed, the time management module converts time between ticks and seconds or milliseconds. + +The time management module of the OpenHarmony LiteOS-M kernel provides time conversion and statistics functions. + +## Time Unit + +- Cycle + + Cycle is the minimum time unit in the system. The cycle duration is determined by the system clock frequency, that is, the number of cycles per second. + +- Tick + + Tick is the basic time unit of the operating system and is determined by the number of ticks per second configured by the user. + + diff --git a/en/device-dev/kernel/kernel-mini-basic-time-guide.md b/en/device-dev/kernel/kernel-mini-basic-time-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..336ce25a55d51ccc26b886e37ba14a7ab671bcb1 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic-time-guide.md @@ -0,0 +1,157 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section783435801510) +- [Development Example](#section460018317164) + - [Example Description](#section127752801718) + - [Sample Code](#section321653551711) + - [Verification](#section4366193318167) + + +The time management module provides APIs to implement conversion between the system running time, ticks, and seconds/milliseconds. + +## Available APIs + +The following table describes APIs available for the OpenHarmony LiteOS-M time management. For more details about the APIs, see the API reference. + +**Table 1** APIs of the time management module + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Time conversion

+

LOS_MS2Tick

+

Converts milliseconds into ticks.

+

LOS_Tick2MS

+

Converts ticks into milliseconds.

+

OsCpuTick2MS

+

Converts cycles into milliseconds. Two UINT32 values indicate the high-order and low-order 32 bits of the result value, respectively.

+

OsCpuTick2US

+

Converts cycles into microseconds. Two UINT32 values indicate the high-order and low-order 32 bits of the result value, respectively.

+

Time statistics

+

LOS_SysClockGet

+

Obtains the system clock.

+

LOS_TickCountGet

+

Obtains the number of ticks since the system starts.

+

LOS_CyclePerTickGet

+

Obtains the number of cycles for each tick.

+
+ +## How to Develop + +The typical development process of time management is as follows: + +1. Complete board configuration and adaptation as required, and configure the system clock frequency \(**OS\_SYS\_CLOCK** in Hz and **LOSCFG\_BASE\_CORE\_TICK\_PER\_SECOND**\). The default value of **OS\_SYS\_CLOCK** varies with the hardware platform. +2. Call the clock conversion and statistics APIs. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The time management module depends on **OS\_SYS\_CLOCK** and **LOSCFG\_BASE\_CORE\_TICK\_PER\_SECOND**. +>- The number of system ticks is not counted when the interrupt feature is disabled. Therefore, the number of ticks cannot be used as the accurate time. +>- The configuration options are maintained in the **target\_config.h** file of the development board project. + +## Development Example + +### Example Description + +The following example describes basic time management methods, including: + +1. Time conversion: converts milliseconds to ticks or converts ticks to milliseconds. +2. Time statistics: obtains the number of cycles per tick, number of ticks since system startup, and number of delayed ticks. + +### Sample Code + +Prerequisites + +- The default value of **LOSCFG\_BASE\_CORE\_TICK\_PER\_SECOND** is **100**. +- The system clock frequency **OS\_SYS\_CLOCK** is configured. + +Time conversion: + +``` +VOID Example_TransformTime(VOID) +{ + UINT32 ms; + UINT32 tick; + + tick = LOS_MS2Tick(10000); // Convert 10000 ms into ticks. + dprintf("tick = %d \n", tick); + ms = LOS_Tick2MS(100); // Convert 100 ticks into ms. + dprintf("ms = %d \n", ms); +} +``` + +Time statistics and delay: + +``` +VOID Example_GetTime(VOID) +{ + UINT32 cyclePerTick; + UINT64 tickCount; + + cyclePerTick = LOS_CyclePerTickGet(); + if(0 != cyclePerTick) { + dprintf("LOS_CyclePerTickGet = %d \n", cyclePerTick); + } + + tickCount = LOS_TickCountGet(); + if(0 != tickCount) { + dprintf("LOS_TickCountGet = %d \n", (UINT32)tickCount); + } + + LOS_TaskDelay(200); + tickCount = LOS_TickCountGet(); + if(0 != tickCount) { + dprintf("LOS_TickCountGet after delay = %d \n", (UINT32)tickCount); + } +} +``` + +### Verification + +The development is successful if the return result is as follows: + +Time conversion: + +``` +tick = 1000 +ms = 1000 +``` + +Time statistics and delay: + +``` +LOS_CyclePerTickGet = 495000 +LOS_TickCountGet = 1 +LOS_TickCountGet after delay = 201 +``` + diff --git a/en/device-dev/kernel/kernel-mini-basic.md b/en/device-dev/kernel/kernel-mini-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..87b28cd0549130ab2e0d32bfb54c7d7a30911a8a --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-basic.md @@ -0,0 +1,15 @@ +# Basic Kernel + +- **[Interrupt Management](kernel-mini-basic-interrupt.md)** + +- **[Task Management](kernel-mini-basic-task.md)** + +- **[Memory Management](kernel-mini-basic-memory.md)** + +- **[Kernel Communication Mechanisms](kernel-mini-basic-ipc.md)** + +- **[Time Management](kernel-basic-mini-time.md)** + +- **[Software Timer](kernel-mini-basic-soft.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-extend-cpup-basic.md b/en/device-dev/kernel/kernel-mini-extend-cpup-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..cef5f25565506eb4dceb43dfd455a18a9999e7ae --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-cpup-basic.md @@ -0,0 +1,31 @@ +# Basic Concepts + +- [Working Principles](#section96644177124) + +The central processing unit percent \(CPUP\) includes the system CPUP and task CPUP. + +The system CPUP is the CPU usage of the system within a period of time. It reflects the CPU load and the system running status \(idle or busy\) in the given period of time. The valid range of the system CPUP is 0 to 100 in percentage. The precision can be adjusted through configuration. The value **100** indicates that the system runs with full load. + +Task CPUP refers to the CPU usage of a single task. It reflects the task status, busy or idle, in a period of time. The valid range of task CPUP is 0 to 100 in percentage. The precision can be adjusted through configuration. The value **100** indicates that the task is being executed for the given period of time. + +With the system CPUP, you can determine whether the current system load exceeds the designed specifications. + +With the CPUP of each task, you can determine whether the CPU usage of each task meets expectations of the design. + +## Working Principles + +The OpenHarmony LiteOS-M CPUP records the system CPU usage on a task basis. When task switching occurs, the task start time and task switch-out or exit time are recorded. Each time when a task exits, the system accumulates the CPU time used by the task. + +You can configure this function in **target\_config.h**. + +The OpenHarmony LiteOS-M provides the following types of CPUP information: + +- System CPUP +- Task CPUP + +The CPUP is calculated as follows: + +System CPUP = Total running time of all tasks except idle tasks/Total running time of the system + +Task CPUP = Total running time of the task/Total running time of the system + diff --git a/en/device-dev/kernel/kernel-mini-extend-cpup-guide.md b/en/device-dev/kernel/kernel-mini-extend-cpup-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..bbbf020701a359becc749bb1c3f92a0f839ababd --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-cpup-guide.md @@ -0,0 +1,163 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section783435801510) +- [Development Example](#section460018317164) + - [Example Description](#section51413507517) + - [Sample Code](#section17617965523) + - [Verification](#section1968771515188) + + +## Available APIs + +**Table 1** Functions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Obtaining the system CPU usage

+

LOS_SysCpuUsage

+

Obtains the current system CPUP.

+

LOS_HistorySysCpuUsage

+

Obtains the historical CPUP of the system.

+

Obtaining the task CPUP

+

LOS_TaskCpuUsage

+

Obtains the CPUP of a specified task.

+

LOS_HistoryTaskCpuUsage

+

Obtains the historical CPUP of a specified task.

+

LOS_AllCpuUsage

+

Obtains the CPUP of all tasks.

+

Outputting the task CPUP

+

LOS_CpupUsageMonitor

+

Outputs the historical CPUP of a task.

+
+ +## How to Develop + +The typical CPUP development process is as follows. + +1. Call **LOS\_SysCpuUsage** to obtain the system CPUP. +2. Call **LOS\_HistorySysCpuUsage** to obtain the historical CPUP of the system. +3. Call **LOS\_TaskCpuUsage** to obtain the CPUP of a specified task. + - If the task has been created, disable interrupt, obtain the CPUP, and then enable interrupt. + - If the task is not created, return an error code. + +4. Call **LOS\_HistoryTaskCpuUsage** to obtain the historical CPUP of a specified task. + - If the task has been created, disable interrupt, obtain the CPUP in different modes, and then enable interrupt. + - If the task is not created, return an error code. + +5. Call **LOS\_AllCpuUsage** to obtain the CPUP of all tasks. + - If the CPUP is initialized, disable interrupt, obtain the CPUP in different modes, and then enable interrupt. + - If CPUP is not initialized or has invalid input parameters, return an error code. + + +## Development Example + +### Example Description + +This example implements the following: + +1. Create a task for the CPUP test. +2. Obtain the CPUP of the current system. +3. Obtain the historical system CPUP in different modes. +4. Obtain the CPUP of the created test task. +5. Obtain the CPUP of the created test task in different modes. + +### Sample Code + +Prerequisites + +In **target\_config.h**, the **LOSCFG\_BASE\_CORE\_CPUP** parameter is enabled. + +The sample code is as follows: + +``` +#include "los_task.h" +#include "los_cpup.h" +#define MODE 4 +UINT32 g_cpuTestTaskID; +VOID ExampleCpup(VOID) +{ + printf("entry cpup test example\n"); + while(1) { + usleep(100); + } +} +UINT32 ItCpupTest(VOID) +{ + UINT32 ret; + UINT32 cpupUse; + TSK_INIT_PARAM_S cpupTestTask = { 0 }; + memset(&cpupTestTask, 0, sizeof(TSK_INIT_PARAM_S)); + cpupTestTask.pfnTaskEntry = (TSK_ENTRY_FUNC)ExampleCpup; + cpupTestTask.pcName = "TestCpupTsk"; + cpupTestTask.uwStackSize = 0x800; + cpupTestTask.usTaskPrio = 5; + ret = LOS_TaskCreate(&g_cpuTestTaskID, &cpupTestTask); + if(ret != LOS_OK) { + printf("cpupTestTask create failed .\n"); + return LOS_NOK; + } + + usleep(100); + + /* Obtain the current CPUP of the system. */ + cpupUse = LOS_SysCpuUsage(); + printf("the current system cpu usage is: %u.%u\n", + cpupUse / LOS_CPUP_PRECISION_MULT, cpupUse % LOS_CPUP_PRECISION_MULT); + + cpupUse = LOS_HistorySysCpuUsage(CPU_LESS_THAN_1S); + /* Obtain the CPUP of the specified task (cpupTestTask in this example).*/ + printf("the history system CPUP in all time: %u.%u\n", + cpupUse / LOS_CPUP_PRECISION_MULT, cpupUse % LOS_CPUP_PRECISION_MULT); + cpupUse = LOS_TaskCpuUsage(g_cpuTestTaskID); + /* Obtain the CPUP of the specified historical task (cpupTestTask in this example) since the system startup. */ + printf("cpu usage of the cpupTestTask:\n TaskID: %d\n usage: %u.%u\n", + g_cpuTestTaskID, cpupUse / LOS_CPUP_PRECISION_MULT, cpupUse % LOS_CPUP_PRECISION_MULT); + cpupUse = LOS_HistoryTaskCpuUsage(g_cpuTestTaskID, CPU_LESS_THAN_1S); + printf("cpu usage of the cpupTestTask in all time:\n TaskID: %d\n usage: %u.%u\n", + g_cpuTestTaskID, cpupUse / LOS_CPUP_PRECISION_MULT, cpupUse % LOS_CPUP_PRECISION_MULT); + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +entry cpup test example +the current system cpu usage is : 1.5 + the history system cpu usage in all time: 3.0 + cpu usage of the cpupTestTask: TaskID:10 usage: 0.0 + cpu usage of the cpupTestTask in all time: TaskID:10 usage: 0.0 +``` + diff --git a/en/device-dev/kernel/kernel-mini-extend-cpup.md b/en/device-dev/kernel/kernel-mini-extend-cpup.md new file mode 100644 index 0000000000000000000000000000000000000000..2c0e14e9945206437d9968532ec98779bbab69e2 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-cpup.md @@ -0,0 +1,7 @@ +# CPUP + +- **[Basic Concepts](kernel-mini-extend-cpup-basic.md)** + +- **[Development Guidelines](kernel-mini-extend-cpup-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-extend-dynamic-loading-basic.md b/en/device-dev/kernel/kernel-mini-extend-dynamic-loading-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..591fb131ef2de3a000706860c15cceb8c633b51f --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-dynamic-loading-basic.md @@ -0,0 +1,91 @@ +# Basic Concepts + +- [Working Principles](#section139861939219) + - [Exporting the Symbol Table](#section15414650102716) + - [Loading an ELF File](#section5221181562810) + - [ELF File Link](#section68441639182817) + +- [ELF Specifications](#section187315541916) + - [ELF Type](#section1701552268) + - [Options for Linking](#section17292133274) + + +In small devices with limited hardware resources, dynamic algorithm deployment capability is required to solve the problem that multiple algorithms cannot be deployed at the same time. The LiteOS-M kernel uses the Executable and Linkable Format \(ELF\) because it is easy to use and compatible with a wide variety of platforms. The LiteOS-M provides APIs similar to **dlopen** and **dlsym**. Apps can load and unload required algorithm libraries by using the APIs provided by the dynamic loading module. As shown in the following figure, the app obtains the corresponding information output through the API required by the third-party algorithm library. The third-party algorithm library depends on the basic APIs provided by the kernel, such as **malloc**. After the app loads the API and relocates undefined symbols, it can call the API to complete the function. The dynamic loading component supports only the Arm architecture. + +**Figure 1** LiteOS-M kernel dynamic loading architecture +![](figure/liteos-m-kernel-dynamic-loading-architecture.png "liteos-m-kernel-dynamic-loading-architecture") + +## Working Principles + +### Exporting the Symbol Table + +The kernel needs to proactively expose the API required by the dynamic library when the shared library calls a kernel API, as shown in the following figure. This mechanism compiles the symbol information to the specified section and calls the **SYM\_EXPORT** macro to export information of the specified symbol. The symbol information is described in the structure **SymInfo**. Its members include the symbol name and symbol address information. The macro **SYM\_EXPORT** imports the symbol information to the **.sym.\*** section by using the **\_\_attribute\_\_** compilation attribute. + +``` +typedef struct { + CHAR *name; + UINTPTR addr; +} SymInfo; + +#define SYM_EXPORT(func) \ +const SymInfo sym_##func __attribute__((section(".sym."#func))) = { \ + .name = #func, \ + .addr = (UINTPTR)func \ +}; +``` + +**Figure 2** Exported symbol table information +![](figure/exported-symbol-table-information.png "exported-symbol-table-information") + +### Loading an ELF File + +During the loading process, the LOAD section to be loaded to the memory is obtained based on the ELF file handle and the section offset of the program header table. Generally, there are two sections: read-only section and read-write section. You can run the **readelf -l** command to view the LOAD section information of the ELF file. The physical memory is requested according to the related alignment attributes. Then, a code section or a data segment is written into the memory based on the loading base address and an offset of each section. + +``` +$ readelf -l lib.so + +Elf file type is DYN (Shared object file) +Entry point 0x5b4 +There are 4 program headers, starting at offset 52 + +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x000760 0x00000760 0x00000760 0x00008 0x00008 R 0x4 + LOAD 0x000000 0x00000000 0x00000000 0x0076c 0x0076c R E 0x10000 + LOAD 0x00076c 0x0001076c 0x0001076c 0x0010c 0x00128 RW 0x10000 + DYNAMIC 0x000774 0x00010774 0x00010774 0x000c8 0x000c8 RW 0x4 + + Section to Segment mapping: + Segment Sections... + 00 .ARM.exidx + 01 .hash .dynsym .dynstr .rel.dyn .rel.plt .init .plt .text .fini .ARM.exidx .eh_frame + 02 .init_array .fini_array .dynamic .got .data .bss + 03 .dynamic +``` + +**Figure 3** Process of loading an ELF file +![](figure/process-of-loading-an-elf-file.png "process-of-loading-an-elf-file") + +### ELF File Link + +A relocation table is obtained by using a **.dynamic** section of the ELF file. Each entry that needs to be relocated in the table is traversed. Then, the symbol is searched, based on the symbol name that needs to be relocated, in the shared library and the exported symbol table provided by the kernel. The relocation information is updated based on the symbol found. + +**Figure 4** ELF file linking process +![](figure/elf-file-linking-process.png "elf-file-linking-process") + +## ELF Specifications + +### ELF Type + +When compiling a shared library, you can add **-fPIC** \(a compilation option\) to compile location-independent code. The shared library file type is **ET\_DYN**, which can be loaded to any valid address range. + +Example: **arm-none-eabi-gcc -fPIC –shared –o lib.so lib.c** + +### Options for Linking + +1. **-nostdlib**: Do not use the lib library in the compiler when linking. +2. **-nostartfiles**: Do not use the startup files in the compiler when linking. +3. **-fPIC**: compiles location-independent shared libraries. +4. **-z max-page-size=4**: sets the number of alignment bytes of the loadable sections in the binary file to **4**. This setting saves memory and can be used for a dynamic library. +5. **-mcpu=** specifies the CPU architecture. + diff --git a/en/device-dev/kernel/kernel-mini-extend-dynamic-loading-guide.md b/en/device-dev/kernel/kernel-mini-extend-dynamic-loading-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..959cb55dbf7813658c252936586794fb11cc71c7 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-dynamic-loading-guide.md @@ -0,0 +1,187 @@ +# Development Guidelines + +- [Available APIs](#section158501652121514) +- [How to Develop](#section5241132917523) +- [Development Example](#section8708112313531) + +## Available APIs + +**Table 1** Functions + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Dynamic loading

+

LOS_DynlinkInit

+

Initializes the dynamic linker linked list and mutex.

+

LOS_SoLoad

+

Loads the shared library in a specified path.

+

LOS_FindSym

+

Searches for the specified symbol based on the shared library handle.

+

LOS_SoUnload

+

Unloads the shared library handle.

+
+ +## How to Develop + +1. Use the arm-none-eabi-gcc cross compiler to compile the shared library and build a FAT or LittleFS image, and burn the image to the flash memory. +2. In the **target\_config.h** file, set **LOSCFG\_DYNLINK** to **1** to enable the dynamic loading module. +3. Call **LOS\_SoLoad** to load the shared library in the specified path. +4. Call **LOS\_FindSym** to search for the specified symbol and obtain the symbol address. +5. Call **LOS\_SoUnload** to unload the handle of the specified shared library. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>1. For details about the compilation options required for compiling the shared library using the cross compiler, see the ELF specifications. +>2. Before creating a file system image, you need to adapt the FAT or LittleFS to the specific board. +>3. The shared library does not depend on the libc library in the compiler and does not support C++. +>4. The shared library depends only on the APIs provided by the kernel and cannot depend on other shared libraries. + +## Development Example + +The following uses the Arm Cortex-M4 board as an example. + +1. Sample Code and Compilation of the Shared Library + + The sample code is used to test the calling of global symbols and calling of the kernel APIs **malloc**, **free**, and **memset**. + + ``` + #include + #include + + int g_param = 10; + + int callee(int a, int b) + { + char *addr = malloc(g_param); + if (addr == NULL) { + return 0; + } + + memset(addr, '1', g_param); + + free(addr); + return a + b + g_param; + } + + int caller(int a, int b) + { + return callee(a, b); + } + ``` + + ``` + $ arm-none-eabi-gcc -fPIC -shared -mcpu=cortex-m4 -nostdlib -nostartfiles -z max-page-size=4 -o test.so test.c + ``` + +2. Export the malloc, free, and memset symbols used in the shared library. Compile the following code into a .c file and use it for OS compilation. + + ``` + #include "stdlib.h" + #include "string.h" + + SYM_EXPORT(malloc); + SYM_EXPORT(free); + SYM_EXPORT(memset); + ``` + +3. Determine the kernel compilation environment and add the following statement to the linking script of the compiler to ensure that the symbol table information is output to the specified section during compilation and linking. + + Add the following statement to the **.icf** linking script of the IAR compiler: + + ``` + keep {section .TABLE.START}; + keep {section .sym.*}; + keep {section .table.end}; + define block SYMBOL_TABLE with fixed order + { + section .TABLE.START, + section .sym.*, + section .table.end + }; + place in ROM_region {readonly, block SYMBOL_TABLE}; + ``` + + Add the following statement to the **.ld** linking script of the GCC compiler: + + ``` + __sym_table_start = .; + KEEP(*( SORT (.sym.*))); + __sym_table_end = .; + ``` + +4. Load, link, execute, and unload the shared library. + + The sample code is used to test whether the functions of the **LOS\_SoLoad**, **LOS\_FindSym**, and **LOS\_SoUnload** can be implemented normally and whether the symbols located by using **LOS\_FindSym** can be properly called. + + ``` + #include "los_dynlink.h" + + VOID DynlinkTest(VOID) + { + VOID *handle = NULL; + INT32 (*func)(INT32, INT32) = NULL; + CHAR *symbolName = "caller"; + CHAR *dsoName = "/lib/test.so"; + INT32 ret; + + handle = (VOID *)LOS_SoLoad(dsoName, NULL); + if (handle == NULL) { + printf("Failed to load so\n"); + return; + } + + func = (INT32 (*)(INT32, INT32))LOS_FindSym(handle, symbolName); + if (func == NULL) { + printf("Failed to find symbol\n"); + LOS_SoUnload(handle); + return; + } + + ret = func(1, 1); + if (ret != 12) { + printf("Failed to execute function\n"); + LOS_SoUnload(handle); + return; + } + + ret = LOS_SoUnload(handle); + if (ret != 0) { + printf("Failed to unload so\n"); + } + + + printf("Success!\n"); + } + ``` + +5. Verification + + ``` + Success! + ``` + + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>In this example, the file system path is **/lib/test.so**. +>You can create a task and call **DynlinkTest** in the task to perform the test. + diff --git a/en/device-dev/kernel/kernel-mini-extend-dynamic-loading.md b/en/device-dev/kernel/kernel-mini-extend-dynamic-loading.md new file mode 100644 index 0000000000000000000000000000000000000000..4e652b4cd890d8c32fd0055189f21bbac5d5d2da --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-dynamic-loading.md @@ -0,0 +1,7 @@ +# Dynamic Loading + +- **[Basic Concepts](kernel-mini-extend-dynamic-loading-basic.md)** + +- **[Development Guidelines](kernel-mini-extend-dynamic-loading-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-extend-file-fat.md b/en/device-dev/kernel/kernel-mini-extend-file-fat.md new file mode 100644 index 0000000000000000000000000000000000000000..2c9e3be0ccd27694c063ba4dc663b30bfec019d2 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-file-fat.md @@ -0,0 +1,177 @@ +# FAT + +- [Basic Concepts](#section1772629121418) +- [Development Guidelines](#section1149072811148) + - [Adaptation of Drivers](#section19174939191414) + - [How to Develop](#section131211626151513) + +- [Development Example](#section1133718619459) + - [Example Description](#section45337345313) + - [Sample Code](#section119813171539) + - [Verification](#section7987101232311) + + +## Basic Concepts + +File Allocation Table \(FAT\) is a file system developed for personal computers. It consists of the DOS Boot Record \(DBR\) region, FAT region, and Data region. Each entry in the FAT region records information about the corresponding cluster in the storage device. The cluster information includes whether the cluster is used, number of the next cluster of the file, whether the file ends with the cluster. The FAT file system supports multiple formats, such as FAT12, FAT16, and FAT32. The numbers 12, 16, and 32 indicate the number of bytes per cluster within the FAT, respectively. The FAT file system supports multiple media, especially removable storage media \(such as USB flash drives, SD cards, and removable hard drives\). The FAT file system ensures good compatibility between embedded devices and desktop systems \(such as Windows and Linux\) and facilitates file management. + +The OpenHarmony kernel supports FAT12, FAT16, and FAT32 file systems. These file systems require a tiny amount of code to implement, use less resources, support a variety of physical media, and are tailorable and compatible with Windows and Linux systems. They also support identification of multiple devices and partitions. The kernel supports multiple partitions on hard drives and allows creation of the FAT file system on the primary partition and logical partition. + +## Development Guidelines + +### Adaptation of Drivers + +The use of the FAT file system requires support from the underlying MultiMediaCard \(MMC\) drivers. To run FatFS on a board with an MMC storage device, you must: + +1. Implement the **disk\_status**, **disk\_initialize**, **disk\_read**, **disk\_write**, and **disk\_ioctl** APIs to adapt to the embedded MMC \(eMMC\) drivers on the board. + +2. Add the **fs\_config.h** file with information such as **FS\_MAX\_SS** \(maximum sector size of the storage device\) and **FF\_VOLUME\_STRS** \(partition names\) configured. The following is an example: + +``` +#define FF_VOLUME_STRS "system", "inner", "update", "user" +#define FS_MAX_SS 512 +#define FAT_MAX_OPEN_FILES 50 +``` + +### How to Develop + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- Note the following when managing FatFS files and directories: +> - A file cannot exceed 4 GB. +> - **FAT\_MAX\_OPEN\_FILES** specifies the maximum number files you can open at a time, and **FAT\_MAX\_OPEN\_DIRS** specifies the maximum number of folders you can open at a time. +> - Root directory management is not supported. File and directory names start with the partition name. For example, **user/testfile** indicates the file or directory **testfile** in the **user** partition. +> - To open a file multiple times, use **O\_RDONLY** \(read-only mode\). **O\_RDWR** or **O\_WRONLY** \(writable mode\) can open a file only once. +> - The read and write pointers are not separated. If a file is open in **O\_APPEND** mode, the read pointer is also at the end of the file. If you want to read the file from the beginning, you must manually set the position of the read pointer. +> - File and directory permission management is not supported. +> - The **stat** and **fstat** APIs do not support query of the modification time, creation time, and last access time. The Microsoft FAT protocol does not support time before A.D. 1980. +>- Note the following when mounting and unmounting FatFS partitions: +> - Partitions can be mounted with the read-only attribute. When the input parameter of the **mount** function is **MS\_RDONLY**, all APIs with the write attribute, such as **write**, **mkdir**, **unlink**, and **open** with **non-O\_RDONLY** attributes, will be rejected. +> - You can use the **MS\_REMOUNT** flag with **mount** to modify the permission for a mounted partition. +> - Before unmounting a partition, ensure that all directories and files in the partition are closed. +> - You can use **umount2** with the **MNT\_FORCE** parameter to forcibly close all files and folders and unmount the partition. However, this may cause data loss. Therefore, exercise caution when running **umount2**. +>- The FAT file system supports re-partitioning and formatting of storage devices using **fatfs\_fdisk** and **fatfs\_format**. +> - If a partition is mounted before being formatted using **fatfs\_format**, you must close all directories and files in the partition and unmount the partition first. +> - Before calling **fatfs\_fdisk**, ensure that all partitions in the device are unmounted. +> - Using **fatfs\_fdisk** and **fatfs\_format** may cause data loss. Exercise caution when using them. + +## Development Example + +### Example Description + +This example implements the following: + +1. Create the **user/test** directory. +2. Create the **file.txt** file in the **user/test** directory. +3. Write "Hello OpenHarmony!" at the beginning of the file. +4. Save the update of the file to the device. +5. Set the offset to the beginning of the file. +6. Read the file. +7. Close the file. +8. Delete the file. +9. Delete the directory. + +### Sample Code + +Prerequisites + +- The MMC device partition is mounted to the **user** directory. + +The sample code is as follows: + +``` +#include +#include +#include "sys/stat.h" +#include "fcntl.h" +#include "unistd.h" + +#define LOS_OK 0 +#define LOS_NOK -1 + +int FatfsTest(void) +{ + int ret; + int fd = -1; + ssize_t len; + off_t off; + char dirName[20] = "user/test"; + char fileName[20] = "user/test/file.txt"; + char writeBuf[20] = "Hello OpenHarmony!"; + char readBuf[20] = {0}; + + /* Create the user/test directory.*/ + ret = mkdir(dirName, 0777); + if (ret != LOS_OK) { + printf("mkdir failed.\n"); + return LOS_NOK; + } + + /* Create the file user/test/file.txt and make it readable and writable.*/ + fd = open(fileName, O_RDWR | O_CREAT, 0777); + if (fd < 0) { + printf("open file failed.\n"); + return LOS_NOK; + } + + /* Write the content from writeBuf to the file. */ + len = write(fd, writeBuf, strlen(writeBuf)); + if (len != strlen(writeBuf)) { + printf("write file failed.\n"); + return LOS_NOK; + } + + /* Save the update of the file to the device.*/ + ret = fsync(fd); + if (ret != LOS_OK) { + printf("fsync failed.\n"); + return LOS_NOK; + } + + /* Move the read/write pointer to the file header. */ + off = lseek(fd, 0, SEEK_SET); + if (off != 0) { + printf("lseek failed.\n"); + return LOS_NOK; + } + + /* Read the file content, with the same size as readBuf, to readBuf.*/ + len = read(fd, readBuf, sizeof(readBuf)); + if (len != strlen(writeBuf)) { + printf("read file failed.\n"); + return LOS_NOK; + } + printf("%s\n", readBuf); + + /* Close the file. */ + ret = close(fd); + if (ret != LOS_OK) { + printf("close failed.\n"); + return LOS_NOK; + } + + /*Delete the file user/test/file.txt.*/ + ret = unlink(fileName); + if (ret != LOS_OK) { + printf("unlink failed.\n"); + return LOS_NOK; + } + + /*Delete the user/test directory.*/ + ret = rmdir(dirName); + if (ret != LOS_OK) { + printf("rmdir failed.\n"); + return LOS_NOK; + } + + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +Hello OpenHarmony! +``` + diff --git a/en/device-dev/kernel/kernel-mini-extend-file-lit.md b/en/device-dev/kernel/kernel-mini-extend-file-lit.md new file mode 100644 index 0000000000000000000000000000000000000000..ed34604fff4ed615677cf835600e7596029824c0 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-file-lit.md @@ -0,0 +1,7 @@ +# LittleFS + +- **[Basic Concepts](kernel-mini-extend-file-littlefs-basic.md)** + +- **[Development Guidelines](kernel-mini-extend-file-littlefs-guide.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-extend-file-littlefs-basic.md b/en/device-dev/kernel/kernel-mini-extend-file-littlefs-basic.md new file mode 100644 index 0000000000000000000000000000000000000000..b794e8bbed5a7ecbfad8db30c45bdca13f4b638c --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-file-littlefs-basic.md @@ -0,0 +1,6 @@ +# Basic Concepts + +LittleFS is a small file system designed for flash. By combining the log-structured file system and the copy-on-write \(COW\) file system, LittleFS stores metadata in log structure and data in the COW structure. This special storage empowers LittleFS high power-loss resilience. LittleFS uses the statistical wear leveling algorithm when allocating COW data blocks, effectively prolonging the service life of flash devices. LittleFS is designed for small-sized devices with limited resources, such as ROM and RAM. All RAM resources are allocated through a buffer with the fixed size \(configurable\). That is, the RAM usage does not grow with the file system. + +LittleFS is a good choice when you look for a flash file system that is power-cut resilient and has wear leveling support on a small device with limited resources. + diff --git a/en/device-dev/kernel/kernel-mini-extend-file-littlefs-guide.md b/en/device-dev/kernel/kernel-mini-extend-file-littlefs-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..02df1a0dab78b18e948956ae9ede4177f05a322f --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-file-littlefs-guide.md @@ -0,0 +1,72 @@ +# Development Guidelines + +- [Sample Code](#section1034515054620) + +When porting LittleFS to a new hardware device, you need to declare **lfs\_config**: + +``` +const struct lfs_config cfg = { + // block device operations + .read = user_provided_block_device_read, + .prog = user_provided_block_device_prog, + .erase = user_provided_block_device_erase, + .sync = user_provided_block_device_sync, + + // block device configuration + .read_size = 16, + .prog_size = 16, + .block_size = 4096, + .block_count = 128, + .cache_size = 16, + .lookahead_size = 16, + .block_cycles = 500, +}; +``` + +**.read**, **.prog**, **.erase**, and **.sync** correspond to the read, write, erase, and synchronization APIs at the bottom layer of the hardware platform, respectively. + +**read\_size** indicates the number of bytes read each time. You can set it to a value greater than the physical read unit to improve performance. This value determines the size of the read cache. However, if the value is too large, more memory is consumed. + +**prog\_size** indicates the number of bytes written each time. You can set it to a value greater than the physical write unit to improve performance. This value determines the size of the write cache and must be an integral multiple of **read\_size**. However, if the value is too large, more memory is consumed. + +**block\_size**: indicates the number of bytes in each erase block. The value can be greater than that of the physical erase unit. However, a smaller value is recommended because each file occupies at least one block. The value must be an integral multiple of **prog\_size**. + +**block\_count** indicates the number of blocks that can be erased, which depends on the capacity of the block device and the size of the block to be erased \(**block\_size**\). + +## Sample Code + +The sample code is as follows: + +``` +int main(void) { + // mount the filesystem + int err = lfs_mount(&lfs, &cfg); + + // reformat if we can't mount the filesystem + // this should only happen on the first boot + if (err) { + lfs_format(&lfs, &cfg); + lfs_mount(&lfs, &cfg); + } + + // read current count + uint32_t boot_count = 0; + lfs_file_open(&lfs, &file, "boot_count", LFS_O_RDWR | LFS_O_CREAT); + lfs_file_read(&lfs, &file, &boot_count, sizeof(boot_count)); + + // update boot count + boot_count += 1; + lfs_file_rewind(&lfs, &file); + lfs_file_write(&lfs, &file, &boot_count, sizeof(boot_count)); + + // remember the storage is not updated until the file is closed successfully + lfs_file_close(&lfs, &file); + + // release any resources we were using + lfs_unmount(&lfs); + + // print the boot count + printf("boot_count: %d\n", boot_count); +} +``` + diff --git a/en/device-dev/kernel/kernel-mini-extend-file.md b/en/device-dev/kernel/kernel-mini-extend-file.md new file mode 100644 index 0000000000000000000000000000000000000000..91bac1858ac843bff626d5df128c3ec8f7891371 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-file.md @@ -0,0 +1,204 @@ +# File System + +The OpenHarmony LiteOS-M kernel supports the FAT file system \(FATFS\) and LittleFS. [Table 1](#table147491853163018) lists the comparison of the functions supported by these two file systems. + +**Table 1** Function list + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

FATFS

+

LittleFS

+

File management

+

open

+

Opens a file.

+

Supported

+

Supported

+

close

+

Closes a file.

+

Supported

+

Supported

+

read

+

Reads a file.

+

Supported

+

Supported

+

write

+

Writes data to a file.

+

Supported

+

Supported

+

lseek

+

Sets the file offset.

+

Supported

+

Supported

+

unlink

+

Deletes a file.

+

Supported

+

Supported

+

rename

+

Renames a file.

+

Supported

+

Supported

+

fstat

+

Obtains file information based on the file handle.

+

Supported

+

Supported

+

stat

+

Obtains file information based on the file path name.

+

Supported

+

Supported

+

fsync

+

Saves file updates to a storage device.

+

Supported

+

Supported

+

Directory management

+

mkdir

+

Creates a directory.

+

Supported

+

Supported

+

opendir

+

Opens a directory.

+

Supported

+

Supported

+

readdir

+

Reads the content of a directory.

+

Supported

+

Supported

+

closedir

+

Closes a directory.

+

Supported

+

Supported

+

rmdir

+

Deletes a directory.

+

Supported

+

Supported

+

Partition management

+

mount

+

Mounts a partition.

+

Supported

+

Supported

+

umount

+

Unmounts a partition.

+

Supported

+

Supported

+

umount2

+

Forcibly unmounts a partition using the MNT_FORCE parameter.

+

Supported

+

Not supported

+

statfs

+

Obtains partition information.

+

Supported

+

Not supported

+
+ +- **[FAT](kernel-mini-extend-file-fat.md)** + +- **[LittleFS](kernel-mini-extend-file-lit.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-extend-support.md b/en/device-dev/kernel/kernel-mini-extend-support.md new file mode 100644 index 0000000000000000000000000000000000000000..fd650f391fb89fc7522bb30dc83888459ac581c8 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend-support.md @@ -0,0 +1,85 @@ +# C++ Support + +- [Basic Concepts](#section11374125415814) +- [Working Principles](#section189351319134418) +- [Development Guidelines](#section166302407911) + - [Available APIs](#section1881825119919) + - [How to Develop](#section76371145108) + - [Development Example](#section994427141111) + + +## Basic Concepts + +As one of the most widely used programming languages, C++ supports features, such as classes, encapsulation, and overloading. It is an object-oriented programming language developed based on the C language. + +## Working Principles + +The compiler supports C++ code identification. The system calls the constructors of global objects to perform initialization operations. + +## Development Guidelines + +### Available APIs + +**Table 1** APIs supported by C++ + + + + + + + + + + + + +

Category

+

API

+

Description

+

Prerequisites for using C++ features

+

LOS_CppSystemInit

+

Initializes C++ constructors.

+
+ +### How to Develop + +Before using C++ features, you need to call **LOS\_CppSystemInit** to initialize C++ constructors. The initialized constructors are stored in the **init\_array** section, and the section range is passed by the variables **\_\_init\_array\_start\_\_** and **\_\_init\_array\_end\_\_**. + +**Table 2** Parameter description + + + + + + + + + + + + + +

Parameter

+

Description

+

__init_array_start__

+

Start of the init_array section

+

__init_array_end__

+

End of the init_array section

+
+ +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>The **LOS\_CppSystemInit** function must be called before a C++ service. When the C library used by the third-party compiler is not musl libc, some classes or APIs \(such as **std::thread** and **std::mutex**\) that are closely related to system resources have compatibility issues and are not recommended to use. + +### Development Example + +``` +void app_init(void) +{ +...... +/* Initialize C++ in the startup phase. */ +LOS_CppSystemInit((UINTPTR)&__init_array_start__, (UINTPTR)&__init_array_end__); +/* C++ service */ +...... +} +``` + diff --git a/en/device-dev/kernel/kernel-mini-extend.md b/en/device-dev/kernel/kernel-mini-extend.md new file mode 100644 index 0000000000000000000000000000000000000000..605a1b425bd4890b5d92dda9369b5fe3cb9b98ee --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-extend.md @@ -0,0 +1,11 @@ +# Extension Components + +- **[C++ Support](kernel-mini-extend-support.md)** + +- **[CPUP](kernel-mini-extend-cpup.md)** + +- **[Dynamic Loading](kernel-mini-extend-dynamic-loading.md)** + +- **[File System](kernel-mini-extend-file.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-imemory-debug-det.md b/en/device-dev/kernel/kernel-mini-imemory-debug-det.md new file mode 100644 index 0000000000000000000000000000000000000000..404ab37e196190d44dd169d27325feaec003ff2f --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-imemory-debug-det.md @@ -0,0 +1,128 @@ +# Memory Leak Check + +- [Basic Concepts](#section1026719436293) +- [Function Configuration](#section13991354162914) +- [Development Guidelines](#section95828159308) + - [How to Develop](#section369844416304) + - [Development Example](#section460801313313) + - [Sample Code](#section96539275311) + - [Verification](#section20527343183119) + + +## Basic Concepts + +As an optional function of the kernel, memory leak check is used to locate dynamic memory leak problems. After this function is enabled, the dynamic memory automatically records the link registers \(LRs\) used when memory is allocated. If a memory leak occurs, the recorded information helps locate the memory allocated for further analysis. + +## Function Configuration + +1. **LOSCFG\_MEM\_LEAKCHECK**: specifies the setting of the memory leak check. This function is disabled by default. To enable the function, set this macro to **1** in **target\_config.h**. +2. **LOSCFG\_MEM\_RECORD\_LR\_CNT**: number of LRs recorded. The default value is **3**. Each LR consumes the memory of **sizeof\(void \*\)** bytes. +3. **LOSCFG\_MEM\_OMIT\_LR\_CNT**: number of ignored LRs. The default value is **4**, which indicates that LRs are recorded from the time when **LOS\_MemAlloc** is called. You can change the value based on actual requirements. This macro is configured because: + - **LOS\_MemAlloc** is also called internally. + - **LOS\_MemAlloc** may be encapsulated externally. + - The number of LRs configured by **LOSCFG\_MEM\_RECORD\_LR\_CNT** is limited. + + +Correctly setting this macro can ignore invalid LRs and reduce memory consumption. + +## Development Guidelines + +### How to Develop + +Memory leak check provides a method to check for memory leak in key code logic. If this function is enabled, LR information is recorded each time when memory is allocated. When **LOS\_MemUsedNodeShow** is called before and after the code snippet is checked, information about all nodes that have been used in the specified memory pool is printed. You can compare the node information. The newly added node information indicates the node where the memory leak may occur. You can locate the code based on the LR and further check whether a memory leak occurs. + +The node information output by calling **LOS\_MemUsedNodeShow** is in the following format: Each line contains information about a node. The first column indicates the node address, based on which you can obtain complete node information using a tool such as a GNU Debugger \(GDB\). The second column indicates the node size, which is equal to the node header size plus the data field size. Columns 3 to 5 list the LR addresses. You can determine the specific memory location of the node based on the LR addresses and the assembly file. + +``` +node size LR[0] LR[1] LR[2] +0x10017320: 0x528 0x9b004eba 0x9b004f60 0x9b005002 +0x10017848: 0xe0 0x9b02c24e 0x9b02c246 0x9b008ef0 +0x10017928: 0x50 0x9b008ed0 0x9b068902 0x9b0687c4 +0x10017978: 0x24 0x9b008ed0 0x9b068924 0x9b0687c4 +0x1001799c: 0x30 0x9b02c24e 0x9b02c246 0x9b008ef0 +0x100179cc: 0x5c 0x9b02c24e 0x9b02c246 0x9b008ef0 +``` + +>![](../public_sys-resources/icon-caution.gif) **CAUTION:** +>Enabling memory leak check affects memory application performance. LR addresses will be recorded for each memory node, increasing memory overhead. + +### Development Example + +This example implements the following: + +1. Calls **LOS\_MemUsedNodeShow** to print information about all nodes. +2. Simulates a memory leak by requesting memory without releasing it. +3. Calls **LOS\_MemUsedNodeShow** to print information about all nodes. +4. Compare the logs to obtain information about the node where a memory leak occurred. +5. Locate the code based on the LR address. + +### Sample Code + +The sample code is as follows: + +``` +#include +#include +#include "los_memory.h" +#include "los_config.h" + +void MemLeakTest(void) +{ + LOS_MemUsedNodeShow(LOSCFG_SYS_HEAP_ADDR); + void *ptr1 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); + void *ptr2 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); + LOS_MemUsedNodeShow(LOSCFG_SYS_HEAP_ADDR); +} +``` + +### Verification + +The log is as follows: + +``` +node size LR[0] LR[1] LR[2] +0x20001b04: 0x24 0x08001a10 0x080035ce 0x080028fc +0x20002058: 0x40 0x08002fe8 0x08003626 0x080028fc +0x200022ac: 0x40 0x08000e0c 0x08000e56 0x0800359e +0x20002594: 0x120 0x08000e0c 0x08000e56 0x08000c8a +0x20002aac: 0x56 0x08000e0c 0x08000e56 0x08004220 + +node size LR[0] LR[1] LR[2] +0x20001b04: 0x24 0x08001a10 0x080035ce 0x080028fc +0x20002058: 0x40 0x08002fe8 0x08003626 0x080028fc +0x200022ac: 0x40 0x08000e0c 0x08000e56 0x0800359e +0x20002594: 0x120 0x08000e0c 0x08000e56 0x08000c8a +0x20002aac: 0x56 0x08000e0c 0x08000e56 0x08004220 +0x20003ac4: 0x1d 0x08001458 0x080014e0 0x080041e6 +0x20003ae0: 0x1d 0x080041ee 0x08000cc2 0x00000000 +``` + +The difference between the two logs is as follows. The following memory nodes are suspected to have blocks with a memory leak. + +``` +0x20003ac4: 0x1d 0x08001458 0x080014e0 0x080041e6 +0x20003ae0: 0x1d 0x080041ee 0x08000cc2 0x00000000 +``` + +The following is part of the assembly file: + +``` + MemLeakTest: + 0x80041d4: 0xb510 PUSH {R4, LR} + 0x80041d6: 0x4ca8 LDR.N R4, [PC, #0x2a0] ; g_memStart + 0x80041d8: 0x0020 MOVS R0, R4 + 0x80041da: 0xf7fd 0xf93e BL LOS_MemUsedNodeShow ; 0x800145a + 0x80041de: 0x2108 MOVS R1, #8 + 0x80041e0: 0x0020 MOVS R0, R4 + 0x80041e2: 0xf7fd 0xfbd9 BL LOS_MemAlloc ; 0x8001998 + 0x80041e6: 0x2108 MOVS R1, #8 + 0x80041e8: 0x0020 MOVS R0, R4 + 0x80041ea: 0xf7fd 0xfbd5 BL LOS_MemAlloc ; 0x8001998 + 0x80041ee: 0x0020 MOVS R0, R4 + 0x80041f0: 0xf7fd 0xf933 BL LOS_MemUsedNodeShow ; 0x800145a + 0x80041f4: 0xbd10 POP {R4, PC} + 0x80041f6: 0x0000 MOVS R0, R0 +``` + +The memory node addressed by **0x080041ee** is not released after being requested in **MemLeakTest**. + diff --git a/en/device-dev/kernel/kernel-mini-memory-debug-cet.md b/en/device-dev/kernel/kernel-mini-memory-debug-cet.md new file mode 100644 index 0000000000000000000000000000000000000000..04948fdabf3570a69968794e037da3753a13d312 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-memory-debug-cet.md @@ -0,0 +1,85 @@ +# Memory Corruption Check + +- [Basic Concepts](#section17368154517335) +- [Function Configuration](#section4696190123420) +- [Development Guidelines](#section672362973417) + - [How to Develop](#section026014863416) + - [Development Example](#section186311302356) + - [Sample Code](#section12709533354) + - [Verification](#section81214126369) + + +## Basic Concepts + +As an optional function of the kernel, memory corruption check is used to check the integrity of a dynamic memory pool. This mechanism can detect memory corruption errors in the memory pool in a timely manner and provide alerts. It helps reduce problem locating costs and increase troubleshooting efficiency. + +## Function Configuration + +**LOSCFG\_BASE\_MEM\_NODE\_INTEGRITY\_CHECK**: specifies the setting of the memory corruption check. This function is disabled by default. To enable the function, set this macro to **1** in **target\_config.h**. + +1. If this macro is enabled, the memory pool integrity will be checked in real time upon each memory allocation. +2. If this macro is not enabled, you can call **LOS\_MemIntegrityCheck** to check the memory pool integrity when required. Using **LOS\_MemIntegrityCheck** does not affect the system performance. In addition, the check accuracy decreases because the node header does not contain the magic number \(which is available only when **LOSCFG\_BASE\_MEM\_NODE\_INTEGRITY\_CHECK** is enabled\). + +This check only detects the corrupted memory node and provides information about the previous node \(because memory is contiguous, a node is most likely corrupted by the previous node\). To further determine the location where the previous node is requested, you need to enable the memory leak check and use LRs to locate the fault. + +>![](../public_sys-resources/icon-caution.gif) **CAUTION:** +>If memory corruption check is enabled, a magic number is added to the node header, which increases the size of the node header. The real-time integrity check has a great impact on the performance. In performance-sensitive scenarios, you are advised to disable this function and use **LOS\_MemIntegrityCheck** to check the memory pool integrity. + +## Development Guidelines + +### How to Develop + +Check for memory corruption by calling **LOS\_MemIntegrityCheck**. If no memory corruption occurs, **0** is returned and no log is output. If memory corruption occurs, related log is output. For details, see the output of the following example. + +### Development Example + +This example implements the following: + +1. Requests two physically adjacent memory blocks. +2. Calls **memset** to construct an out-of-bounds access and overwrites the first four bytes of the next node. +3. Calls **LOS\_MemIntegrityCheck** to check whether memory corruption occurs. + +### Sample Code + +The sample code is as follows: + +``` +#include +#include +#include "los_memory.h" +#include "los_config.h" + +void MemIntegrityTest(void) +{ + /* Request two physically adjacent memory blocks.*/ + void *ptr1 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); + void *ptr2 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); + /* Construct an out-of-bounds access to cause memory corruption. The memory block of the first node is 8 bytes. Clearing 12 bytes overwrites the header of the second memory node. */ + memset(ptr1, 0, 8 + 4); + LOS_MemIntegrityCheck(LOSCFG_SYS_HEAP_ADDR); +} +``` + +### Verification + +The log is as follows: + +``` +[ERR][OsMemMagicCheckPrint], 2028, memory check error! +memory used but magic num wrong, magic num = 0x00000000 /* Error information, indicating that the first four bytes, that is, the magic number, of the next node are corrupted.*/ + + broken node head: 0x20003af0 0x00000000 0x80000020, prev node head: 0x20002ad4 0xabcddcba 0x80000020 +/* Key information about the corrupted node and its previous node, including the address of the previous node, magic number of the node, and sizeAndFlag of the node. In this example, the magic number of the corrupted node is cleared. */ + + broken node head LR info: /* The node LR information can be output only after the memory leak check is enabled.*/ + LR[0]:0x0800414e + LR[1]:0x08000cc2 + LR[2]:0x00000000 + + pre node head LR info: /* Based on the LR information, you can find where the previous node is requested in the assembly file and then perform further analysis.*/ + LR[0]:0x08004144 + LR[1]:0x08000cc2 + LR[2]:0x00000000 +[ERR]Memory interity check error, cur node: 0x20003b10, pre node: 0x20003af0 /* Addresses of the corrupted node and its previous node*/ +``` + diff --git a/en/device-dev/kernel/kernel-mini-memory-debug-mes.md b/en/device-dev/kernel/kernel-mini-memory-debug-mes.md new file mode 100644 index 0000000000000000000000000000000000000000..dfb48d549593e5ac47e50361e045ae6e7553fc94 --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-memory-debug-mes.md @@ -0,0 +1,116 @@ +# Memory Information Statistics + +- [Basic Concepts](#section52691565235) +- [Function Configuration](#section470611682411) +- [Development Guidelines](#section9368374243) + - [How to Develop](#section679912407257) + - [Development Example](#section1025453412611) + - [Sample Code](#section165277971315) + - [Verification](#section3460102414271) + + +## Basic Concepts + +Memory information includes the memory pool size, memory usage, remaining memory size, maximum free memory, memory waterline, number of memory nodes, and fragmentation rate. + +- Memory waterline: indicates the maximum memory used in a memory pool. The waterline value is updated upon each memory allocation and release. The memory pool size can be optimized based on this value. + +- Fragmentation rate: indicates the fragmentation degree of the memory pool. If the fragmentation rate is high, there are a large number of free memory blocks in the memory pool but each block is small. You can use the following formula to calculate the fragmentation rate: + + Fragmentation rate = 100 – 100 x Maximum free memory block size/Remaining memory size + + +- Other parameters: You can call APIs \(described in [Memory Management](kernel-mini-basic-memory-basic.md)\) to scan node information in the memory pool and collect statistics. + +## Function Configuration + +**LOSCFG\_MEM\_WATERLINE**: specifies the setting of the memory information statistics function. This function is enabled by default. To disable the function, set this macro to **0** in **target\_config.h**. If you want to obtain the memory waterline, you must enable this macro. + +## Development Guidelines + +### How to Develop + +Key structure: + +``` +typedef struct { + UINT32 totalUsedSize; // Memory usage of the memory pool + UINT32 totalFreeSize; // Remaining memory in the memory pool + UINT32 maxFreeNodeSize; // Maximum size of the free memory block in the memory pool + UINT32 usedNodeNum; // Number of non-free memory blocks in the memory pool + UINT32 freeNodeNum; // Number of free memory blocks in the memory pool +#if (LOSCFG_MEM_WATERLINE == 1) // This macro is enabled by default. To disable it, set it to 0 in target_config.h. + UINT32 usageWaterLine; // Waterline of the memory pool +#endif +} LOS_MEM_POOL_STATUS; +``` + +- To obtain the memory waterline, call **LOS\_MemInfoGet**. The first parameter in the API is the start address of the memory pool, and the second parameter is the handle of the **LOS\_MEM\_POOL\_STATUS** type. The **usageWaterLine** field indicates the waterline. + +- To calculate the memory fragmentation rate, call **LOS\_MemInfoGet** to obtain the remaining memory size and the maximum free memory block size in the memory pool, and then calculate the fragmentation rate of the dynamic memory pool as follows: + + Fragmentation rate = 100 – 100 x Maximum free memory block size/Remaining memory size + + +### Development Example + +This example implements the following: + +1. Creates a monitoring thread to obtain information about the memory pool. + +2. Calls **LOS\_MemInfoGet** to obtain the basic information about the memory pool. + +3. Calculates the memory usage and fragmentation rate. + +### Sample Code + +The sample code is as follows: + +``` +#include +#include +#include "los_task.h" +#include "los_memory.h" +#include "los_config.h" + +void MemInfoTaskFunc(void) +{ + LOS_MEM_POOL_STATUS poolStatus = {0}; + + /* pool is the memory address of the information to be collected. OS_SYS_MEM_ADDR is used as an example.*/ + void *pool = OS_SYS_MEM_ADDR; + LOS_MemInfoGet(pool, &poolStatus); + /* Calculate the fragmentation rate of the memory pool. */ + unsigned char fragment = 100 - poolStatus.maxFreeNodeSize * 100 / poolStatus.totalFreeSize; + /* Calculate the memory usage of the memory pool. */ + unsigned char usage = LOS_MemTotalUsedGet(pool) * 100 / LOS_MemPoolSizeGet(pool); + printf("usage = %d, fragment = %d, maxFreeSize = %d, totalFreeSize = %d, waterLine = %d\n", usage, fragment, poolStatus.maxFreeNodeSize, + poolStatus.totalFreeSize, poolStatus.usageWaterLine); +} + +int MemTest(void) +{ + unsigned int ret; + unsigned int taskID; + TSK_INIT_PARAM_S taskStatus = {0}; + taskStatus.pfnTaskEntry = (TSK_ENTRY_FUNC)MemInfoTaskFunc; + taskStatus.uwStackSize = 0x1000; + taskStatus.pcName = "memInfo"; + taskStatus.usTaskPrio = 10; + ret = LOS_TaskCreate(&taskID, &taskStatus); + if (ret != LOS_OK) { + printf("task create failed\n"); + return -1; + } + return 0; +} +``` + +### Verification + +The result is as follows: + +``` +usage = 22, fragment = 3, maxFreeSize = 49056, totalFreeSize = 50132, waterLine = 1414 +``` + diff --git a/en/device-dev/kernel/kernel-mini-memory-debug.md b/en/device-dev/kernel/kernel-mini-memory-debug.md new file mode 100644 index 0000000000000000000000000000000000000000..23495e1b92221cc3e8dd0565a6a001455acbed5c --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-memory-debug.md @@ -0,0 +1,11 @@ +# Memory Debugging + +The purpose of memory debugging is to locate problems related to dynamic memory. The kernel provides a variety of memory debugging methods. Dynamic memory pool statistics helps you learn the memory pool waterline and fragmentation rate. Memory leak check helps you accurately locate the code where memory leak occurs and analyze the memory usage of each module. Memory corruption check helps you locate memory corruptions. + +- **[Memory Information Statistics](kernel-mini-memory-debug-mes.md)** + +- **[Memory Leak Check](kernel-mini-imemory-debug-det.md)** + +- **[Memory Corruption Check](kernel-mini-memory-debug-cet.md)** + + diff --git a/en/device-dev/kernel/kernel-mini-memory-exception.md b/en/device-dev/kernel/kernel-mini-memory-exception.md new file mode 100644 index 0000000000000000000000000000000000000000..a78a58604d57d4f40058eaeb00f2489302d1c36d --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-memory-exception.md @@ -0,0 +1,329 @@ +# Exception Debugging + +- [Basic Concepts](#section2741911123412) +- [Working Principles](#section16618124317346) +- [Available APIs](#section16111931351) +- [Usage Guidelines](#section16317163520350) + - [How to Develop](#section13457839133618) + - [How to Locate Exceptions](#section197332323815) + + +## Basic Concepts + +The OpenHarmony LiteOS-M provides exception handling and debugging measures to help locate and analyze problems. Exception handling involves a series of actions taken by the OS to respond to exceptions occurred during the OS running, for example, printing the exception type, system status, call stack information of the current function, CPU information, and call stack information of tasks. + +## Working Principles + +A stack frame contains information such as function parameters, variables, and return value in a function call process. When a function is called, a stack frame of the subfunction is created, and the input parameters, local variables, and registers of the function are stored into the stack. Stack frames grow towards lower addresses. The ARM32 CPU architecture is used as an example. Each stack frame stores the historical values of the program counter \(PC\), LR \(link register\), stack pointer \(SP\), and frame pointer \(FP\) registers. The LR points to the return address of a function, and the FP points to the start address of the stack frame of the function's parent function. The FP helps locate the parent function's stack frame, which further helps locate the parent function's FP. The parent function's FP helps locate the grandparent function's stack frame and FP... In this way, the call stack of the program can be traced to obtain the relationship between the functions called. + +When an exception occurs in the system, the system prints the register information in the stack frame of the abnormal function as well as the LRs and FPs in the stack frames of its parent function and grandfather function. The relationships between the functions help you locate the cause of the exception. + +The following figure illustrates the stack analysis mechanism for your reference. The actual stack information varies depending on the CPU architecture. + +**Figure 1** Stack analysis mechanism +![](figure/stack-analysis-mechanism.png "stack-analysis-mechanism") + +In the figure, the registers in different colors indicate different functions. The registers save related data when functions are called. The FP register helps track the stack to the parent function of the abnormal function and further presents the relationships between the functions called. + +## Available APIs + +The following table describes APIs available for the OpenHarmony LiteOS-M stack trace module. For more details about the APIs, see the API reference. + +**Table 1** APIs of the stack trace module + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Stack trace

+

LOS_BackTrace

+

Prints the call stack relationship at the function calling point.

+

LOS_RecordLR

+

Obtains the call stack relationship at the function calling point when print is unavailable.

+
+ +## Usage Guidelines + +### How to Develop + +The typical process for enabling exception debugging is as follows: + +1. Configure the macros related to exception handling. + + Modify the configuration in the **target\_config.h** file. + + + + + + + + + + + + + + + + +

Parameter

+

Description

+

Value

+

LOSCFG_BACKTRACE_DEPTH

+

Depth of the function call stack. The default value is 15.

+

15

+

LOSCFG_BACKTRACE_TYPE

+

Type of the stack trace.

+

0: disabled

+

1: supports function call stack analysis of the Cortex-m series hardware.

+

2: supports function call stack analysis of the RISC-V series hardware.

+

Set this parameter to 1 or 2 based on the toolchain type.

+
+ + +1. Use the error code in the example to build and run a project, and check the error information displayed on the serial port terminal. The sample code simulates error code. During actual product development, use the exception debugging mechanism to locate exceptions. + + The following example demonstrates the exception output through a task. The task entry function simulates calling of multiple functions and finally calls a function that simulates an exception. The sample code is as follows: + + ``` + #include + #include "los_config.h" + #include "los_interrupt.h" + #include "los_task.h" + + UINT32 g_taskExcId; + #define TSK_PRIOR 4 + + /* Simulate an abnormal function. */ + + UINT32 Get_Result_Exception_0(UINT16 dividend){ + UINT32 divisor = 0; + UINT32 result = dividend / divisor; + return result; + } + + UINT32 Get_Result_Exception_1(UINT16 dividend){ + return Get_Result_Exception_0(dividend); + } + + UINT32 Get_Result_Exception_2(UINT16 dividend){ + return Get_Result_Exception_1(dividend); + } + + UINT32 Example_Exc(VOID) + { + UINT32 ret; + + printf("Enter Example_Exc Handler.\r\n"); + + /* Simulate the function calling. */ + ret = Get_Result_Exception_2(TSK_PRIOR); + printf("Divided result =%u.\r\n", ret); + + printf("Exit Example_Exc Handler.\r\n"); + return ret; + } + + + /* Task entry function used to create a task with an exception. */ + UINT32 Example_Exc_Entry(VOID) + { + UINT32 ret; + TSK_INIT_PARAM_S initParam; + + /* Lock task scheduling to prevent newly created tasks from being scheduled prior to this task due to higher priority.*/ + LOS_TaskLock(); + + printf("LOS_TaskLock() Success!\r\n"); + + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_Exc; + initParam.usTaskPrio = TSK_PRIOR; + initParam.pcName = "Example_Exc"; + initParam.uwStackSize = LOSCFG_SECURE_STACK_DEFAULT_SIZE; + /* Create a task with higher priority. The task will not be executed immediately after being created, because task scheduling is locked.*/ + ret = LOS_TaskCreate(&g_taskExcId, &initParam); + if (ret != LOS_OK) { + LOS_TaskUnlock(); + + printf("Example_Exc create Failed!\r\n"); + return LOS_NOK; + } + + printf("Example_Exc create Success!\r\n"); + + /* Unlock task scheduling. The task with the highest priority in the Ready queue will be executed.*/ + LOS_TaskUnlock(); + + return LOS_OK; + } + ``` + + +1. The error information displayed on the serial port terminal is as follows: + + ``` + entering kernel init... + LOS_TaskLock() Success! + Example_Exc create Success! + Entering scheduler + Enter Example_Exc Handler. + *************Exception Information************** + Type = 10 + ThrdPid = 4 + Phase = exc in task + FaultAddr = 0xabababab + Current task info: + Task name = Example_Exc + Task ID = 4 + Task SP = 0x200051ac + Task ST = 0x20004ff0 + Task SS = 0x200 + Exception reg dump: + PC = 0x80037da + LR = 0x80037fe + SP = 0x20005190 + R0 = 0x4 + R1 = 0x40 + R2 = 0x4 + R3 = 0x0 + R4 = 0x4040404 + R5 = 0x5050505 + R6 = 0x6060606 + R7 = 0x20005190 + R8 = 0x8080808 + R9 = 0x9090909 + R10 = 0x10101010 + R11 = 0x11111111 + R12 = 0x12121212 + PriMask = 0x0 + xPSR = 0x41000000 + ----- backtrace start ----- + backtrace 0 -- lr = 0x800381a + backtrace 1 -- lr = 0x8003836 + backtrace 2 -- lr = 0x8005a4e + backtrace 3 -- lr = 0x8000494 + backtrace 4 -- lr = 0x8008620 + backtrace 5 -- lr = 0x800282c + backtrace 6 -- lr = 0x80008a0 + backtrace 7 -- lr = 0x80099f8 + backtrace 8 -- lr = 0x800a01a + backtrace 9 -- lr = 0x800282c + backtrace 10 -- lr = 0x80008a0 + backtrace 11 -- lr = 0x80099f8 + backtrace 12 -- lr = 0x8009bf0 + backtrace 13 -- lr = 0x8009c52 + backtrace 14 -- lr = 0x80099aa + ----- backtrace end ----- + + TID Priority Status StackSize WaterLine StackPoint TopOfStack EventMask SemID name + --- -------- -------- --------- ---------- ---------- ---------- --------- ----- ---- + 0 0 Pend 0x2d0 0x104 0x200029bc 0x200027f0 0x0 0xffff Swt_Task + 1 31 Ready 0x500 0x44 0x20002f84 0x20002ac8 0x0 0xffff IdleCore000 + 2 6 Ready 0x1000 0x44 0x20003f94 0x20002fd8 0x0 0xffff TaskSampleEntry1 + 3 7 Ready 0x1000 0x44 0x20004f9c 0x20003fe0 0x0 0xffff TaskSampleEntry2 + 4 4 Running 0x200 0xec 0x200051ac 0x20004ff0 0x0 0xffff Example_Exc + + OS exception NVIC dump: + interrupt enable register, base address: 0xe000e100, size: 0x20 + 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 + interrupt pending register, base address: 0xe000e200, size: 0x20 + 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 + interrupt active register, base address: 0xe000e300, size: 0x20 + 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 + interrupt priority register, base address: 0xe000e400, size: 0xf0 + 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 + 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 + 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 + 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 + interrupt exception register, base address: 0xe000ed18, size: 0xc + 0x0 0x0 0xf0f00000 + interrupt shcsr register, base address: 0xe000ed24, size: 0x4 + 0x70008 + interrupt control register, base address: 0xe000ed04, size: 0x4 + 0x400f806 + + memory pools check: + system heap memcheck over, all passed! + memory pool check end! + ``` + + +### How to Locate Exceptions + +The procedure for locating the exception is as follows: + +1. Open the image disassembly file \(.asm\) generated after compilation. If the file is not generated by default, use the objdump tool to generate it. Run the following command: + + ``` + arm-none-eabi-objdump -S -l XXX.elf + ``` + + +1. Search for the PC \(pointing to the instruction being executed\) in the ASM file to locate the abnormal function. + + The PC address directs to the instruction being executed when the exception occurs. In the ASM file corresponding to the currently executed binary file, search for the PC value **0x80037da** and locate the instruction being executed by the CPU. Disassemble the code as follows: + + ``` + UINT32 Get_Result_Exception_0(UINT16 dividend){ + 80037c8: b480 push {r7} + 80037ca: b085 sub sp, #20 + 80037cc: af00 add r7, sp, #0 + 80037ce: 4603 mov r3, r0 + 80037d0: 80fb strh r3, [r7, #6] + kernel_liteos_m\targets\cortex-m7_nucleo_f767zi_gcc/Core/Src/exc_example.c:10 + UINT32 divisor = 0; + 80037d2: 2300 movs r3, #0 + 80037d4: 60fb str r3, [r7, #12] + kernel_liteos_m\targets\cortex-m7_nucleo_f767zi_gcc/Core/Src/exc_example.c:11 + UINT32 result = dividend / divisor; + 80037d6: 88fa ldrh r2, [r7, #6] + 80037d8: 68fb ldr r3, [r7, #12] + 80037da: fbb2 f3f3 udiv r3, r2, r3 + 80037de: 60bb str r3, [r7, #8] + ``` + + +1. As indicated by the code: + 1. When the exception occurs, the CPU is executing **udiv r3, r2, r3**. The value of **r3** is **0**, which causes the divide-by-zero error. + 2. The exception occurs in the **Get\_Result\_Exception\_0** function. + +2. Locate the parent function of the abnormal function based on the LR value. + + The code disassembly of the LR value **0x80037fe** is as follows: + + ``` + 080037ec : + Get_Result_Exception_1(): + kernel_liteos_m\targets\cortex-m7_nucleo_f767zi_gcc/Core/Src/exc_example.c:15 + UINT32 Get_Result_Exception_1(UINT16 dividend){ + 80037ec: b580 push {r7, lr} + 80037ee: b082 sub sp, #8 + 80037f0: af00 add r7, sp, #0 + 80037f2: 4603 mov r3, r0 + 80037f4: 80fb strh r3, [r7, #6] + kernel_liteos_m\targets\cortex-m7_nucleo_f767zi_gcc/Core/Src/exc_example.c:16 + return Get_Result_Exception_0(dividend); + 80037f6: 88fb ldrh r3, [r7, #6] + 80037f8: 4618 mov r0, r3 + 80037fa: f7ff ffe5 bl 80037c8 + 80037fe: 4603 mov r3, r0 + ``` + + +1. The previous line of LR **80037fe** is **bl 80037c8 **, which calls the abnormal function. The parent function that calls the abnormal function is **Get\_Result\_Exception\_1\(\)**. +2. Repeat [3](#li18973161743110) to analyze the LR values between **backtrace start** and **backtrace end** in the exception information to obtain the call stack relationship and find the exception cause. + diff --git a/en/device-dev/kernel/kernel-mini-memory-trace.md b/en/device-dev/kernel/kernel-mini-memory-trace.md new file mode 100644 index 0000000000000000000000000000000000000000..d73c715802e01e9fb9a4a4aeb4ce7dea686af35d --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-memory-trace.md @@ -0,0 +1,196 @@ +# Trace Debugging + +- [Basic Concepts](#section44851752123712) +- [Working Principles](#section5282148123813) +- [Available APIs](#section16304193215387) +- [Development Guidelines](#section498695853819) + - [How to Develop](#section1875652316393) + - [Development Example](#section0403134913395) + - [Sample Code](#section1492711418400) + - [Verification](#section869613984012) + + +## Basic Concepts + +Trace debugging helps you learn about the kernel running process and the execution sequence of modules and tasks. With the information, you can better understand the code running process of the kernel and locate time sequence problems. + +## Working Principles + +The kernel provides a framework to embed hooks in main processes of modules. You can register callback functions at the required hooks. When the kernel runs the corresponding process, the kernel proactively calls the **Hook** function to transfer key data of the current process to you. + +## Available APIs + +The following table describes APIs available for the OpenHarmony trace module. For more details about the APIs, see the API reference. + +**Table 1** Trace module APIs + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Registering a hook

+

LOS_HookReg

+

Registers a callback function at a specified hook.

+

Unregistering a hook

+

LOS_HookUnReg

+

Unregisters the callback function at the current hook.

+
+ +## Development Guidelines + +### How to Develop + +The typical process for enabling trace debugging is as follows: + +1. Configure the macros related to the trace module. + + Modify the configuration in the **target\_config.h** file. + + + + + + + + + + + + +

Parameter

+

Description

+

Value

+

LOSCFG_DEBUG_HOOK

+

Setting of the trace function

+

0: disable; 1: enable

+
+ +2. Select the hooks for registering callback functions. For details about the hook types, see **liteos\_m/utils/internal/los\_hook\_types.h**. +3. Call **LOS\_HookReg** to register functions. + +### Development Example + +This example invokes the malloc and free APIs to allocate and release memory of different sizes and records the malloc and free behavior and time sequence. + +### Sample Code + +The sample code is as follows: + +``` +#include "stdio.h" +#include "stdlib.h" +#include "string.h" +#include "los_hook.h" + +#define SIZE_512 512 +#define SIZE_1K 1024 +#define SIZE_2K 2048 + +/* Print the size of malloc when the callback function is invoked. */ +void MallocRecord(void *pool, unsigned int size) +{ + printf("malloc size = %u\n", size); + return; +} + +/* Print the free pointer address when the callback function is invoked. */ +void FreeRecord(void *pool, void *ptr) +{ + printf("free pool = 0x%x ptr = 0x%x\n", pool, ptr); + return; +} + +void TestTrace(void) +{ + char *pool1 = NULL; + char *pool2 = NULL; + char *pool3 = NULL; + char *retptr = NULL; + /* Allocate memory of different sizes to pool1, pool2, and pool3. */ + pool1 = (char *)malloc(SIZE_512); + if (pool1 == NULL) { + printf("pool1 malloc failed!\n"); + return; + } + retptr = memset(pool1, 'a', SIZE_512); + if (retptr == NULL) { + printf("pool1 memset failed!\n"); + return; + } + printf("pool1 addr = 0x%x *pool1[0] = %c\n", pool1, *pool1); + + pool2 = (char *)malloc(SIZE_1K); + if (pool2 == NULL) { + printf("pool2 malloc failed!\n"); + return; + } + retptr = memset(pool2, 'b', SIZE_1K); + if (retptr == NULL) { + printf("pool2 memset failed!\n"); + return; + } + printf("pool2 addr = 0x%x *pool2[0] = %c\n", pool2, *pool2); + + pool3 = (char *)malloc(SIZE_2K); + if (pool3 == NULL) { + printf("pool3 malloc failed!\n"); + return; + } + retptr = memset(pool3, 'c', SIZE_2K); + if (retptr == NULL) { + printf("pool3 memset failed!\n"); + return; + } + printf("pool3 addr = 0x%x *pool3[0] = %c\n", pool3, *pool3); + + /* Release pool3, pool1, and pool2 in sequence to check the time sequence of the callback functions. */ + free(pool3); + free(pool1); + free(pool2); + + return; +} +/* Before the trace module is used, callback functions are registered. Note that the return value of the callback functions is void. */ +void InitTest(void) +{ + printf("init hook\n"); + /* Register the hook based on the trace information to be obtained. For details about the hook types, see liteos_m/utils/internal/los_hook_types.h. */. + LOS_HookReg(LOS_HOOK_TYPE_MEM_ALLOC, MallocRecord); + LOS_HookReg(LOS_HOOK_TYPE_MEM_FREE, FreeRecord); + return; +} +``` + +### Verification + +The output is as follows: + +``` +init hook +malloc size = 512 +pool1 addr = 0x20002f44 *pool1[0] = a +malloc size = 1024 +pool2 addr = 0x2000314c *pool2[0] = b +malloc size = 2048 +pool3 addr = 0x20003554 *pool3[0] = c +free pool = 0x200002a4 ptr = 0x20003554 +free pool = 0x200002a4 ptr = 0x20002f44 +free pool = 0x200002a4 ptr = 0x2000314c +``` + +According to the address information, the sequence of free is pool3, pool1, and pool2. + diff --git a/en/device-dev/kernel/kernel-mini-overview.md b/en/device-dev/kernel/kernel-mini-overview.md new file mode 100644 index 0000000000000000000000000000000000000000..b0b7cb8328f7f47bee0d39d06a4ab3ad2cd8338a --- /dev/null +++ b/en/device-dev/kernel/kernel-mini-overview.md @@ -0,0 +1,67 @@ +# Kernel Overview + +- [Overview](#section1429342661510) + - [CPU Architecture Support](#section48891456112819) + - [Working Principles](#section4599142312817) + + +## Overview + +The OpenHarmony LiteOS-M kernel is a lightweight operating system \(OS\) kernel designed for the IoT field. It features small size, low power consumption, and high performance. The LiteOS-M kernel has simple code structure, including the minimum function set, kernel abstraction layer, optional components, and project directory. + +The OpenHarmony LiteOS-M kernel architecture consists of the hardware-related layer and the hardware-irrelevant layer, as shown in [Figure 1](#fig17231457191415). + +- The **Kernel arch** module belongs to the hardware-related layer. This module provides unified hardware abstraction layer \(HAL\) interfaces based on the compilation toolchain and chip architecture, improving hardware adaptability and meeting the expansion requirements of diversified AIoT hardware and compilation toolchains. +- **Components** and other modules belong to the hardware-irrelevant layer. Kernel modules, such as the task, provide basic capabilities. **Components** provide component capabilities, such as network and file system capabilities. **Utils** provides error handling and debugging capabilities. The Kernel Abstraction Layer \(**KAL**\) provides unified standard interfaces. + +**Figure 1** Kernel architecture +![](figure/kernel-architecture.png "kernel-architecture") + +### CPU Architecture Support + +The CPU architecture includes two layers: general architecture definition layer and specific architecture definition layer. The former provides interfaces supported and implemented by all architectures. The latter is specific to an architecture. For a new architecture to be added, the general architecture definition layer must be implemented first and the architecture-specific functions can be implemented at the specific architecture definition layer. + +**Table 1** CPU architecture rules + + + + + + + + + + + + + + + + + + + + +

Rule

+

General Architecture Definition Layer

+

Specific Architecture Definition Layer

+

Header file location

+

kernel/arch/include

+

kernel/arch/<arch>/<arch>/<toolchain>/

+

Header file name

+

los_<function>.h

+

los_arch_<function>.h

+

Function name

+

Halxxxx

+

Halxxxx

+
+ +LiteOS-M supports mainstream architectures, such as ARM Cortex-M3, ARM Cortex-M4, ARM Cortex-M7, ARM Cortex-M33, and RISC-V. If you need to expand the CPU architecture, see [Chip Architecture Adaptation](../porting/porting-chip-kernel-overview.md#section137431650339). + +### Working Principles + +Configure the system clock and number of ticks per second in the **target\_config.h** file of the development board. 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. For details, see [Figure 2](#fig19742101817344). + +**Figure 2** Kernel startup process +![](figure/kernel-startup-process.png "kernel-startup-process") + diff --git a/en/device-dev/kernel/kernel-small-apx-bitwise.md b/en/device-dev/kernel/kernel-small-apx-bitwise.md new file mode 100644 index 0000000000000000000000000000000000000000..38076b683907915c8417ad08d6ce4647c4ff6fae --- /dev/null +++ b/en/device-dev/kernel/kernel-small-apx-bitwise.md @@ -0,0 +1,125 @@ +# Bitwise Operation + +- [Basic Concepts](#section1990715203418) +- [Available APIs](#section848334511411) +- [Development Example](#section67569495514) + - [Example Description](#section33551554391) + - [Verification](#section8931859194) + + +## Basic Concepts + +A bitwise operation operates on a binary number at the level of its individual bits. For example, a variable can be set as a program PSW \(PSW\), and each bit \(flag bit\) in the PSW can have a self-defined meaning. + +## Available APIs + +The system provides operations for setting the flag bit to **1** or **0**, changing the flag bit content, and obtaining the most significant bit and least significant bit of the flag bit 1 in a PSW. You can also perform bitwise operations on system registers. The following table describes the APIs available for the bitwise operation module. For more details about the APIs, see the API reference. + +**Table 1** Bitwise operation module APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Setting the flag bit to 1 or 0

+

LOS_BitmapSet

+

Sets a flag bit of a PSW to 1.

+

LOS_BitmapClr

+

Sets a flag bit of a PSW to 0.

+

Obtaining the bit whose flag bit is 1

+

LOS_HighBitGet

+

Obtains the most significant bit of 1 in the PSW.

+

LOS_LowBitGet

+

Obtains the least significant bit of 1 in the PSW.

+

Operating continuous bits

+

LOS_BitmapSetNBits

+

Sets the continuous flag bits of a PSW to 1.

+

LOS_BitmapClrNBits

+

Sets the continuous flag bits of a PSW to 0.

+

LOS_BitmapFfz

+

Obtains the first 0 bit starting from the least significant bit (LSB).

+
+ +## Development Example + +### Example Description + +This example implements the following: + +1. Set a flag bit to **1**. +2. Obtain the most significant bit of flag bit 1. +3. Set a flag bit to **0**. +4. Obtains the least significant bit of the flag bit 1. + +``` +#include "los_bitmap.h" +#include "los_printf.h" + +static UINT32 BitSample(VOID) +{ + UINT32 flag = 0x10101010; + UINT16 pos; + + PRINTK("\nBitmap Sample!\n"); + PRINTK("The flag is 0x%8x\n", flag); + + pos = 8; + LOS_BitmapSet(&flag, pos); + PRINTK("LOS_BitmapSet:\t pos : %d, the flag is 0x%0+8x\n", pos, flag); + + pos = LOS_HighBitGet(flag); + PRINTK("LOS_HighBitGet:\t The highest one bit is %d, the flag is 0x%0+8x\n", pos, flag); + + LOS_BitmapClr(&flag, pos); + PRINTK("LOS_BitmapClr:\t pos : %d, the flag is 0x%0+8x\n", pos, flag); + + pos = LOS_LowBitGet(flag); + PRINTK("LOS_LowBitGet:\t The lowest one bit is %d, the flag is 0x%0+8x\n\n", pos, flag); + + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +Bitmap Sample! +The flag is 0x10101010 +LOS_BitmapSet: pos : 8, the flag is 0x10101110 +LOS_HighBitGet:The highest one bit is 28, the flag is 0x10101110 +LOS_BitmapClr: pos : 28, the flag is 0x00101110 +LOS_LowBitGet: The lowest one bit is 4, the flag is 0x00101110 +``` + diff --git a/en/device-dev/kernel/kernel-small-apx-dll.md b/en/device-dev/kernel/kernel-small-apx-dll.md new file mode 100644 index 0000000000000000000000000000000000000000..1e4489eb828c67adcbb64d59e7479e968f62d7af --- /dev/null +++ b/en/device-dev/kernel/kernel-small-apx-dll.md @@ -0,0 +1,229 @@ +# Doubly Linked List + +- [Basic Concepts](#section1990715203418) +- [Available APIs](#section848334511411) +- [How to Develop](#section01781261552) + - [Development Example](#section8354175218128) + + +## Basic Concepts + +A doubly linked list is a linked data structure that consists of a set of sequentially linked records called nodes. Each node contains a pointer to the previous node and a pointer to the next node in the sequence of nodes. The pointer head is unique. A doubly linked list allows access from a list node to its next node and also the previous node on the list. This data structure facilitates data search, especially traversal of a large amount of data. The symmetry of the doubly linked list also makes operations, such as insertion and deletion, easy. However, pay attention to the pointer direction when performing operations. + +## Available APIs + +The following table describes APIs available for the doubly linked list. For more details about the APIs, see the API reference. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Initializing a linked list

+

LOS_ListInit

+

Initializes a specified node as a doubly linked list node.

+

LOS_DL_LIST_HEAD

+

Defines a node and initializes it as a doubly linked list node.

+

Adding a node

+

LOS_ListAdd

+

Inserts the specified node to the head of a doubly linked list.

+

LOS_ListHeadInsert

+

Inserts the specified node to the head of a doubly linked list. It is the same as LOS_ListAdd.

+

LOS_ListTailInsert

+

Inserts the specified node to the end of a doubly linked list.

+

Adding a linked list

+

LOS_ListAddList

+

Inserts the head of a specified linked list into the head of a doubly linked list.

+

LOS_ListHeadInsertList

+

Inserts the head of a specified linked list into the head of a doubly linked list. It is the same as LOS_ListAddList.

+

LOS_ListTailInsertList

+

Inserts the end of a specified linked list into the head of a doubly linked list.

+

Deleting a node

+

LOS_ListDelete

+

Deletes the specified node from a doubly linked list.

+

LOS_ListDelInit

+

Deletes the specified node from the linked list and uses the node to initialize the linked list.

+

Determining a doubly linked list

+

LOS_ListEmpty

+

Checks whether a linked list is empty.

+

LOS_DL_LIST_IS_END

+

Checks whether the specified linked list node is at the end of the linked list.

+

LOS_DL_LIST_IS_ON_QUEUE

+

Check whether the linked list node is in a doubly linked list.

+

Obtaining structure information

+

LOS_OFF_SET_OF

+

Obtains the offset of a member in a specified structure relative to the start address of the structure.

+

LOS_DL_LIST_ENTRY

+

Obtains the address of the structure that contains the first node in the linked list. The first input parameter of the API indicates the head node in the list, the second input parameter indicates the name of the structure to be obtained, and the third input parameter indicates the name of the linked list in the structure.

+

LOS_ListPeekHeadType

+

Obtains the address of the structure that contains the first node in the linked list. The first input parameter of the API indicates the head node in the list, the second input parameter indicates the name of the structure to be obtained, and the third input parameter indicates the name of the linked list in the structure. Return Null if the linked list is empty.

+

LOS_ListRemoveHeadType

+

Obtains the address of the structure that contains the first node in the linked list, and deletes the first node from the list. The first input parameter of the API indicates the head node in the list, the second input parameter indicates the name of the structure to be obtained, and the third input parameter indicates the name of the linked list in the structure. Return Null if the linked list is empty.

+

LOS_ListNextType

+

Obtains the address of the structure that contains the next node of the specified node in the linked list. The first input parameter of the API indicates the head node in the list, the second input parameter indicates the specified node, the third parameter indicates the name of the structure to be obtained, and the fourth input parameter indicates the name of the linked list in the structure. If the next node of the linked list node is the head node and is empty, NULL is returned.

+

Traversing a doubly linked list

+

LOS_DL_LIST_FOR_EACH

+

Traverses a doubly linked list.

+

LOS_DL_LIST_FOR_EACH_SAFE

+

Traverses a doubly linked list, and stores the next node of the current node for security verification.

+

Traversing the structure that contains the doubly linked list

+

LOS_DL_LIST_FOR_EACH_ENTRY

+

Traverses the specified doubly linked list and obtains the address of the structure that contains the linked list node.

+

LOS_DL_LIST_FOR_EACH_ENTRY_SAFE

+

Traverses the specified doubly linked list, obtains the structure address of the node that contains the linked list, and stores the structure address that contains the next node of the current node.

+
+ +## How to Develop + +The typical development process of the doubly linked list is as follows: + +1. Call **LOS\_ListInit/LOS\_DL\_LIST\_HEAD** to initialize a doubly linked list. +2. Call **LOS\_ListAdd** to insert a node to the list. +3. Call **LOS\_ListTailInsert** to insert a node to the end of the list. +4. Call **LOS\_ListDelete** to delete the specified node. +5. Call **LOS\_ListEmpty** to check whether a linked list is empty. +6. Call **LOS\_ListDelInit** to delete a specified node, and initialize the linked list based on this node. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- Pay attention to the operations of the front and back pointer of the node. +>- The linked list operation APIs are underlying APIs and do not check whether the input parameters are empty. You must ensure that the input parameters are valid. +>- If the memory of a linked list node is dynamically requested, release the memory after deleting the node. + +### Development Example + +Example Description + +This example implements the following: + +1. Initialize a doubly linked list. +2. Add nodes. +3. Delete a node. +4. Check whether the operation is performed successfully. + +``` +#include "stdio.h" +#include "los_list.h" + +static UINT32 ListSample(VOID) +{ + LOS_DL_LIST listHead = {NULL,NULL}; + LOS_DL_LIST listNode1 = {NULL,NULL}; + LOS_DL_LIST listNode2 = {NULL,NULL}; + + // Initialize the linked list. + PRINTK("Initial head\n"); + LOS_ListInit(&listHead); + + // Add node 1 and node 2 and verify their relationship. + LOS_ListAdd(&listHead, &listNode1); + if (listNode1.pstNext == &listHead && listNode1.pstPrev == &listHead) { + PRINTK("Add listNode1 success\n"); + } + + LOS_ListTailInsert(&listHead, &listNode2); + if (listNode2.pstNext == &listHead && listNode2.pstPrev == &listNode1) { + PRINTK("Tail insert listNode2 success\n"); + } + + // Delete the two nodes. + LOS_ListDelete(&listNode1); + LOS_ListDelete(&listNode2); + + // Check that the linked list is empty. + if (LOS_ListEmpty(&listHead)) { + PRINTK("Delete success\n"); + } + + return LOS_OK; +} +``` + +**Verification** + +The development is successful if the return result is as follows: + +``` +Initial head +Add listNode1 success +Tail insert listNode2 success +Delete success +``` + diff --git a/en/device-dev/kernel/kernel-small-apx-library.md b/en/device-dev/kernel/kernel-small-apx-library.md new file mode 100644 index 0000000000000000000000000000000000000000..8bd0b23fd5db447e137f61f30fd06a53dd79349f --- /dev/null +++ b/en/device-dev/kernel/kernel-small-apx-library.md @@ -0,0 +1,287 @@ +# Standard Library + +- [Standard Library API Framework](#section149319478561) +- [Development Example](#section20874620185915) +- [Differences from the Linux Standard Library](#section6555642165713) + - [Process](#section11299104511409) + - [Memory](#section175754484116) + - [File System](#section118191113134220) + - [Signal](#section195939264421) + - [Time](#section20825124304213) + + +The OpenHarmony kernel uses the musl libc library that supports the Portable Operating System Interface \(POSIX\). You can develop components and applications working on the kernel based on the POSIX. + +## Standard Library API Framework + +**Figure 1** POSIX framework +![](figure/posix-framework.png "posix-framework") + +The musl libc library supports POSIX standards. The OpenHarmony kernel adapts the related system call APIs to implement external functions. + +For details about the APIs supported by the standard library, see the API document of the C library, which also covers the differences between the standard library and the POSIX standard. + +## Development Example + +In this example, the main thread creates **THREAD\_NUM** child threads. Once a child thread is started, it enters the standby state. After the main thread successfully wakes up all child threads, they continue to execute until the lifecycle ends. The main thread uses the **pthread\_join** method to wait until all child threads are executed. + +``` +#include +#include +#include + +#ifdef __cplusplus +#if __cplusplus +extern "C" { +#endif /* __cplusplus */ +#endif /* __cplusplus */ + +#define THREAD_NUM 3 +int g_startNum = 0; /* Number of started threads */ +int g_wakenNum = 0; /* Number of wakeup threads */ + +struct testdata { + pthread_mutex_t mutex; + pthread_cond_t cond; +} g_td; + +/* + * Entry function of child threads. + */ +static void *ChildThreadFunc(void *arg) +{ + int rc; + pthread_t self = pthread_self(); + + /* Acquire a mutex. */ + rc = pthread_mutex_lock(&g_td.mutex); + if (rc != 0) { + printf("ERROR:take mutex lock failed, error code is %d!\n", rc); + goto EXIT; + } + + /* The value of g_startNum is increased by 1. The value indicates the number of child threads that have acquired a mutex. */ + g_startNum++; + + /* Wait for the cond variable. */ + rc = pthread_cond_wait(&g_td.cond, &g_td.mutex); + if (rc != 0) { + printf("ERROR: pthread condition wait failed, error code is %d!\n", rc); + (void)pthread_mutex_unlock(&g_td.mutex); + goto EXIT; + } + + /* Attempt to acquire a mutex, which is failed in normal cases. */ + rc = pthread_mutex_trylock(&g_td.mutex); + if (rc == 0) { + printf("ERROR: mutex gets an abnormal lock!\n"); + goto EXIT; + } + + /* The value of g_wakenNum is increased by 1. The value indicates the number of child threads that have been woken up by the cond variable. */ + g_wakenNum++; + + /* Unlock a mutex. */ + rc = pthread_mutex_unlock(&g_td.mutex); + if (rc != 0) { + printf("ERROR: mutex release failed, error code is %d!\n", rc); + goto EXIT; + } +EXIT: + return NULL; +} + +static int testcase(void) +{ + int i, rc; + pthread_t thread[THREAD_NUM]; + + /* Initialize a mutex. */ + rc = pthread_mutex_init(&g_td.mutex, NULL); + if (rc != 0) { + printf("ERROR: mutex init failed, error code is %d!\n", rc); + goto ERROROUT; + } + + /* Initialize the cond variable. */ + rc = pthread_cond_init(&g_td.cond, NULL); + if (rc != 0) { + printf("ERROR: pthread condition init failed, error code is %d!\n", rc); + goto ERROROUT; + } + + /* Create child threads in batches. The number is specified by THREAD_NUM. */ + for (i = 0; i < THREAD_NUM; i++) { + rc = pthread_create(&thread[i], NULL, ChildThreadFunc, NULL); + if (rc != 0) { + printf("ERROR: pthread create failed, error code is %d!\n", rc); + goto ERROROUT; + } + } + + /* Wait until all child threads lock a mutex. */ + while (g_startNum < THREAD_NUM) { + usleep(100); + } + + /* Acquire a mutex and block all threads using pthread_cond_wait. */ + rc = pthread_mutex_lock(&g_td.mutex); + if (rc != 0) { + printf("ERROR: mutex lock failed, error code is %d\n", rc); + goto ERROROUT; + } + + /* Release a mutex. */ + rc = pthread_mutex_unlock(&g_td.mutex); + if (rc != 0) { + printf("ERROR: mutex unlock failed, error code is %d!\n", rc); + goto ERROROUT; + } + + for (int j = 0; j < THREAD_NUM; j++) { + /* Broadcast signals on the cond variable. */ + rc = pthread_cond_signal(&g_td.cond); + if (rc != 0) { + printf("ERROR: pthread condition failed, error code is %d!\n", rc); + goto ERROROUT; + } + } + + sleep(1); + + /* Check whether all child threads are woken up. */ + if (g_wakenNum != THREAD_NUM) { + printf("ERROR: not all threads awaken, only %d thread(s) awaken!\n", g_wakenNum); + goto ERROROUT; + } + + /* Wait for all threads to terminate. */ + for (i = 0; i < THREAD_NUM; i++) { + rc = pthread_join(thread[i], NULL); + if (rc != 0) { + printf("ERROR: pthread join failed, error code is %d!\n", rc); + goto ERROROUT; + } + } + + /* Destroy the cond variable. */ + rc = pthread_cond_destroy(&g_td.cond); + if (rc != 0) { + printf("ERROR: pthread condition destroy failed, error code is %d!\n", rc); + goto ERROROUT; + } + return 0; +ERROROUT: + return -1; +} + +/* + * Sample code main function + */ +int main(int argc, char *argv[]) +{ + int rc; + + /* Start the test function. */ + rc = testcase(); + if (rc != 0) { + printf("ERROR: testcase failed!\n"); + } + + return 0; +} +#ifdef __cplusplus +#if __cplusplus +} +#endif /* __cplusplus */ +#endif /* __cplusplus */ +``` + +## Differences from the Linux Standard Library + +This section describes the key differences between the standard library carried by the OpenHarmony kernel and the Linux standard library. For more differences, see the API document of the C library. + +### Process + +1. The OpenHarmony user-space processes support only static priorities, which range from 10 \(highest\) to 31 \(lowest\). +2. The OpenHarmony user-space threads support only static priorities, which range from 0 \(highest\) to 31 \(lowest\). +3. The OpenHarmony process scheduling support **SCHED\_RR** only, and thread scheduling support **SCHED\_RR** or **SCHED\_FIFO**. + +### Memory + +**h2****Difference with Linux mmap** + +mmap prototype: **void \*mmap \(void \*addr, size\_t length, int prot, int flags, int fd, off\_t offset\)** + +The lifecycle implementation of **fd** is different from that of Linux glibc. glibc releases the **fd** handle immediately after successfully invoking **mmap** for mapping. In the OpenHarmony kernel, you are not allowed to close the **fd** immediately after the mapping is successful. You can close the **fd** only after **munmap** is called. If you do not close **fd**, the OS reclaims the **fd** when the process exits. + +**h2****Sample Code** + +Linux OS: + +``` +int main(int argc, char *argv[]) +{ + int fd; + void *addr = NULL; + ... + fd = open(argv[1], O_RDONLY); + if (fd == -1){ + perror("open"); + exit(EXIT_FAILURE); + } + addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, offset); + if (addr == MAP_FAILED) { + perror("mmap"); + exit(EXIT_FAILURE); + } + close(fd); /* OpenHarmony does not support closing fd immediately after the mapping is successful. */ + ... + exit(EXIT_SUCCESS); +} +``` + +OpenHarmony: + +``` +int main(int argc, char *argv[]) +{ + int fd; + void *addr = NULL; + ... + fd = open(argv[1], O_RDONLY); + if (fd == -1) { + perror("open"); + exit(EXIT_FAILURE); + } + addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, offset); + if (addr == MAP_FAILED) { + perror("mmap"); + exit(EXIT_FAILURE); + } + ... + munmap(addr, length); + close(fd); /* Close fd after the munmap is canceled. */ + exit(EXIT_SUCCESS); +} +``` + +### File System + +**System directories**: You cannot modify system directories and device mount directories, which include **/dev**, **/proc**, **/app**, **/bin**, **/data**, **/etc**, **/lib**, **/system** and **/usr**. + +**User directory**: The user directory refers to the **/storage** directory. You can create, read, and write files in this directory, but cannot mount devices. + +Except the system and user directories, you can create directories and mount devices. Note that nested mount is not allowed, that is, a mounted folder and its subfolders cannot be mounted repeatedly. A non-empty folder cannot be mounted. + +### Signal + +- The default behavior for signals does not include **STOP**, **CONTINUE**, or **COREDUMP**. +- A sleeping process \(for example, a process enters the sleeping status by calling the sleep function\) cannot be woken up by a signal. The signal mechanism does not support the wakeup function. The behavior for a signal can be processed only when the process is scheduled by the CPU. +- After a process exits, **SIGCHLD** is sent to the parent process. The sending action cannot be canceled. +- Only signals 1 to 30 are supported. The callback is executed only once even if the same signal is received multiple times. + +### Time + +The OpenHarmony time precision is based on tick. The default value is 10 ms/tick. The time error of the **sleep** and **timeout** functions is less than or equal to 20 ms. + diff --git a/en/device-dev/kernel/kernel-small-apx-structure.md b/en/device-dev/kernel/kernel-small-apx-structure.md new file mode 100644 index 0000000000000000000000000000000000000000..7e27b4cea1df8c36fdfc218b8d5fc9919dde5e44 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-apx-structure.md @@ -0,0 +1,7 @@ +# Basic Data Structure + +- **[Doubly Linked List](kernel-small-apx-dll.md)** + +- **[Bitwise Operation](kernel-small-apx-bitwise.md)** + + diff --git a/en/device-dev/kernel/kernel-small-apx.md b/en/device-dev/kernel/kernel-small-apx.md new file mode 100644 index 0000000000000000000000000000000000000000..4855425ba469d0f00f1c7e9539d3622ba16e6fa6 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-apx.md @@ -0,0 +1,7 @@ +# Appendix + +- **[Basic Data Structure](kernel-small-apx-structure.md)** + +- **[Standard Library](kernel-small-apx-library.md)** + + diff --git a/en/device-dev/kernel/kernel-small-basic-atomic.md b/en/device-dev/kernel/kernel-small-basic-atomic.md new file mode 100644 index 0000000000000000000000000000000000000000..2f480a1d08da4bfaa974cd668602e1bb860d5ad8 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-atomic.md @@ -0,0 +1,288 @@ +# Atomic Operation + +- [Basic Concepts](#section1792118384594) +- [Working Principles](#section1786635117596) +- [Development Guidelines](#section2911115308) + - [Available APIs](#section335914201010) + - [How to Develop](#section12207371304) + - [Development Example](#section8538651511) + + +## Basic Concepts + +In an OS that supports multiple tasks, modifying data in a memory area requires three steps: read data, modify data, and write data. However, data in a same memory area may be simultaneously accessed by multiple tasks. If the data modification is interrupted by another task, the execution result of the operation is unpredictable. + +Although you can enable or disable interrupts to ensure that the multi-task execution results meet expectation, the system performance is affected. + +The ARMv6 architecture has introduced the **LDREX** and **STREX** instructions to support more discreet non-blocking synchronization of the shared memory. The atomic operations implemented thereby can ensure that the "read-modify-write" operations on the same data will not be interrupted, that is, the operation atomicity is ensured. + +## Working Principles + +The OpenHarmony system has encapsulated the **LDREX** and **STREX** in the ARMv6 architecture to provide a set of atomic operation APIs. + +- LDREX Rx, \[Ry\] + + Reads the value in the memory and marks the exclusive access to the memory segment. + + - Reads the 4-byte memory data pointed by the register **Ry** and saves the data to the **Rx** register. + - Adds an exclusive access flag to the memory area pointed by **Ry**. + +- STREX Rf, Rx, \[Ry\] + + Checks whether the memory has an exclusive access flag. If yes, the system updates the memory value and clears the flag. If no, the memory is not updated. + + - If there is an exclusive access flag, the system: + - Updates the **Rx** register value to the memory pointed to by the **Ry** register. + - Sets the **Rf** register to **0**. + + - If there is no exclusive access flag: + - The memory is not updated. + - The system sets the **Rf** register to **1**. + + +- Flag register + - If the flag register is **0**, the system exits the loop and the atomic operation is complete. + - If the flag register is **1**, the system continues the loop and performs the atomic operation again. + + +## Development Guidelines + +### Available APIs + +The following table describes the APIs available for the OpenHarmony LiteOS-A kernel atomic operation module. For more details about the APIs, see the API reference. + +**Table 1** Atomic operation APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Read

+

LOS_AtomicRead

+

Reads 32-bit atomic data.

+

LOS_Atomic64Read

+

Reads 64-bit atomic data.

+

Write

+

LOS_AtomicSet

+

Sets 32-bit atomic data.

+

LOS_Atomic64Set

+

Sets 64-bit atomic data.

+

Add

+

LOS_AtomicAdd

+

Adds 32-bit atomic data.

+

LOS_Atomic64Add

+

Adds 64-bit atomic data.

+

LOS_AtomicInc

+

Adds 1 to 32-bit atomic data.

+

LOS_Atomic64Inc

+

Adds 1 to 64-bit atomic data.

+

LOS_AtomicIncRet

+

Adds 1 to 32-bit atomic data and returns the data.

+

LOS_Atomic64IncRet

+

Adds 1 to 64-bit atomic data and returns the data.

+

Subtract

+

LOS_AtomicSub

+

Performs subtraction on 32-bit atomic data.

+

LOS_Atomic64Sub

+

Performs subtraction on 64-bit atomic data.

+

LOS_AtomicDec

+

Subtracts 1 from 32-bit atomic data.

+

LOS_Atomic64Dec

+

Subtracts 1 from 64-bit atomic data.

+

LOS_AtomicDecRet

+

Subtracts 1 from 32-bit atomic data and returns the result.

+

LOS_Atomic64DecRet

+

Subtracts 1 from 64-bit atomic data and returns the result.

+

Swap

+

LOS_AtomicXchgByte

+

Swaps 8-bit memory data.

+

LOS_AtomicXchg16bits

+

Swaps 16-bit memory data.

+

LOS_AtomicXchg32bits

+

Swaps 32-bit memory data.

+

LOS_AtomicXchg64bits

+

Swaps 64-bit memory data.

+

Compare and swap

+

LOS_AtomicCmpXchgByte

+

Compares and swaps 8-bit memory data.

+

LOS_AtomicCmpXchg16bits

+

Compares and swaps 16-bit memory data.

+

LOS_AtomicCmpXchg32bits

+

Compares and swaps 32-bit memory data.

+

LOS_AtomicCmpXchg64bits

+

Compares and swaps 64-bit memory data.

+
+ +### How to Develop + +When multiple tasks perform addition, subtraction, and swap operations on the same memory data, use atomic operations to ensure predictability of results. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>Atomic operation APIs support only integer data. + +### Development Example + +Example Description + +Call the atomic operation APIs and observe the result. + +1. Create two tasks. + - Task 1: Call **LOS\_AtomicInc** to add the global variables 100 times. + - Task 2: Call **LOS\_AtomicDec** to subtract the global variables 100 times. + +2. After the subtasks are complete, print the values of the global variables in the main task. + +**Sample Code** + +The sample code is as follows: + +``` +#include "los_hwi.h" +#include "los_atomic.h" +#include "los_task.h" + +UINT32 g_testTaskId01; +UINT32 g_testTaskId02; +Atomic g_sum; +Atomic g_count; + +UINT32 Example_Atomic01(VOID) +{ + int i = 0; + for(i = 0; i < 100; ++i) { + LOS_AtomicInc(&g_sum); + } + + LOS_AtomicInc(&g_count); + return LOS_OK; +} + +UINT32 Example_Atomic02(VOID) +{ + int i = 0; + for(i = 0; i < 100; ++i) { + LOS_AtomicDec(&g_sum); + } + + LOS_AtomicInc(&g_count); + return LOS_OK; +} + +UINT32 Example_AtomicTaskEntry(VOID) +{ + TSK_INIT_PARAM_S stTask1={0}; + stTask1.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_Atomic01; + stTask1.pcName = "TestAtomicTsk1"; + stTask1.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + stTask1.usTaskPrio = 4; + stTask1.uwResved = LOS_TASK_STATUS_DETACHED; + + TSK_INIT_PARAM_S stTask2={0}; + stTask2.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_Atomic02; + stTask2.pcName = "TestAtomicTsk2"; + stTask2.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + stTask2.usTaskPrio = 4; + stTask2.uwResved = LOS_TASK_STATUS_DETACHED; + + LOS_TaskLock(); + LOS_TaskCreate(&g_testTaskId01, &stTask1); + LOS_TaskCreate(&g_testTaskId02, &stTask2); + LOS_TaskUnlock(); + + while(LOS_AtomicRead(&g_count) != 2); + PRINTK("g_sum = %d\n", g_sum); + + return LOS_OK; +} +``` + +**Verification** + +``` +g_sum = 0 +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-inner-reflect.md b/en/device-dev/kernel/kernel-small-basic-inner-reflect.md new file mode 100644 index 0000000000000000000000000000000000000000..667ccf35e2be300f8469bceac352656fc37d65c2 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-inner-reflect.md @@ -0,0 +1,88 @@ +# Virtual-to-Physical Mapping + +- [Basic Concepts](#section9108144913615) +- [Working Principles](#section12392621871) +- [Development Guidelines](#section10264102013713) + - [Available APIs](#section195320251578) + - [How to Develop](#section152774210712) + + +## Basic Concepts + +The Memory Management Unit \(MMU\) is used to map the virtual addresses in the process space and the actual physical addresses and specify corresponding access permissions and cache attributes. When a program is executed, the CPU accesses the virtual memory, locates the corresponding physical memory based on the MMU page table entry, and executes the code or performs data read/write operations. The page tables of the MMU store the mappings between virtual and physical addresses and the access permission. A page table is created when each process is created. The page table contains page table entries \(PTEs\), and each PTE describes a mapping between a virtual address region and a physical address region. The MMU has a Translation Lookaside Buffer \(TLB\) to perform address translation. During address translation, the MMU first searches the TLB for the corresponding PTE. If a match is found, the address can be returned directly. The following figure illustrates how the CPU accesses the memory or peripherals. + +**Figure 1** CPU accessing the memory or peripheral +![](figure/cpu-accessing-the-memory-or-peripheral.png "cpu-accessing-the-memory-or-peripheral") + +## Working Principles + +Virtual-to-physical address mapping is a process of establishing page tables. The MMU has multiple levels of page tables. The LiteOS-A kernel uses the level-2 page tables to describe the process space. Each level-1 PTE descriptor occupies 4 bytes, which indicate a mapping record of 1 MiB memory space. The 1 GiB user space of the LiteOS-A kernel has 1024 level-1 PTEs. When a user process is created, a 4 KiB memory block is requested from the memory as the storage area of the level-1 page table. The level-2 page table dynamically request memory based on requirements of the process. + +- When a user program is loaded and started, the code segment and data segment are mapped to the virtual memory space \(for details, see [Dynamic Loading and Linking](kernel-small-bundles-linking.md)\). At that time, no physical page is mapped. +- When the program is executed, as shown by the bold arrow in the following figure, the CPU accesses the virtual address and checks for the corresponding physical memory in the MMU. If the virtual address does not have the corresponding physical address, a page missing fault is triggered. The kernel requests the physical memory, writes the virtual-physical address mapping and the related attributes to the page table, and caches the PTE in the TLB. Then, the CPU can directly access the actual physical memory. +- If the PTE already exists in the TLB, the CPU can access the physical memory without accessing the page table stored in the memory. + +**Figure 2** CPU accessing the memory +![](figure/cpu-accessing-the-memory.png "cpu-accessing-the-memory") + +## Development Guidelines + +### Available APIs + +**Table 1** APIs of the virtual-to-physical address mapping module + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

MMU operations

+

LOS_ArchMmuQuery

+

Obtains the physical address and attributes corresponding to the virtual address of the process space.

+

LOS_ArchMmuMap

+

Maps the virtual address region of the process space and the physical address region.

+

LOS_ArchMmuUnmap

+

Removes the mapping between the virtual address region of the process space and the physical address region.

+

LOS_ArchMmuChangeProt

+

Modifies the mapping attributes of the virtual address region of the process space.

+

LOS_ArchMmuMove

+

Moves a mapping record of a virtual address region in the process space to another unused virtual address region for remapping.

+
+ +### How to Develop + +To use virtual-to-physical address mapping APIs: + +1. Call **LOS\_ArchMmuMap** to map a physical memory block. +2. Perform the following operations on the mapped address region: + - Call **LOS\_ArchMmuQuery** to query the physical address region corresponding to a virtual address region and the mapping attributes. + + - Call **LOS\_ArchMmuChangeProt** to modify the mapping attributes. + - Call **LOS\_ArchMmuMove** to remap the virtual address region. + +3. Call **LOS\_ArchMmuUnmap** to remove the mapping. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>The preceding APIs can be used after the MMU initialization is complete and the page tables of the related process are created. The MMU initialization is complete during system startup. Page tables are created when the processes are created. You do not need to perform any operation. + diff --git a/en/device-dev/kernel/kernel-small-basic-interrupt.md b/en/device-dev/kernel/kernel-small-basic-interrupt.md new file mode 100644 index 0000000000000000000000000000000000000000..cde3913599b25f0c5934d348ed55539561e6358c --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-interrupt.md @@ -0,0 +1,147 @@ +# Interrupt and Exception Handling + +- [Basic Concepts](#section439816296117) +- [Working Principles](#section2792838318) +- [Development Guidelines](#section15415165510110) + - [Available APIs](#section57441612024) + - [How to Develop](#section64332181221) + - [Development Example](#section204698276478) + - [Verification](#section1466144215476) + + +## Basic Concepts + +An interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention. An interrupt alerts the processor to a high-priority condition requiring the interruption of the current code being executed by the processor. In this way, the CPU does not need to spend a lot of time in waiting and querying the peripheral status, which effectively improves the real-time performance and execution efficiency of the system. + +Exception handling involves a series of actions taken by the OS to respond to exceptions \(chip hardware faults\) occurred during the OS running, for example, printing the call stack information of the current function, CPU information, and call stack information of tasks when the virtual memory page is missing. + +## Working Principles + +Peripherals can complete certain work without the intervention of the CPU. In some cases, however, the CPU needs to perform certain work for peripherals. By using the interrupt mechanism, the CPU responds to the interrupt request from a peripheral only when required, and execute other tasks when the peripherals do not require the CPU. The interrupt controller receives the input of other peripheral interrupt pins and sends interrupt signals to the CPU. You can enable or disable the interrupt source and set the priority and trigger mode of the interrupt source by programming the interrupt controller. Common interrupt controllers include vector interrupt controllers \(VICs\) and general interrupt controllers \(GICs\). The ARM Cortex-A7 uses GICs. After receiving an interrupt signal sent by the interrupt controller, the CPU interrupts the current task to respond to the interrupt request. + +Exception handling interrupts the normal running process of the CPU to handle exceptions, such as, undefined instruction exception, an attempt to modify read-only data, and unaligned address access. When an exception occurs, the CPU suspends the current program, handles the exception, and then continues to execute the program interrupted by the exception. + +The following uses the ARMv7-a architecture as an example. The interrupt vector table is the entry for interrupt and exception handling. The interrupt vector table contains the entry function for each interrupt and exception handling. + +**Figure 1** Interrupt vector table + + +![](figure/en-us_image_0000001173449871.png) + +## Development Guidelines + +### Available APIs + +Exception handling is an internal mechanism and does not provide external APIs. The following table describes APIs available for the interrupt module. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting interrupts

+

LOS_HwiCreate

+

Creates an interrupt and registers the interrupt ID, interrupt triggering mode, interrupt priority, and interrupt handler. When an interrupt is triggered, the interrupt handler will be called.

+

LOS_HwiDelete

+

Deletes an interrupt.

+

Enabling and disabling all interrupts

+

LOS_IntUnLock

+

Enables all interrupts of the current processor.

+

LOS_IntLock

+

Disables all interrupts for the current processor.

+

LOS_IntRestore

+

Restores to the status before all interrupts are disabled by using LOS_IntLock.

+

Obtaining the maximum number of interrupts supported

+

LOS_GetSystemHwiMaximum

+

Obtains the maximum number of interrupts supported by the system.

+
+ +### How to Develop + +1. Call **LOS\_HwiCreate** to create an interrupt. +2. Call **LOS\_HwiDelete** to delete the specified interrupt. Use this API based on actual requirements. + +### Development Example + +This example implements the following: + +1. Create an interrupt. +2. Delete an interrupt. + +The following sample code shows how to create and delete an interrupt. When the interrupt **HWI\_NUM\_TEST** is generated, the interrupt handler function will be called. + +``` +#include "los_hwi.h" +/* Interrupt handler function*/ +STATIC VOID HwiUsrIrq(VOID) +{ + printf("in the func HwiUsrIrq \n"); +} + +static UINT32 Example_Interrupt(VOID) +{ + UINT32 ret; + HWI_HANDLE_T hwiNum = 7; + HWI_PRIOR_T hwiPrio = 3; + HWI_MODE_T mode = 0; + HWI_ARG_T arg = 0; + +/* Create an interrupt.*/ + ret = LOS_HwiCreate(hwiNum, hwiPrio, mode, (HWI_PROC_FUNC)HwiUsrIrq, (HwiIrqParam *)arg); + if(ret == LOS_OK){ + printf("Hwi create success!\n"); + } else { + printf("Hwi create failed!\n"); + return LOS_NOK; + } + + /* Delay 50 ticks. When a hardware interrupt occurs, the HwiUsrIrq function will be called.*/ + LOS_TaskDelay(50); + + /* Delete an interrupt./ + ret = LOS_HwiDelete(hwiNum, (HwiIrqParam *)arg); + if(ret == LOS_OK){ + printf("Hwi delete success!\n"); + } else { + printf("Hwi delete failed!\n"); + return LOS_NOK; + } + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +Hwi create success! +Hwi delete success! +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-memory-heap.md b/en/device-dev/kernel/kernel-small-basic-memory-heap.md new file mode 100644 index 0000000000000000000000000000000000000000..e6960d8dfc0c8fea6418ad8bcb11b0da2b29b529 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-memory-heap.md @@ -0,0 +1,249 @@ +# Heap Memory Management + +- [Basic Concepts](#section449414395916) +- [Working Principles](#section465085575911) +- [Development Guidelines](#section577019272015) + - [When to Use](#section326917198583) + - [Available APIs](#section1032331584) + - [How to Develop](#section07271773592) + - [Development Example](#section84931234145913) + - [Verification](#section165233233917) + + +## Basic Concepts + +Memory management module, one of the core modules of the OS, manages the memory resources of the system. Memory management involves memory initialization, allocation, and release. The heap memory management of the OpenHarmony LiteOS-A provides functions such as memory initialization, allocation, and release. While the OS is running, the heap memory management module manages the memory usage of users and the OS by allocating and releasing memory. This helps achieve the optimal memory usage and usage efficiency and minimize memory fragments. + +## Working Principles + +Heap memory management allows memory blocks of any size to be allocated from a large contiguous memory \(memory pool or heap memory\) configured in the system based on user demands when memory resources are sufficient. The memory block can be released for further use when not required. Heap memory management is a type of dynamic memory management. Compared with static memory management, dynamic memory management allows memory allocation on demand but causes fragmentation of memory. The heap memory of the OpenHarmony LiteOS-A has optimized the memory space partitioning based on the Two-Level Segregate Fit \(TLSF\) algorithm to achieve higher performance and minimize fragmentation. [Figure 1](#fig14558185217397) shows the core algorithm of the heap memory management. + +**Figure 1** Heap memory core algorithm +![](figure/heap-memory-core-algorithm.png "heap-memory-core-algorithm") + +Multiple free lists are used for management based on the size of the free memory block. The free memory blocks are divided into two parts: \[4, 127\] and \[27, 231\], as indicated by the size class in the above figure. + +1. The memory in the range of \[4, 127\] \(lower part in the figure\) is equally divided into 31 parts. The size of the memory block corresponding to each part is a multiple of 4 bytes. Each part corresponds to a free list and a bit that indicates whether the free list is empty. The value **1** indicates that the free list is not empty. There are 31 bits corresponding to the 31 memory parts in the range of \[4, 127\]. +2. The memory greater than 127 bytes is managed in power of two increments. The size of each range is \[2^n, 2^\(n+1\) -1\], where n is an integer in \[7, 30\]. This range is divided into 24 parts, each of which is further divided into 8 second-level \(L2\) ranges, as shown in Size Class and Size SubClass in the upper part of the figure. Each L2 range corresponds to a free list and a bit that indicates whether the free list is empty. There are a total of 192 \(24 x 8\) L2 ranges, corresponding to 192 free lists and 192 bits. + +For example, insert 40-byte free memory to a free list. The 40-byte free memory corresponds to the 10th free list in the range of \[40, 43\], and the 10th bit indicates the use of the free list. The system inserts the 40-byte free memory to the 10th free list and determines whether to update the bitmap flag. When 40-byte memory is requested, the system obtains the free list corresponding to the memory block of the requested size based on the bitmap flag, and then obtains a free memory node from the free list. If the size of the allocated node is greater than the memory requested, the system splits the node and inserts the remaining node to the free list. If 580-byte free memory needs to be inserted to a free list, the 580-byte free memory corresponds to the 47th \(31 + 2 x 8\) free list in L2 range \[2^9, 2^9+2^6\], and the 47th bit indicates the use of the free list. The system inserts the 580-byte free memory to the 47th free list and determines whether to update the bitmap flag. When 580-byte memory is requested, the system obtains the free list corresponding to the memory block of the requested size based on the bitmap flag, and then obtains a free memory node from the free list. If the size of the allocated node is greater than the memory requested, the system splits the node and inserts the remaining node to the free list. If the corresponding free list is empty, the system checks for a free list meeting the requirements in a larger memory range. In actual application, the system can locate the free list that meets the requirements at a time. + +The following figure shows the memory management structure. + +**Figure 2** Dynamic memory management structure +![](figure/dynamic-memory-management-structure-20.png "dynamic-memory-management-structure-20") + +- Memory pool header + + The memory pool header contains the memory pool information, bitmap flag array, and free list array. The memory pool information includes the start address of the memory pool, total size of the heap memory, and attributes of the memory pool. The bitmap flag array consists of seven 32-bit unsigned integers. Each bit indicates whether the free list is inserted with free memory block nodes. The free list contains information about 223 free memory head nodes. The free memory head node information contains a memory node header and information about the previous and next nodes in the free list. + +- Memory pool nodes + + There are three types of nodes: free node, used node, and end node. Each memory node maintains the size and use flag of the memory node and a pointer to the previous memory node in the memory pool. The free nodes and used nodes have a data area, but the end node has no data area. + + +## Development Guidelines + +### When to Use + +Heap memory management is mainly used to dynamically allocate and manage memory ranges requested by users. Heap memory management is mainly used in scenarios where users need to use memory blocks of different sizes. You can obtain a memory block of a specified size by using a dynamic memory application function of the operating system. Once the memory is used up, the memory release function is used to release the occupied memory so that the memory can be reused. + +### Available APIs + +The following table describes APIs available for OpenHarmony LiteOS-A heap memory management. For more details about the APIs, see the API reference. + +**Table 1** Heap memory management APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Initializing or deleting a memory pool

+

LOS_MemInit

+

Initializes a dynamic memory pool of the specified size.

+

LOS_MemDeInit

+

Deletes a memory pool. It is valid only when LOSCFG_MEM_MUL_POOL is enabled.

+

Allocating or releasing dynamic memory

+

LOS_MemAlloc

+

Allocates memory of the specified size from the dynamic memory pool.

+

LOS_MemFree

+

Releases the memory allocated from the specified dynamic memory.

+

LOS_MemRealloc

+

Re-allocates a memory block of the required size and copies data from the original block to the newly allocated bock. If the new memory block is successfully allocated, the original memory block will be released.

+

LOS_MemAllocAlign

+

Allocates the memory of the specified size and aligned based on the specified bytes from a dynamic memory pool.

+

Obtaining memory pool information

+

LOS_MemPoolSizeGet

+

Obtains the total size of the specified dynamic memory pool.

+

LOS_MemTotalUsedGet

+

Obtains the total memory usage of the specified dynamic memory pool.

+

LOS_MemInfoGet

+

Obtains the memory structure information of the specified memory pool, including the free memory, used memory, number of free memory blocks, number of used memory blocks, and maximum size of the free memory block.

+

LOS_MemPoolList

+

Prints information about all initialized memory pools in the system, including the start address, size, total free memory, used memory, maximum size of the free memory block, number of free memory blocks, and number of used memory blocks of each memory pool. It is valid only when LOSCFG_MEM_MUL_POOL is enabled.

+

Obtaining memory block information

+

LOS_MemFreeNodeShow

+

Prints the size and number of free memory blocks in the specified memory pool.

+

Checking memory pool integrity

+

LOS_MemIntegrityCheck

+

Checks the integrity of the specified memory pool. It is valid only when LOSCFG_BASE_MEM_NODE_INTEGRITY_CHECK is enabled.

+
+ +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The dynamic memory module manages memory through control block structures, which consume extra memory. Therefore, the actual memory space available to users is less than the value of **OS\_SYS\_MEM\_SIZE**. +>- The **LOS\_MemAllocAlign** and **LOS\_MemMallocAlign** APIs consume extra memory for memory alignment, which may cause memory loss. When the memory used for alignment is freed up, the lost memory will be reclaimed. + +### How to Develop + +The typical development process of dynamic memory is as follows: + +1. Call the **LOS\_MemInit** API to initialize a memory pool. + + After a memory pool is initialized, a memory pool control header and end node will be generated, and the remaining memory is marked as free nodes. The end node is the last node in the memory pool, and its size is **0**. + + +1. Call the **LOS\_MemAlloc** API to allocate dynamic memory of any size. + + The system checks whether the dynamic memory pool has free memory blocks greater than the requested size. If yes, the system allocates a memory block and returns the pointer to the memory block. If no, the system returns NULL. If the memory block allocated is greater than the requested size, the system splits the memory block and inserts the remaining memory block to the free list. + + +1. Call the **LOS\_MemFree** API to release dynamic memory. + + The released memory block can be reused. When **LOS\_MemFree** is called, the memory block will be reclaimed and marked as free nodes. When memory blocks are reclaimed, adjacent free nodes are automatically merged. + + +### Development Example + +The example below implements the following: + +1. Initialize a dynamic memory pool. +2. Allocate a memory block from the dynamic memory pool. +3. Store a piece of data in the memory block. +4. Print the data in the memory block. +5. Release the memory block. + +The sample code is as follows: + +``` +#include "los_memory.h" + +#define TEST_POOL_SIZE (2*1024*1024) +__attribute__((aligned(4))) UINT8 g_testPool[TEST_POOL_SIZE]; + +VOID Example_DynMem(VOID) +{ + UINT32 *mem = NULL; + UINT32 ret; + + /* Initialize the memory pool. */ + ret = LOS_MemInit(g_testPool, TEST_POOL_SIZE); + if (LOS_OK == ret) { + printf("Mem init success!\n"); + } else { + printf("Mem init failed!\n"); + return; + } + + /* Allocate memory.*/ + mem = (UINT32 *)LOS_MemAlloc(g_testPool, 4); + if (NULL == mem) { + printf("Mem alloc failed!\n"); + return; + } + printf("Mem alloc success!\n"); + + /* Assign a value.*/ + *mem = 828; + printf("*mem = %d\n", *mem); + + /* Release memory.*/ + ret = LOS_MemFree(g_testPool, mem); + if (LOS_OK == ret) { + printf("Mem free success!\n"); + } else { + printf("Mem free failed!\n"); + } + + return; +} +UINT32 ExampleDynMemEntry(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S initParam = {0}; + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_DynMem; + initParam.usTaskPrio = 10; + initParam.pcName = "Example_DynMem"; + initParam.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + initParam.uwResved = LOS_TASK_STATUS_DETACHED; + + /* Create a task with a higher priority. The task will not be executed immediately after being created, because task scheduling is locked.*/ + ret = LOS_TaskCreate(&g_taskHiID, &initParam); + if (ret != LOS_OK) { + LOS_TaskUnlock(); + PRINTK("Example_DynMem create Failed! ret=%d\n", ret); + return LOS_NOK; + } + PRINTK("Example_DynMem create Success!\n"); + while(1){}; + return LOS_OK; +} +``` + +### Verification + +The output is as follows: + +``` +Mem init success! +Mem alloc success! +*mem = 828 +Mem free success! +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-memory-physical.md b/en/device-dev/kernel/kernel-small-basic-memory-physical.md new file mode 100644 index 0000000000000000000000000000000000000000..f5a33d885b3e4a36aa178b007f75a55b20f2ba70 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-memory-physical.md @@ -0,0 +1,228 @@ +# Physical Memory Management + +- [Basic Concepts](#section210891719217) +- [Working Principles](#section111355315213) +- [Development Guidelines](#section393116496217) + - [Available APIs](#section13210155619214) + - [How to Develop](#section178441091231) + - [Development Example](#section1258174015319) + - [Verification](#section515091342819) + + +## Basic Concepts + +Physical memory is one of the most important resources on a computer. It is the memory space that is provided by the physical memory devices and can be directly addressed through the CPU bus. The physical memory provides temporary storage space for the OS and programs. The LiteOS-A kernel manages the physical memory by memory paging. Except the memory occupied by the kernel heap, other available memory is divided into page frames in the unit of 4 KiB. Memory is allocated and reclaimed by page frame. The kernel uses the buddy algorithm to manage free pages to reduce the fragmentation rate and improve the memory allocation and release efficiency. However, a small block may block the merge of a large block, causing a failure in allocating a large memory block. + +## Working Principles + +As shown in the following figure, the physical memory distribution of the LiteOS-A kernel consists of the kernel image, kernel heap, and physical pages. For details about the kernel heap, see "Heap Memory Management." + +**Figure 1** Physical memory usage distribution +![](figure/physical-memory-usage-distribution.png "physical-memory-usage-distribution") + +The buddy algorithm divides all free page frames into 9 memory block groups, each of which contains 2N page frames. For example, the memory block in group 0 has 20, that is, 1 page frame. The memory block in the eighth group has 28, that is, 256 page frames. Memory blocks of the same size are added to the same linked list for management. + +- Requesting memory + + When 12 KiB memory \(3 page frames\) is requested, the list in group 3 \(with 8 page frames\) meets the requirement. After 12 KiB memory is allocated, 20 KiB memory \(5 page frames\) is left. The 5 page frames can be divided into 4 \(22\) page frames and 1 \(20\) page frame. The 4 page frames have no buddy in the list, and therefore are inserted into list 2. The 1 page frame has a buddy in list 0. If the addresses of the two \(20\) memory blocks are contiguous, the memory blocks are merged as 2 page frames \(21\) and inserted to list 2. If the addresses are not contiguous, the two \(20\) page frames are left in list 0. + + **Figure 2** Requesting memory + ![](figure/requesting-memory.png "requesting-memory") + + +- Releasing memory + + When 12 KiB memory \(3 page frames\) is released, the 3 page frames can be divided into 2 \(21\) page frames and 1 \(20\) page frame. The 2 page frames can be merged with the memory in linked list 1 if their addresses are contiguous and inserted to list 2. The one page frame can be merged with the memory in linked list 0 if their addresses are contiguous and inserted to list 1. In this way, the memory is released based on the buddy mechanism. + + **Figure 3** Releasing memory + ![](figure/releasing-memory.png "releasing-memory") + + +## Development Guidelines + +### Available APIs + +**Table 1** Physical memory management module APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Requesting physical memory

+

LOS_PhysPageAlloc

+

Requests a physical page.

+

LOS_PhysPagesAlloc

+

Requests a physical page and adds it to the corresponding linked list.

+

LOS_PhysPagesAllocContiguous

+

Requests memory of contiguous pages.

+

Releasing physical memory

+

LOS_PhysPageFree

+

Releases a physical page.

+

LOS_PhysPagesFree

+

Releases the physical pages added to a linked list.

+

LOS_PhysPagesFreeContiguous

+

Releases memory of contiguous pages.

+

Querying memory address

+

LOS_VmPageGet

+

Obtains the physical page structure pointer based on the physical address.

+

LOS_PaddrToKVaddr

+

Obtains the kernel virtual address based on the physical address.

+
+ +### How to Develop + +APIs need to be called to request memory. Heap management APIs are recommended for requesting small amount of memory. Physical memory management APIs are recommended for requesting 4 KiB or larger memory. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- APIs used for requesting physical memory can be used only after memory initialization is complete by calling **OsSysMemInit**. +>- The basic unit for memory allocation is page frame, that is, 4 KiB. +>- To leave contiguous memory blocks for the modules that demand them, use **LOS\_PhysPagesAllocContiguous** to request contiguous memory blocks and use **LOS\_PhysPagesAlloc** to request memory blocks that are not contiguous. + +### Development Example + +This example calls APIs to request and release memory, including requesting one and multiple memory pages. + +``` +#include "los_vm_phys.h" + +#define PHYS_PAGE_SIZE 0x4000 + +// Request a page. +VOID OsPhysPagesAllocTest3(VOID) +{ + PADDR_T newPaddr; + VOID *kvaddr = NULL; + LosVmPage *newPage = NULL; + + newPage = LOS_PhysPageAlloc(); + if (newPage == NULL) { + printf("LOS_PhysPageAlloc fail\n"); + return; + } + printf("LOS_PhysPageAlloc success\n"); + + newPaddr = VM_PAGE_TO_PHYS(newPage); + kvaddr = OsVmPageToVaddr(newPage); + + // Handle the physical memory + + // Free the physical memory + LOS_PhysPageFree(newPage); +} + +// Request multiple pages that do not need to be contiguous. +VOID OsPhysPagesAllocTest2(VOID) +{ + UINT32 sizeCount; + UINT32 count; + UINT32 size = PHYS_PAGE_SIZE; + LosVmPage *vmPageArray[PHYS_PAGE_SIZE >> PAGE_SHIFT] = { NULL }; + UINT32 i = 0; + LosVmPage *vmPage = NULL; + PADDR_T pa; + + size = LOS_Align(size, PAGE_SIZE); + if (size == 0) { + return; + } + sizeCount = size >> PAGE_SHIFT; + + LOS_DL_LIST_HEAD(pageList); + + count = LOS_PhysPagesAlloc(sizeCount, &pageList); + if (count < sizeCount) { + printf("failed to allocate enough pages (ask %zu, got %zu)\n", sizeCount, count); + goto ERROR; + } + printf("LOS_PhysPagesAlloc success\n"); + while ((vmPage = LOS_ListRemoveHeadType(&pageList, LosVmPage, node))) { + pa = vmPage->physAddr; + vmPageArray[i++] = vmPage; + // Handle the physical memory + } + + // Free the physical memory + for (i = 0; i < sizeCount; ++i) { + LOS_PhysPageFree(vmPageArray[i]); + } + + return; + +ERROR: + (VOID)LOS_PhysPagesFree(&pageList); +} + +// Request multiple contiguous memory pages. +VOID OsPhysPagesAllocTest1(VOID) +{ + VOID *ptr = NULL; + LosVmPage *page = NULL; + UINT32 size = PHYS_PAGE_SIZE; + + ptr = LOS_PhysPagesAllocContiguous(ROUNDUP(size, PAGE_SIZE) >> PAGE_SHIFT); + if (ptr == NULL) { + printf("LOS_PhysPagesAllocContiguous fail\n"); + return; + } + + printf("LOS_PhysPagesAllocContiguous success\n"); + + // Handle the physical memory + + // Free the physical memory + page = OsVmVaddrToPage((VOID *)ptr); + LOS_PhysPagesFreeContiguous((VOID *)ptr, size >> PAGE_SHIFT); +} + +UINT32 ExamplePhyMemCaseEntry(VOID) +{ + OsPhysPagesAllocTest1(); + OsPhysPagesAllocTest2(); + OsPhysPagesAllocTest3(); + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +LOS_PhysPagesAllocContiguous success +LOS_PhysPagesAlloc success +LOS_PhysPageAlloc success +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-memory-virtual.md b/en/device-dev/kernel/kernel-small-basic-memory-virtual.md new file mode 100644 index 0000000000000000000000000000000000000000..8f6e6389e4f444153881c4383177b9ac7e8d46cf --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-memory-virtual.md @@ -0,0 +1,333 @@ +# Virtual Memory Management + +- [Basic Concepts](#section650193717411) +- [Working Principles](#section072885512412) +- [Development Guidelines](#section20956116050) + - [Available APIs](#section166137221657) + - [How to Develop](#section8752103914513) + + +## Basic Concepts + +Virtual memory management is a technology used by computer systems to manage memory. Each process has a continuous virtual address space. The size of the virtual address space is determined by the number of CPU bits. The maximum addressing space for a 32-bit hardware platform ranges from 0 GiB to 4 GiB. The 4 GiB space is divided into two parts: 3 GiB higher-address space for the LiteOS-A kernel and 1 GiB lower-address space for processes. The virtual address space of each process space is independent, and the code and data do not affect each other. + +The system divides the virtual memory into memory blocks called virtual pages. The size of a virtual page is generally 4 KiB or 64 KiB. The virtual page of the LiteOS-A kernel is 4 KiB by default. You can configure memory management units \(MMUs\) as required. The minimum unit of the virtual memory management is a page. A virtual address region in the LiteOS-A kernel can contain one virtual page or multiple virtual pages with contiguous addresses. Similarly, the physical memory is also divided by page, and each memory block is called page frame. The virtual address space is divided as follows: 3 GiB \(**0x40000000** to **0xFFFFFFFF**\) for the kernel space and 1 GiB \(**0x01000000** to **0x3F000000**\) for the user space. The following tables describe the virtual address plan. You can view or configure virtual addresses in **los\_vm\_zone.h**. + +**Table 1** Kernel-space addresses + + + + + + + + + + + + + + + + + + + + +

Zone

+

Description

+

Property

+

DMA zone

+

Addresses for direct memory access (DMA) of I/O devices.

+

Uncache

+

Normal zone

+

Addresses for loading the kernel code segment, data segment, heap, and stack.

+

Cache

+

high mem zone

+

Addresses for allocating contiguous virtual memory. The mapped physical memory blocks may not be contiguous.

+

Cache

+
+ +**Table 2** User-space virtual addresses + + + + + + + + + + + + + + + + + + + + + + + + +

Zone

+

Description

+

Property

+

Code segment

+

User-space code segment address range

+

Cache

+

Heap

+

User-space heap address range

+

Cache

+

Stack

+

User-space stack address range

+

Cache

+

Shared library

+

Address range for loading the user-space shared library, including the address range mapped by mmap.

+

Cache

+
+ +## Working Principles + +In virtual memory management, the virtual address space is contiguous, but the mapped physical memory is not necessarily contiguous, as shown in the following figure. When an executable program is loaded and runs, the CPU accesses the code or data in the virtual address space in the following two cases: + +- If the page \(for example, V0\) containing the virtual address accessed by the CPU is mapped to a physical page \(for example, P0\), the CPU locates the page table entry corresponding to the process \(for details, see [Virtual-to-Physical Mapping](kernel-small-basic-inner-reflect.md)"\), accesses the physical memory based on the physical address information in the page table entry, and returns the content. +- If the page \(for example, V2\) containing the virtual address accessed by the CPU is not mapped to a physical page, the system triggers a page missing fault, requests a physical page, copies the corresponding information to the physical page, and updates the start address of the physical page to the page table entry. Then, the CPU can access specific code or data by executing the instruction for accessing the virtual memory again. + +**Figure 1** Mapping between the virtual and physical memory addresses +![](figure/mapping-between-the-virtual-and-physical-memory-addresses.png "mapping-between-the-virtual-and-physical-memory-addresses") + +## Development Guidelines + +### Available APIs + +**Table 3** Virtual memory management module APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Obtaining process memory space

+

LOS_CurrSpaceGet

+

Obtains the pointer to the current process space structure.

+

LOS_SpaceGet

+

Obtains the pointer to the process space structure corresponding to the virtual address.

+

LOS_GetKVmSpace

+

Obtains the pointer to the kernel process space structure.

+

LOS_GetVmallocSpace

+

Obtains the pointer to the vmalloc space structure.

+

LOS_GetVmSpaceList

+

Obtains the pointer to the process space linked list.

+

Operations related to the virtual address region

+

LOS_RegionFind

+

Checks whether a virtual address region exists in the process space based on the start address.

+

LOS_RegionRangeFind

+

Checks whether a virtual address region exists in the process space based on the address region.

+

LOS_IsRegionFileValid

+

Checks whether the virtual address region is mapped to a file.

+

LOS_RegionAlloc

+

Requests a free virtual address region.

+

LOS_RegionFree

+

Releases a specific region in the process space.

+

LOS_RegionEndAddr

+

Obtains the end address of the specified address region.

+

LOS_RegionSize

+

Obtains the size of a region.

+

LOS_IsRegionTypeFile

+

Checks whether it is a file memory mapping.

+

LOS_IsRegionPermUserReadOnly

+

Checks whether the address region is read-only in the user space.

+

LOS_IsRegionFlagPrivateOnly

+

Checks whether the address region has private attributes.

+

LOS_SetRegionTypeFile

+

Sets the file memory mapping attribute.

+

LOS_IsRegionTypeDev

+

Checks whether it is device memory mapping.

+

LOS_SetRegionTypeDev

+

Sets the device memory mapping attribute.

+

LOS_IsRegionTypeAnon

+

Checks whether it is an anonymous mapping.

+

LOS_SetRegionTypeAnon

+

Sets the anonymous mapping attribute.

+

Verifying address

+

LOS_IsUserAddress

+

Checks whether the address is in the user space.

+

LOS_IsUserAddressRange

+

Checks whether the address region is in the user space.

+

LOS_IsKernelAddress

+

Checks whether the address is in the kernel space.

+

LOS_IsKernelAddressRange

+

Checks whether the address region is in the kernel space.

+

LOS_IsRangeInSpace

+

Checks whether the address region is in the process space.

+

vmalloc operations

+

LOS_VMalloc

+

Requests memory using vmalloc.

+

LOS_VFree

+

Releases memory using vmalloc.

+

LOS_IsVmallocAddress

+

Checks whether the address is requested by using vmalloc.

+

Requesting memory

+

LOS_KernelMalloc

+

Requests memory less than 16 KiB from the heap memory pool; otherwise, requests multiple contiguous physical memory pages.

+

LOS_KernelMallocAlign

+

Requests memory with alignment attributes according to the following rules: obtain memory less than 16 KiB from the heap memory pool; otherwise, request multiple contiguous physical memory pages.

+

LOS_KernelFree

+

Releases kernel heap memory.

+

LOS_KernelRealloc

+

Reallocates the kernel memory space.

+

Others

+

LOS_PaddrQuery

+

Obtains the physical IP address based on the virtual address.

+

LOS_VmSpaceFree

+

Releases the process space, including the virtual memory region and page table.

+

LOS_VmSpaceReserve

+

Reserves a memory space in the process space.

+

LOS_VaddrToPaddrMmap

+

Maps the physical address region with the specified length to a virtual address region. You need to request the physical address region before the operation.

+

LOS_UserSpaceVmAlloc

+

Requests an address region in the user process space based on information such as the address, size, and permission.

+
+ +### How to Develop + +To use APIs related to virtual memory: + +1. Obtain the process space structure using the APIs for obtaining the process space, and access the structure information. +2. Perform the following operations on the virtual address region: + - Call **LOS\_RegionAlloc** to request a virtual address region. + + - Call **LOS\_RegionFind** and **LOS\_RegionRangeFind** to check whether the corresponding address region exists. + - Call **LOS\_RegionFree** to release a virtual address region. + +3. Call **vmalloc** and memory requesting APIs to apply for memory in the kernel as required. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>The physical memory requested by using the memory requesting APIs must be contiguous. If the system cannot provide a large number of contiguous memory blocks, the request fails. Therefore, the memory requesting APIs are recommended for requesting small memory blocks. Non-contiguous physical memory can be obtained by using **vmalloc**. However, the memory is allocated in the unit of pages \(4096 bytes/page in the current system\). If you want memory that is an integer multiple of a page, you can use **vmalloc**. For example, you can use **vmalloc** to request memory for file reading in a file system, which demands a large cache. + diff --git a/en/device-dev/kernel/kernel-small-basic-memory.md b/en/device-dev/kernel/kernel-small-basic-memory.md new file mode 100644 index 0000000000000000000000000000000000000000..ebe667d5bc9b8b81b1d916ab03ce151a9bac4c94 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-memory.md @@ -0,0 +1,11 @@ +# Memory Management + +- **[Heap Memory Management](kernel-small-basic-memory-heap.md)** + +- **[Physical Memory Management](kernel-small-basic-memory-physical.md)** + +- **[Virtual Memory Management](kernel-small-basic-memory-virtual.md)** + +- **[Virtual-to-Physical Mapping](kernel-small-basic-inner-reflect.md)** + + diff --git a/en/device-dev/kernel/kernel-small-basic-process-process.md b/en/device-dev/kernel/kernel-small-basic-process-process.md new file mode 100644 index 0000000000000000000000000000000000000000..1486a3e1e86931efa9c7fe2cec1e665f5b337e47 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-process-process.md @@ -0,0 +1,178 @@ +# Process + +- [Basic Concepts](#section89346055119) +- [Working Principles](#section174514474512) +- [Development Guidelines](#section159637182521) + - [Available APIs](#section1153124135212) + - [How to Develop](#section1533674618526) + + +## Basic Concepts + +A process is the minimum unit for system resource management. The process module provided by the OpenHarmony LiteOS-A kernel is used to isolate user-space processes. The kernel space is considered as a process space and does not have other processes except KIdle, which is an idle process provided by the system and shares the same process space with KProcess. + +- The OpenHarmony process module allows multiple processes to run simultaneously, switch, and communicate, facilitating your management over service programs. +- The OpenHarmony processes use the preemption scheduling mechanism. The process with a higher priority is scheduled over the process with a lower priority. Time slice round-robin is used to schedule processes with the same priority. +- The OpenHarmony processes are assigned 32 priorities \(**0** to **31**\). Among them, user processes can be configured with 22 priorities from **10** \(highest\) to **31** \(lowest\). +- A higher-priority process can preempt the resources of a lower-priority process. The lower-priority process can be scheduled only after the higher-priority process is blocked or terminated. +- Each user-space process has its own memory space, which is invisible to other processes. In this way, processes are isolated from each other. +- The user-space root process **init** is created by the kernel. Other user-space processes are created by the **init** process via the **fork** call. + +**Process States:** + +- Init: The process is being created. + +- Ready: The process is in the Ready queue and waits for being scheduled by the CPU. +- Running: The process is running. +- Pending: The process is blocked and suspended. When all threads in a process are blocked, the process is blocked and suspended. +- Zombies: The process stops running and waits for the parent process to reclaim its control block resources. + +**Figure 1** Process state transition +![](figure/process-state-transition.png "process-state-transition") + +**Process State Transition:** + +- Init→Ready: + + When a process is created, the process enters the Init state to start initialization after obtaining the process control block. After the process is initialized, the process is inserted into the scheduling queue and therefore enters the Ready state. + +- Ready→Running: + + When a process switchover is triggered, the process with the highest priority in the Ready queue is executed and enters the Running state. If this process has no thread in the Ready state, the process is deleted from the Ready queue and resides only in the Running state. However, if it has threads in the Ready state, the process still stays in the Ready queue. In this case, the process is in both the Ready and Running states, but presented as the Running state. + +- Running→Pending: + + When the last thread of a process enters the Pending state, all threads in the process are in the Pending state. Then, the process enters the Pending state, and process switching occurs. + +- Pending→Ready: + + When any thread in a Pending process restores to the Ready state, the process is added to the Ready queue and changes to the Ready state. + +- Ready→Pending: + + When the last ready thread in a process enters the Pending state, the process is deleted from the Ready queue, and the process changes from the Ready state to the Pending state. + +- Running→Ready: + + A process may change from the Running state to the Ready state in either of the following scenarios: + + 1. After a process with a higher priority is created or restored, processes will be scheduled. The process with the highest priority in the Ready queue will change to the Running state, and the originally running process will change from the Running state to the Ready state. + 2. If a process has the **LOS\_SCHED\_RR** scheduling policy and shares the same priority with another process in the Ready state, this process will change from the Running state to the Ready state after its time slices are used up, and the other process with the same priority will change from the Ready state to the Running state. + +- Running→Zombies: + + After the main thread or all threads of a process are stopped, the process changes from the **Running** state to the **Zombies** state and waits for the parent process to reclaim resources. + + +## Working Principles + +The OpenHarmony process module is used to isolate user-space processes and supports the following functions: creating and exiting user-space processes, reclaiming process resources, setting and obtaining scheduling parameters and process group IDs, and obtaining process IDs. + +A user-space process is created by forking a parent process. During forking, the virtual memory space of the parent process is cloned to the child process. When the child process is running, the content of the parent process is copied to the virtual memory space of the child process as required through the copy-on-write mechanism. + +A process is only a resource management unit, and the actual running is executed by threads in the process. When threads in different processes switch with each other, the process space is switched. + +**Figure 2** Process management + + +![](figure/en-us_image_0000001127519136.png) + +## Development Guidelines + +### Available APIs + +**Table 1** Process management module APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Process scheduling parameter control

+

LOS_GetProcessScheduler

+

Obtains the scheduling policy of the specified process.

+

LOS_SetProcessScheduler

+

Sets the scheduling parameters, including the priority and scheduling policy, for the specified process.

+

LOS_GetProcessPriority

+

Obtains the priority of the specified process.

+

LOS_SetProcessPriority

+

Sets the priority of the specified process.

+

Waiting for reclaiming child processes

+

LOS_Wait

+

Waits for the specified child process to terminate and reclaims its resources.

+

Process group

+

LOS_GetProcessGroupID

+

Obtains the process group ID of the specified process.

+

LOS_GetCurrProcessGroupID

+

Obtains the process group ID of the current process.

+

Obtaining the process ID.

+

LOS_GetCurrProcessID

+

Obtains the ID of the current process.

+

User and user group

+

LOS_GetUserID

+

Obtains the user ID of the current process.

+

LOS_GetGroupID

+

Obtains the user group ID of the current process.

+

LOS_CheckInGroups

+

Checks whether the specified user group ID is in the user group of the current process.

+

Maximum number of processes supported

+

LOS_GetSystemProcessMaximum

+

Obtains the maximum number of processes supported by the system.

+
+ +### How to Develop + +Kernel-space processes cannot be created. Therefore, kernel-space process development is not involved. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The number of idle threads depends on the number of CPU cores. Each CPU has a corresponding idle thread. +>- Except KProcess and KIdle, other kernel-space processes cannot be created. +>- The thread created by calling a user-space process in the kernel space is a KProcess, not a user-space process. + diff --git a/en/device-dev/kernel/kernel-small-basic-process-scheduler.md b/en/device-dev/kernel/kernel-small-basic-process-scheduler.md new file mode 100644 index 0000000000000000000000000000000000000000..d1110b4033948296524efcfcdafb0a4894df219c --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-process-scheduler.md @@ -0,0 +1,63 @@ +# Scheduler + +- [Basic Concepts](#section123882355719) +- [Working Principles](#section143015396572) +- [Development Guidelines](#section10604192145816) + - [Available APIs](#section207985910582) + - [How to Develop](#section1015110331584) + + +## Basic Concepts + +The OpenHarmony LiteOS-A kernel uses the preemptive scheduling mechanism for tasks. The task with a higher priority is scheduled over the task with a lower priority. Time slice round-robin is used to schedule tasks with the same priority. The system runs based on the real-time timeline from the startup, which ensures good real-time performance of the scheduling algorithm. + +The OpenHarmony scheduling algorithm is embedded with the tickless mechanism, which ensures lower power consumption and on-demand response to tick interrupts. This minimizes useless tick interrupt response time and further improves the real-time performance of the system. + +The OpenHarmony process scheduling policy is **SCHED\_RR**, and the thread scheduling policy can be **SCHED\_RR** or **SCHED\_FIFO**. + +Threads are the minimum scheduling units in the OpenHarmony. + +## Working Principles + +The OpenHarmony uses process priority queue and thread priority queue for scheduling. The process priority ranges from 0 to 31, and there are 32 process priority bucket queues. Each bucket queue corresponds to a thread priority bucket queue. The thread priority ranges from 0 to 31, and a thread priority bucket queue also has 32 priority queues. + +**Figure 1** Schematic diagram of scheduling priority bucket queues + + +![](figure/en-us_image_0000001127520662.png) + +The OpenHarmony system starts scheduling after the kernel initialization is complete. The processes or threads created during running are added to the scheduling queues. The system selects the optimal thread for scheduling based on the priorities of the processes and threads and the time slice consumption of the threads. Once a thread is scheduled, it is deleted from the scheduling queue. If a thread is blocked during running, the thread is added to the corresponding blocking queue and triggers scheduling of another thread. If no thread in the scheduling queue can be scheduled, the system selects the thread of the KIdle process for scheduling. + +**Figure 2** Scheduling process + + +![](figure/en-us_image_0000001176974089.png) + +## Development Guidelines + +### Available APIs + + + + + + + + + + + + +

Category

+

API

+

Description

+

System scheduling

+

LOS_Schedule

+

Triggers system scheduling.

+
+ +### How to Develop + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>Scheduling cannot be triggered during the system initialization process. + diff --git a/en/device-dev/kernel/kernel-small-basic-process-thread.md b/en/device-dev/kernel/kernel-small-basic-process-thread.md new file mode 100644 index 0000000000000000000000000000000000000000..4f255f922e8f9096b0d005dd29ef555bf15bf996 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-process-thread.md @@ -0,0 +1,331 @@ +# Thread + +- [Basic Concepts](#section138411646175417) +- [Working Principles](#section1381918945512) +- [Development Guidelines](#section10649727135519) + - [Available APIs](#section78333315555) + - [How to Develop](#section16229657115514) + - [Development Example](#section2809723165612) + + +## Basic Concepts + +Threads are the minimum running units that compete for system resources. They can use or wait to use CPUs and use system resources such as memory. They run independently from one another. + +Threads in the processes of the same priority in the OpenHarmony kernel are scheduled and run in a unified manner. + +Threads in the OpenHarmony kernel use the preemptive scheduling mechanism, either round-robin \(RR\) scheduling or First In First Out \(FIFO\) scheduling. + +Threads in the OpenHarmony kernel are assigned 32 priorities, ranging from **0** \(highest\) to **31** \(lowest\). + +In the same process, a higher-priority process can preempt resources of a lower-priority process. The lower-priority process can be scheduled only after the higher-priority process is blocked or terminated. + +**Thread States:** + +- Init: The thread is being created. + +- Ready: The thread is in the Ready queue and waits for being scheduled by the CPU. +- Running: The thread is running. +- Blocked: The thread is blocked and suspended. The Blocked states include pending \(blocked due to lock, event, or semaphore issues\), suspended \(active pending\), delay \(blocked due to delays\), and pendtime \(blocked by waiting timeout of locks, events, or semaphores\). +- Exit: The thread stops running and waits for the parent thread to reclaim its control block resources. + +**Figure 1** Thread state transition +![](figure/thread-state-transition.png "thread-state-transition") + +**Thread State Transition:** + +- Init→Ready: + + When a thread is created, the thread obtains the control block and enters the Init state \(initialization\). After the initialization is complete, the thread is inserted into the scheduling queue and enters the Ready state. + +- Ready→Running: + + When a thread switching is triggered, the thread with the highest priority in the Ready queue is executed and enters the Running state. Then, this thread is deleted from the Ready queue. + +- Running→Blocked: + + When a running thread is blocked \(for example, is pended, delayed, or reading semaphores\), its state changes from Running to Blocked. Then, a thread switching is triggered to run the thread with the highest priority in the Ready queue. + +- Blocked→Ready: + + After the blocked thread is restored \(the thread is restored, the delay times out, the semaphore reading times out, or the semaphore is read\), the thread is added to the Ready queue and changes from the Blocked state to the Ready state. + +- Ready→Blocked: + + A thread may also be blocked \(suspended\) in the Ready state. The blocked thread will change from the Ready state to the Blocked state and is deleted from the Ready queue. The thread will not be scheduled until it is restored. + +- Running→Ready: + + After a thread with a higher priority is created or restored, threads will be scheduled. The thread with the highest priority in the Ready queue will change to the Running state. The originally running thread will change from the Running state to the Ready state and be added to the Ready queue. + +- Running→Exit: + + When a running thread is terminated, its state changes from Running to Exit. If the thread is set with a detach attribute \(**LOS\_TASK\_STATUS\_DETACHED**\), it will be directly destroyed after the running is complete. + + +## Working Principles + +The OpenHarmony thread management module provides the following functions: creating, delaying, suspending, and restoring threads, locking and unlocking thread scheduling, and querying thread control block information by ID. + +When a thread is created, the system initializes the thread stack and presets the context. The system places the thread entry function in the corresponding position so that the function will be executed when the thread enters the Running state for the first time. + +## Development Guidelines + +### Available APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Thread creation and deletion

+

LOS_TaskCreateOnly

+

Creates a thread and places the thread in the Init state but not be scheduled.

+

LOS_TaskCreate

+

Creates a thread and places the thread in the Init state and be scheduled.

+

LOS_TaskDelete

+

Deletes the specified thread.

+

Thread status control

+

LOS_TaskResume

+

Resumes a suspended thread.

+

LOS_TaskSuspend

+

Suspends the specified thread.

+

LOS_TaskDelay

+

Delays a thread.

+

LOS_TaskYield

+

Adjusts the scheduling sequence of threads that call the thread priority.

+

Thread scheduling control

+

LOS_TaskLock

+

Locks thread scheduling.

+

LOS_TaskUnlock

+

Unlocks thread scheduling.

+

Thread priority control

+

LOS_CurTaskPriSet

+

Sets the priority for the current thread.

+

LOS_TaskPriSet

+

Sets the priority of the specified thread.

+

LOS_TaskPriGet

+

Obtains the priority of the specified thread.

+

Obtaining thread information

+

LOS_CurTaskIDGet

+

Obtains the ID of the current thread.

+

LOS_TaskInfoGet

+

Obtains information about the specific thread.

+

Binding threads to CPU cores

+

LOS_TaskCpuAffiSet

+

Binds a specified thread to a specified CPU. It is used only in multi-core scenarios.

+

LOS_TaskCpuAffiGet

+

Obtains the core binding information of a specified thread. It is used only in multi-core scenarios.

+

Thread scheduling parameter control

+

LOS_GetTaskScheduler

+

Obtains the scheduling policy of the specified thread.

+

LOS_SetTaskScheduler

+

Sets the scheduling parameters, including the priority and scheduling policy, for the specified thread.

+

Maximum number of threads supported

+

LOS_GetSystemTaskMaximum

+

Obtains the maximum number of threads supported by the system.

+
+ +### How to Develop + +The typical thread development process is as follows: + +1. Call **LOS\_TaskCreate** to create a thread. + - Specify the execution entry function for the thread. + + - Specify the thread name. + - Specify the thread stack size. + - Specify the priority of the thread. + - Specify the thread attribute, that is, whether to support the **LOS\_TASK\_STATUS\_DETACHED** attribute. + - Specify the thread-core binding attribute for multi-core environment. + +2. Run the service code to implement thread scheduling. +3. After the thread execution is complete, the thread resources are automatically reclaimed if the **LOS\_TASK\_STATUS\_DETACHED** attribute is set. If the **LOS\_TASK\_STATUS\_DETACHED** attribute is not set, call the **LOS\_TaskDelete** API to reclaim the thread resources. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The kernel space has the highest permission and can operate threads in any process. +>- The thread created by calling a user-space process in the kernel space is a KProcess, not a user-space process. + +### Development Example + +The sample code is as follows: + +``` +UINT32 g_taskLoID; +UINT32 g_taskHiID; +#define TSK_PRIOR_HI 4 +#define TSK_PRIOR_LO 5 +UINT32 ExampleTaskHi(VOID) +{ + UINT32 ret; + PRINTK("Enter TaskHi Handler.\n"); + /* Delay the thread for 2 ticks. The task is then suspended, and the remaining task with the highest priority (g_taskLoID) will be executed.*/ + ret = LOS_TaskDelay(2); + if (ret != LOS_OK) { + PRINTK("Delay Task Failed.\n"); + return LOS_NOK; + } + /*After 2 ticks elapse, the task is resumed and executed.*/ + PRINTK("TaskHi LOS_TaskDelay Done.\n"); + /* Suspend the task.*/ + ret = LOS_TaskSuspend(g_taskHiID); + if (ret != LOS_OK) { + PRINTK("Suspend TaskHi Failed.\n"); + return LOS_NOK; + } + PRINTK("TaskHi LOS_TaskResume Success.\n"); + return LOS_OK; +} + +/* Entry function of the lower-priority task */ +UINT32 ExampleTaskLo(VOID) +{ + UINT32 ret; + PRINTK("Enter TaskLo Handler.\n"); + /* Delay the thread for 2 ticks. The task is then suspended, and the remaining task with the highest priority (background task) will be executed.*/ + ret = LOS_TaskDelay(2); + if (ret != LOS_OK) { + PRINTK("Delay TaskLo Failed.\n"); + return LOS_NOK; + } + PRINTK("TaskHi LOS_TaskSuspend Success.\n"); + /* Resume the suspended task g_taskHiID.*/ + ret = LOS_TaskResume(g_taskHiID); + if (ret != LOS_OK) { + PRINTK("Resume TaskHi Failed.\n"); + return LOS_NOK; + } + PRINTK("TaskHi LOS_TaskDelete Success.\n"); + return LOS_OK; +} +/* Task test entry function, which is used to create two tasks with different priorities.*/ +UINT32 ExampleTaskCaseEntry(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S initParam = {0}; + + /* Lock task scheduling.*/ + LOS_TaskLock(); + PRINTK("LOS_TaskLock() Success!\n"); + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)ExampleTaskHi; + initParam.usTaskPrio = TSK_PRIOR_HI; + initParam.pcName = "HIGH_NAME"; + initParam.uwStackSize = LOS_TASK_MIN_STACK_SIZE; + initParam.uwResved = LOS_TASK_STATUS_DETACHED; + + /* Create a task with a higher priority. The task will not be executed immediately after being created, because task scheduling is locked.*/ + ret = LOS_TaskCreate(&g_taskHiID, &initParam); + if (ret != LOS_OK) { + LOS_TaskUnlock(); + PRINTK("ExampleTaskHi create Failed! ret=%d\n", ret); + return LOS_NOK; + } + PRINTK("ExampleTaskHi create Success!\n"); + + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)ExampleTaskLo; + initParam.usTaskPrio = TSK_PRIOR_LO; + initParam.pcName = "LOW_NAME"; + initParam.uwStackSize = LOS_TASK_MIN_STACK_SIZE; + initParam.uwResved = LOS_TASK_STATUS_DETACHED; + + /*Create a task with a lower priority. The task will not be executed immediately after being created, because task scheduling is locked.*/ + ret = LOS_TaskCreate(&g_taskLoID, &initParam); + if (ret!= LOS_OK) { + LOS_TaskUnlock(); + PRINTK("ExampleTaskLo create Failed!\n"); + return LOS_NOK; + } + PRINTK("ExampleTaskLo create Success!\n"); + + /* Unlock task scheduling. The task with the highest priority in the Ready queue will be executed.*/ + LOS_TaskUnlock(); + + while(1){}; + return LOS_OK; +} +``` + +The development is successful if the return result is as follows: + +``` +LOS_TaskLock() Success! +ExampleTaskHi create Success! +ExampleTaskLo create Success! +Enter TaskHi Handler. +Enter TaskLo Handler. +TaskHi LOS_TaskDelay Done. +TaskHi LOS_TaskSuspend Success. +TaskHi LOS_TaskResume Success. +TaskHi LOS_TaskDelete Success. +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-process.md b/en/device-dev/kernel/kernel-small-basic-process.md new file mode 100644 index 0000000000000000000000000000000000000000..5bd51676cfa7d86ba1ece51da4f2af06759207c9 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-process.md @@ -0,0 +1,9 @@ +# Process Management + +- **[Process](kernel-small-basic-process-process.md)** + +- **[Thread](kernel-small-basic-process-thread.md)** + +- **[Scheduler](kernel-small-basic-process-scheduler.md)** + + diff --git a/en/device-dev/kernel/kernel-small-basic-softtimer.md b/en/device-dev/kernel/kernel-small-basic-softtimer.md new file mode 100644 index 0000000000000000000000000000000000000000..84a1fe8ccf23a8353054907ec1e36d41710e5c44 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-softtimer.md @@ -0,0 +1,236 @@ +# Software Timer + +- [Basic Concepts](#section4118241563) +- [Working Principles](#section31079397569) +- [Development Guidelines](#section18576131520577) + - [Available APIs](#section3138019145719) + - [How to Develop](#section1344817403575) + - [Development Example](#section114416313585) + + +## Basic Concepts + +The software timer is a software-simulated timer based on system tick interrupts. When the preset tick counter value has elapsed, the user-defined callback will be invoked. The timing precision is related to the cycle of the system tick clock. Due to the limitation in hardware, the number of hardware timers cannot meet users' requirements. Therefore, the Huawei LiteOS provides the software timer function. The software timer allows more timing services to be created, increasing the number of timers. + +The software timer supports the following functions: + +- Disabling the software timer using a macro +- Creating a software timer +- Starting a software timer +- Stopping a software timer +- Deleting a software timer +- Obtaining the number of remaining ticks of a software timer + +## Working Principles + +The software timer is a system resource. When modules are initialized, a contiguous section of memory is allocated for software timers. The maximum number of timers supported by the system is configured by the **LOSCFG\_BASE\_CORE\_SWTMR\_LIMIT** macro in **los\_config.h**. Software timers use a queue and a task resource of the system. The software timers are triggered based on the First In First Out \(FIFO\) rule. For the timers set at the same time, the timer with a shorter value is always closer to the queue head than the timer with a longer value, and is preferentially triggered. The software timer counts time in ticks. When a software timer is created and started, the OpenHarmony system determines the timer expiry time based on the current system time \(in ticks\) and the timing interval set by the user, and adds the timer control structure to the global timing list. + +When a tick interrupt occurs, the tick interrupt handler scans the global timing list for expired timers. If such timers are found, the timers are recorded. + +When the tick interrupt handling function is complete, the software timer task \(with the highest priority\) is woken up. In this task, the timeout callback function for the recorded timer is called. + +Timer States + +- OS\_SWTMR\_STATUS\_UNUSED + + The timer is not in use. When the timer module is initialized, all timer resources in the system are set to this state. + +- OS\_SWTMR\_STATUS\_CREATED + + The timer is created but not started or the timer is stopped. When **LOS\_SwtmrCreate** is called for a timer that is not in use or **LOS\_SwtmrStop** is called for a newly started timer, the timer changes to this state. + +- OS\_SWTMR\_STATUS\_TICKING + + The timer is running \(counting\). When **LOS\_SwtmrStart** is called for a newly created timer, the timer enters this state. + + +Timer Modes + +The OpenHarmony provides three types of software timers: + +- One-shot timer: Once started, the timer is automatically deleted after triggering only one timer event. +- Periodic timer: This type of timer periodically triggers timer events until it is manually stopped. +- One-shot timer deleted by calling an API + +## Development Guidelines + +### Available APIs + +The following table describes APIs available for the OpenHarmony LiteOS-A software timer module. For more details about the APIs, see the API reference. + +**Table 1** Software timer APIs + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting timers

+

LOS_SwtmrCreate

+

Creates a software timer.

+

LOS_SwtmrDelete

+

Deletes a software timer.

+

Starting or stopping timers

+

LOS_SwtmrStart

+

Starts a software timer.

+

LOS_SwtmrStop

+

Stops a software timer.

+

Obtaining remaining ticks of a software timer

+

LOS_SwtmrTimeGet

+

Obtains the number of remaining ticks of a software timer.

+
+ +### How to Develop + +The typical development process of software timers is as follows: + +1. Configure the software timer. + - Check that **LOSCFG\_BASE\_CORE\_SWTMR** and **LOSCFG\_BASE\_IPC\_QUEUE** are enabled. + - Configure **LOSCFG\_BASE\_CORE\_SWTMR\_LIMIT** \(maximum number of software timers supported by the system\). + - Configure **OS\_SWTMR\_HANDLE\_QUEUE\_SIZE** \(maximum length of the software timer queue\). + +2. Call **LOS\_SwtmrCreate** to create a software timer. + - Create a software timer with the specified timing duration, timeout handling function, and triggering mode. + - Return the function execution result \(success or failure\). + +3. Call **LOS\_SwtmrStart** to start the software timer. +4. Call **LOS\_SwtmrTimeGet** to obtain the remaining number of ticks of the software timer. +5. Call **LOS\_SwtmrStop** to stop the software timer. +6. Call **LOS\_SwtmrDelete** to delete the software timer. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- Avoid too many operations in the callback function of the software timer. Do not use APIs or perform operations that may cause task suspension or blocking. +>- The software timers use a queue and a task resource of the system. The priority of the software timer tasks is set to **0** and cannot be changed. +>- The number of software timer resources that can be configured in the system is the total number of software timer resources available to the entire system, not the number of software timer resources available to users. For example, if the system software timer occupies one more resource, the number of software timer resources available to users decreases by one. +>- If a one-shot software timer is created, the system automatically deletes the timer and reclaims resources after the timer times out and the callback function is executed. +>- For a one-shot software timer that will not be automatically deleted after expiration, you need to call **LOS\_SwtmrDelete** to delete it and reclaim the timer resource to prevent resource leakage. + +### Development Example + +Prerequisites: + +- In **los\_config.h**, **LOSCFG\_BASE\_CORE\_SWTMR** is enabled. +- The maximum number of software timers supported by the system \(**LOSCFG\_BASE\_CORE\_SWTMR\_LIMIT**\) is configured. +- The maximum length of the software timer queue \(OS\_SWTMR\_HANDLE\_QUEUE\_SIZE\) is configured. + +**Sample Code** + +``` +#include "los_swtmr.h" + +void Timer1_Callback(uint32_t arg); +void Timer2_Callback(uint32_t arg); + +UINT32 g_timercount1 = 0; +UINT32 g_timercount2 = 0; + +void Timer1_Callback(uint32_t arg) // Callback function 1 +{ + unsigned long tick_last1; + g_timercount1++; + tick_last1=(UINT32)LOS_TickCountGet(); // Obtain the current number of ticks. + PRINTK("g_timercount1=%d\n",g_timercount1); + PRINTK("tick_last1=%d\n",tick_last1); +} + +void Timer2_Callback(uint32_t arg) // Callback function 2 +{ + unsigned long tick_last2; + tick_last2=(UINT32)LOS_TickCountGet(); + g_timercount2 ++; + PRINTK("g_timercount2=%d\n",g_timercount2); + PRINTK("tick_last2=%d\n",tick_last2); +} + +void Timer_example(void) +{ + UINT16 id1; + UINT16 id2; // timer id + UINT32 uwTick; + + /* Create a one-shot software timer, with the number of ticks set to 1000. When the number of ticks reaches 1000, callback function 1 is executed. */ + LOS_SwtmrCreate (1000, LOS_SWTMR_MODE_ONCE, Timer1_Callback, &id1, 1); + + /* Create a periodic software timer and execute callback function 2 every 100 ticks. */ + LOS_SwtmrCreate(100, LOS_SWTMR_MODE_PERIOD, Timer2_Callback, &id2, 1); + PRINTK("create Timer1 success\n"); + + LOS_SwtmrStart (id1); // Start the one-shot software timer. + dprintf("start Timer1 success\n"); + LOS_TaskDelay(200); // Delay 200 ticks. + LOS_SwtmrTimeGet(id1, &uwTick); // Obtain the number of remaining ticks of the one-short software timer. + PRINTK("uwTick =%d\n", uwTick); + + LOS_SwtmrStop(id1); // Stop the software timer. + PRINTK("stop Timer1 success\n"); + + LOS_SwtmrStart(id1); + LOS_TaskDelay(1000); + LOS_SwtmrDelete(id1); // Delete the software timer. + PRINTK("delete Timer1 success\n"); + + LOS_SwtmrStart(id2); // Start the periodic software timer. + PRINTK("start Timer2\n"); + + LOS_TaskDelay(1000); + LOS_SwtmrStop(id2); + LOS_SwtmrDelete(id2); +} +``` + +**Output** + +``` +create Timer1 success +start Timer1 success +uwTick =800 +stop Timer1 success +g_timercount1=1 +tick_last1=1201 +delete Timer1 success +start Timer2 +g_timercount2 =1 +tick_last1=1301 +g_timercount2 =2 +tick_last1=1401 +g_timercount2 =3 +tick_last1=1501 +g_timercount2 =4 +tick_last1=1601 +g_timercount2 =5 +tick_last1=1701 +g_timercount2 =6 +tick_last1=1801 +g_timercount2 =7 +tick_last1=1901 +g_timercount2 =8 +tick_last1=2001 +g_timercount2 =9 +tick_last1=2101 +g_timercount2 =10 +tick_last1=2201 +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-time.md b/en/device-dev/kernel/kernel-small-basic-time.md new file mode 100644 index 0000000000000000000000000000000000000000..d83df28cd43720327df312cd0b0a2f4a1c574187 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-time.md @@ -0,0 +1,153 @@ +# Time Management + +- [Basic Concepts](#section12903185785119) +- [Development Guidelines](#section430981720522) + - [Available APIs](#section1040142705214) + - [How to Develop](#section1381224710522) + - [Development Example](#section1344610245416) + + +## Basic Concepts + +Time management provides all time-related services for applications based on the system clock. The system clock is generated by the interrupts triggered by the output pulse of a timer or counter. The system clock is generally defined as an integer or a long integer. The period of an output pulse is a "clock tick". The system clock is also called time scale or tick. The duration of a tick can be configured statically. People use second or millisecond as the time unit, while the operating system uses tick. When operations such as suspending a task or delaying a task are performed, the time management module converts time between ticks and seconds or milliseconds. + +The mapping between ticks and seconds can be configured. + +- **Cycle** + + Cycle is the minimum time unit in the system. The cycle duration is determined by the system clock frequency, that is, the number of cycles per second. + + +- **Tick** + + Tick is the basic time unit of the operating system and is determined by the number of ticks per second configured by the user. + + +The OpenHarmony time management module provides time conversion, statistics, and delay functions to meet users' time requirements. + +## Development Guidelines + +The time management module provides APIs to implement conversion between the system running time, ticks, and seconds/milliseconds. + +### Available APIs + +The following table describes APIs available for the OpenHarmony LiteOS-A time management. For more details about the APIs, see the API reference. + +**Table 1** APIs of the time management module + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Time conversion

+

LOS_MS2Tick

+

Converts milliseconds into ticks.

+

LOS_Tick2MS

+

Converts ticks into milliseconds.

+

Time statistics

+

LOS_TickCountGet

+

Obtains the current number of ticks.

+

LOS_CyclePerTickGet

+

Obtains the number of cycles per tick.

+
+ +### How to Develop + +1. Call APIs to convert time. +2. Call APIs to perform time statistics. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The system tick count can be obtained only after the system clock is enabled. +>- The time management module depends on **OS\_SYS\_CLOCK** and **LOSCFG\_BASE\_CORE\_TICK\_PER\_SECOND** in **los\_config.h**. +>- The number of system ticks is not counted when the interrupt feature is disabled. Therefore, the number of ticks cannot be used as the accurate time. + +### Development Example + +Prerequisites: + +- **LOSCFG\_BASE\_CORE\_TICK\_PER\_SECOND**, that is, the number of ticks per second in the system is configured. +- **OS\_SYS\_CLOCK**, that is, system clock \(in Hz\), is configured. + +**Sample Code** + +Time conversion: + +``` +VOID Example_TransformTime(VOID) +{ + UINT32 uwMs; + UINT32 uwTick; + uwTick = LOS_MS2Tick(10000);// Convert 10000 ms into ticks. + PRINTK("uwTick = %d \n",uwTick); + uwMs= LOS_Tick2MS(100); // Convert 100 ticks into ms. + PRINTK("uwMs = %d \n",uwMs); +} +``` + +Time statistics and delay: + +``` +VOID Example_GetTime(VOID) +{ + UINT32 uwcyclePerTick; + UINT64 uwTickCount; + + uwcyclePerTick = LOS_CyclePerTickGet(); // Obtain the number of cycles per tick. + if(0 != uwcyclePerTick) + { + PRINTK("LOS_CyclePerTickGet = %d \n", uwcyclePerTick); + } + + uwTickCount = LOS_TickCountGet(); // Obtain the number of ticks. + if(0 != uwTickCount) + { + PRINTK("LOS_TickCountGet = %d \n", (UINT32)uwTickCount); + } + LOS_TaskDelay(200);// Delay 200 ticks. + uwTickCount = LOS_TickCountGet(); + if(0 != uwTickCount) + { + PRINTK("LOS_TickCountGet after delay = %d \n", (UINT32)uwTickCount); + } +} +``` + +**Verification** + +The result is as follows: + +Time conversion: + +``` +uwTick = 10000 +uwMs = 100 +``` + +Time statistics and delay: + +``` +LOS_CyclePerTickGet = 49500 +LOS_TickCountGet = 5042 +LOS_TickCountGet after delay = 5242 +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-trans-event.md b/en/device-dev/kernel/kernel-small-basic-trans-event.md new file mode 100644 index 0000000000000000000000000000000000000000..0978b1fed621576cae3427d37ce79138faccc280 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-trans-event.md @@ -0,0 +1,251 @@ +# Event + +- [Basic Concepts](#section122115620816) +- [Working Principles](#section94611116593) + - [Event Control Block](#section1161415384467) + - [Working Principles](#section187761153144617) + +- [Development Guidelines](#section44744471891) + - [Available APIs](#section172373513919) + - [How to Develop](#section1118215161013) + - [Development Example](#section19986143311020) + - [Example Description](#section128221510145718) + - [Sample Code](#section71507479577) + - [Verification](#section16570171645813) + + +## Basic Concepts + +An event is a mechanism for communication between tasks. It can be used to synchronize tasks. + +In multi-task environment, synchronization is required between tasks. Events implement the following types of synchronization: + +- One-to-many synchronization: A task waits for the triggering of multiple events. A task is woken up by one or multiple events. +- Many-to-many synchronization: Multiple tasks wait for the triggering of multiple events. + +The events provided by the OpenHarmony LiteOS-A event module have the following features: + +- A task triggers or waits for an event by creating an event control block. +- Events are independent of each other. The internal implementation is a 32-bit unsigned integer, and each bit indicates an event type. The 25th bit is unavailable. Therefore, a maximum of 31 event types are supported. +- Events are used only for synchronization between tasks, but not for data transmission. +- Writing the same event type to the event control block for multiple times is equivalent to writing the event type only once before the event control block is cleared. +- Multiple tasks can read and write the same event. +- The event read/write timeout mechanism is supported. + +## Working Principles + +### Event Control Block + +``` +/** +* Event control block data structure + */ +typedef struct tagEvent { + UINT32 uwEventID; /* Event set, which is a collection of events processed (written and cleared).*/ + LOS_DL_LIST stEventList; /* List of tasks waiting for specific events*/ +} EVENT_CB_S, *PEVENT_CB_S; +``` + +### Working Principles + +**Initializing an event**: An event control block is created to maintain a collection of processed events and a linked list of tasks waiting for specific events. + +**Writing an event**: When a specified event is written to the event control block, the event control block updates the event set, traverses the task linked list, and determines whether to wake up related task based on the task conditions. + +**Reading an event**: If the read event already exists, it is returned synchronously. In other cases, the return time is determined based on the timeout period and event triggering status. If the wait event condition is met before the timeout period expires, the blocked task will be directly woken up. Otherwise, the blocked task will be woken up only after the timeout period has expired. + +The input parameters **eventMask** and **mode** determine whether the condition for reading an event is met. **eventMask** indicates the mask of the event. **mode** indicates the handling mode, which can be any of the following: + +- **LOS\_WAITMODE\_AND**: Event reading is successful only when all the events corresponding to **eventMask** occur. Otherwise, the task will be blocked, or an error code will be returned. +- **LOS\_WAITMODE\_OR**: Event reading is successful when any of the events corresponding to **eventMask** occur. Otherwise, the task will be blocked, or an error code will be returned. +- **LOS\_WAITMODE\_CLR**: This mode must be used with **LOS\_WAITMODE\_AND** or **LOS\_WAITMODE\_OR** \(LOS\_WAITMODE\_AND | LOS\_WAITMODE\_CLR or LOS\_WAITMODE\_OR | LOS\_WAITMODE\_CLR\). In this mode, if **LOS\_WAITMODE\_AND** or **LOS\_WAITMODE\_OR** is successful, the corresponding event type bit in the event control block will be automatically cleared. + +**Clearing event**: Clear the event set of the event control block based on the specified mask. If the mask is **0**, the event set will be cleared. If the mask is **0xffff**, no event will be cleared, and the event set remains unchanged. + +**Destroying an event**: Destroy the specified event control block. + +**Figure 1** Event working mechanism +![](figure/event-working-mechanism-21.png "event-working-mechanism-21") + +## Development Guidelines + +### Available APIs + +The following table describes APIs available for the OpenHarmony LiteOS-A event module. + +**Table 1** Event module APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Initializing events

+

LOS_EventInit

+

Initialize an event control block.

+

Reading/Writing events

+

LOS_EventRead

+

Reads a specified type of event, with the timeout period of a relative time period in ticks.

+

LOS_EventWrite

+

Writes a specified type of event.

+

Clearing events

+

LOS_EventClear

+

Clears a specified type of event.

+

Checking the event mask

+

LOS_EventPoll

+

Returns whether the event input by the user meets the expectation based on the event ID, event mask, and read mode passed by the user.

+

Destroying events

+

LOS_EventDestroy

+

Destroys a specified event control block.

+
+ +### How to Develop + +The typical event development process is as follows: + +1. Initialize an event control block. +2. Block a read event control block. +3. Write related events. +4. Wake up a blocked task, read the event, and check whether the event meets conditions. +5. Handle the event control block. +6. Destroy an event control block. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- When an event is read or written, the 25th bit of the event is reserved and cannot be set. +>- Repeated writes of the same event are treated as one write. + +### Development Example + +### Example Description + +In this example, run the **Example\_TaskEntry** task to create the **Example\_Event** task. Run the **Example\_Event** task to read an event to trigger task switching. Run the **Example\_TaskEntry** task to write an event. You can understand the task switching during event operations based on the sequence in which logs are recorded. + +1. Create the **Example\_Event** task in the **Example\_TaskEntry** task with a higher priority than the **Example\_TaskEntry** task. +2. Run the **Example\_Event** task to read event **0x00000001**. Task switching occurs to execute the **Example\_TaskEntry** task. +3. Run the **Example\_TaskEntry** task to write event **0x00000001**. Task switching occurs to execute the **Example\_Event** task. +4. The **Example\_Event** task is executed. +5. The **Example\_TaskEntry** task is executed. + +### Sample Code + +The sample code is as follows: + +``` +#include "los_event.h" +#include "los_task.h" +#include "securec.h" + +/* Task ID*/ +UINT32 g_testTaskId; + +/* Event control structure*/ +EVENT_CB_S g_exampleEvent; + +/* Type of the wait event*/ +#define EVENT_WAIT 0x00000001 + +/* Example task entry function*/ +VOID Example_Event(VOID) +{ + UINT32 event; + + /* Set a timeout period for event reading to 100 ticks. If the specified event is not read within 100 ticks, the read operation times out and the task is woken up.*/ + printf("Example_Event wait event 0x%x \n", EVENT_WAIT); + + event = LOS_EventRead(&g_exampleEvent, EVENT_WAIT, LOS_WAITMODE_AND, 100); + if (event == EVENT_WAIT) { + printf("Example_Event,read event :0x%x\n", event); + } else { + printf("Example_Event,read event timeout\n"); + } +} + +UINT32 Example_EventEntry(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S task1; + + /* Initialize the event.*/ + ret = LOS_EventInit(&g_exampleEvent); + if (ret != LOS_OK) { + printf("init event failed .\n"); + return -1; + } + + /* Create a task.*/ + (VOID)memset_s(&task1, sizeof(TSK_INIT_PARAM_S), 0, sizeof(TSK_INIT_PARAM_S)); + task1.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_Event; + task1.pcName = "EventTsk1"; + task1.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task1.usTaskPrio = 5; + ret = LOS_TaskCreate(&g_testTaskId, &task1); + if (ret != LOS_OK) { + printf("task create failed.\n"); + return LOS_NOK; + } + + /* Write the task wait event (g_testTaskId). */ + printf("Example_TaskEntry write event.\n"); + + ret = LOS_EventWrite(&g_exampleEvent, EVENT_WAIT); + if (ret != LOS_OK) { + printf("event write failed.\n"); + return LOS_NOK; + } + + /* Clear the flag.*/ + printf("EventMask:%d\n", g_exampleEvent.uwEventID); + LOS_EventClear(&g_exampleEvent, ~g_exampleEvent.uwEventID); + printf("EventMask:%d\n", g_exampleEvent.uwEventID); + + /* Delete the task.*/ + ret = LOS_TaskDelete(g_testTaskId); + if (ret != LOS_OK) { + printf("task delete failed.\n"); + return LOS_NOK; + } + + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +Example_Event wait event 0x1 +Example_TaskEntry write event. +Example_Event,read event :0x1 +EventMask:1 +EventMask:0 +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-trans-mutex.md b/en/device-dev/kernel/kernel-small-basic-trans-mutex.md new file mode 100644 index 0000000000000000000000000000000000000000..202ee9ee9d58893a85aa88663a58881818c084c0 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-trans-mutex.md @@ -0,0 +1,317 @@ +# Mutex + +- [Basic Concepts](#section85865329185) +- [Working Principles](#section8547454201819) +- [Development Guidelines](#section2038861117194) + - [Available APIs](#section11168318131917) + - [How to Develop](#section4201191122116) + - [Development Example](#section10679328202117) + + +## Basic Concepts + +A mutual exclusion \(mutex\) is a special binary semaphore used for exclusive access to shared resources. When a task holds the mutex, the task obtains the ownership of the mutex. When the task releases the mutex, the task will lose the ownership of the mutex. When a task holds a mutex, other tasks cannot hold the mutex. In an environment where multiple tasks compete for shared resources, the mutex can protect the shared resources via exclusive access. + +A mutex has three attributes: protocol attribute, priority upper limit attribute, and type attribute. The protocol attribute is used to handle a mutex requested by tasks of different priorities. The protocol attribute can be any of the following: + +- LOS\_MUX\_PRIO\_NONE + + Do not inherit or protect the priority of the task requesting the mutex. + +- LOS\_MUX\_PRIO\_INHERIT + + Inherits the priority of the task that requests the mutex. This is the default protocol attribute. When the mutex protocol attribute is set to this value: If a task with a higher priority is blocked because the mutex is already held by a task, the priority of the task holding the mutex will be copied to the priority bitmap of the task control block, and then set to be the same as that of the task of a higher priority. When the task holding the mutex releases the mutex, the task priority is restored to its original value. + +- LOS\_MUX\_PRIO\_PROTECT + + Protects the priority of the task that requests the mutex. When the mutex protocol attribute is set to this value: If the priority of the task that requests the mutex is lower than the upper limit of the mutex priority, the task priority will be backed up to the priority bitmap of the task control block, and then set to the upper limit value of the mutex priority. When the mutex is released, the task priority is restored to its original value. + + +The type attribute of a mutex specifies whether to check for deadlocks and whether to support recursive holding of the mutex. The type attribute can be any of the following: + +- LOS\_MUX\_NORMAL + + Common mutex, which does not check for deadlocks. If a task repeatedly attempts to hold a mutex, the thread will be deadlocked. If the mutex type attribute is set to this value, a task cannot release a mutex held by another task or repeatedly release a mutex. Otherwise, unexpected results will be caused. + +- LOS\_MUX\_RECURSIVE + + Recursive mutex, which is the default attribute. If the type attribute of a mutex is set to this value, a task can hold the mutex for multiple times. Another task can hold this mutex only when the number of lock holding times is the same as the number of lock release times. However, any attempt to hold a mutex held by another task or attempt to release a mutex that has been released will cause an error code. + +- LOS\_MUX\_ERRORCHECK + + Allows automatic check for deadlocks. When a mutex is set to this type, an error code will be returned if a task attempts to repeatedly hold the mutex, attempts to release the mutex held by another task, or attempts to release the mutex that has been released. + + +## Working Principles + +In a multi-task environment, multiple tasks may access the same shared resource. However, certain shared resources are not shared, and can only be accessed exclusively by tasks. A mutex can be used to address this issue. + +When non-shared resources are accessed by a task, the mutex is locked. Other tasks will be blocked until the mutex is released by the task. The mutex allows only one task to access the shared resources at a time, ensuring integrity of operations on the shared resources. + +**Figure 1** Mutex working mechanism +![](figure/mutex-working-mechanism-23.png "mutex-working-mechanism-23") + +## Development Guidelines + +### Available APIs + +**Table 1** Mutex module APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Initializing or destroying a mutex

+

LOS_MuxInit

+

Initializes a mutex.

+

LOS_MuxDestroy

+

Destroys the specified mutex.

+

Requesting or releasing a mutex

+

LOS_MuxLock

+

Requests the specified mutex.

+

LOS_MuxTrylock

+

Attempts to request the specified mutex without blocking.

+

LOS_MuxUnlock

+

Releases the specified mutex.

+

Verifying a mutex

+

LOS_MuxIsValid

+

Checks whether the mutex release is valid.

+

Initializing or destroying mutex attributes

+

LOS_MuxAttrInit

+

Initializes mutex attributes.

+

LOS_MuxAttrDestroy

+

Destroys the specified mutex attributes.

+

Setting and obtaining mutex attributes

+

LOS_MuxAttrGetType

+

Obtains the type attribute of a specified mutex.

+

LOS_MuxAttrSetType

+

Sets the type attribute of a specified mutex.

+

LOS_MuxAttrGetProtocol

+

Obtains the protocol attribute of a specified mutex.

+

LOS_MuxAttrSetProtocol

+

Sets the protocol attribute of a specified mutex.

+

LOS_MuxAttrGetPrioceiling

+

Obtains the priority upper limit attribute of a specified mutex.

+

LOS_MuxAttrSetPrioceiling

+

Sets the priority upper limit attribute of a specified mutex.

+

LOS_MuxGetPrioceiling

+

Obtains the mutex priority upper limit attribute.

+

LOS_MuxSetPrioceiling

+

Sets the mutex priority upper limit attribute.

+
+ +### How to Develop + +The typical mutex development process is as follows: + +1. Call **LOS\_MuxInit** to initialize a mutex. + +2. Call **LOS\_MuxLock** to request a mutex. + +The following modes are available: + +- Non-block mode: A task acquires the mutex if the requested mutex is not held by any task or the task holding the mutex is the same as the task requesting the mutex. +- Permanent block mode: A task acquires the mutex if the requested mutex is not occupied. If the mutex is occupied, the task will be blocked and the task with the highest priority in the ready queue will be executed. The blocked task can be unlocked and executed only when the mutex is released. +- Scheduled block mode: A task acquires the mutex if the requested mutex is not occupied. If the mutex is occupied, the task will be blocked and the task with the highest priority in the ready queue will be executed. The blocked task can be executed only when the mutex is released within the specified timeout period or when the specified timeout period expires. + +3. Call **LOS\_MuxUnlock** to release a mutex. + +- If tasks are blocked by the specified mutex, the task with a higher priority will be unblocked when the mutex is released. The unblocked task changes to the Ready state and is scheduled. +- If no task is blocked by the specified mutex, the mutex is released successfully. + +4. Call **LOS\_MuxDestroy** to destroy a mutex. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- Two tasks cannot lock the same mutex. If a task attempts to lock a mutex held by another task, the task will be blocked until the mutex is unlocked. +>- Mutexes cannot be used in the interrupt service program. +>- When using the LiteOS-A kernel, the OpenHarmony must ensure real-time task scheduling and avoid long-time task blocking. Therefore, a mutex must be released as soon as possible after use. + +### Development Example + +Example Description + +This example implements the following: + +1. Create a mutex in the **Example\_TaskEntry** task, and lock task scheduling. Create two tasks **Example\_MutexTask1** and **Example\_MutexTask2**. and unlock task scheduling. +2. When being scheduled, **Example\_MutexTask2** requests a mutex in permanent block mode. After acquiring the mutex, **Example\_MutexTask2** enters the sleep mode for 100 ticks. **Example\_MutexTask2** is suspended, and **Example\_MutexTask1** is woken up. +3. **Example\_MutexTask1** requests a mutex in scheduled block mode, and waits for 10 ticks. Because the mutex is still held by **Example\_MutexTask2**, **Example\_MutexTask1** is suspended. After 10 ticks, **Example\_MutexTask1** is woken up and attempts to request a mutex in permanent block mode. **Example\_MutexTask1** is suspended because the mutex is still held by **Example\_MutexTask2**. +4. After 100 ticks, **Example\_MutexTask2** is woken up and releases the mutex, and then **Example\_MutexTask1** is woken up. **Example\_MutexTask1** acquires the mutex and then releases the mutex. At last, the mutex is deleted. + +**Sample Code** + +The sample code is as follows: + +``` +#include +#include "los_mux.h" + +/* Mutex */ +LosMux g_testMux; +/* Task ID*/ +UINT32 g_testTaskId01; +UINT32 g_testTaskId02; + +VOID Example_MutexTask1(VOID) +{ + UINT32 ret; + + printf("task1 try to get mutex, wait 10 ticks.\n"); + /* Request a mutex.*/ + ret = LOS_MuxLock(&g_testMux, 10); + + if (ret == LOS_OK) { + printf("task1 get mutex g_testMux.\n"); + /* Release the mutex.*/ + LOS_MuxUnlock(&g_testMux); + return; + } + if (ret == LOS_ETIMEDOUT ) { + printf("task1 timeout and try to get mutex, wait forever.\n"); + /* Request a mutex.*/ + ret = LOS_MuxLock(&g_testMux, LOS_WAIT_FOREVER); + if (ret == LOS_OK) { + printf("task1 wait forever, get mutex g_testMux.\n"); + /*Release the mutex.*/ + LOS_MuxUnlock(&g_testMux); + /* Delete the mutex. */ + LOS_MuxDestroy(&g_testMux); + printf("task1 post and delete mutex g_testMux.\n"); + return; + } + } + return; +} + +VOID Example_MutexTask2(VOID) +{ + printf("task2 try to get mutex, wait forever.\n"); + /* Request a mutex.*/ + (VOID)LOS_MuxLock(&g_testMux, LOS_WAIT_FOREVER); + + printf("task2 get mutex g_testMux and suspend 100 ticks.\n"); + + /* Enable the task to enter sleep mode for 100 ticks.*/ + LOS_TaskDelay(100); + + printf("task2 resumed and post the g_testMux\n"); + /* Release the mutex.*/ + LOS_MuxUnlock(&g_testMux); + return; +} + +UINT32 Example_MutexEntry(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S task1; + TSK_INIT_PARAM_S task2; + + /* Initializes the mutex./ + LOS_MuxInit(&g_testMux, NULL); + + /* Lock task scheduling.*/ + LOS_TaskLock(); + + /* Create task 1.*/ + memset(&task1, 0, sizeof(TSK_INIT_PARAM_S)); + task1.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_MutexTask1; + task1.pcName = "MutexTsk1"; + task1.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task1.usTaskPrio = 5; + ret = LOS_TaskCreate(&g_testTaskId01, &task1); + if (ret != LOS_OK) { + printf("task1 create failed.\n"); + return LOS_NOK; + } + + /* Create task 2.*/ + memset(&task2, 0, sizeof(TSK_INIT_PARAM_S)); + task2.pfnTaskEntry = (TSK_ENTRY_FUNC)Example_MutexTask2; + task2.pcName = "MutexTsk2"; + task2.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task2.usTaskPrio = 4; + ret = LOS_TaskCreate(&g_testTaskId02, &task2); + if (ret != LOS_OK) { + printf("task2 create failed.\n"); + return LOS_NOK; + } + + /* Unlock task scheduling.*/ + LOS_TaskUnlock(); + + return LOS_OK; +} +``` + +**Verification** + +The development is successful if the return result is as follows: + +``` +task1 try to get mutex, wait 10 ticks. +task2 try to get mutex, wait forever. +task2 get mutex g_testMux and suspend 100 ticks. +task1 timeout and try to get mutex, wait forever. +task2 resumed and post the g_testMux +task1 wait forever, get mutex g_testMux. +task1 post and delete mutex g_testMux. +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-trans-queue.md b/en/device-dev/kernel/kernel-small-basic-trans-queue.md new file mode 100644 index 0000000000000000000000000000000000000000..96ad5f86e8b64f5856a7e534dce1d37260b7dfee --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-trans-queue.md @@ -0,0 +1,266 @@ +# Queue + +- [Basic Concepts](#section81171363232) +- [Working Principles](#section1074515132316) + - [Queue Control Block](#section194431851201315) + - [Working Principles](#section89875741418) + +- [Development Guidelines](#section827981242419) + - [Available APIs](#section19327151642413) + - [How to Develop](#section1390154210243) + +- [Development Example](#section27132341285) + - [Example Description](#section197311443141017) + - [Sample Code](#section972214490107) + - [Verification](#section19287165416106) + + +## Basic Concepts + +A queue, also called a message queue, is a data structure used for communication between tasks. The queue receives messages of unfixed length from tasks or interrupts, and determines whether to store the transferred messages in the queue based on different APIs. + +Tasks can read messages from a queue. When the queue has no messages, the tasks are suspended. When the queue has a new message, the suspended tasks are woken up and process the new message. Tasks can also write messages to the queue. When the queue is full, the write task is suspended. When there is an available message node in the queue, the suspended write task is woken up and writes a message. + +You can adjust the timeout period of the read queue and write queue to adjust the block mode of the read and write APIs. If the timeout period is set to **0** for the read queue and write queue, tasks will not be suspended and the API directly returns. This is the non-block mode. If the timeout period is greater than **0**, block mode is used. + +An asynchronous processing mechanism is provided to allow messages in a queue not to be processed immediately. In addition, queues can be used to buffer messages and implement asynchronous task communication. Queues have the following features: + +- Messages are queued in first-in-first-out \(FIFO\) mode and can be read and written asynchronously. +- Both the read queue and write queue support the timeout mechanism. +- Each time a message is read, the message node becomes available. +- The types of messages to be sent are determined by the parties involved in communication. Messages of different lengths \(not exceeding the message node size of the queue\) are allowed. +- A task can receive messages from and send messages to any message queue. +- Multiple tasks can receive messages from and send messages to the same queue. +- When a queue is created, the required dynamic memory space is automatically allocated in the queue API. + +## Working Principles + +### Queue Control Block + +``` +/** + * Data structure of the queue control block + */ +typedef struct { + UINT8 *queueHandle; /**< Pointer to a queue handle */ + UINT16 queueState; /**< Queue state */ + UINT16 queueLen; /**< Queue length */ + UINT16 queueSize; /**< Node size */ + UINT32 queueID; /**< queueID */ + UINT16 queueHead; /**< Node head */ + UINT16 queueTail; /**< Node tail */ + UINT16 readWriteableCnt[OS_QUEUE_N_RW]; /**< Count of readable or writable resources, 0:readable, 1:writable */ + LOS_DL_LIST readWriteList[OS_QUEUE_N_RW]; /**< the linked list to be read or written, 0:readlist, 1:writelist */ + LOS_DL_LIST memList; /**< Pointer to the memory linked list */ +} LosQueueCB; +``` + +Each queue control block contains information about the queue status. + +- **OS\_QUEUE\_UNUSED**: The queue is not in use. +- **OS\_QUEUE\_INUSED**: The queue is in use. + +### Working Principles + +- The queue ID is returned if a queue is created successfully. +- The queue control block contains **Head** and **Tail**, which indicate the storage status of messages in a queue. **Head** indicates the start position of occupied message nodes in the queue. **Tail** indicates the end position of the occupied message nodes and the start position of idle message nodes. When a queue is created, **Head** and **Tail** point to the start position of the queue. +- When data is to be written to a queue, **readWriteableCnt\[1\]** is used to determine whether data can be written to the queue. If **readWriteableCnt\[1\]** is **0**, the queue is full and data cannot be written to it. Data can be written to the head node or tail node of a queue. To write data to the tail node, locate the start idle message node based on **Tail** and write data to it. If **Tail** is pointing to the tail of the queue, the rewind mode is used. To write data to the head node, locate previous node based on **Head** and write data to it. If **Head** is pointing to the start position of the queue, the rewind mode is used. +- When a queue is to be read, **readWriteableCnt\[0\]** is used to determine whether the queue has messages to read. Reading an idle queue \(**readWriteableCnt\[0\]** is** 0**\) will cause task suspension. If the queue has messages to read, the system locates the first node to which data is written based on **Head** and read the message from the node. If **Head** is pointing to the tail of the queue, the rewind mode is used. +- When a queue is to be deleted, the system locates the queue based on the queue ID, sets the queue status to **OS\_QUEUE\_UNUSED**, sets the queue control block to the initial state, and releases the memory occupied by the queue. + +**Figure 1** Reading and writing data in a queue +![](figure/reading-and-writing-data-in-a-queue.png "reading-and-writing-data-in-a-queue") + +The preceding figure illustrates how to write data to the tail node only. Writing data to the head node is similar. + +## Development Guidelines + +### Available APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting a message queue

+

LOS_QueueCreate

+

Creates a message queue. The system dynamically allocates the queue space.

+

LOS_QueueDelete

+

Deletes the specified queue based on the queue ID.

+

Reading or writing data in a queue (without the content contained in the address)

+

LOS_QueueRead

+

Reads data in the head node of the specified queue. The data in the queue node is an address.

+

LOS_QueueWrite

+

Writes the value of the input parameter bufferAddr (buffer address) to the tail node of the specified queue.

+

LOS_QueueWriteHead

+

Writes the value of the input parameter bufferAddr (buffer address) to the head node of the specified queue.

+

Reading or writing in a queue (with the content contained in the address)

+

LOS_QueueReadCopy

+

Reads data from the head node of the specified queue.

+

LOS_QueueWriteCopy

+

Writes the data saved in the input parameter bufferAddr to the tail node of the specified queue.

+

LOS_QueueWriteHeadCopy

+

Writes the data saved in the input parameter bufferAddr to the head node of the specified queue.

+

Obtaining queue information

+

LOS_QueueInfoGet

+

Obtains information about the specified queue, including the queue ID, queue length, message node size, head node, tail node, number of readable nodes, number of writable nodes, tasks waiting for read operations, and tasks waiting for write operations.

+
+ +### How to Develop + +1. Call **LOS\_QueueCreate** to create a queue. The queue ID is returned when the queue is created. +2. Call **LOS\_QueueWrite** or **LOS\_QueueWriteCopy** to write messages to the queue. +3. Call **LOS\_QueueRead** or **LOS\_QueueReadCopy** to read messages from the queue. +4. Call **LOS\_QueueInfoGet** to obtain queue information. +5. Call **LOS\_QueueDelete** to delete a queue. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The maximum number of queues supported by the system is the total number of queue resources of the system, not the number of queue resources available to users. For example, if the system software timer occupies one more queue resource, the number of queue resources available to users decreases by one. +>- The input parameters queue name and flags passed when a queue is created are reserved for future use. +>- The input parameter **timeOut** in the queue interface function is relative time. +>- **LOS\_QueueReadCopy**, **LOS\_QueueWriteCopy**, and **LOS\_QueueWriteHeadCopy** are a group of APIs that must be used together. **LOS\_QueueRead**, **LOS\_QueueWrite**, and **LOS\_QueueWriteHead** are a group of APIs that must be used together. +>- As **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are used to manage data addresses, you must ensure that the memory directed by the pointer obtained by calling **LOS\_QueueRead** is not modified or released abnormally when the queue is being read. Otherwise, unpredictable results may occur. +>- **LOS\_QueueWrite**, **LOS\_QueueWriteHead**, and **LOS\_QueueRead** are called to manage data addresses, which means that the actual data read or written is pointer data. Therefore, before using these APIs, ensure that the message node size is the pointer length during queue creation, to avoid waste and read failures. + +## Development Example + +### Example Description + +Create a queue and two tasks. Enable task 1 to call the queue write API to send messages, and enable task 2 to receive messages by calling the queue read API. + +1. Create task 1 and task 2 by calling **LOS\_TaskCreate**. +2. Create a message queue by calling **LOS\_QueueCreate**. +3. Enable messages to be sent in task 1 by calling **SendEntry**. +4. Enable messages to be received in task 2 by calling **RecvEntry**. +5. Call **LOS\_QueueDelete** to delete a queue. + +### Sample Code + +The sample code is as follows: + +``` +#include "los_task.h" +#include "los_queue.h" +static UINT32 g_queue; +#define BUFFER_LEN 50 + +VOID SendEntry(VOID) +{ + UINT32 ret = 0; + CHAR abuf[] = "test message"; + UINT32 len = sizeof(abuf); + + ret = LOS_QueueWriteCopy(g_queue, abuf, len, 0); + if(ret != LOS_OK) { + printf("send message failure, error: %x\n", ret); + } +} + +VOID RecvEntry(VOID) +{ + UINT32 ret = 0; + CHAR readBuf[BUFFER_LEN] = {0}; + UINT32 readLen = BUFFER_LEN; + + // Sleep for 1s. + usleep(1000000); + ret = LOS_QueueReadCopy(g_queue, readBuf, &readLen, 0); + if(ret != LOS_OK) { + printf("recv message failure, error: %x\n", ret); + } + + printf("recv message: %s\n", readBuf); + + ret = LOS_QueueDelete(g_queue); + if(ret != LOS_OK) { + printf("delete the queue failure, error: %x\n", ret); + } + + printf("delete the queue success!\n"); +} + +UINT32 ExampleQueue(VOID) +{ + printf("start queue example\n"); + UINT32 ret = 0; + UINT32 task1, task2; + TSK_INIT_PARAM_S initParam = {0}; + + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)SendEntry; + initParam.usTaskPrio = 9; + initParam.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + initParam.pcName = "SendQueue"; + + LOS_TaskLock(); + ret = LOS_TaskCreate(&task1, &initParam); + if(ret != LOS_OK) { + printf("create task1 failed, error: %x\n", ret); + return ret; + } + + initParam.pcName = "RecvQueue"; + initParam.pfnTaskEntry = (TSK_ENTRY_FUNC)RecvEntry; + ret = LOS_TaskCreate(&task2, &initParam); + if(ret != LOS_OK) { + printf("create task2 failed, error: %x\n", ret); + return ret; + } + + ret = LOS_QueueCreate("queue", 5, &g_queue, 0, 50); + if(ret != LOS_OK) { + printf("create queue failure, error: %x\n", ret); + } + + printf("create the queue success!\n"); + LOS_TaskUnlock(); + return ret; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +start test example +create the queue success! +recv message: test message +delete the queue success! +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-trans-rwlock.md b/en/device-dev/kernel/kernel-small-basic-trans-rwlock.md new file mode 100644 index 0000000000000000000000000000000000000000..c6e7edc003dc93a5becbc34d62523dc2f3844d78 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-trans-rwlock.md @@ -0,0 +1,134 @@ +# RW Lock + +- [Basic Concepts](#section4692105214260) +- [Working Principles](#section1239111562720) +- [Development Guidelines](#section11643194275) + - [Available APIs](#section15335332122717) + - [How to Develop](#section14774114882714) + + +## Basic Concepts + +Similar to a mutex, a read-write lock \(RW lock\) can be used to synchronize tasks in the same process. Different from a mutex, an RW lock allows concurrent access for read operations, while write operations require exclusive access. + +An RW lock has three states: locked in read mode, locked in write mode, and unlocked. + +Observe the following rules when using RW locks: + +- If there is no lock in write mode in the protected area, any task can add a lock in read mode. +- A lock in write mode can be added only when the protected area is in the unlocked state. + +In a multi-task environment, multiple tasks may access the same shared resource. A lock in read mode allows access to a protected area in shared mode, and a lock in a write mode allows exclusive access to the shared resource. + +This sharing-exclusive manner is suitable for a multi-task environment where the data read operations are far more than data write operations. It can improve multi-task concurrency of the application. + +## Working Principles + +How does an RW lock implement lock in read mode and lock in write mode to control read/write access of multiple tasks? + +- If task A acquires the lock in write mode for the first time, other tasks cannot acquire or attempt to acquire the lock in read mode. + +- If task A acquires the lock in read mode, the RW lock count increments by 1 when a task acquires or attempts to acquire the lock in read mode. + +## Development Guidelines + +### Available APIs + +**Table 1** Read/write lock module APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating and deleting an RW lock

+

LOS_RwlockInit

+

Creates an RW lock.

+

LOS_RwlockDestroy

+

Deletes the specified RW lock.

+

Requesting a lock in read mode

+

LOS_RwlockRdLock

+

Requests the specified lock in read mode.

+

LOS_RwlockTryRdLock

+

Attempts to request the specified lock in read mode.

+

Requesting a lock in write mode

+

LOS_RwlockWrLock

+

Requests the specified lock in write mode.

+

LOS_RwlockTryWrLock

+

Attempts to request the specified lock in write mode.

+

Releasing an RW lock

+

LOS_RwlockUnLock

+

Releases the specified RW lock.

+

Verifying RW lock validity

+

LOS_RwlockIsValid

+

Checks the validity of an RW lock.

+
+ +### How to Develop + +The typical development process is as follows: + +1. Call **LOS\_RwlockInit** to create an RW lock. + +2. Call **LOS\_RwlockRdLock** to request a lock in read mode or call **LOS\_RwlockWrLock** to request a lock in write mode. + +If a lock in read mode is requested: + +- If the lock is not held, the read task can acquire the lock. +- If the lock is held, the read task acquires the lock and is executed based on the task priority. +- If the lock in write mode is held by another task, the task cannot acquire the lock until the lock in write mode is released. + +If a lock in write mode is requested: + +- If the lock is not held or if the task that holds the lock in read mode is the same as the task that requests the lock in write mode, the task acquires the lock in write mode immediately. +- If the lock already has a lock in read mode and the read task has a higher priority, the current task is suspended until the lock in read mode is released. + +3. There are three types of locks in read mode and write mode: non-block mode, permanent block mode, and scheduled block mode. The difference lies in the task suspension time. + +4. Call **LOS\_RwlockUnLock** to release an RW lock. + +- If tasks are blocked by the specified RW lock, the task with the highest priority is woken up, enters the Ready state, and is scheduled. + +- If no task is blocked by the specified RW lock, the RW lock is released. + +5. Call **LOS\_RwlockDestroy** to delete an RW lock. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The RW lock cannot be used in the interrupt service program. +>- When using the LiteOS-A kernel, the OpenHarmony must ensure real-time task scheduling and avoid long-time task blocking. Therefore, an RW lock must be released as soon as possible after use. +>- When an RW lock is held by a task, the task priority cannot be changed by using APIs such as **LOS\_TaskPriSet**. + diff --git a/en/device-dev/kernel/kernel-small-basic-trans-semaphore.md b/en/device-dev/kernel/kernel-small-basic-trans-semaphore.md new file mode 100644 index 0000000000000000000000000000000000000000..2a3c04fb26454ea3ba54005f33ed78bd50565ef5 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-trans-semaphore.md @@ -0,0 +1,273 @@ +# Semaphore + +- [Basic Concepts](#section1577111168131) +- [Working Principles](#section118423019134) +- [Development Guidelines](#section01419503131) + - [Available APIs](#section1232345431312) + - [How to Develop](#section154261711141419) + - [Development Example](#section658135571417) + - [Example Description](#section125244411653) + - [Sample Code](#section1742105514512) + - [Verification](#section11297301617) + + +## Basic Concepts + +Semaphore is a mechanism for implementing inter-task communication. It implements synchronization between tasks or exclusive access to shared resources. + +In the data structure of a semaphore, there is a value indicating the number of shared resources available. The value can be: + +- **0**: The semaphore is unavailable. Tasks waiting for the semaphore may exist. +- Positive number: The semaphore is available. + +The semaphore for synchronization is different from the semaphore for mutex: + +- Semaphore used for exclusive access: The initial semaphore counter value is not 0, indicating the number of shared resources available. The semaphore counter value must be acquired before a shared resource is used, and released after the resource is used. When all shared resources are used, the semaphore counter is reduced to 0 and the tasks that need to obtain the semaphores will be blocked. This ensures exclusive access to shared resources. In addition, when the number of shared resources is 1, a binary semaphore \(similar to the mutex mechanism\) is recommended. +- Semaphore used for synchronization: The initial semaphore counter value is 0. Task 1 cannot acquire the semaphore and is blocked. Task 1 enters Ready or Running state only when the semaphore is released by task 2. In this way, task synchronization is implemented. + +## Working Principles + +Semaphore control block + +``` +/** + * Data structure of the semaphore control block + */ +typedef struct { + UINT16 semStat; /* Semaphore status */ + UINT16 semType; /* Semaphore type*/ + UINT16 semCount; /* Semaphore count*/ + UINT16 semId; /* Semaphore index*/ + LOS_DL_LIST semList; /* Mount the task blocked by the semaphore.*/ +} LosSemCB; +``` + +Working Principles + +Semaphore allows only a specified number of tasks to access a shared resource at a time. When the number of tasks accessing the resource reaches the limit, other tasks will be blocked until the semaphore is released. + +- Semaphore initialization + + The system allocates memory for the semaphores configured \(you can configure the number of semaphores using the **LOSCFG\_BASE\_IPC\_SEM\_LIMIT** macro\), initializes all semaphores to be unused semaphores, and adds them to a linked list for the system to use. + +- Semaphore creation + + The system obtains a semaphore from the linked list of unused semaphores and assigns an initial value to the semaphore. + +- Semaphore request + + If the counter value is greater than 0, the system allocates a semaphore, decreases the value by 1, and returns a success message. Otherwise, the system blocks the task and adds the task to the end of a task queue waiting for semaphores. The wait timeout period can be set. + +- Semaphore release + + When a semaphore is released, if there is no task waiting for it, the counter is increased by 1. Otherwise, the first task in the wait queue is woken up. + +- Semaphore deletion + + The system sets a semaphore in use to unused state and inserts it to the linked list of unused semaphores. + + +The following figure illustrates the semaphore working mechanism. + +**Figure 1** Semaphore working mechanism +![](figure/semaphore-working-mechanism-22.png "semaphore-working-mechanism-22") + +## Development Guidelines + +### Available APIs + +**Table 1** Semaphore module APIs + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Creating or deleting a semaphore

+

LOS_SemCreate

+

Creates a semaphore and returns the semaphore ID.

+

LOS_BinarySemCreate

+

Creates a binary semaphore. The maximum counter value is 1.

+

LOS_SemDelete

+

Deletes a semaphore.

+

Requesting or releasing a semaphore

+

LOS_SemPend

+

Requests a specified semaphore and sets the timeout period.

+

LOS_SemPost

+

Posts (releases) a semaphore.

+
+ +### How to Develop + +1. Call **LOS\_SemCreate** to create a semaphore. To create a binary semaphore, call **LOS\_BinarySemCreate**. +2. Call **LOS\_SemPend** to request a semaphore. +3. Call **LOS\_SemPost** to release a semaphore. +4. Call **LOS\_SemDelete** to delete a semaphore. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>As interrupts cannot be blocked, semaphores cannot be requested in block mode for interrupts. + +### Development Example + +### Example Description + +This example implements the following: + +1. Create a semaphore in task **ExampleSem** and lock task scheduling. Create two tasks **ExampleSemTask1** and **ExampleSemTask2** \(with higher priority\). Enable the two tasks to request the same semaphore. Unlock task scheduling. Enable task **ExampleSem** to enter sleep mode for 400 ticks. Release the semaphore in task **ExampleSem**. +2. Enable** ExampleSemTask2** to enter sleep mode for 20 ticks after acquiring the semaphore. \(When **ExampleSemTask2** is delayed, **ExampleSemTask1** is woken up.\) +3. Enable **ExampleSemTask1** to request the semaphore in scheduled block mode, with a wait timeout period of 10 ticks. \(Because the semaphore is still held by **ExampleSemTask2**, **ExampleSemTask1** is suspended. **ExampleSemTask1** is woken up after 10 ticks.\) Enable **ExampleSemTask1** to request the semaphore in permanent block mode after it is woken up 10 ticks later. \(Because the semaphore is still held by **ExampleSemTask2**, **ExampleSemTask1** is suspended.\) +4. After 20 ticks, **ExampleSemTask2** is woken up and releases the semaphore. **ExampleSemTask1** acquires the semaphore and is scheduled to run. When **ExampleSemTask1** is complete, it releases the semaphore. +5. Task **ExampleSem** is woken up after 400 ticks and deletes the semaphore. + +### Sample Code + +The sample code is as follows: + +``` +#include "los_sem.h" +#include "securec.h" + +/* Task ID*/ +static UINT32 g_testTaskId01; +static UINT32 g_testTaskId02; + +/* Task priority */ +#define TASK_PRIO_TEST 5 + +/* Semaphore structure ID*/ +static UINT32 g_semId; + +VOID ExampleSemTask1(VOID) +{ + UINT32 ret; + + printf("ExampleSemTask1 try get sem g_semId, timeout 10 ticks.\n"); + + /* Request the semaphore in scheduled block mode, with a wait timeout period of 10 ticks.*/ + ret = LOS_SemPend(g_semId, 10); + + /* The semaphore is acquired.*/ + if (ret == LOS_OK) { + LOS_SemPost(g_semId); + return; + } + /* The semaphore is not acquired when the timeout period has expired.*/ + if (ret == LOS_ERRNO_SEM_TIMEOUT) { + printf("ExampleSemTask1 timeout and try get sem g_semId wait forever.\n"); + + /* Request the semaphore in permanent block mode.*/ + ret = LOS_SemPend(g_semId, LOS_WAIT_FOREVER); + printf("ExampleSemTask1 wait_forever and get sem g_semId.\n"); + if (ret == LOS_OK) { + LOS_SemPost(g_semId); + return; + } + } +} + +VOID ExampleSemTask2(VOID) +{ + UINT32 ret; + printf("ExampleSemTask2 try get sem g_semId wait forever.\n"); + + /* Request the semaphore in permanent block mode.*/ + ret = LOS_SemPend(g_semId, LOS_WAIT_FOREVER); + + if (ret == LOS_OK) { + printf("ExampleSemTask2 get sem g_semId and then delay 20 ticks.\n"); + } + + /* Enable the task to enter sleep mode for 20 ticks.*/ + LOS_TaskDelay(20); + + printf("ExampleSemTask2 post sem g_semId.\n"); + /* Release the semaphore.*/ + LOS_SemPost(g_semId); + return; +} + +UINT32 ExampleSem(VOID) +{ + UINT32 ret; + TSK_INIT_PARAM_S task1; + TSK_INIT_PARAM_S task2; + + /* Create a semaphore.*/ + LOS_SemCreate(0, &g_semId); + + /* Lock task scheduling.*/ + LOS_TaskLock(); + + /* Create task 1.*/ + (VOID)memset_s(&task1, sizeof(TSK_INIT_PARAM_S), 0, sizeof(TSK_INIT_PARAM_S)); + task1.pfnTaskEntry = (TSK_ENTRY_FUNC)ExampleSemTask1; + task1.pcName = "TestTask1"; + task1.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task1.usTaskPrio = TASK_PRIO_TEST; + ret = LOS_TaskCreate(&g_testTaskId01, &task1); + if (ret != LOS_OK) { + printf("task1 create failed .\n"); + return LOS_NOK; + } + + /* Create task 2.*/ + (VOID)memset_s(&task2, sizeof(TSK_INIT_PARAM_S), 0, sizeof(TSK_INIT_PARAM_S)); + task2.pfnTaskEntry = (TSK_ENTRY_FUNC)ExampleSemTask2; + task2.pcName = "TestTask2"; + task2.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE; + task2.usTaskPrio = (TASK_PRIO_TEST - 1); + ret = LOS_TaskCreate(&g_testTaskId02, &task2); + if (ret != LOS_OK) { + printf("task2 create failed.\n"); + return LOS_NOK; + } + + /* Unlock task scheduling.*/ + LOS_TaskUnlock(); + + ret = LOS_SemPost(g_semId); + + /* Enable the task to enter sleep mode for 400 ticks.*/ + LOS_TaskDelay(400); + + /* Delete the semaphore. */ + LOS_SemDelete(g_semId); + return LOS_OK; +} +``` + +### Verification + +The development is successful if the return result is as follows: + +``` +ExampleSemTask2 try get sem g_semId wait forever. +ExampleSemTask2 get sem g_semId and then delay 20 ticks. +ExampleSemTask1 try get sem g_semId, timeout 10 ticks. +ExampleSemTask1 timeout and try get sem g_semId wait forever. +ExampleSemTask2 post sem g_semId. +ExampleSemTask1 wait_forever and get sem g_semId. +``` + diff --git a/en/device-dev/kernel/kernel-small-basic-trans-user-mutex.md b/en/device-dev/kernel/kernel-small-basic-trans-user-mutex.md new file mode 100644 index 0000000000000000000000000000000000000000..acf3c95a4b8a4cf9854ff2fb3f4fb6992c324a63 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-trans-user-mutex.md @@ -0,0 +1,64 @@ +# Futex + +- [Basic Concepts](#section643519912920) +- [Working Principles](#section16834132502910) + +## Basic Concepts + +Fast userspace mutex \(futex\) is a system call capability provided by the kernel. It is a user-space lock that combines basic components and user-space lock logic. It is a lock used by both user space and kernel space, for example, userspace mutex, barrier and cond synchronization lock, and RW lock. The user-space part implements lock logic, and the kernel-space part implements lock scheduling. + +When a user-space thread requests a lock, the lock status is first checked in user space. If no lock contention occurs, the user-space thread acquires the lock directly. If lock contention occurs, the futex system call is invoked to request the kernel to suspend the thread and maintain the blocking queue. + +When a user-space thread releases a lock, the lock status is first checked in user space. If no other thread is blocked by the lock, the lock is directly released in user space. If there are threads blocked by the lock, the futex system call is invoked to request the kernel to wake up the threads in the blocking queue. + +## Working Principles + +When thread scheduling is required to resolve lock contention or lock release in user space, the futex system call is triggered to pass the user-space lock address to the kernel. The user-space locks are distinguished by lock address in the futex of the kernel. The available virtual address space in user space is 1 GiB. To facilitate search and management of lock addresses, the kernel futex uses hash buckets to store the user-space locks. + +There are 80 hash buckets. Buckets 0 to 63 are used to store private locks \(hashed based on virtual addresses\), and buckets 64 to 79 are used to store shared locks \(hashed based on physical addresses\). The private/shared attributes are determined by initialization of user-space locks and the input parameters in the futex system call. + +**Figure 1** Futex design +![](figure/futex-design.jpg "futex-design") + +As shown in above figure, each futex hash bucket stores the futex nodes with the same hash value linked in a futex\_list. Each futex node corresponds to a suspended task. The key value of a node uniquely identifies a user-space lock. The nodes with the same key value added to a queue\_list indicate a queue of tasks blocked by the same lock. + +The following table describes the APIs available for the futex module. + +**Table 1** Futex module APIs + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Putting a thread to wait

+

OsFutexWait

+

Inserts a node representing a blocked thread into the futex list.

+

Waking up a thread

+

OsFutexWake

+

Wakes up a thread that is blocked by a specified lock.

+

Modifying the lock address

+

OsFutexRequeue

+

Adjusts the position of a specified lock in the futex list.

+
+ +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>The futex system call and user-space logic form a user-space lock. Therefore, you are advised to use the locks via the user-space POSIX APIs. + diff --git a/en/device-dev/kernel/kernel-small-basic-trans-user-signal.md b/en/device-dev/kernel/kernel-small-basic-trans-user-signal.md new file mode 100644 index 0000000000000000000000000000000000000000..ddfb38afa0aeb13b9bd99688202b3915ab122ce8 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-trans-user-signal.md @@ -0,0 +1,86 @@ +# Signal + +- [Basic Concepts](#section172788254307) +- [Working Principles](#section1249693812301) + +## Basic Concepts + +Signal is a common inter-process asynchronous communication mechanism. It uses software-simulated interrupt signals. When a process needs to communicate with another process, it sends a signal to the kernel. The kernel then transfers the signal to the destination process. The destination process does not need to wait for the signal. + +## Working Principles + +The following table describes the APIs available for signal operations. + +**Table 1** Signal operation process and APIs \(user-space APIs\) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Registering the signal callback

+

signal

+

Registers the main signal entry, and registers and unregisters the callback function of a signal.

+

sigaction

+

Same as signal. This API is added with configuration options related to signal transmission. Currently, only some parameters in the SIGINFO structure are supported.

+

Sending signals

+

kill

+

Sends a signal to a process or sends messages to a thread in a process, and sets signal flags for threads in a process.

+

pthread_kill

+

raise

+

alarm

+

abort

+

Triggering a callback

+

None

+

Triggered by a system call or an interrupt. Before the switching between the kernel space and user space, the specified function in user space is entered, and the corresponding callbacks are processed. After that, the original user-space program continues to run.

+
+ +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>The signal mechanism enables communication between user-space programs. The user-space POSIX APIs listed in the above table are recommended. +>Register a callback function. +>``` +>void *signal(int sig, void (*func)(int))(int); +>``` +>a. Signal 31 is used to register the handling entry of the process callback. Repeated registration is not allowed. +>b. Signals 0 to 30 are used to register and unregister callbacks. +>Register a callback. +>``` +>int sigaction(int, const struct sigaction *__restrict, struct sigaction *__restrict); +>``` +>You can obtain and modify the configuration of signal registration. Currently, only the **SIGINFO** options are supported. For details, see the description of the **sigtimedwait** API. +>Transmit a signal. +>a. Among the default signal-receiving behaviors, the process does not support **STOP**, **COTINUE**, and **COREDUMP** defined in the POSIX standard. +>b. The SIGSTOP, SIGKILL, and SIGCONT signals cannot be shielded. +>c. If a process killed is not reclaimed by its parent process, the process becomes a zombie process. +>d. A process will not call back the signal received until the process is scheduled. +>e. When a process is killed, **SIGCHLD** is sent to its parent process. The signal sending action cannot be canceled. +>f. A process in the DELAY state cannot be woken up by a signal. + diff --git a/en/device-dev/kernel/kernel-small-basic-trans.md b/en/device-dev/kernel/kernel-small-basic-trans.md new file mode 100644 index 0000000000000000000000000000000000000000..bc7fe50a1f4e337820e456823ba9ceb698276b3f --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basic-trans.md @@ -0,0 +1,17 @@ +# Kernel Communication Mechanisms + +- **[Event](kernel-small-basic-trans-event.md)** + +- **[Semaphore](kernel-small-basic-trans-semaphore.md)** + +- **[Mutex](kernel-small-basic-trans-mutex.md)** + +- **[Queue](kernel-small-basic-trans-queue.md)** + +- **[RW Lock](kernel-small-basic-trans-rwlock.md)** + +- **[Futex](kernel-small-basic-trans-user-mutex.md)** + +- **[Signal](kernel-small-basic-trans-user-signal.md)** + + diff --git a/en/device-dev/kernel/kernel-small-basics.md b/en/device-dev/kernel/kernel-small-basics.md new file mode 100644 index 0000000000000000000000000000000000000000..68ba677548dbfa2ad8f60f841663fe02cd158ede --- /dev/null +++ b/en/device-dev/kernel/kernel-small-basics.md @@ -0,0 +1,17 @@ +# Basic Kernel + +- **[Interrupt and Exception Handling](kernel-small-basic-interrupt.md)** + +- **[Process Management](kernel-small-basic-process.md)** + +- **[Memory Management](kernel-small-basic-memory.md)** + +- **[Kernel Communication Mechanisms](kernel-small-basic-trans.md)** + +- **[Time Management](kernel-small-basic-time.md)** + +- **[Software Timer](kernel-small-basic-softtimer.md)** + +- **[Atomic Operation](kernel-small-basic-atomic.md)** + + diff --git a/en/device-dev/kernel/kernel-small-bundles-fs-new.md b/en/device-dev/kernel/kernel-small-bundles-fs-new.md new file mode 100644 index 0000000000000000000000000000000000000000..2211a971a05c06a11837146b78bfc56d6d20656e --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-fs-new.md @@ -0,0 +1,223 @@ +# File System Adaptation + +- [Basic Concepts](#section19480121811422) +- [Adapting the Mount API](#section147051940104212) +- [Adapting the Lookup API](#section11930181394317) +- [Summary and Precautions](#section5617183014319) + +## Basic Concepts + +The purpose of interconnecting with the VFS layer is to implement API functions defined by the VFS layer. You can adapt some APIs based on the file system features and service requirements. Basically, file read and write must be supported. The minimum file system adaptation is as follows: + +``` +struct MountOps g_yourFsMountOps = { + .Mount = YourMountMethod, +}; + +struct file_operations_vfs g_yourFsFileOps = { + .read = YourReadMethod, + .write = YourWriteMethod, +} + +struct VnodeOps g_yourFsVnodeOps = { + .Create = YourCreateMethod; + .Lookup = YourLookupMethod; + .Reclaim = YourReclaimMethod; +}; + +FSMAP_ENTRY(yourfs_fsmap, "your fs name", g_yourFsMountOps, TRUE, TRUE); // Register the file system. +``` + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>1. The **open** and **close** APIs are not necessarily implemented because they are used to operate files and are imperceptible to the underlying file system. You need to implement these APIs only when special operations need to be performed during the open and close operations on the file system. +>2. Basic file system knowledge is required for file system adaptation. You need to have a deep understanding of the principles and implementation of the target file system. This section does not include the file system basics in detail. If you have any questions during the adaptation process, refer to the code in the **kernel/liteos\_a/fs** directory. + +## Adapting the Mount API + +**Mount** is the first API called by the file system. This API reads the driver parameters, initializes the file system based on the configuration, and generates the root node of the file system. The **Mount** API is defined as follows: + +``` +int (*Mount)(struct Mount *mount, struct Vnode *blkDriver, const void *data); +``` + +The parameter **struct Mount \*mount** specifies information about the mount point. The following variables need to be set during adaptation: + +``` +struct Mount { + const struct MountOps *ops; /* Mount-related function hooks */ + struct Vnode *vnodeCovered; /* root node of the file system generated after the mount*/ + void *data; /* Private data of the mount point*/ +}; +``` + +The parameter **struct Vnode \*blkDriver** specifies the driver node, which can be used to access the driver. + +The parameter **const void \*data** specifies the data passed by the **mount** command and can be processed according to the requirements of the file system. + +The following uses JFFS2 as an example to describe how the adapt the **mount** API: + +``` +int VfsJffs2Bind(struct Mount *mnt, struct Vnode *blkDriver, const void *data) +{ + int ret; + int partNo; + mtd_partition *p = NULL; + struct MtdDev *mtd = NULL; + struct Vnode *pv = NULL; + struct jffs2_inode *rootNode = NULL; + + LOS_MuxLock(&g_jffs2FsLock, (uint32_t)JFFS2_WAITING_FOREVER); + + /* Obtain information required by the file system from the driver node, for example, the partition ID for the JFFS2. */ + p = (mtd_partition *)((struct drv_data *)blkDriver->data)->priv; + mtd = (struct MtdDev *)(p->mtd_info); + + if (mtd == NULL || mtd->type != MTD_NORFLASH) { + LOS_MuxUnlock(&g_jffs2FsLock); + return -EINVAL; + } + + partNo = p->patitionnum; + + /* Generate a root Vnode for the file system. Do not mix rootNode and root Vnode. The rootNode type is inode, which is the private data maintained in JFFS2. Vnode is a common file node of VFS. + This step saves the private information in the file system to the Vnode. As a result, you can directly find the corresponding file in the file system through the Vnode. + */ + ret = jffs2_mount(partNo, &rootNode); + if (ret != 0) { + LOS_MuxUnlock(&g_jffs2FsLock); + return ret; + } + + ret = VnodeAlloc(&g_jffs2Vops, &pv); + if (ret != 0) { + LOS_MuxUnlock(&g_jffs2FsLock); + goto ERROR_WITH_VNODE; + } + + /* The following enters information about the file corresponding to the Vnode. Some file systems may not support uid, gid, and mode, which can be skipped.*/ + pv->type = VNODE_TYPE_DIR; + pv->data = (void *)rootNode; + pv->originMount = mnt; + pv->fop = &g_jffs2Fops; + mnt->data = p; + mnt->vnodeCovered = pv; + pv->uid = rootNode->i_uid; + pv->gid = rootNode->i_gid; + pv->mode = rootNode->i_mode; + + /* HashInsert is used to prevent repeated generation of Vnodes. The second parameter is generally set to the unique file identifier in the file system, for example, the inode address in JFFS2. */ + (void)VfsHashInsert(pv, rootNode->i_ino); + + g_jffs2PartList[partNo] = blkDriver; + + LOS_MuxUnlock(&g_jffs2FsLock); + + return 0; +ERROR_WITH_VNODE: + return ret; +} +... +... +const struct MountOps jffs_operations = { + .Mount = VfsJffs2Bind, + ... + ... +}; +``` + +Summary: + +1. Obtain the required private information from the driver node. +2. Generate the root node of the file system based on the private information. + +## Adapting the **Lookup** API + +**Lookup** is used to search for files. The function prototype of **Lookup** is: + +``` +int (*Lookup)(struct Vnode *parent, const char *name, int len, struct Vnode **vnode); +``` + +This function searches for the Vnode from the parent node based on the file name \(**name**\) and file name length \(**len**\) and returns the Vnode to the upper layer. + +You need to specify the parent node information and file name to implement search for the file of the specified name under the parent directory. The following uses JFFS2 as an example: + +``` +int VfsJffs2Lookup(struct Vnode *parentVnode, const char *path, int len, struct Vnode **ppVnode) +{ + int ret; + struct Vnode *newVnode = NULL; + struct jffs2_inode *node = NULL; + struct jffs2_inode *parentNode = NULL; + + LOS_MuxLock(&g_jffs2FsLock, (uint32_t)JFFS2_WAITING_FOREVER); + + /* Obtain information about the parent node from the private data.*/ + parentNode = (struct jffs2_inode *)parentVnode->data; + + /* Obtain information about the target node. Note that the jffs2_lookup function called is a function of JFFS2. */ + node = jffs2_lookup(parentNode, (const unsigned char *)path, len); + if (!node) { + LOS_MuxUnlock(&g_jffs2FsLock); + return -ENOENT; + } + + /* Check whether the located target has an existing vnode, which corresponds to VfsHashInsert mentioned earlier. */ + (void)VfsHashGet(parentVnode->originMount, node->i_ino, &newVnode, NULL, NULL); + LOS_MuxUnlock(&g_jffs2FsLock); + if (newVnode) { + newVnode->parent = parentVnode; + *ppVnode = newVnode; + return 0; + } + + /* If the Vnode does not exist, create a Vnode and enter related information. */ + ret = VnodeAlloc(&g_jffs2Vops, &newVnode); + if (ret != 0) { + PRINT_ERR("%s-%d, ret: %x\n", __FUNCTION__, __LINE__, ret); + (void)jffs2_iput(node); + LOS_MuxUnlock(&g_jffs2FsLock); + return ret; + } + + Jffs2SetVtype(node, newVnode); + newVnode->fop = parentVnode->fop; + newVnode->data = node; + newVnode->parent = parentVnode; + newVnode->originMount = parentVnode->originMount; + newVnode->uid = node->i_uid; + newVnode->gid = node->i_gid; + newVnode->mode = node->i_mode; + + /* Insert the newly created Vnode into the hashtable.*/ + (void)VfsHashInsert(newVnode, node->i_ino); + + *ppVnode = newVnode; + + LOS_MuxUnlock(&g_jffs2FsLock); + return 0; +} +``` + +Summary: + +1. Obtain private data from the parent node. +2. Obtain the private data of the target file based on the private data. +3. Create the target Vnode based on the private data of the target file. + +## Summary and Precautions + +The general adaptation procedure is as follows: + +1. Obtain the private data required by the file system based on the Vnode input parameters. +2. Implement the API based on the private data. +3. Encapsulate the result in the format required by the Vnode or other APIs and return the result to the upper layer. + +The core logic is how to use the private data to implement API functions. These APIs implement common functions of the file systems and are generally implemented before the files systems are ported. Therefore, the key is to determine the private data required by the file system and store the data in Vnode for later use. Generally, the private data is information that can uniquely locate a file on a storage medium. Most file systems have similar data structures, for example, the inode data structure in JFFS2. + +>![](../public_sys-resources/icon-caution.gif) **CAUTION:** +>1. When a file is accessed, the **Lookup** API of the file system is not necessrily called. The **Lookup** API is called only when the path cache is invalid. +>2. Do not directly return the Vnode located by using **VfsHashGet** as the result. The information stored in the Vnode may be invalid. Update the fields and return it. +>3. Vnodes are automatically released in the background based on memory usage. If data needs to be stored persistently, do not save it only in Vnodes. +>4. The **Reclaim** API is automatically called when a Vnode is released. Release the resources used by the private data in this API. + diff --git a/en/device-dev/kernel/kernel-small-bundles-fs-support-fat.md b/en/device-dev/kernel/kernel-small-bundles-fs-support-fat.md new file mode 100644 index 0000000000000000000000000000000000000000..a6c26ea8b3ff6ac15da9eb3a70bf33eca9a003c3 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-fs-support-fat.md @@ -0,0 +1,45 @@ +# FAT + +- [Basic Concepts](#section621393911385) +- [Working Principles](#section10796155213381) +- [Development Guidelines](#section144094483919) + - [How to Develop](#section139086116394) + + +## Basic Concepts + +File Allocation Table \(FAT\) is a file system developed for personal computers. It consists of the Dos Boot Record \(DBR\) region, FAT region, and Data region. Each entry in the FAT region records information about the corresponding cluster in the storage device. The cluster information includes whether the cluster is used, number of the next cluster of the file, whether the file ends. The FAT file system supports multiple formats, such as FAT12, FAT16, and FAT32. The numbers 12, 16, and 32 indicate the number of bytes of the FAT table entries, respectively, and also restrict the maximum file size in the system. The FAT file system supports multiple media, especially removable storage media \(such as USB flash drives, SD cards, and removable hard drives\). The FAT file system ensures good compatibility between embedded devices and desktop systems \(such as Windows and Linux\) and facilitates file management. + +The OpenHarmony kernel supports FAT12, FAT16, and FAT32 file systems. These file systems have a small amount of code, feature small code volume and resource usage, support a variety of physical media, and are tailorable and compatible with Windows and Linux systems. They also support identification of multiple devices and partitions. The kernel supports multiple partitions on hard drives and allows creation of the FAT file system on the primary partition and logical partition. + +## Working Principles + +This document does not include the FAT design and physical layout. You can find a lot of reference on the Internet. + +The OpenHarmony LiteOS-A kernel uses block cache \(Bcache\) to improve the FAT performance. When read and write operations are performed, Bcache caches the sectors close to the read and write sectors to reduce the number of I/Os and improve performance. The basic cache unit of Bcache is block. The size of each block is the same. By default, there are 28 blocks, and each block caches data of 64 sectors. When the Bcache dirty block rate \(number of dirty sectors/total number of sectors\) reaches the threshold, writeback is triggered. If the dirty block rate does not reach the threshold, cached data is not written back to disks. You can call **sync** and **fsync** to write data to disks if you want. Some FAT APIs \(such as **close** and **umount**\) may also trigger writeback operations. However, you are advised not to use these APIs to trigger writeback. + +## Development Guidelines + +### How to Develop + +The development process involves mounting partitions, managing files and directories, and unmounting partitions. + +The device name of the SD card or MMC is **mmcblk\[x\]p\[y\]**, and the file system type is **vfat**. + +Example: + +``` +mount("/dev/mmcblk0p0", "/mnt", "vfat", 0, NULL); +``` + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The size of a single FAT file cannot be greater than 4 GiB. +>- When there are two SD card slots, the first card inserted is card 0, and that inserted later is card 1. +>- When multi-partition is enabled and there are multiple partitions, the device node **/dev/mmcblk0** \(primary device\) registered by card 0 and **/dev/mmcblk0p0** \(secondary device\) are the same device. In this case, you cannot perform operations on the primary device. +>- Before removing an SD card, close the open files and directories and unmount the related nodes. Otherwise, SD card exceptions or memory leaks may occur. +>- Before performing the **format** operation, unmount the mount point. +>- After the Bcache function takes effect, note the following: +> - When **MS\_NOSYNC** is carried in the **mount** function, FAT does not proactively write the content in the cache back to the storage device. The FAT-related APIs **open**, **close**, **unlink**, **rename**, **mkdir**, **rmdir**, and **truncate** do not automatically perform the **sync** operation, which improves the operation speed. However, the upper layer must actively invoke the **sync** operation to synchronize data. Otherwise, data loss may occur. +> - Bcache provides scheduled write-back. After **LOSCFG\_FS\_FAT\_CACHE\_SYNC\_THREAD** is enabled in **menuconfig**, the OpenHarmony kernel creates a scheduled task to write the Bcache data back to disks. By default, the kernel checks the dirty block rate in the Bcache every 5 seconds. If the dirty block rate exceeds 80%, the **sync** operation will be performed to write all dirty data in the Bcache to disks. You can call **LOS\_SetSyncThreadPrio**, **LOS\_SetSyncThreadInterval**, and **LOS\_SetDirtyRatioThreshold** to set the task priority, flush interval, and dirty block rate threshold, respectively. +> - The cache has 28 blocks by default, and each block has 64 sectors. + diff --git a/en/device-dev/kernel/kernel-small-bundles-fs-support-jffs2.md b/en/device-dev/kernel/kernel-small-bundles-fs-support-jffs2.md new file mode 100644 index 0000000000000000000000000000000000000000..cee59071e89c006a35dec492a49b375b357c82de --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-fs-support-jffs2.md @@ -0,0 +1,121 @@ +# JFFS2 + +- [Basic Concepts](#section11411110155919) +- [Working Principles](#section23911025195913) +- [Development Guidelines](#section179711119014) + +## Basic Concepts + +Journalling Flash File System Version 2 \(JFFS2\) is a log-structured file system designed for Memory Technology Devices \(MTDs\). + +JFFS2 is used on the NOR flash memory of the OpenHarmony. JFFS2 is readable and writable, supports data compression, provides crash/power failure protection, and supports wear leveling. There are many differences between flash memory and disk media. Running a disk file system on a flash memory device will lead to performance and security problems. JFFS2 is a file system optimized for flash memory. + +## Working Principles + +This document does not include the physical layout of JFFS2 on storage devices and JFFS2 specifications. For details, see the [official JFFS2 specification document](https://sourceware.org/jffs2/). + +The following describes several important mechanisms and features of JFFS2 that developers may concern. + +1. Mount mechanism and speed: According to the JFFS2 design, all files are divided into nodes of different sizes based on certain rules and stored on the flash memory device in sequence. In the mount process, all node information needs to be obtained and cached in the memory. Therefore, the mount speed is in linear proportion to the flash device capacity and the number of files. This is a native design issue of JFFS2. To increase the mount speed, you can select **Enable JFFS2 SUMMARY** during kernel compilation. If this option is selected, information required by the mount operation will be stored to the flash memory in advance. When the mount operation is performed, this information can be read and parsed quickly, ensuring relatively constant mount speed. However, this space-for-time practice consumes about 8% extra space. +2. Wear leveling: Due to the physical attributes of flash memory devices, read and write operations can be performed only on blocks of a specific size. To prevent certain blocks from being severely worn, wear leveling is used on written blocks in JFFS2 to ensure relatively balanced writes on all blocks. This prolongs the overall service life of the flash memory devices. +3. Garbage collection \(GC\) mechanism: When a deletion operation is performed in JFFS2, the physical memory is not released immediately. An independent GC thread performs GC operations such as space defragmentation and migration. However, GC in JFFS2 affects instantaneous read/write performance, like all GC mechanisms. In addition, JFFS2 reserves about three blocks in each partition for space defragmentation. The reserved space is invisible to users. +4. Compression mechanism: The underlying layer automatically decompresses or compresses the data read or written each time in JFFS2. The actual I/O size is different from the read or write size requested by the user. You cannot estimate whether the write operation will succeed or not based on the size of the written data and the remaining space of the flash memory. +5. Hard link mechanism: JFFS2 supports hard links. Multiple hard links of the same file occupy physical memory space of only one hard link. The physical space is released only when all hard links are deleted. + +## Development Guidelines + +The development based on JFFS2 and NOR flash memory is similar to the development based on other file systems because the VFS shields the differences of specific file systems and the standard POSIX APIs are used as external APIs. + +The raw NOR flash device has no place to centrally manage and record partition information. Therefore, you need to transfer the partition information by using other configuration methods \(using the **bootargs** parameter during image burning\), call the corresponding API in the code to add partitions, and then mount the partitions. + +**Creating a JFFS2 Image** + +Use the **mkfs.jffs2** tool to create an image. The default page size is 4 KiB, and the default **eraseblock** size is 64 KiB. Modify the parameter values to match your development. + +``` +./mkfs.jffs2 -d rootfs/ -o rootfs.jffs2 +``` + +**Table 1** Command description \(run **mkfs.jffs2 --help** to view more details\) + + + + + + + + + + + + + + + + + + + + + + +

Command

+

Description

+

-s

+

Specifies the page size. If this parameter is not specified, the default value 4KiB is used.

+

-e

+

Specifies the eraseblock size. If this parameter is not specified, the default value 64KiB is used.

+

-p

+

Specifies the image size. 0xFF is filled at the end of the image file to make the file to the specified size. If the size is not specified, 0xFF is filled to a value aligned with eraseblock.

+

-d

+

Specifies the source directory of the file system image.

+

-o

+

Specifies the image name.

+
+ +**Mounting a JFFS2 Partition** + +Call **int mount\(const char \*source, const char \*target, const char \*filesystemtype, unsigned long mountflags, const void \*data\)** to mount the device node and mount point. + +This function has the following parameters: + +- **const char \*source** specifies the device node. +- **const char \*target** specifies the mount point. +- **const char \*filesystemtype** specifies the file system type. +- **unsigned long mountflags** specifies the mount flag, which is **0** by default. +- **const void \*data** specifies the data, which is **NULL** by default. + +You can also run the **mount** command in **shell** to mount a JFFS2 partition. You do not need to specify the last two parameters. + +Run the following command: + +``` +OHOS # mount /dev/spinorblk1 /jffs1 jffs2 +``` + +If the following information is displayed, the JFFS2 partition is mounted: + +``` +OHOS # mount /dev/spinorblk1 /jffs1 jffs2 +mount OK +``` + +Now, you can perform read and write operations on the NOR flash memory. + +**Unmounting a JFFS2 Partition** + +Call **int umount\(const char \*target\)** to unmount a partition. You only need to specify the correct mount point. + +Run the following command: + +``` +OHOS # umount /jffs1 +``` + +If the following information is displayed, the JFFS2 partition is unmounted: + +``` +OHOS # umount /jffs1 +umount ok +``` + diff --git a/en/device-dev/kernel/kernel-small-bundles-fs-support-nfs.md b/en/device-dev/kernel/kernel-small-bundles-fs-support-nfs.md new file mode 100644 index 0000000000000000000000000000000000000000..fc24e1bcb1771e43fd73efaf266ba2f2667fc5ad --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-fs-support-nfs.md @@ -0,0 +1,138 @@ +# NFS + +- [Basic Concepts](#section195414101464) +- [Working Principles](#section165621321194618) +- [Development Guidelines](#section7454935184611) + +## Basic Concepts + +NFS allows you to share files across hosts and OSs over a network. You can treat NFS as a file system service, which is equivalent to folder sharing in the Windows OS to some extent. + +## Working Principles + +The NFS of the OpenHarmony LiteOS-A kernel acts as an NFS client. The NFS client can mount the directory shared by a remote NFS server to the local machine and run the programs and shared files without occupying the storage space of the current system. To the local machine, the directory on the remote server is like its disk. + +## Development Guidelines + +1. Create an NFS server. + +The following uses the Ubuntu OS as an example to describe how to configure an NFS server. + +- Install the NFS server software. + +Set the download source of the Ubuntu OS when the network connection is normal. + +``` +sudo apt-get install nfs-kernel-server +``` + +- Create a directory for mounting and assign full permissions for the directory. + +``` +mkdir -p /home/sqbin/nfs +sudo chmod 777 /home/sqbin/nfs +``` + +- Configure and start the NFS server. + +Append the following line in the **/etc/exports** file: + +``` +/home/sqbin/nfs *(rw,no_root_squash,async) +``` + +**/home/sqbin/nfs** is the root directory shared by the NFS server. + +Start the NFS server. + +``` +sudo /etc/init.d/nfs-kernel-server start +``` + +Restart the NFS server. + +``` +sudo /etc/init.d/nfs-kernel-server restart +``` + +1. Configure the board as an NFS client. + +In this section, the NFS client is a device running the OpenHarmony kernel. + +- Set the hardware connection. + +Connect the OpenHarmony kernel device to the NFS server. Set their IP addresses in the same network segment. For example, set the IP address of the NFS server to **10.67.212.178/24** and set the IP address of the OpenHarmony kernel device to **10.67.212.3/24**. Note that the preceding IP addresses are private IP addresses used as examples. You need to use your actual IP addresses. + +You can run the **ifconfig** command to check the OpenHarmony kernel device's IP address. + +- Start the network and ensure that the network between the board and NFS server is normal. + +Start the Ethernet or another type of network, and then run **ping** to check whether the network connection to the server is normal. + +``` +OHOS # ping 10.67.212.178 +[0]Reply from 10.67.212.178: time=1ms TTL=63 +[1]Reply from 10.67.212.178: time=0ms TTL=63 +[2]Reply from 10.67.212.178: time=1ms TTL=63 +[3]Reply from 10.67.212.178: time=1ms TTL=63 +--- 10.67.212.178 ping statistics --- +4 packets transmitted, 4 received, 0 loss +``` + +Initialize the NFS client. + +``` +OHOS # mkdir /nfs +OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000 +``` + +If the following information is displayed, the NFS client is initialized. + +``` +OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000 +Mount nfs on 10.67.212.178:/home/sqbin/nfs, uid:1011, gid:1000 +Mount nfs finished. +``` + +This command mounts the **/home/sqbin/nfs** directory on the NFS server whose IP address is 10.67.212.178 to the **/nfs** directory on the OpenHarmony kernel device. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>This section assumes that the NFS server is available, that is, the **/home/sqbin/nfs** directory on the NFS server 10.67.212.178 is accessible. +>The **mount** command format is as follows: +>``` +>mount nfs +>``` +>- **SERVER\_IP** indicates the IP address of the server. +>- **SERVER\_PATH** indicates the path of the shared directory on the NFS server. +>- **CLIENT\_PATH** indicates the NFS path on the local device. +>- **nfs** indicates the path to which the remote shared directory is mounted on the local device. +>Replace the parameters as required. +>If you do not want to restrict the NFS access permission, set the permission of the NFS root directory to **777** on the Linux CLI. +>``` +>chmod -R 777 /home/sqbin/nfs +>``` +>The NFS client setting is complete, and the NFS file system has been mounted. + +1. Share files using NFS. + +Create the **dir** directory on the NFS server and save the directory. Run the **ls** command in the OpenHarmony kernel. + +``` +OHOS # ls /nfs +``` + +The following information is returned from the serial port: + +``` +OHOS # ls /nfs +Directory /nfs: +drwxr-xr-x 0 u:0 g:0 dir +``` + +The **dir** directory created on the NFS server has been synchronized to the **/nfs** directory on the client \(OpenHarmony kernel system\). + +Similarly, you can create files and directories on the client \(OpenHarmony kernel system\) and access them from the NFS server. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>Currently, the NFS client supports some NFS v3 specifications. Therefore, the NFS client is not fully compatible with all types of NFS servers. You are advised to use the Linux NFS server to perform the development. + diff --git a/en/device-dev/kernel/kernel-small-bundles-fs-support-procfs.md b/en/device-dev/kernel/kernel-small-bundles-fs-support-procfs.md new file mode 100644 index 0000000000000000000000000000000000000000..3b0451434d0782baf0d9ce0192ea102d17b3b22c --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-fs-support-procfs.md @@ -0,0 +1,85 @@ +# procfs + +- [Basic Concepts](#section146801917174017) +- [Working Principles](#section479762916408) +- [Development Guidelines](#section1221174524014) + - [Development Example](#section52016575401) + + +## Basic Concepts + +The proc filesystem \(procfs\) is a virtual file system that displays process or other system information in a file-like structure. It is more convenient to obtain system information in file operation mode compared with API calling mode. + +## Working Principles + +In the OpenHarmony kernel, procfs is automatically mounted to the **/proc** directory during startup. Only the kernel module can create file nodes to provide the query service. + +## Development Guidelines + +To create a procfs file, you need to use **ProcMkdir** to create a directory and use **CreateProcEntry** to create a file. The development of the file node function is to hook the read and write functions to the file created by **CreateProcEntry**. When the procfs file is read or written, the hooked functions will be called to implement customized functions. + +### Development Example + +The following describes how to create the **/proc/hello/world** file to implement the following functions: + +1. Create a file in **/proc/hello/world**. + +2. Read the file. When the file is read, "HelloWorld!" is returned. + +3. Write the file and print the data written in the file. + +``` +#include "proc_fs.h" + +static int TestRead(struct SeqBuf *buf, void *arg) +{ + LosBufPrintf(buf, "Hello World! \n"); /* Print "Hello World!" to the buffer. The data in the buffer will be returned to the read result. */ + return 0; +} + +static int TestWrite(struct ProcFile *pf, const char *buffer, size_t buflen, loff_t *ppos) +{ + if ((buffer == NULL) || (buflen <= 0)) { + return -EINVAL; + } + + PRINTK("your input is: %s\n", buffer); /* Different from the read API, the write API prints the data only to the console. */ + return buflen; +} +static const struct ProcFileOperations HELLO_WORLD_OPS = { + .read = TestRead, + .write = TestWrite, +}; + +void HelloWorldInit(void) +{ + /* Create the hello directory.*/ + struct ProcDirEntry *dir = ProcMkdir("hello", NULL); + if (dir == NULL) { + PRINT_ERR("create dir failed!\n"); + return; + } + + /*Create the world file. */ + struct ProcDirEntry *entry = CreateProcEntry("world", 0, dir); + if (entry == NULL) { + PRINT_ERR("create entry failed!\n"); + return; + } + + /* Hook the customized read and write APIs to the file. */ + entry->procFileOps = &HELLO_WORLD_OPS; +} +``` + +**Verification** + +After the OS startup, run the following command in the shell: + +``` +OHOS # cat /proc/hello/world +OHOS # Hello World! +OHOS # echo "yo" > /proc/hello/world +OHOS # your input is: yo +``` + diff --git a/en/device-dev/kernel/kernel-small-bundles-fs-support-ramfs.md b/en/device-dev/kernel/kernel-small-bundles-fs-support-ramfs.md new file mode 100644 index 0000000000000000000000000000000000000000..20a4931031adc8cb191c798850138e31a42a53a3 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-fs-support-ramfs.md @@ -0,0 +1,64 @@ +# Ramfs + +- [Basic Concepts](#section9507151014420) +- [Working Principles](#section1859711263447) +- [Development Guidelines](#section163554380448) + +## Basic Concepts + +Ramfs is a RAM-based file system whose size can be dynamically adjusted. Ramfs does not have a backing store. Directory entries and page caches are allocated when files are written into ramfs. However, data is not written back to any other storage medium, and data is lost after a power outage. + +## Working Principles + +Ramfs stores all files in RAM, and read/write operations are performed in RAM. Ramfs is generally used to store temporary data or data that needs to be frequently modified, such as the **/tmp** and **/var** directories. Using ramfs reduces the read/write loss of the memory and improves the data read/write speed. + +## Development Guidelines + +Mount: + +``` +mount(NULL, "/dev/shm", "ramfs", 0, NULL) +``` + +Create a directory: + +``` +mkdir(pathname, mode) +``` + +Create a file: + +``` +open(pathname, O_NONBLOCK | O_CREAT | O_RDWR, mode) +``` + +Read a directory: + +``` +dir = opendir(pathname) +ptr = readdir(dir) +closedir(dir) +``` + +Delete a file: + +``` +unlink(pathname) +``` + +Deletes a directory: + +``` +rmdir(pathname) +``` + +Unmount: + +``` +umount("/dev/shm") +``` + +>![](../public_sys-resources/icon-caution.gif) **CAUTION:** +>- A ramfs file system can be mounted only once. Once mounted to a directory, it cannot be mounted to other directories. +>- Ramfs is under debugging and disabled by default. Do not use it in formal products. + diff --git a/en/device-dev/kernel/kernel-small-bundles-fs-support.md b/en/device-dev/kernel/kernel-small-bundles-fs-support.md new file mode 100644 index 0000000000000000000000000000000000000000..ee0741ca974b0fa21236abeb956f48adf43ebd38 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-fs-support.md @@ -0,0 +1,13 @@ +# Supported File Systems + +- **[FAT](kernel-small-bundles-fs-support-fat.md)** + +- **[JFFS2](kernel-small-bundles-fs-support-jffs2.md)** + +- **[NFS](kernel-small-bundles-fs-support-nfs.md)** + +- **[Ramfs](kernel-small-bundles-fs-support-ramfs.md)** + +- **[procfs](kernel-small-bundles-fs-support-procfs.md)** + + diff --git a/en/device-dev/kernel/kernel-small-bundles-fs-virtual.md b/en/device-dev/kernel/kernel-small-bundles-fs-virtual.md new file mode 100644 index 0000000000000000000000000000000000000000..f8fc8e5e1c7cbcb9848c00dfd8d68b50febdb3cd --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-fs-virtual.md @@ -0,0 +1,794 @@ +# Virtual File System + +- [Basic Concepts](#section1253851143520) +- [Working Principles](#section14915913123510) +- [Development Guidelines](#section1759563620358) + - [Available APIs](#section17865142133511) + - [How to Develop](#section64113023616) + - [Development Example](#section236041883618) + + +## Basic Concepts + +The Virtual File System \(VFS\) is not a real file system. It is an abstract layer on top of a heterogeneous file system and provides you with a unified Unix-like file operation interface. Different types of file systems provide different interfaces. If there are multiple types of file systems in the system, different and non-standard interfaces are required for accessing these file systems. The VFS can be introduced as an abstract layer in the system to harmonize the differences between these heterogeneous file systems. In this way, the system does not need to care about the storage medium and file system type at the bottom layer when accessing a file system. + +In the OpenHarmony kernel, the VFS framework is implemented through the tree structure in the memory. Each node of the tree is a **Vnode** structure, and the relationship between the parent and child nodes is stored in the **PathCache** structure. The VFS provides the following functions: + +- Node query +- Unified file system invoking \(standard\) + +## Working Principles + +The VFS layer uses function pointers to call different interfaces for different types of file systems to implement standard APIs. It uses the Vnode and PathCache mechanisms to improve path search and file access performance, manages partitions through mount point management, and isolates File Descriptors \(FDs\) between processes through FD management. These mechanisms are briefly described below. + +1. File system function pointer: The VFS uses function pointers to distribute calls to different file systems for underlying operations based on the file system type. Each file system implements a set of Vnode operation, mount point operation, and file operation APIs, and stores them in the corresponding Vnode, mount point, and file structures in the form of function pointer structures, so that the VFS layer can access the Vnode, mount point, and file structures. +2. Vnode: A Vnode is an abstract encapsulation of a specific file or directory at the VFS layer. It shields the differences between different file systems and implements unified resource management. Vnodes include the following types: + + - Mount point: used to mount a specific file system, for example, **/** and **/storage**. + - Device node: mapping to a device in the **/dev** directory, for example, **/dev/mmcblk0** + - File/Directory node: corresponds to a file or directory in a file system, for example, **/bin/init**. + + Vnodes are managed using the hash and least recently used \(LRU\) mechanisms. After a system is started, the Vnode cache is preferentially searched in the hash linked list for an access request for a file or directory. If the cache is not hit, the target file or directory is searched in the corresponding file system, and the corresponding Vnode is created and cached. When the number of cached Vnodes reaches the upper limit, the Vnodes that are not accessed for a long time will be deleted. The mount point Vnodes and device node Vnodes are not deleted. The default number of Vnodes in the system is 512. You can configure the value in **LOSCFG\_MAX\_VNODE\_SIZE**. Increasing the value can improve search performance but cause high memory usage. The following figure shows the process of creating a Vnode. + + **Figure 1** Process of creating a Vnode + ![](figure/process-of-creating-a-vnode.png "process-of-creating-a-vnode") + + +1. PathCache: The PathCache is a path cache. It is stored in a hash table. Based on the address of the parent Vnode and the file name of the child node in the PathCache, the Vnode corresponding to the child node can be quickly found. The following figure shows how a file or directory is located. + + **Figure 2** Process of locating a file + ![](figure/process-of-locating-a-file.png "process-of-locating-a-file") + + +1. PageCache: The PageCache is a cache of files in the kernel. Currently, the PageCache can cache only binary files. When a file is accessed for the first time, the file is mapped to the memory using **mmap**. When the file is accessed the next time, the file can be directly read from the PageCache, accelerating the read and write speed of the file. In addition, page cache helps implement IPC based on files. +2. FD management: A FD uniquely identifies an open file or directory in an OS. The OpenHarmony has 896 FDs, which include the following: + + - 512 file descriptors + - 128 socket descriptors + - 256 message queue descriptors + + In the OpenHarmony kernel, the FDs of different processes are isolated. That is, a process can access only its own FD. The FDs of all processes are mapped to a global FD table for unified allocation and management. The maximum number of process file descriptors is 256. + +3. Mount point management: The OpenHarmony kernel manages all mount points in a linked list. The mount point structure records all Vnodes in the mounted partition. When a partition is unmounted, all Vnodes in the partition are released. + +## Development Guidelines + +### Available APIs + +In the following table, "×" indicates that the corresponding file system does not support the API. + +**Table 1** File system APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

FAT

+

JFFS2

+

NFS

+

TMPFS

+

PROCFS

+

File management

+

open

+

Opens a file.

+

+

+

+

+

+

read/pread/readv/preadv

+

Reads a file.

+

+

+

+

+

+

write/pwrite/writev/pwritev

+

Writes a file.

+

+

+

+

+

+

lseek

+

Sets the file offset.

+

+

+

+

+

×

+

close

+

Closes a file.

+

+

+

+

+

+

unlink

+

Deletes a file.

+

+

+

+

+

×

+

fstat

+

Queries file information.

+

+

+

+

+

+

fallocate

+

Pre-allocates a file.

+

+

×

+

×

+

×

+

×

+

truncate

+

Truncates a file.

+

+

+

×

+

+

×

+

link

+

Creates a hard link.

+

×

+

+

×

+

×

+

×

+

symlink

+

Creates a soft link.

+

+

+

×

+

×

+

×

+

readlink

+

Reads a soft link.

+

+

+

×

+

×

+

×

+

dup

+

Copies a file handle.

+

+

+

+

+

+

fsync

+

Saves the update of a file to a device.

+

+

×

+

×

+

×

+

×

+

ioctl

+

Controls a device.

+

×

+

×

+

×

+

+

×

+

fcntl

+

Performs file control operations.

+

+

+

+

+

+

Directory management

+

mkdir

+

Creates a directory.

+

+

+

+

+

×

+

opendir

+

Opens a directory.

+

+

+

+

+

+

readdir

+

Reads a directory.

+

+

+

+

+

+

closedir

+

Closes a directory.

+

+

+

+

+

+

telldir

+

Obtains the directory offset.

+

+

+

+

+

+

seekdir

+

Sets the directory offset.

+

+

+

+

+

+

rewinddir

+

Resets the directory offset.

+

+

+

+

+

×

+

scandir

+

Reads directory data.

+

+

+

+

+

+

rmdir

+

Deletes a directory.

+

+

+

+

+

×

+

chdir

+

Changes the current directory.

+

+

+

+

+

+

getcwd

+

Obtains the current directory.

+

+

+

+

+

+

realpath

+

Converts between the relative and absolute paths.

+

+

+

+

+

+

rename

+

Renames a file or directory.

+

+

+

+

+

×

+

chmod

+

Modifies the file or directory property.

+

+

+

×

+

×

+

×

+

chown

+

Changes the file or directory owner.

+

+

+

×

+

×

+

×

+

stat/lstat

+

Queries file or directory information.

+

+

+

+

+

+

access

+

Queries the access permission on a file or directory.

+

+

+

+

+

+

Partition management

+

mount

+

Mounts a partition.

+

+

+

+

+

+

umount

+

Unmounts a partition.

+

+

+

+

+

×

+

statfs

+

Queries information about a mounted partition.

+

+

+

+

+

+

format

+

Formats a partition.

+

+

×

+

×

+

×

+

×

+

sync

+

Saves the partition information to a device.

+

+

×

+

×

+

×

+

×

+
+ +### How to Develop + +The file system development process involves mounting and unmounting partitions and managing directories and files. + +### Development Example + +The sample code is as follows: + +``` +#include +#include +#include "sys/stat.h" +#include "fcntl.h" +#include "unistd.h" + +#define LOS_OK 0 +#define LOS_NOK -1 + +int main(void) +{ + int ret; + int fd = -1; + ssize_t len; + off_t off; + char mntName[20] = "/storage"; + char devName[20] = "/dev/mmcblk0p0"; + char dirName[20] = "/storage/test"; + char fileName[20] = "/storage/test/file.txt"; + char writeBuf[20] = "Hello OpenHarmony!"; + char readBuf[20] = {0}; + + /* Create the directory /storage. + ret = mkdir(mntName, 0777); + if (ret != LOS_OK) { + printf("mkdir failed.\n"); + return LOS_NOK; + } + + /* Mount the /dev/mmcblk0p0 device to the /storage directory.*/ + ret = mount(devName, mntName, "vfat", 0, 0); + if (ret != LOS_OK) { + printf("mount failed.\n"); + return LOS_NOK; + } + + /* Create the directory /storage/test. + ret = mkdir(dirName, 0777); + if (ret != LOS_OK) { + printf("mkdir failed.\n"); + return LOS_NOK; + } + + /* Create the file /storage/test/file.txt and make it readable and writable.*/ + fd = open(fileName, O_RDWR | O_CREAT, 0777); + if (fd < 0) { + printf("open file failed.\n"); + return LOS_NOK; + } + + /* Write the content from writeBuf to the file. */ + len = write(fd, writeBuf, strlen(writeBuf)); + if (len != strlen(writeBuf)) { + printf("write file failed.\n"); + return LOS_NOK; + } + + /* Save the update of the file to the storage device.*/ + ret = fsync(fd); + if (ret != LOS_OK) { + printf("fsync failed.\n"); + return LOS_NOK; + } + + /* Move the read/write pointer to the file header. */ + off = lseek(fd, 0, SEEK_SET); + if (off != 0) { + printf("lseek failed.\n"); + return LOS_NOK; + } + + /* Read the file content, with the same size as readBuf, to readBuf.*/ + len = read(fd, readBuf, sizeof(readBuf)); + if (len != strlen(readBuf)) { + printf("read file failed.\n"); + return LOS_NOK; + } + printf("%s\n", readBuf); + + /* Close the file. */ + ret = close(fd); + if (ret != LOS_OK) { + printf("close failed.\n"); + return LOS_NOK; + } + + /*Delete the file /storage/test/file.txt.*/ + ret = unlink(fileName); + if (ret != LOS_OK) { + printf("unlink failed.\n"); + return LOS_NOK; + } + + /*Delete the /storage/test directory.*/ + ret = rmdir(dirName); + if (ret != LOS_OK) { + printf("rmdir failed.\n"); + return LOS_NOK; + } + + /* Unmount the /storage partition.*/ + ret = umount(mntName); + if (ret != LOS_OK) { + printf("umount failed.\n"); + return LOS_NOK; + } + + /*Delete the /storage/ directory.*/ + ret = rmdir(mntName); + if (ret != LOS_OK) { + printf("rmdir failed.\n"); + return LOS_NOK; + } + + return LOS_OK; +} +``` + +**Verification** + +The development is successful if the return result is as follows: + +``` +Hello OpenHarmony! +``` + diff --git a/en/device-dev/kernel/kernel-small-bundles-fs.md b/en/device-dev/kernel/kernel-small-bundles-fs.md new file mode 100644 index 0000000000000000000000000000000000000000..f052b6075d82dc112b4eb4a0830f1d450b4203de --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-fs.md @@ -0,0 +1,16 @@ +# File Systems + +A file system \(often abbreviated to FS\) provides an input and output manner for an OS. It implements the interaction with internal and external storage devices. + +The file system provides standard POSIX operation APIs for the upper-layer system through the C library. For details, see the API reference of the C library. The VFS virtual layer in kernel space shields the differences between file systems. The basic architecture is as follows: + +**Figure 1** Overall file system architecture +![](figure/overall-file-system-architecture.png "overall-file-system-architecture") + +- **[Virtual File System](kernel-small-bundles-fs-virtual.md)** + +- **[Supported File Systems](kernel-small-bundles-fs-support.md)** + +- **[File System Adaptation](kernel-small-bundles-fs-new.md)** + + diff --git a/en/device-dev/kernel/kernel-small-bundles-ipc.md b/en/device-dev/kernel/kernel-small-bundles-ipc.md new file mode 100644 index 0000000000000000000000000000000000000000..d4d7107842735adcdbde825908e87a48e0f720fb --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-ipc.md @@ -0,0 +1,70 @@ +# LiteIPC + +- [Basic Concepts](#section1980994712918) +- [Working Principles](#section849811592918) +- [Development Guidelines](#section17571315171017) + - [Available APIs](#section725022011103) + + +## Basic Concepts + +LiteIPC is a new inter-process communication \(IPC\) mechanism provided by the OpenHarmony LiteOS-A kernel. Different from the traditional System V IPC, LiteIPC is designed for Remote Procedure Call \(RPC\). In addition, it provides APIs for the upper layer through device files, not through traditional API functions. + +LiteIPC has two important concepts: ServiceManager and Service. The entire system can have one ServiceManager and multiple Services. ServiceManager is responsible for registering and unregistering services, and managing Service access permission \(only authorized tasks can send IPC messages to corresponding Services\). + +## Working Principles + +ServiceManager registers the task that needs to receive IPC messages as a Service, and sets the access permission for the Service task \(specifies the tasks that can send IPC messages to the Service\). LiteIPC maintains an IPC message queue for each Service task in kernel space. The message queue provides the upper-layer user-space programs with the read operation \(receiving IPC messages\) and the write operations \(sending IPC messages\) through LiteIPC device files. + +## Development Guidelines + +### Available APIs + +**Table 1** LiteIPC module APIs \(for LiteOS-A internal use only\) + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Module initialization

+

OsLiteIpcInit

+

Initializes the LiteIPC module.

+

IPC message memory pool

+

LiteIpcPoolInit

+

Initializes the IPC message memory pool of processes.

+

LiteIpcPoolReInit

+

Re-initializes the IPC message memory pool of processes.

+

LiteIpcPoolDelete

+

Releases the IPC message memory pool of processes.

+

Service management

+

LiteIpcRemoveServiceHandle

+

Deletes the specified Service.

+
+ +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>LiteIPC module APIs are used for LiteOS-A internal use only. + diff --git a/en/device-dev/kernel/kernel-small-bundles-linking.md b/en/device-dev/kernel/kernel-small-bundles-linking.md new file mode 100644 index 0000000000000000000000000000000000000000..dcca834b580975c5e7ef1abf9be342f9c9578e13 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-linking.md @@ -0,0 +1,82 @@ +# Dynamic Loading and Linking + +- [Basic Concepts](#section208951139453) +- [Working Principles](#section14140155320511) +- [Development Guidelines](#section133501496612) + - [Available APIs](#section874113201669) + - [How to Develop](#section196712561563) + + +## Basic Concepts + +The OpenHarmony dynamic loading and linking mechanism includes a kernel loader and a dynamic linker. The kernel loader loads application programs and the dynamic linker. The dynamic linker loads the shared library on which the application programs depend, and performs symbol relocation for the application programs and shared libraries. Compared with static linking, dynamic linking is a mechanism for delaying the linking of applications and dynamic libraries to run time. + +**Advantages of Dynamic Linking** + +1. Dynamic linking allows multiple applications to share code. The minimum loading unit is page. It saves disk and memory space than static linking. +2. When a shared library is upgraded, the new shared library overwrites the earlier version \(the APIs of the shared library are downward compatible\). You do not need to re-link the shared library. +3. The loading address can be randomized to prevent attacks and ensure security. + +## Working Principles + +**Figure 1** Dynamic loading process +![](figure/dynamic-loading-process.png "dynamic-loading-process") + +1. The kernel maps the **PT\_LOAD** section in the ELF file of the application to the process space. For files of the ET\_EXEC type, fixed address mapping is performed based on **p\_vaddr** in the **PT\_LOAD** section. For files of the ET\_DYN type \(position-independent executable programs, obtained through the compile option **-fPIE**\), the kernel selects the **base** address via **mmap** for mapping \(load\_addr = base + p\_vaddr\). +2. If the application is statically linked \(static linking does not support the compile option **-fPIE**\), after the stack information is set, the system redirects to the address specified by **e\_entry** in the ELF file of the application and runs the application. If the program is dynamically linked, the application ELF file contains the **PT\_INTERP** section, which stores the dynamic linker path information \(ET\_DYN type\). The dynamic linker of musl is a part of the **libc-musl.so**. The entry of **libc-musl.so** is the entry of the dynamic linker. The kernel selects the **base** address for mapping via the **mmap** API, sets the stack information, redirects to the **base + e\_entry** \(entry of the dynamic linker\) address, and runs the dynamic linker. +3. The dynamic linker bootstraps and searches for all shared libraries on which the application depends, relocates the imported symbols, and finally redirects to the **e\_entry** \(or **base + e\_entry**\) of the application to run the application. + +**Figure 2** Program execution process +![](figure/program-execution-process.png "program-execution-process") + +1. The loader and linker call **mmap** to map the **PT\_LOAD** section. +2. The kernel calls **map\_pages** to search for and map the existing page cache. +3. If the memory does not have the required code or data when the program is executed, a page missing interrupt is triggered to read the content of the ELF file into the memory and add the memory block to the page cache. +4. Map the memory blocks of the file read to the virtual address region. +5. The program continues to run. + +The program is executed with continuous page missing interrupts. + +## Development Guidelines + +### Available APIs + +LOS\_DoExecveFile + +**Function prototype:** + +INT32 LOS\_DoExecveFile\(const CHAR \*fileName, CHAR \* const \*argv, CHAR \* const \*envp\); + +**Function**: Executes a new user program based on **fileName**. + +**Parameter Description** + + + + + + + + + + + + + + + + +

Parameter

+

Description

+

fileName

+

Name of a binary executable file. It can be a path name.

+

argv

+

Parameters, ended with NULL, required for program execution. If no parameter is required, set this parameter to NULL.

+

envp

+

New environment variables, ended with NULL, required for program execution. If no new environment variable is required, set this parameter to NULL.

+
+ +### How to Develop + +The kernel cannot directly call the **LOS\_DoExecveFile** API to start a new process. This API is generally called through the **execve** API to create a new process using the system call mechanism. + diff --git a/en/device-dev/kernel/kernel-small-bundles-share.md b/en/device-dev/kernel/kernel-small-bundles-share.md new file mode 100644 index 0000000000000000000000000000000000000000..fc519c07e156e371cc723a4b7e7ec82f6d92ed17 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-share.md @@ -0,0 +1,47 @@ +# Virtual Dynamic Shared Object + +- [Basic Concepts](#section174577181688) +- [Working Principles](#section546363114810) + +## Basic Concepts + +Different from a common dynamic shared library, which stores its so files in the file system, the virtual dynamic shared object \(VDSO\) has its so files stored in the system image. The kernel determines the so files and provides them to the application program. That is why the VDSO is called a virtual dynamic shared library. + +The VDSO mechanism allows OpenHarmony user-space programs to quickly obtain kernel-related data. It can accelerate certain system calls and implement quick read of non-sensitive data \(hardware and software configuration\). + +## Working Principles + +The VDSO can be regarded as a section of memory \(read-only\) maintained by the kernel and mapped to the address space of the user-space applications. By linking **vdso.so**, the applications can directly access this mapped memory instead of invoking system calls, accelerating application execution. + +VDSO can be divided into: + +- Data page: provides the kernel-time data mapped to the user process. +- Code page: provides the logic for shielding system calls. + +**Figure 1** VDSO system design +![](figure/vdso-system-design.jpg "vdso-system-design") + +The VDSO mechanism involves the following steps: + +1. Creates the VDSO data page during kernel initialization. + +2. Creates the VDSO code page during kernel initialization. + +3. Updates kernel data to the VDSO data page based on the system clock interrupts. + +4. Maps the code page to the user space when a user process is created. + +5. Binds the VDSO symbols when the user program creates dynamic linking. + +6. The VDSO code page intercepts specific system calls \(for example, **clock\_gettime\(CLOCK\_REALTIME\_COARSE, &ts\)**\). + +7. The VDSO code page allows direct read of the mapped VDSO data page rather than invoking a system call. + +8. Returns data from the VDSO data page to the VDSO code page. + +9. Returns the data obtained from the VDSO data page to the user program. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The VDSO mechanism supports the **CLOCK\_REALTIME\_COARSE** and **CLOCK\_MONOTONIC\_COARSE** functions of the **clock\_gettime** API in the LibC library. For details about how to use the **clock\_gettime** API, see the POSIX standard. You can call **clock\_gettime\(CLOCK\_REALTIME\_COARSE, &ts\)** or **clock\_gettime\(CLOCK\_MONOTONIC\_COARSE, &ts\)** of the LibC library to use the VDSO. +>- When VDSO is used, the time precision is the same as that of the tick interrupt of the system. The VDSO mechanism is applicable to the scenario where there is no demand for high time precision and **clock\_gettime** or **gettimeofday** is frequently triggered in a short period of time. The VDSO mechanism is not recommended for the system demanding high time precision. + diff --git a/en/device-dev/kernel/kernel-small-bundles-system.md b/en/device-dev/kernel/kernel-small-bundles-system.md new file mode 100644 index 0000000000000000000000000000000000000000..12d304f4f634325627f4ccf143feb8623458fda7 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles-system.md @@ -0,0 +1,176 @@ +# System Call + +- [Basic Concepts](#section889710401734) +- [Working Principles](#section195177541314) +- [Development Guidelines](#section193492047135419) + - [How to Develop](#section7165741122210) + - [Development Example](#section107131418224) + + +## Basic Concepts + +The OpenHarmony LiteOS-A isolates the user space and kernel space. User-space programs cannot directly access kernel resources. System calls provide a channel for user-space programs to access kernel resources and interact with the kernel. + +## Working Principles + +As shown in the following figure, a user program calls the System API \(a POSIX interface provided by the system\) to access kernel resources and interacts with the kernel. An SVC/SWI exception is triggered inside the POSIX interface to complete switching of the system from the user space to the kernel space. Then, the kernel Syscall Handler \(unified system call interface\) parses parameters received and distributes the parameters to the specific kernel functions for processing. + +**Figure 1** System call +![](figure/system-call.png "system-call") + +The Syscall Handler is implemented by the **OsArmA32SyscallHandle** function in **kernel/liteos\_a/syscall/los\_syscall.c**. This function is called when a system software interrupt occurs. The input parameters of system calls are parsed according to the list in **kernel/liteos\_a/syscall/syscall\_lookup.h** so that the specific kernel functions are executed. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- System calls implement basic interaction between user-space programs and the kernel. You are advised to use the POSIX APIs provided by the kernel instead of system call APIs. If you want to add system call APIs, see the development guide. +>- For details about the system call APIs provided by the kernel for the user space, see **kernel/liteos\_a/syscall/syscall\_lookup.h**. For details about the system call functions provided by the kernel, see **kernel/liteos\_a/syscall/los\_syscall.h**. + +## Development Guidelines + +### How to Develop + +The typical development process of adding a system call API is as follows: + +1. Determine and add the new system call number to the LibC library. +2. Add the declaration and implementation of the new user-space function API to the LibC library. +3. Add the new system call number and the declaration of the corresponding kernel processing function to the kernel system call header file. +4. Add the kernel processing function corresponding to the system call to the kernel. + +### Development Example + +**Sample Code** + +1. Add the system call number to **syscall.h.in** in the LibC library. + + In the following example, **\_\_NR\_new\_syscall\_sample** specifies the system call number added. + + ``` + ... + /* Current system call list */ + /* OHOS customized syscalls, not compatible with ARM EABI */ + #define __NR_OHOS_BEGIN 500 + #define __NR_pthread_set_detach (__NR_OHOS_BEGIN + 0) + #define __NR_pthread_join (__NR_OHOS_BEGIN + 1) + #define __NR_pthread_deatch (__NR_OHOS_BEGIN + 2) + #define __NR_creat_user_thread (__NR_OHOS_BEGIN + 3) + #define __NR_processcreat (__NR_OHOS_BEGIN + 4) + #define __NR_processtart (__NR_OHOS_BEGIN + 5) + #define __NR_printf (__NR_OHOS_BEGIN + 6) + #define __NR_dumpmemory (__NR_OHOS_BEGIN + 13) + #define __NR_mkfifo (__NR_OHOS_BEGIN + 14) + #define __NR_mqclose (__NR_OHOS_BEGIN + 15) + #define __NR_realpath (__NR_OHOS_BEGIN + 16) + #define __NR_format (__NR_OHOS_BEGIN + 17) + #define __NR_shellexec (__NR_OHOS_BEGIN + 18) + #define __NR_ohoscapget (__NR_OHOS_BEGIN + 19) + #define __NR_ohoscapset (__NR_OHOS_BEGIN + 20) + + #define __NR_new_syscall_sample (__NR_OHOS_BEGIN + 21) /* Add the new system call number: __NR_new_syscall_sample:521 */ + + #define __NR_syscallend (__NR_OHOS_BEGIN + 22) + ... + ``` + +2. Add the declaration and implementation of the new user-space API to the LibC library. + + ``` + #include "stdio_impl.h" + #include "syscall.h" + ... + /* Add the implementation of the new user-space system call API.*/ + void newSyscallSample(int num) + { + printf("user mode: num = %d\n", num); + __syscall(SYS_new_syscall_sample, num); + return; + } + ``` + +3. Add the system call number to the kernel system call header file. + + In the **third\_party/musl/porting/liteos\_a/kernel/include/bits/syscall.h** file, **\_\_NR\_new\_syscall\_sample** specifies the new system call number . + + ``` + ... + /* Current system call list */ + /* OHOS customized syscalls, not compatible with ARM EABI */ + #define __NR_OHOS_BEGIN 500 + #define __NR_pthread_set_detach (__NR_OHOS_BEGIN + 0) + #define __NR_pthread_join (__NR_OHOS_BEGIN + 1) + #define __NR_pthread_deatch (__NR_OHOS_BEGIN + 2) + #define __NR_creat_user_thread (__NR_OHOS_BEGIN + 3) + #define __NR_processcreat (__NR_OHOS_BEGIN + 4) + #define __NR_processtart (__NR_OHOS_BEGIN + 5) + #define __NR_printf (__NR_OHOS_BEGIN + 6) + #define __NR_dumpmemory (__NR_OHOS_BEGIN + 13) + #define __NR_mkfifo (__NR_OHOS_BEGIN + 14) + #define __NR_mqclose (__NR_OHOS_BEGIN + 15) + #define __NR_realpath (__NR_OHOS_BEGIN + 16) + #define __NR_format (__NR_OHOS_BEGIN + 17) + #define __NR_shellexec (__NR_OHOS_BEGIN + 18) + #define __NR_ohoscapget (__NR_OHOS_BEGIN + 19) + #define __NR_ohoscapset (__NR_OHOS_BEGIN + 20) + + #define __NR_new_syscall_sample (__NR_OHOS_BEGIN + 21) /* Add the new system call number: __NR_new_syscall_sample:521 */ + + #define __NR_syscallend (__NR_OHOS_BEGIN + 22) + ... + ``` + + In **kernel/liteos\_a/syscall/syscall\_lookup.h**, add the line **SYSCALL\_HAND\_DEF\(\_\_NR\_new\_syscall\_sample, SysNewSyscallSample, void, ARG\_NUM\_1\)**. + + ``` + ... + /* Current system call list */ + SYSCALL_HAND_DEF(__NR_chown, SysChown, int, ARG_NUM_3) + SYSCALL_HAND_DEF(__NR_chown32, SysChown, int, ARG_NUM_3) + #ifdef LOSCFG_SECURITY_CAPABILITY + SYSCALL_HAND_DEF(__NR_ohoscapget, SysCapGet, UINT32, ARG_NUM_2) + SYSCALL_HAND_DEF(__NR_ohoscapset, SysCapSet, UINT32, ARG_NUM_1) + #endif + /* Add a system call. */ + SYSCALL_HAND_DEF(__NR_new_syscall_sample, SysNewSyscallSample, void, ARG_NUM_1) + ... + ``` + +4. Add a function corresponding to the new system call to the kernel. + + In **kernel/liteos\_a/syscall/los\_syscall.h**, **SysNewSyscallSample** is the declaration of the kernel processing function corresponding to the new system call. + + ``` + ... + /* List of the declaration of the current kernel processing functions for system calls. */ + extern int SysClockSettime64(clockid_t clockID, const struct timespec64 *tp); + extern int SysClockGettime64(clockid_t clockID, struct timespec64 *tp); + extern int SysClockGetres64(clockid_t clockID, struct timespec64 *tp); + extern int SysClockNanoSleep64(clockid_t clk, int flags, const struct timespec64 *req, struct timespec64 *rem); + extern int SysTimerGettime64(timer_t timerID, struct itimerspec64 *value); + extern int SysTimerSettime64(timer_t timerID, int flags, const struct itimerspec64 *value, struct itimerspec64 *oldValue); + /* Declaration of the kernel processing function for the new system call*/ + extern void SysNewSyscallSample(int num); + ... + ``` + + The newly added kernel processing function is implemented as follows: + + ``` + include "los_printf.h" + ... + /* Add the implementation of the kernel processing function for the new system call. */ + void SysNewSyscallSample(int num) + { + PRINTK("kernel mode: num = %d\n", num); + return; + } + ``` + + +**Verification** + +The user-space program calls the **newSyscallSample\(10\)** API. The output is as follows: + +``` +/* The output in both user-space and kernel-space APIs indicates that the new system call is enabled. */ +user mode: num = 10 +kernel mode: num = 10 +``` + diff --git a/en/device-dev/kernel/kernel-small-bundles.md b/en/device-dev/kernel/kernel-small-bundles.md new file mode 100644 index 0000000000000000000000000000000000000000..1d1e7ad20eec3d0c6303566552f4a8d9372fbe54 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-bundles.md @@ -0,0 +1,13 @@ +# Extension Components + +- **[System Call](kernel-small-bundles-system.md)** + +- **[Dynamic Loading and Linking](kernel-small-bundles-linking.md)** + +- **[Virtual Dynamic Shared Object](kernel-small-bundles-share.md)** + +- **[LiteIPC](kernel-small-bundles-ipc.md)** + +- **[File Systems](kernel-small-bundles-fs.md)** + + diff --git a/en/device-dev/kernel/kernel-small-debug-memory-corrupt.md b/en/device-dev/kernel/kernel-small-debug-memory-corrupt.md new file mode 100644 index 0000000000000000000000000000000000000000..1196dd3ce2208996324f41e4dc9c3355007b8946 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-memory-corrupt.md @@ -0,0 +1,84 @@ +# Memory Corruption Check + +- [Basic Concepts](#section17368154517335) +- [Function Configuration](#section4696190123420) +- [Development Guidelines](#section672362973417) + - [How to Develop](#section026014863416) + - [Development Example](#section186311302356) + + +## Basic Concepts + +As an optional function of the kernel, memory corruption check is used to check the integrity of a dynamic memory pool. This mechanism can detect memory corruption errors in the memory pool in a timely manner and provide alerts. It helps reduce problem locating costs and increase troubleshooting efficiency. + +## Function Configuration + +**LOSCFG\_BASE\_MEM\_NODE\_INTEGRITY\_CHECK**: specifies the setting of the memory corruption check. This function is disabled by default. To enable this function, configure it in **Debug-\> Enable integrity check or not**. + +If this macro is enabled, the memory pool integrity will be checked in real time upon each memory allocation. + +If this macro is not enabled, you can call **LOS\_MemIntegrityCheck** to check the memory pool integrity when required. Using **LOS\_MemIntegrityCheck** does not affect the system performance. In addition, the check accuracy decreases because the node header does not contain the magic number \(which is available only when **LOSCFG\_BASE\_MEM\_NODE\_INTEGRITY\_CHECK** is enabled\). + +This check only detects the corrupted memory node and provides information about the previous node \(because memory is contiguous, a node is most likely corrupted by the previous node\). To further determine the location where the previous node is requested, you need to enable the memory leak check and use LRs to locate the fault. + +>![](../public_sys-resources/icon-caution.gif) **CAUTION:** +>If memory corruption check is enabled, a magic number is added to the node header, which increases the size of the node header. The real-time integrity check has a great impact on the performance. In performance-sensitive scenarios, you are advised to disable this function and use **LOS\_MemIntegrityCheck** to check the memory pool integrity. + +## Development Guidelines + +### How to Develop + +Check for memory corruption by calling **LOS\_MemIntegrityCheck**. If no memory corruption occurs, **0** is returned and no log is output. If memory corruption occurs, related log is output. For details, see the output of the following example. + +### Development Example + +This example implements the following: + +1. Requests two physically adjacent memory blocks. +2. Calls **memset** to construct an out-of-bounds access and overwrites the first four bytes of the next node. +3. Calls **LOS\_MemIntegrityCheck** to check whether memory corruption occurs. + +**Sample Code** + +The sample code is as follows: + +``` +#include +#include +#include "los_memory.h" +#include "los_config.h" + +void MemIntegrityTest(void) +{ + /* Request two physically adjacent memory blocks.*/ + void *ptr1 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); + void *ptr2 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); + /* Construct an out-of-bounds access to cause memory corruption. The memory block of the first node is 8 bytes. Clearing 12 bytes overwrites the header of the second memory node. */ + memset(ptr1, 0, 8 + 4); + LOS_MemIntegrityCheck(LOSCFG_SYS_HEAP_ADDR); +} +``` + +**Verification** + +The log is as follows: + +``` +[ERR][OsMemMagicCheckPrint], 2028, memory check error! +memory used but magic num wrong, magic num = 0x00000000 /* Error information, indicating that the first four bytes, that is, the magic number, of the next node are corrupted.*/ + + broken node head: 0x20003af0 0x00000000 0x80000020, prev node head: 0x20002ad4 0xabcddcba 0x80000020 +/* Key information about the corrupted node and its previous node, including the address of the previous node, magic number of the node, and sizeAndFlag of the node. In this example, the magic number of the corrupted node is cleared. */ + + broken node head LR info: /* The node LR information can be output only after the memory leak check is enabled.*/ + LR[0]:0x0800414e + LR[1]:0x08000cc2 + LR[2]:0x00000000 + + pre node head LR info: /* Based on the LR information, you can find where the previous node is requested in the assembly file and then perform further analysis.*/ + LR[0]:0x08004144 + LR[1]:0x08000cc2 + LR[2]:0x00000000 +[ERR]Memory interity check error, cur node: 0x20003b10, pre node: 0x20003af0 /* Addresses of the corrupted node and its previous node*/ +``` + diff --git a/en/device-dev/kernel/kernel-small-debug-memory-info.md b/en/device-dev/kernel/kernel-small-debug-memory-info.md new file mode 100644 index 0000000000000000000000000000000000000000..f2be31a222f612da4f6afb30d339b20ffdacbaf7 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-memory-info.md @@ -0,0 +1,112 @@ +# Memory Information Statistics + +- [Basic Concepts](#section52691565235) +- [Function Configuration](#section470611682411) +- [Development Guidelines](#section9368374243) + - [How to Develop](#section679912407257) + - [Development Example](#section1025453412611) + + +## Basic Concepts + +Memory information includes the memory pool size, memory usage, remaining memory size, maximum free memory, memory waterline, number of memory nodes, and fragmentation rate. + +- Memory waterline: indicates the maximum memory used in a memory pool. The waterline value is updated upon each memory allocation and release. The memory pool size can be optimized based on this value. + +- Fragmentation rate: indicates the fragmentation degree of the memory pool. If the fragmentation rate is high, there are a large number of free memory blocks in the memory pool but each block is small. You can use the following formula to calculate the fragmentation rate: + + Fragmentation rate = 100 – 100 x Maximum free memory block size/Remaining memory size + + +- Other statistics: When **LOS\_MemInfoGet** is called, the node information in the memory pool is scanned and related statistics are collected. + +## Function Configuration + +**LOSCFG\_MEM\_WATERLINE**: specifies the setting of the memory information statistics function. This function is disabled by default. To enable this function, configure it in **Debug-\> Enable memory pool waterline or not in the configuration item**. If you want to obtain the memory waterline, you must enable this macro. + +## Development Guidelines + +### How to Develop + +Key structure: + +``` +typedef struct { + UINT32 totalUsedSize; // Memory usage of the memory pool + UINT32 totalFreeSize; // Remaining memory in the memory pool + UINT32 maxFreeNodeSize; // Maximum size of the free memory block in the memory pool + UINT32 usedNodeNum; // Number of non-free memory blocks in the memory pool + UINT32 freeNodeNum; // Number of free memory blocks in the memory pool +#if (LOSCFG_MEM_WATERLINE == 1) // This function is disabled by default and can be enabled using the menuconfig tool. + UINT32 usageWaterLine; // Waterline of the memory pool +#endif +} LOS_MEM_POOL_STATUS; +``` + +- To obtain the memory waterline, call **LOS\_MemInfoGet**. The first parameter in the API is the start address of the memory pool, and the second parameter is the handle of the **LOS\_MEM\_POOL\_STATUS** type. The **usageWaterLine** field indicates the waterline. + +- To calculate the memory fragmentation rate, call **LOS\_MemInfoGet** to obtain the remaining memory size and the maximum free memory block size in the memory pool, and then calculate the fragmentation rate of the dynamic memory pool as follows: + + Fragmentation rate = 100 – 100 x Maximum free memory block size/Remaining memory size + + +### Development Example + +This example implements the following: + +1. Creates a monitoring thread to obtain information about the memory pool. +2. Calls **LOS\_MemInfoGet** to obtain the basic information about the memory pool. +3. Calculates the memory usage and fragmentation rate. + +**Sample Code** + +The sample code is as follows: + +``` +#include +#include +#include "los_task.h" +#include "los_memory.h" +#include "los_config.h" + +void MemInfoTaskFunc(void) +{ + LOS_MEM_POOL_STATUS poolStatus = {0}; + + /* pool is the memory address of the information to be collected. OS_SYS_MEM_ADDR is used as an example.*/ + void *pool = OS_SYS_MEM_ADDR; + LOS_MemInfoGet(pool, &poolStatus); + /* Calculate the fragmentation rate of the memory pool. */ + unsigned char fragment = 100 - poolStatus.maxFreeNodeSize * 100 / poolStatus.totalFreeSize; + /* Calculate the memory usage of the memory pool. */ + unsigned char usage = LOS_MemTotalUsedGet(pool) * 100 / LOS_MemPoolSizeGet(pool); + printf("usage = %d, fragment = %d, maxFreeSize = %d, totalFreeSize = %d, waterLine = %d\n", usage, fragment, poolStatus.maxFreeNodeSize, + poolStatus.totalFreeSize, poolStatus.usageWaterLine); +} + +int MemTest(void) +{ + unsigned int ret; + unsigned int taskID; + TSK_INIT_PARAM_S taskStatus = {0}; + taskStatus.pfnTaskEntry = (TSK_ENTRY_FUNC)MemInfoTaskFunc; + taskStatus.uwStackSize = 0x1000; + taskStatus.pcName = "memInfo"; + taskStatus.usTaskPrio = 10; + ret = LOS_TaskCreate(&taskID, &taskStatus); + if (ret != LOS_OK) { + printf("task create failed\n"); + return -1; + } + return 0; +} +``` + +**Verification** + +The result is as follows: + +``` +usage = 22, fragment = 3, maxFreeSize = 49056, totalFreeSize = 50132, waterLine = 1414 +``` + diff --git a/en/device-dev/kernel/kernel-small-debug-memory-leak.md b/en/device-dev/kernel/kernel-small-debug-memory-leak.md new file mode 100644 index 0000000000000000000000000000000000000000..9034ad920ac1c840881440367f3cf1cb14e08999 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-memory-leak.md @@ -0,0 +1,126 @@ +# Memory Leak Check + +- [Basic Concepts](#section1026719436293) +- [Function Configuration](#section13991354162914) +- [Development Guidelines](#section95828159308) + - [How to Develop](#section369844416304) + - [Development Example](#section460801313313) + + +## Basic Concepts + +As an optional function of the kernel, memory leak check is used to locate dynamic memory leak problems. After this function is enabled, the dynamic memory automatically records the link registers \(LRs\) used when memory is allocated. If a memory leak occurs, the recorded information helps locate the memory allocated for further analysis. + +## Function Configuration + +1. **LOSCFG\_MEM\_LEAKCHECK**: specifies the setting of the memory leak check. This function is disabled by default. To enable this function, configure it in **Debug-\> Enable Function call stack of Mem operation recorded**. +2. **LOS\_RECORD\_LR\_CNT**: number of LRs recorded. The default value is **3**. Each LR consumes the memory of **sizeof\(void \*\)** bytes. +3. **LOS\_OMIT\_LR\_CNT**: number of ignored LRs. The default value is **2**, which indicates that LRs are recorded from the time when **LOS\_MemAlloc** is called. You can change the value based on actual requirements. This macro is configured because: + - **LOS\_MemAlloc** is also called internally. + - **LOS\_MemAlloc** may be encapsulated externally. + - The number of LRs configured by **LOS\_RECORD\_LR\_CNT** is limited. + + +Correctly setting this macro can ignore invalid LRs and reduce memory consumption. + +## Development Guidelines + +### How to Develop + +Memory leak check provides a method to check for memory leak in key code logic. If this function is enabled, LR information is recorded each time when memory is allocated. When **LOS\_MemUsedNodeShow** is called before and after the code snippet is checked, information about all nodes that have been used in the specified memory pool is printed. You can compare the node information. The newly added node information indicates the node where the memory leak may occur. You can locate the code based on the LR and further check whether a memory leak occurs. + +The node information output by calling **LOS\_MemUsedNodeShow** is in the following format: Each line contains information about a node. The first column indicates the node address, based on which you can obtain complete node information using a tool such as a GNU Debugger \(GDB\). The second column indicates the node size, which is equal to the node header size plus the data field size. Columns 3 to 5 list the LR addresses. You can determine the specific memory location of the node based on the LR addresses and the assembly file. + +``` +node size LR[0] LR[1] LR[2] +0x10017320: 0x528 0x9b004eba 0x9b004f60 0x9b005002 +0x10017848: 0xe0 0x9b02c24e 0x9b02c246 0x9b008ef0 +0x10017928: 0x50 0x9b008ed0 0x9b068902 0x9b0687c4 +0x10017978: 0x24 0x9b008ed0 0x9b068924 0x9b0687c4 +0x1001799c: 0x30 0x9b02c24e 0x9b02c246 0x9b008ef0 +0x100179cc: 0x5c 0x9b02c24e 0x9b02c246 0x9b008ef0 +``` + +>![](../public_sys-resources/icon-caution.gif) **CAUTION:** +>Enabling memory leak check affects memory application performance. LR addresses will be recorded for each memory node, increasing memory overhead. + +### Development Example + +This example implements the following: + +1. Calls **OsMemUsedNodeShow** to print information about all nodes. +2. Simulates a memory leak by requesting memory without releasing it. +3. Calls **OsMemUsedNodeShow** to print information about all nodes. +4. Compare the logs to obtain information about the node where a memory leak occurred. +5. Locate the code based on the LR address. + +**Sample Code** + +The sample code is as follows: + +``` +#include +#include +#include "los_memory.h" +#include "los_config.h" + +void MemLeakTest(void) +{ + OsMemUsedNodeShow(LOSCFG_SYS_HEAP_ADDR); + void *ptr1 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); + void *ptr2 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8); + OsMemUsedNodeShow(LOSCFG_SYS_HEAP_ADDR); +} +``` + +**Verification** + +The log is as follows: + +``` +node size LR[0] LR[1] LR[2] +0x20001b04: 0x24 0x08001a10 0x080035ce 0x080028fc +0x20002058: 0x40 0x08002fe8 0x08003626 0x080028fc +0x200022ac: 0x40 0x08000e0c 0x08000e56 0x0800359e +0x20002594: 0x120 0x08000e0c 0x08000e56 0x08000c8a +0x20002aac: 0x56 0x08000e0c 0x08000e56 0x08004220 + +node size LR[0] LR[1] LR[2] +0x20001b04: 0x24 0x08001a10 0x080035ce 0x080028fc +0x20002058: 0x40 0x08002fe8 0x08003626 0x080028fc +0x200022ac: 0x40 0x08000e0c 0x08000e56 0x0800359e +0x20002594: 0x120 0x08000e0c 0x08000e56 0x08000c8a +0x20002aac: 0x56 0x08000e0c 0x08000e56 0x08004220 +0x20003ac4: 0x1d 0x08001458 0x080014e0 0x080041e6 +0x20003ae0: 0x1d 0x080041ee 0x08000cc2 0x00000000 +``` + +The difference between the two logs is as follows. The following memory nodes are suspected to have blocks with a memory leak. + +``` +0x20003ac4: 0x1d 0x08001458 0x080014e0 0x080041e6 +0x20003ae0: 0x1d 0x080041ee 0x08000cc2 0x00000000 +``` + +The following is part of the assembly file: + +``` + MemLeakTest: + 0x80041d4: 0xb510 PUSH {R4, LR} + 0x80041d6: 0x4ca8 LDR.N R4, [PC, #0x2a0] ; g_memStart + 0x80041d8: 0x0020 MOVS R0, R4 + 0x80041da: 0xf7fd 0xf93e BL LOS_MemUsedNodeShow ; 0x800145a + 0x80041de: 0x2108 MOVS R1, #8 + 0x80041e0: 0x0020 MOVS R0, R4 + 0x80041e2: 0xf7fd 0xfbd9 BL LOS_MemAlloc ; 0x8001998 + 0x80041e6: 0x2108 MOVS R1, #8 + 0x80041e8: 0x0020 MOVS R0, R4 + 0x80041ea: 0xf7fd 0xfbd5 BL LOS_MemAlloc ; 0x8001998 + 0x80041ee: 0x0020 MOVS R0, R4 + 0x80041f0: 0xf7fd 0xf933 BL LOS_MemUsedNodeShow ; 0x800145a + 0x80041f4: 0xbd10 POP {R4, PC} + 0x80041f6: 0x0000 MOVS R0, R0 +``` + +The memory node addressed by **0x080041ee** is not released after being requested in **MemLeakTest**. + diff --git a/en/device-dev/kernel/kernel-small-debug-memory.md b/en/device-dev/kernel/kernel-small-debug-memory.md new file mode 100644 index 0000000000000000000000000000000000000000..ad6093e6fa3c986b3af319a4e15cebcd1c417338 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-memory.md @@ -0,0 +1,9 @@ +# Memory Debugging + +- **[Memory Information Statistics](kernel-small-debug-memory-info.md)** + +- **[Memory Leak Check](kernel-small-debug-memory-leak.md)** + +- **[Memory Corruption Check](kernel-small-debug-memory-corrupt.md)** + + diff --git a/en/device-dev/kernel/kernel-small-debug-other.md b/en/device-dev/kernel/kernel-small-debug-other.md new file mode 100644 index 0000000000000000000000000000000000000000..b4a19694532ce220b4db5de55169d3c225a9d50a --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-other.md @@ -0,0 +1,7 @@ +# Other Kernel Debugging Methods + +- **[Dying Gasp](kernel-small-debug-trace-other-lastwords.md)** + +- **[Common Fault Locating Methods](kernel-small-debug-trace-other-faqs.md)** + + diff --git a/en/device-dev/kernel/kernel-small-debug-process-cpu.md b/en/device-dev/kernel/kernel-small-debug-process-cpu.md new file mode 100644 index 0000000000000000000000000000000000000000..2a5249e7fb14ed65ee130836d5e8c701db753006 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-process-cpu.md @@ -0,0 +1,195 @@ +# CPUP + +- [Basic Concepts](#section17683419227) +- [Working Principles](#section593718536227) +- [Development Guidelines](#section11284210152311) + - [Available APIs](#section3745151592312) + - [How to Develop](#section122901429182316) + - [Development Example](#section1765785212310) + + +## Basic Concepts + +The central processing unit percent \(CPUP\) includes the system CPUP, process CPUP, task CPUP, and interrupt CPUP. With the system CPUP, you can determine whether the current system load exceeds the designed specifications. With the CPUP of each task/process/interrupt, you can determine whether the CPU usage of each task/process/interrupt meets expectations of the design. + +- System CPUP + + The system CPUP is the CPU usage of the system within a period of time. It reflects the CPU load and the system running status \(idle or busy\) in a period of time. The valid range of the system CPUP is 0 to 100 in percentage. The precision can be adjusted through configuration. The value **100** indicates that the system runs with full load. + +- Process CPUP + + Process CPUP refers to the CPU usage of a single process. It reflects the process status, busy or idle, in a period of time. The valid range of the process CPUP is 0 to 100 in percentage. The precision can be adjusted through configuration. The value **100** indicates that the process is being executed for a period of time. + +- Task CPUP + + Task CPUP refers to the CPU usage of a single task. It reflects the task status, busy or idle, in a period of time. The valid range of task CPUP is 0 to 100 in percentage. The precision can be adjusted through configuration. The value **100** indicates that the task is being executed for a period of time. + +- Interrupt CPUP + + Task CPUP refers to the CPU usage of a single interrupt. It reflects the interrupt status, busy or idle, in a period of time. The valid range of the interrupt CPUP is 0 to 100 in percentage. The precision can be adjusted through configuration. The value **100** indicates that the interrupt is being executed for a period of time. + + +## Working Principles + +The OpenHarmony LiteOS-A kernel CPUP module records the CPU usage by process, task, and interrupt. When a process or task is switched, the start time of the process or task is recorded. When the process or task is switched out or exits, the system accumulates the CPU time of the entire process or task. When an interrupt is executed, the system accumulates and records the execution time of each interrupt. + +The OpenHarmony provides the following types of CPUP information: + +- System CPUP +- Process CPUP +- Task CPUP +- Interrupt CPUP + +You can calculate the CPUP as follows: + +System CPUP = Total running time of all tasks except idle tasks/Total running time of the system + +Process CPUP = Total running time of the process/Total running time of the system + +Task CPUP = Total running time of the task/Total running time of the system + +Interrupt CPUP = Total running time of the interrupt/Total running time of the system + +## Development Guidelines + +### Available APIs + +**Table 1** CPUP module APIs + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

System CPUP

+

LOS_HistorySysCpuUsage

+

Obtains the historical CPUP of the system.

+

Process CPUP

+

LOS_HistoryProcessCpuUsage

+

Obtains the historical CPUP of a specified process.

+

LOS_GetAllProcessCpuUsage

+

Obtains the historical CPUP of all processes in the system.

+

Task CPUP

+

LOS_HistoryTaskCpuUsage

+

Obtains the historical CPUP of a specified task.

+

Interrupt CPUP

+

LOS_GetAllIrqCpuUsage

+

Obtains the historical CPUP of all interrupts in the system.

+
+ +### How to Develop + +The typical CPUP development process is as follows. + +1. Call **LOS\_HistorySysCpuUsage** to obtain the historical CPUP of the system. +2. Call **LOS\_HistoryProcessCpuUsage** to obtain the historical CPUP of a specified process. + - If the process has been created, disable interrupt, obtain the CPUP in different modes, and then enable interrupt. + - If the process is not created, return an error code. + +3. Call **LOS\_GetAllProcessCpuUsage** to obtain the CPUP of all processes. + - If the CPUP is initialized, disable interrupt, obtain the CPUP in different modes, and then enable interrupt. + - If CPUP is not initialized or has invalid input parameters, return an error code. + +4. Call **LOS\_HistoryTaskCpuUsage** to obtain the historical CPUP of a specified task. + - If the task has been created, disable interrupt, obtain the CPUP in different modes, and then enable interrupt. + - If the task is not created, return an error code. + +5. Call **LOS\_GetAllIrqCpuUsage** to obtain the CPUP of all interrupts. + - If the CPUP is initialized, disable interrupt, obtain the CPUP in different modes, and then enable interrupt. + - If CPUP is not initialized or has invalid input parameters, return an error code. + + +### Development Example + +This example implements the following: + +1. Create a task for the CPUP test. +2. Obtain the CPUP of the current system. +3. Obtain the historical system CPUP in different modes. +4. Obtain the CPUP of the created test task. +5. Obtains the CPUP of the created test task in different modes. + +Prerequisites + +Enable the cpup control switch in the **menuconfig** configuration. + +**Sample Code** + +The sample code is as follows: + +``` +#include "los_task.h" +#include "los_cpup.h" +#define MODE 4 +UINT32 g_cpuTestTaskID; +VOID ExampleCpup(VOID) +{ + printf("entry cpup test example\n"); + while(1) { + usleep(100); + } +} +UINT32 ItCpupTest(VOID) +{ + UINT32 ret; + UINT32 cpupUse; + TSK_INIT_PARAM_S cpupTestTask = { 0 }; + memset(&cpupTestTask, 0, sizeof(TSK_INIT_PARAM_S)); + cpupTestTask.pfnTaskEntry = (TSK_ENTRY_FUNC)ExampleCpup; + cpupTestTask.pcName = "TestCpupTsk"; + cpupTestTask.uwStackSize = 0x800; + cpupTestTask.usTaskPrio = 5; + ret = LOS_TaskCreate(&g_cpuTestTaskID, &cpupTestTask); + if(ret != LOS_OK) { + printf("cpupTestTask create failed .\n"); + return LOS_NOK; + } + + usleep(100); + + /* Obtain the historical CPUP of the system. */ + cpupUse = LOS_HistorySysCpuUsage(CPU_LESS_THAN_1S); + printf("the history system cpu usage in all time: %u.%u\n", + cpupUse / LOS_CPUP_PRECISION_MULT, cpupUse % LOS_CPUP_PRECISION_MULT); + /* Obtain the CPUP of the specified task (cpupTestTask in this example).*/ + cpupUse = LOS_HistoryTaskCpuUsage(g_cpuTestTaskID, CPU_LESS_THAN_1S); + printf("cpu usage of the cpupTestTask in all time:\n TaskID: %d\n usage: %u.%u\n", + g_cpuTestTaskID, cpupUse / LOS_CPUP_PRECISION_MULT, cpupUse % LOS_CPUP_PRECISION_MULT); + return LOS_OK; +} +``` + +**Verification** + +The development is successful if the return result is as follows: + +``` +entry cpup test example +the history system cpu usage in all time: 3.0 +cpu usage of the cpupTestTask in all time: TaskID:10 usage: 0.0 +``` + diff --git a/en/device-dev/kernel/kernel-small-debug-process.md b/en/device-dev/kernel/kernel-small-debug-process.md new file mode 100644 index 0000000000000000000000000000000000000000..a57488bf665341f048fc60b512596660bd1cb951 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-process.md @@ -0,0 +1,5 @@ +# Process Commissioning + +- **[CPUP](kernel-small-debug-process-cpu.md)** + + diff --git a/en/device-dev/kernel/kernel-lite-small-shell-sample.md b/en/device-dev/kernel/kernel-small-debug-shell-build.md similarity index 74% rename from en/device-dev/kernel/kernel-lite-small-shell-sample.md rename to en/device-dev/kernel/kernel-small-debug-shell-build.md index 07ee08e7c72d21c3762e23ffbd511eaf271ed26c..b8aabd6dbba9906697e51852bb64b21469fbd360 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-sample.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-build.md @@ -1,20 +1,20 @@ -# Shell Command Programming Example +# Shell Command Programming Example - [Example Description](#section87143612316) - [Static Registration](#section1660495712314) -- [Static Registration Programming Example](#section0410326242) +- [Static Registration Programming Example](#section1233411684113) - [Dynamic Registration](#section6804126192412) -- [Dynamic Registration Programming Example](#section17474410102419) +- [Dynamic Registration Programming Example](#section2335121613418) ## Example Description -This section provides examples of how to add a shell command **test** using static registration and dynamic registration, respectively. +This section describes how to add a shell command **test** using static registration and dynamic registration, respectively. ## Static Registration Development process: -1. Define the **cmd\_test** execution function to be called to add a command. +1. Define the **cmd\_test** function to be called to add a command. 2. Use the **SHELLCMD\_ENTRY** function to add the new command. @@ -23,9 +23,9 @@ Development process: 4. Recompile the code and run it. -## Static Registration Programming Example +## Static Registration Programming Example -1. Define the **cmd\_test** execution function to be called to add a command. +1. Define the **cmd\_test** function to be called to add a command. ``` #include "shell.h" @@ -53,7 +53,9 @@ Development process: make clean;make ``` -5. Run the **help** command to view all the commands registered in the system. The command output shows that the **test** command has been registered. \(The following command output is for reference only.\) +5. Run the **help** command to view all the commands registered in the system. + + The command output contains the **test** command \(the following command output is for reference only.\) ``` OHOS # help @@ -64,7 +66,7 @@ Development process: ifconfig ipdebug kill log ls lsfd memcheck mkdir mount netstat oom partinfo partition ping ping6 pwd reset rm rmdir sem statfs su swtmr sync - systeminfo task telnet test tftp touch umount uname + tftp touch umount uname test systeminfo task telnet watch writeproc ``` @@ -78,7 +80,7 @@ Development process: 2. Recompile the code and run it. -## Dynamic Registration Programming Example +## Dynamic Registration Programming Example 1. Call the **osCmdReg** function from the **app\_init** function to dynamically register the command. @@ -105,7 +107,9 @@ Development process: make clean;make ``` -3. Run the **help** command to view all the commands registered in the system. The command output shows that the **test** command has been registered. +3. Run the **help** command to view all the commands registered in the system. + + The command output contains the **test** command. ``` OHOS # help @@ -116,7 +120,7 @@ Development process: ifconfig ipdebug kill log ls lsfd memcheck mkdir mount netstat oom partinfo partition ping ping6 pwd reset rm rmdir sem statfs su swtmr sync - systeminfo task telnet test tftp touch umount uname + tftp touch umount uname test systeminfo task telnet watch writeproc ``` diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-cpup.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-cpup.md similarity index 59% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-cpup.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-cpup.md index fc8d35798807612cd32d68d78af1735edab736fc..5dc651761a7b351f259ea20c0d23d3caffc8c3c5 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-cpup.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-cpup.md @@ -1,46 +1,45 @@ -# cpup +# cpup - [Command Function](#section1842161614217) - [Syntax](#section5629527427) -- [Parameter Description](#section133651361023) +- [Parameters](#section133651361023) - [Usage](#section156611948521) - [Example](#section68501605319) - [Output](#section19871522144219) ## Command Function -This command is used to query the CPU usage of the system. +This command is used to query the CPU usage \(CPU percent\) of the system. ## Syntax cpup \[_mode_\] \[_taskID_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

+ - - - - - - @@ -54,7 +53,7 @@ cpup \[_mode_\] \[_taskID_\] ## Example -Enter **cpup 1 5**. +Run **cpup 1 5**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-date.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-date.md similarity index 84% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-date.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-date.md index ebd63e75d05e9f349275be20f465b3c3a15ca561..81699efec836fad5f089c6fa0769fff5768f3fe1 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-date.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-date.md @@ -1,8 +1,8 @@ -# date +# date - [Command Function](#section56472016338) - [Syntax](#section16635112512316) -- [Parameter Description](#section15896030039) +- [Parameters](#section15896030039) - [Usage](#section116361036636) - [Example](#section021711411237) - [Output](#section17950184414312) @@ -25,22 +25,22 @@ date_ _-s_ _\[_hh:mm:ss_\]__ date -r \[_Filename_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

Description

+

Description

Value Range

+

Value Range

mode

Indicates the period in which the CPU usage is to be queried. By default, the CPU usage within the last 10 seconds is displayed.

-
  • 0: displays the CPU usage of the system within the last 10 seconds.
  • 1: displays the CPU usage of the system within the last 1 second.
  • Other value: displays the total CPU usage since the system is started.
+
  • Default: displays the CPU usage of the system within the last 10 seconds.
  • 0: displays the CPU usage within the last 10 seconds.
  • 1: displays the CPU usage of the system within the last 1 second.
  • Other value: displays the total CPU usage since the system is started.

[0, 0xFFFFFFFF]

+

[0,0xFFFFFFFF]

taskID

Indicates the task ID.

+

Task ID

[0, 0xFFFFFFFF]

+

[0,0xFFFFFFFF]

Parameter

+ - - - @@ -49,7 +49,7 @@ date -r \[_Filename_\] - - @@ -83,7 +83,9 @@ date -r \[_Filename_\] ## Example -Enter **date +%Y--%m--%d**. +Example: + +Run **date +%Y--%m--%d**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-demsg.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-dmesg.md similarity index 88% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-demsg.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-dmesg.md index d122787795603df26b1d319151fa094c4cd674fa..73a0f21a668d97bed53e764c1c7157f68e698901 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-demsg.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-dmesg.md @@ -1,8 +1,8 @@ -# dmesg +# dmesg - [Command Function](#section4643204919313) - [Syntax](#section6553153635) -- [Parameter Description](#section208971157532) +- [Parameters](#section208971157532) - [Usage](#section213115219413) - [Example](#section13736564418) - [Output](#section194005101413) @@ -23,16 +23,16 @@ dmesg -l \[_level_\] dmesg \> \[_fileA_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

Description

+

Description

Value Range

+

Value Range

--help

Uses the help.

+

Displays the help information.

N/A

Prints the date and time based on Format.

Placeholders listed in --help.

+

Placeholders listed in --help.

-s YY/MM/DD

@@ -68,7 +68,7 @@ date -r \[_Filename_\]

-r Filename

Queries the modification time of the Filename file.

+

Queries the modification time of the Filename file.

N/A

Parameter

+ - - @@ -90,7 +90,7 @@ dmesg \> \[_fileA_\] ## Usage -- This command depends on **LOSCFG\_SHELL\_DMESG**. Before running this command, enable the **Enable Shell dmesg** configuration item using **menuconfig**. +- This command depends on **LOSCFG\_SHELL\_DMESG**. Before using this command, select **Enable Shell dmesg** on **menuconfig**. Debug ---\> Enable a Debug Version ---\> Enable Shell ---\> Enable Shell dmesg @@ -102,7 +102,9 @@ dmesg \> \[_fileA_\] ## Example -Enter **dmesg \> /usr/dmesg.log**. +Example: + +Run **dmesg \> /usr/dmesg.log**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-exec.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-exec.md similarity index 72% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-exec.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-exec.md index e68a27f893b835538ac24e9ed38eacf4854d10ed..c9a7a4b03df1d3b2b43592cb5e82bd750ac906dc 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-exec.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-exec.md @@ -1,8 +1,8 @@ -# exec +# exec - [Command Function](#section4643204919313) - [Syntax](#section6553153635) -- [Parameter Description](#section208971157532) +- [Parameters](#section208971157532) - [Usage](#section213115219413) - [Example](#section13736564418) - [Output](#section194005101413) @@ -15,16 +15,16 @@ This command is a built-in shell command used to execute user-space programs. exec <_executable-file_\> -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

Description

+

Description

Value Range

+

Value Range

Parameter

+ - - @@ -44,7 +44,9 @@ Currently, this command supports only valid binary programs. The programs are su ## Example -Enter **exec helloworld**. +Example: + +Run **exec helloworld**. ## Output @@ -54,5 +56,5 @@ OHOS # hello world! ``` >![](../public_sys-resources/icon-note.gif) **NOTE:** ->After the executable file is executed, prompt **OHOS \#** is printed first. The shell **exec** command is executed in the background, causing the prompt to be printed in advance. +>After the executable file is executed, the prompt **OHOS \#** is printed first. The shell **exec** command is executed in the background, causing the prompt to be printed in advance. diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-free.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-free.md similarity index 80% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-free.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-free.md index 09e281e9f498c2673b1c71974cc80ab23cc4cce0..72ccebde071b2728179f055c4bf3d31c9e63af96 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-free.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-free.md @@ -1,8 +1,8 @@ -# free +# free - [Command Function](#section175151514841) - [Syntax](#section8488721749) -- [Parameter Description](#section27272181949) +- [Parameters](#section27272181949) - [Usage](#section148661259410) - [Example](#section68081530242) - [Output](#section171235517543) @@ -15,36 +15,36 @@ This command is used to display the system memory usage and the sizes of the ** free \[_-k | -m_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

Description

+

Description

Value Range

+

Value Range

Parameter

+ - - - - - @@ -58,17 +58,17 @@ None ## Example -Enter **free**, **free -k**, and **free -m**, respectively. +Run **free**, **free -k**, and **free -m**, respectively. ## Output **Figure 1** Displaying the memory usage in three units ![](figure/displaying-the-memory-usage-in-three-units.png "displaying-the-memory-usage-in-three-units") -**Table 2** Output description +**Table 2** Output -

Parameter

Description

+

Description

Value Range

+

Value Range

No parameter

Displays the size in the unit of byte.

+

Displays the size in bytes.

N/A

-k

Displays the size in the unit of KB.

+

Displays the size in KiB.

N/A

-m

Displays the size in the unit of MB.

+

Displays the size in MiB.

N/A

Parameter

+ @@ -76,42 +76,42 @@ Enter **free**, **free -k**, and **free -m**, respectively. - - - - - - - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-help.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-help.md similarity index 84% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-help.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-help.md index 3687be7868ebc0a050d96af1c6d1cd2331ef7b65..3dfed6fdfdbb505a656873d44fd0c21ac6f48984 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-help.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-help.md @@ -1,21 +1,21 @@ -# help +# help - [Command Function](#section991211345413) - [Syntax](#section19103204016410) -- [Parameter Description](#section1533416233432) +- [Parameters](#section1533416233432) - [Usage](#section4156445417) - [Example](#section12776124712417) - [Output](#section092662412544) ## Command Function -This command is used to display all commands in the current OS. +This command is used to display all commands in the OS. ## Syntax help -## Parameter Description +## Parameters None @@ -25,7 +25,7 @@ You can run **help** to display all commands in the current OS. ## Example -Enter **help**. +Run **help**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-hwi.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-hwi.md similarity index 72% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-hwi.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-hwi.md index 90027ac456a656ca1dd41d7451491df2caba5ba7..5617700d4a9cca3ffb82744624e2723fa6c54593 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-hwi.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-hwi.md @@ -1,27 +1,27 @@ -# hwi +# hwi - [Command Function](#section445335110416) - [Syntax](#section1795712553416) -- [Parameter Description](#section92544592410) +- [Parameters](#section92544592410) - [Usage](#section104151141252) - [Example](#section11545171957) - [Output](#section075617368542) ## Command Function -This command is used to query information about the current interrupts. +This command is used to query information about the interrupts. ## Syntax hwi -## Parameter Description +## Parameters None ## Usage -- Enter **hwi** to display the current interrupt ID, count of interrupts, and registered interrupt name. +- Run **hwi** to display the current interrupt ID, count of interrupts, and registered interrupt name. - If **LOSCFG\_CPUP\_INCLUDE\_IRQ** is enabled, the processing time \(cycles\), CPU usage, and interrupt type of each interrupt are displayed. ## Example @@ -30,18 +30,18 @@ Enter **hwi**. ## Output -1. Interrupt information \(with **LOSCFG\_CPUP\_INCLUDE\_IRQ** disabled\) +1. Interrupt information \(**LOSCFG\_CPUP\_INCLUDE\_IRQ** disabled\) - ![](figure/en-us_image_0000001053826366.png) + ![](figure/en-us_image_0000001179967527.png) -2. Interrupt information \(with **LOSCFG\_CPUP\_INCLUDE\_IRQ** enabled\) +2. Interrupt information \(**LOSCFG\_CPUP\_INCLUDE\_IRQ** enabled\) - ![](figure/en-us_image_0000001052810304.png) + ![](figure/en-us_image_0000001133848164.png) - **Table 1** Output description + **Table 1** Output -

Output

Description

total

Indicates the total size of the dynamic memory pool.

+

Total size of the dynamic memory pool

used

Indicates the size of the used memory.

+

Size of the used memory

free

Indicates the size of the unallocated memory.

+

Size of the unallocated memory

heap

Indicates the size of the allocated heap.

+

Size of the allocated heap

text

Indicates the size of a code segment.

+

Size of a code segment

data

Indicates the size of a data segment.

+

Size of a data segment

rodata

Indicates the size of a read-only data segment.

+

Size of a read-only data segment

bss

Indicates the size of the memory occupied by uninitialized global variables.

+

Size of the memory occupied by uninitialized global variables

Parameter

+ @@ -49,43 +49,43 @@ Enter **hwi**. - - - - - - - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-kill.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-kill.md similarity index 77% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-kill.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-kill.md index 3b69b6c8da73988cfbd00566587adffc425613b7..e1f20cf890b2eee2a34332880ea1782d9852f612 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-kill.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-kill.md @@ -1,8 +1,8 @@ -# kill +# kill - [Command Function](#section366714216619) - [Syntax](#section8833164614615) -- [Parameter Description](#section12809111019453) +- [Parameters](#section12809111019453) - [Usage](#section15935131220717) - [Example](#section79281818476) - [Output](#section12742311179) @@ -15,31 +15,31 @@ This command is used to send a specific signal to a specified process. kill \[_signo_ | _-signo_\] \[_pid_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Output

Description

InterruptNo

Indicates the interrupt ID.

+

Interrupt ID

Count

Indicates the count of interrupts.

+

Count of interrupts

Name

Indicates the registered interrupt name.

+

Registered interrupt name

CYCLECOST

Indicates the interrupt processing time (cycles).

+

Interrupt processing time (in cycles)

CPUUSE

Indicates the CPU usage.

+

CPU usage

CPUUSE10s

Indicates CPU usage within the last 10 seconds.

+

CPU usage within the last 10 seconds

CPUUSE1s

Indicates CPU usage within the last 1 second.

+

CPU usage within the last 1 second

mode

Indicates the interrupt mode.

-
  • normal: non-shared interrupt.
  • shared: shared interrupt.
+

Interrupt mode, which can be any of the following:

+
  • normal: non-shared interrupt.
  • shared: shared interrupt.

Parameter

+ - - - - - - @@ -56,7 +56,7 @@ The **pid** value range varies depending on the system configuration. For exam ## Example -1. Query the current process list and determine the PID \(7\) of the process to be killed. +1. Query the process list and determine the PID \(7\) of the process to be killed. **Figure 1** Querying PIDs ![](figure/querying-pids.png "querying-pids") @@ -78,5 +78,5 @@ The signal is successfully sent if no error is reported. **Figure 4** Signal sending failure ![](figure/signal-sending-failure.png "signal-sending-failure") -The preceding figure shows a signal sending failure caused by invalid parameters. In this case, check that the signal ID and PID are valid. +The signal fails to send due to invalid parameters. Check the signal ID and PID for fault. diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-log.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-log.md similarity index 80% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-log.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-log.md index ae7b0cde098849ed4a0762b59394ac75531c7fc7..509983f1971bc27d01623ef93cb9434fae49ea43 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-log.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-log.md @@ -1,8 +1,8 @@ -# log +# log - [Command Function](#section128219131856) - [Syntax](#section3894181710519) -- [Parameter Description](#section7693122310515) +- [Parameters](#section7693122310515) - [Usage](#section1982111281512) - [Example](#section176301333259) - [Output](#section14354765415) @@ -15,9 +15,9 @@ This command is used to modify and query log configurations. log level \[_levelNum_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

Description

+

Description

Value Range

+

Value Range

signo

Indicates the signal ID.

+

Specifies the signal ID.

[1, 30]

+

[1,30]

pid

Indicates the process ID.

+

Specifies the process ID.

[1, MAX_INT]

+

[1,MAX_INT]

- @@ -40,7 +40,7 @@ log level \[_levelNum_\] ## Usage -- This command depends on **LOSCFG\_SHELL\_LK**. Before running this command, enable the **Enable Shell lk** configuration item using **menuconfig**. +- This command depends on **LOSCFG\_SHELL\_LK**. Before using this command, select **Enable Shell lk** on **menuconfig**. Debug ---\> Enable a Debug Version ---\> Enable Shell ---\> Enable Shell lK @@ -58,15 +58,17 @@ log level \[_levelNum_\] TRACE\_DEBUG = 5 - If the level is not within the valid range, a message is printed. + If the level is not within the valid range, a message will be displayed. - If the **\[levelNum\]** parameter is not specified, the current log level and its usage are printed by default. ## Example -Enter **log level 4**. +Example: + +Run **log level 4**. ## Output -![](figure/en-us_image_0000001052530298.png) +![](figure/en-us_image_0000001179847649.png) diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-mem.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-memcheck.md similarity index 82% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-mem.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-memcheck.md index 965a6eb17045482ecf59a9e19e0f4e8e5e7cfa77..c635c4b16fabdc80730f00f65d507146cab28ddd 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-mem.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-memcheck.md @@ -1,8 +1,8 @@ -# memcheck +# memcheck - [Command Function](#section191633812516) - [Syntax](#section428816435510) -- [Parameter Description](#section1939943304411) +- [Parameters](#section1939943304411) - [Usage](#section228914491951) - [Example](#section17373205314515) - [Output](#section13406205385413) @@ -15,18 +15,18 @@ This command is used to check whether the dynamically requested memory block is memcheck -## Parameter Description +## Parameters None ## Usage - If all nodes in the memory pool are complete, "system memcheck over, all passed!" is displayed. -- If a node in the memory pool is incomplete, information about the memory block of the damaged node is displayed. +- If a node in the memory pool is incomplete, information about the memory block of the corrupted node is displayed. ## Example -Enter **memcheck**. +Run **memcheck**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-oom.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-oom.md similarity index 70% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-oom.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-oom.md index 7748844b3fc8ddc7d2a213b262481fc554aaa1be..026dbd948c5c5b13d476ef21dfbd2367108d61f7 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-oom.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-oom.md @@ -1,10 +1,9 @@ -# oom +# oom - [Command Function](#section366714216619) - [Syntax](#section8833164614615) -- [Parameter Description](#section12809111019453) +- [Parameters](#section12809111019453) - [Usage](#section15935131220717) -- [Example](#section79281818476) - [Output](#section12742311179) ## Command Function @@ -23,31 +22,31 @@ oom -r \[_mem byte_\] oom -h | --help -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

@@ -30,7 +30,7 @@ log level \[_levelNum_\]

levelNum

Indicates the print level of configuration logs.

+

Specifies the print level of logs.

[0x0, 0x5]

Parameter

+ - - - - - - - @@ -69,20 +68,20 @@ oom -h | --help ## Usage -- If no parameter is specified, the current configurations of the OOM function are displayed. +- If no parameter is specified, the current OOM configurations are displayed. -## Example + >![](../public_sys-resources/icon-note.gif) **NOTE:** + >When the system memory is insufficient, the system displays a message indicating the insufficiency. -When the system memory is insufficient, the system displays a message indicating the insufficiency. ## Output -![](figure/en-us_image_0000001053710680.png) +![](figure/en-us_image_0000001134008030.png) -**Table 2** Output description +**Table 2** Output -

Parameter

Description

+

Description

Value Range

+

Value Range

-i [interval]

Sets the interval for checking the Out Of Memory (OOM) thread task.

+

Sets the interval (in ms) for checking the Out Of Memory (OOM) thread task.

100 ms – 10000 ms

+

100 to 10000

-m [mem byte]

Sets the low memory threshold.

+

Sets the low memory threshold (in MB).

0 MB (does not check for low memory) – 1 MB

+

0 (disables the low memory check) to 1

-r [mem byte]

@@ -59,7 +58,7 @@ oom -h | --help

-h | --help

Uses the help.

+

Displays help information.

N/A

Parameter

+ @@ -92,27 +91,27 @@ When the system memory is insufficient, the system displays a message indicating

total physical memory: 0x1bcf000(byte), used: 0x1b50000(byte), free: 0x7f000(byte), low memory threshold: 0x80000(byte)

- - - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-pmm.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-pmm.md similarity index 73% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-pmm.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-pmm.md index 34e2594d5d6d61d6cbb935b62986eb796334d5b5..73afe9605395da1c0bb3b85f7dda489e4009dbdf 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-pmm.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-pmm.md @@ -1,8 +1,8 @@ -# pmm +# pmm - [Command Function](#section445335110416) - [Syntax](#section1795712553416) -- [Parameter Description](#section92544592410) +- [Parameters](#section92544592410) - [Usage](#section104151141252) - [Example](#section11545171957) - [Output](#section075617368542) @@ -15,7 +15,7 @@ This command is used to check the usage of the physical pages and page cache of pmm -## Parameter Description +## Parameters None @@ -25,17 +25,17 @@ This command is available only in the **Debug** version. ## Example -Enter **pmm**. +Run **pmm**. ## Output **Figure 1** Viewing the usage of physical pages ![](figure/viewing-the-usage-of-physical-pages.png "viewing-the-usage-of-physical-pages") -**Table 1** Output description +**Table 1** Output -

Output

Description

The memory usage of the OS is low.

-

The available physical memory in the entire OS is 0x1bcf000 bytes, 0x1b50000 bytes have been used, and 0x7f000 bytes are available. The current low memory threshold is 0x80000 bytes.

+

The available physical memory in the entire OS is 0x1bcf000 bytes, 0x1b50000 bytes have been used, and 0x7f000 bytes are available. The current low memory threshold is 0x80000 bytes.

[oom] candidate victim process init pid: 1, actual phy mem byte: 82602

The memory usage of each process is printed. The init process actually uses 82602 bytes, and the shared memory is calculated based on the proportion.

+

The memory usage of each process is printed. The init process uses 82602 bytes, and the shared memory is calculated based on the proportion.

[oom] candidate victim process UserProcess12 pid: 12, actual phy mem byte: 25951558

The actual memory used by the UserProcess12 process is 25951558 bytes.

+

The actual memory used by the UserProcess12 process is 25951558 bytes.

[oom] max phy mem used process UserProcess12 pid: 12, actual phy mem: 25951558

The process that uses the most memory currently is UserProcess12.

+

The process that uses the most memory currently is UserProcess12.

excFrom: User!

When the system memory is low, the UserProcess12 process fails to apply for memory and exits as a result.

+

The system memory is low, and the UserProcess12 process fails to apply for memory and exits.

Parameter

+ @@ -43,47 +43,49 @@ Enter **pmm**. - - - - - - - - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-reset.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-reset.md similarity index 75% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-reset.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-reset.md index 95d3ef994ddb5c3f7634d4432806c7eab00e5ddd..dc99159f9c86d35c2e9cef4005b1406db83f9b70 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-reset.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-reset.md @@ -1,8 +1,8 @@ -# reset +# reset - [Command Function](#section366714216619) - [Syntax](#section8833164614615) -- [Parameter Description](#section12809111019453) +- [Parameters](#section12809111019453) - [Usage](#section15935131220717) - [Example](#section79281818476) - [Output](#section12742311179) @@ -15,7 +15,7 @@ This command is used to restart a device. reset -## Parameter Description +## Parameters None @@ -25,7 +25,7 @@ After the **reset** command is executed, the device restarts immediately. ## Example -Enter **reset**. +reset ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sem.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-sem.md similarity index 67% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sem.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-sem.md index 1941131dd0fcc3a410f4786a9491a2ee34d79547..1c45bf5e7d5a8fb8a50ce6b00aeaa5293682567e 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sem.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-sem.md @@ -1,8 +1,8 @@ -# sem +# sem - [Command Function](#section366714216619) - [Syntax](#section8833164614615) -- [Parameter Description](#section12809111019453) +- [Parameters](#section12809111019453) - [Usage](#section15935131220717) - [Example](#section79281818476) - [Output](#section1975118519456) @@ -15,29 +15,29 @@ This command is used to query information about kernel semaphores. sem \[_ID__ / fulldata_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Output

Description

phys_seg

Indicates the address of the physical page control block.

+

Address of the physical page control block

base

Indicates the first physical page address, that is, start address of the physical page memory.

+

First physical page address, that is, start address of the physical page memory

size

Indicates the size of the physical page memory.

+

Size of the physical page memory

free_pages

Indicates the number of idle physical pages.

+

Number of free physical pages

active anon

Indicates the number of active anonymous pages in the page cache.

+

Number of active anonymous pages in the page cache

inactive anon

Indicates the number of inactive anonymous pages in the page cache.

+

Number of inactive anonymous pages in the page cache

active file

Indicates the number of active file pages in the page cache.

+

Number of active file pages in the page cache

inactive file

Indicates the number of inactive file pages in the page cache.

+

Number of inactive file pages in the page cache

pmm pages

  • total: indicates the total number of physical pages.
  • used: indicates the number of used physical pages.
  • free: indicates the number of idle physical pages.
+

total: indicates the total number of physical pages.

+

used: indicates the number of used physical pages.

+

free: indicates the number of free physical pages.

Parameter

+ - - - - @@ -49,21 +49,21 @@ sem \[_ID__ / fulldata_\] - If the parameters are not specified, this command displays the number of used semaphores and the total number of semaphores. - If the **ID** parameter is specified, semaphores of the specified ID are displayed. -- The **fulldata** parameter depends on **LOSCFG\_DEBUG\_SEMAPHORE**. Before specifying the **fulldata** parameter, enable the **Enable Semaphore Debugging** configuration item using **menuconfig**. +- The **fulldata** parameter depends on **LOSCFG\_DEBUG\_SEMAPHORE**. Before using this parameter, select **Enable Semaphore Debugging** on **menuconfig**. Debug ---\> Enable a Debug Version ---\> Enable Debug LiteOS Kernel Resource ---\> Enable Semaphore Debugging ## Example -Example 1: Enter **sem fulldata**. +Run **sem fulldata**. ## Output **Figure 1** Querying information about all semaphores in use ![](figure/querying-information-about-all-semaphores-in-use.png "querying-information-about-all-semaphores-in-use") -**Table 2** Output description +**Table 2** Output

Parameter

Description

+

Parameters

Value Range

+

Value Range

ID

Indicates the semaphore ID.

+

Specifies the semaphore ID.

[0, 0xFFFFFFFF]

fulldata

Queries information about all the semaphores in use. The information to be printed includes SemID, Count, OriginalCount, Creater(TaskEntry), and LastAccessTime.

+

Queries information about all the semaphores in use. The information to be printed includes SemID, Count, OriginalCount, Creater(TaskEntry), and LastAccessTime.

N/A

- -

Parameter

@@ -74,18 +74,18 @@ Example 1: Enter **sem fulldata**.

SemID

Indicates the semaphore ID.

+

Semaphore ID

Count

Indicates the number of used semaphores.

+

Number of used semaphores

>![](../public_sys-resources/icon-note.gif) **NOTE:** ->- The **ID** value can be in decimal or hexadecimal format. ->- When the **ID** value is within the range of \[0, 1023\], semaphore information of the specified ID is displayed. If the semaphore ID is not used, a message is displayed to inform you of this case. For other values, a message is displayed indicating that the input parameter is incorrect. +>The **ID** value can be in decimal or hexadecimal format. +>When the **ID** value is within the range of \[0, 1023\], semaphore information of the specified ID is displayed. If the semaphore ID is not used, a message is displayed to inform you of this case. For other values, a message is displayed indicating that the parameter is incorrect. diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-stack.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-stack.md similarity index 83% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-stack.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-stack.md index e9d5ab785c3dbca69d6245083c90e6522e3fd826..9a85dcfd07b9a5e6e99ade02a11978d85c9c9bb5 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-stack.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-stack.md @@ -1,8 +1,8 @@ -# stack +# stack - [Command Function](#section445335110416) - [Syntax](#section1795712553416) -- [Parameter Description](#section92544592410) +- [Parameters](#section92544592410) - [Usage](#section104151141252) - [Example](#section11545171957) - [Output](#section075617368542) @@ -15,7 +15,7 @@ This command is used to check the usage of each stack in the system. stack -## Parameter Description +## Parameters None @@ -25,19 +25,19 @@ None ## Example -Enter **stack**. +Run **stack**. ## Output **Figure 1** System stack usage -![](figure/en-us_image_0000001054624363.png) +![](figure/en-us_image_0000001133848370.png) -**Table 1** Output description +**Table 1** Output -

Parameter

+ @@ -45,27 +45,27 @@ Enter **stack**. - - - - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-su.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-su.md similarity index 76% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-su.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-su.md index 44f370e01867c0ac061f77598d178c93d71241fb..7886594c61103fb9e42f6d4223661d53535ef063 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-su.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-su.md @@ -1,8 +1,8 @@ -# su +# su - [Command Function](#section297810431676) - [Syntax](#section157131147876) -- [Parameter Description](#section04145521671) +- [Parameters](#section04145521671) - [Usage](#section14615155610719) - [Example](#section13338150985) - [Output](#section125021924194613) @@ -15,31 +15,31 @@ This command is used to switch the user. su \[_uid_\] \[_gid_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Output

Description

stack name

Indicates the system stack name.

+

Name of the stack

cpu id

Indicates the CPU ID.

+

CPU ID

stack addr

Indicates the stack address.

+

Stack address

total size

Indicates the stack size.

+

Total stack size

used size

Indicates the used size of the stack.

+

Size of the stack used

Parameter

+ - - - - - - @@ -49,11 +49,11 @@ su \[_uid_\] \[_gid_\] - The **su** command is used to switch to user **root** by default. The default value for both **uid** and **gid** is **0**. - If the **uid** and **gid** parameters are specified, this command can switch to the user with the specified **uid** and **gid**. -- If the input parameter is out of the range, an error message is printed. +- If the input parameter is out of the range, an error message will be printed. ## Example -Enter **su 1000 1000**. +Run **su 1000 1000**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-swymr.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-swtmr.md similarity index 68% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-swymr.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-swtmr.md index c69f0d3c071d618f595d4418f3763b05ebda77eb..8c0579172f79f8a82da84d3b751db9685bc5ffb1 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-swymr.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-swtmr.md @@ -1,8 +1,8 @@ -# swtmr +# swtmr - [Command Function](#section166171064814) - [Syntax](#section424011111682) -- [Parameter Description](#section1268410459465) +- [Parameters](#section1268410459465) - [Usage](#section169806213815) - [Example](#section16676026389) - [Output](#section1541991614710) @@ -15,24 +15,24 @@ This command is used to query information about system software timers. swtmr \[_ID_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

Description

+

Description

Value Range

+

Value Range

uid

Indicates the ID of the target user.

+

Specifies the ID of the target user.

  • Left blank
  • [0, 60000]
+
  • Left blank
  • [0,60000]

gid

Indicates the ID of the target user group.

+

Specifies the ID of the target user group.

  • Left blank
  • [0, 60000]
+
  • Left blank
  • [0,60000]

Parameter

+ - - - - @@ -40,22 +40,22 @@ swtmr \[_ID_\] ## Usage -- If the parameter is not specified, information about all software timers is displayed. +- If no parameter is specified, information about all software timers is displayed. - If the **ID** parameter is specified, information about the specified software timer is displayed. ## Example -Enter **swtmr** and **swtmr 1**. +Run **swtmr** and **swtmr 1**. ## Output **Figure 1** Querying information about all software timers ![](figure/querying-information-about-all-software-timers.png "querying-information-about-all-software-timers") -**Figure 2** Querying information about a specified software timer -![](figure/querying-information-about-a-specified-software-timer.png "querying-information-about-a-specified-software-timer") +**Figure 2** Querying information about software timer 1 +![](figure/querying-information-about-software-timer-1.png "querying-information-about-software-timer-1") -**Table 2** Output description +**Table 2** Output

Parameter

Description

+

Description

Value Range

+

Value Range

ID

Indicates the ID of a software timer.

+

Specifies the ID of a software timer.

[0, 0xFFFFFFFF]

+

[0,0xFFFFFFFF]

- - - - - - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sys.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-sysinfo.md similarity index 84% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sys.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-sysinfo.md index 8868225020ea651976928fda71a42afe12fc715c..d5f65ba9ee6cc2be9f0af434423766954f8e78a5 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sys.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-sysinfo.md @@ -1,8 +1,8 @@ -# systeminfo +# systeminfo - [Command Function](#section863016434820) - [Syntax](#section139791817795) -- [Parameter](#section19472339164813) +- [Parameters](#section19472339164813) - [Usage](#section285522592) - [Example](#section9471171015105) - [Output](#section1657011114915) @@ -15,7 +15,7 @@ This command is used to display the resource usage of the current OS, including systeminfo -## Parameter +## Parameters None @@ -25,17 +25,17 @@ None ## Example -Enter **systeminfo**. +Run **systeminfo**. ## Output **Figure 1** Usage of system resources ![](figure/usage-of-system-resources.png "usage-of-system-resources") -**Table 1** Output description +**Table 1** Output -

Parameter

@@ -66,39 +66,39 @@ Enter **swtmr** and **swtmr 1**.

SwTmrID

Indicates the ID of the software timer.

+

ID of the software timer

State

Indicates the status of the software timer.

-

The value can be UnUsed, Created, or Ticking.

+

Status of the software timer

+

The value can be UnUsed, Created, or Ticking.

Mode

Indicates the mode of the software timer.

-

The value can be Once, Period, or NSD (one-time timer that will not be automatically deleted after the timer expires).

+

Mode of the software timer

+

The value can be Once, Period, or NSD (one-shot timer that will not be automatically deleted after the timer has expired).

Interval

Indicates the number of ticks used by the software timer.

+

Number of ticks used by the software timer

Count

Indicates the number of times that the software timer has been working.

+

Number of times that the software timer has been used

Arg

Indicates the input parameter.

+

Input parameter passed

handlerAddr

Indicates the callback address.

+

Callback address

Parameter

+ @@ -43,47 +43,47 @@ Enter **systeminfo**. - - - - - - - - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-task.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-task.md similarity index 81% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-task.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-task.md index bcef76f8b87049ab74a81be659756f7721caf3b0..c5ed3e1dbe1eb20a3b9dfcc134884f2cb1928526 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-task.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-task.md @@ -1,8 +1,8 @@ -# task +# task - [Command Function](#section0533181714106) - [Syntax](#section1014412308101) -- [Parameter Description](#section116057158506) +- [Parameters](#section116057158506) - [Usage](#section2053502951112) - [Example](#section12629113381116) - [Output](#section19299103465015) @@ -15,16 +15,16 @@ This command is used to query information about processes and threads. task/task -a -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Output

Description

Module

Indicates the module name.

+

Module name

Used

Indicates the quantity of currently used resources.

+

Used resources

Total

Indicates the total quantity of available resources.

+

Total resources

Enabled

Indicates whether the module is enabled.

+

Whether the module is enabled

Task

Indicates the task.

+

Task

Sem

Indicates the semaphore.

+

Semaphore

Mutex

Indicates the mutex.

+

Mutex

Queue

Indicates the queue.

+

Message queue

SwTmr

Indicates the timer.

+

Software timer

Parameter

+ - - @@ -40,18 +40,18 @@ task/task -a ## Usage -If the parameter is not specified, partial task information is printed by default. +- If the parameter is not specified, partial task information is printed by default. ## Example -Enter **task**. +Run **task**. ## Output **Figure 1** Querying partial task information ![](figure/querying-partial-task-information.png "querying-partial-task-information") -**Table 2** Output description +**Table 2** Output

Parameter

Description

+

Description

Value Range

+

Value Range

- - - - - - - - - - - - diff --git a/en/device-dev/kernel/kernel-small-debug-shell-cmd-uname.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-uname.md new file mode 100644 index 0000000000000000000000000000000000000000..615b8d46bdca25e5940c4691a5c8372c055bc894 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-uname.md @@ -0,0 +1,72 @@ +# uname + +- [Command Function](#section107697383115) +- [Syntax](#section162824341116) +- [Usage](#section2652124861114) +- [Example](#section0107995132) +- [Output](#section1215113245511) + +## Command Function + +This command is used to display the name, version creation time, system name, and version information of the current OS. + +## Syntax + +uname \[_-a | -s | -t | -v | --help_\] + +**Table 1** Parameters + + +

Parameter

@@ -62,62 +62,62 @@ Enter **task**.

PID

Indicates the process ID.

+

Process ID

PPID

Indicates the parent process ID.

+

Parent process ID

PGID

Indicates the process group ID.

+

Process group ID

UID

Indicates the user ID.

+

User ID

Status

Indicates the current task status.

+

Current task status

CPUUSE10s

Indicates the CPU usage within 10 seconds.

+

CPU usage within last 10 seconds

PName

Indicates the process name.

+

Process name

TID

Indicates the task ID.

+

Task ID

StackSize

Indicates the size of the task stack.

+

Size of the task stack

WaterLine

Indicates the peak value used by the stack.

+

Peak value of the stack used

MEMUSE

Indicates the memory usage.

+

Memory usage

TaskName

Indicates the task name.

+

Task name

+ + + + + + + + + + + + + + + + + + + + + + +

Parameter

+

Parameters

+

No parameter

+

Displays the OS name by default.

+

-a

+

Displays all information.

+

-t

+

Displays the time when the version was created.

+

-s

+

Displays the OS name.

+

-v

+

Displays the version information.

+

--help

+

Displays the help information.

+
+ +## Usage + +The **uname** command displays the name of the current OS by default. The **uname -a | -t| -s| -v** command displays the name of the in-use OS in the standard output. These parameters are mutually exclusive. + +## Example + +Run **uname -a**. + +## Output + +Querying system information + +![](figure/en-us_image_0000001179967909.png) + diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-vmm.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-vmm.md similarity index 81% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-vmm.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-vmm.md index 920498ee8af7bb23537cd0225b4966645e35ab2f..621cefee4f4640b8ffe78a1e5fd3aedc786f67d8 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-vmm.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-vmm.md @@ -1,8 +1,8 @@ -# vmm +# vmm - [Command Function](#section445335110416) - [Syntax](#section1795712553416) -- [Parameter Description](#section92544592410) +- [Parameters](#section92544592410) - [Usage](#section104151141252) - [Example](#section11545171957) - [Output](#section075617368542) @@ -17,16 +17,16 @@ vmm \[_-a / -h / --help_\] vmm \[_pid_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

+ - - @@ -39,16 +39,16 @@ vmm \[_pid_\] - - - @@ -60,7 +60,7 @@ By default, the virtual memory usage of all processes is displayed. ## Example -Enter **vmm 3**. +Run **vmm 3**. ## Output @@ -78,32 +78,32 @@ Enter **vmm 3**. - - - - - - @@ -112,7 +112,7 @@ Enter **vmm 3**. **Table 3** Virtual memory region information -

Parameter

Description

+

Description

Value Range

+

Value Range

-h | --help

Displays the help information.

+

Displays help information.

N/A

pid

Indicates the ID of the process to query.

+

Specifies the ID of the process to query.

[0, 63]

+

[0,63]

PID

Indicates the process ID.

+

Process ID

aspace

Indicates the address of the virtual memory control block.

+

Address of the virtual memory control block

name

Indicates the process name.

+

Process name

base

Indicates the start address of the virtual memory.

+

Start address of the virtual memory

size

Indicates the size of virtual memory.

+

Size of virtual memory

pages

Indicates the number of used physical pages.

+

Number of used physical pages

Parameter

+ @@ -120,37 +120,37 @@ Enter **vmm 3**. - - - - - - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-watch.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd-watch.md similarity index 62% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-watch.md rename to en/device-dev/kernel/kernel-small-debug-shell-cmd-watch.md index 99eb40aabfed18d4a06fd2d9847fc2794b694607..48ac0ba4138057b0258485136a1ee58fdc14df78 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-watch.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd-watch.md @@ -1,11 +1,11 @@ -# watch +# watch - [Command Function](#section20643141481314) - [Syntax](#section1075441721316) -- [Parameter Description](#section1472810220135) +- [Parameters](#section1472810220135) - [Usage](#section186772414131) - [Example](#section4764192791314) -- [Output](#section5791253155517) +- [Output Description](#section5791253155517) ## Command Function @@ -17,62 +17,62 @@ watch watch \[_-c/-n/-t/--count/--interval/-no-title/--over_\] \[_command_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Output

Description

region

Indicates the address of the control block in the virtual memory region.

+

Address of the control block in the virtual memory region

name

Indicates the name of the virtual memory region.

+

Name of the virtual memory region

base

Indicates the start address of the virtual memory region.

+

Start address of the virtual memory region

size

Indicates the size of the virtual memory region.

+

Size of the virtual memory region

mmu_flags

Indicates the MMU mapping attribute of the virtual memory region.

+

MMU mapping attribute of the virtual memory region

pages

Indicates the number of used physical pages (including the shared memory).

+

Number of used physical pages, including that of the shared memory

pg/ref

Indicates the number of used physical pages.

+

Number of used physical pages

Parameter

+ - - - - - - - - - - - - - @@ -86,9 +86,11 @@ You can run the **watch --over** command to stop the currently running command ## Example -Enter **watch -n 2 -c 6 task**. +Example: -## Output +watch -n 2 -c 6 task + +## Output Description **Figure 1** **task** command monitoring result ![](figure/task-command-monitoring-result.png "task-command-monitoring-result") diff --git a/en/device-dev/kernel/kernel-small-debug-shell-cmd.md b/en/device-dev/kernel/kernel-small-debug-shell-cmd.md new file mode 100644 index 0000000000000000000000000000000000000000..3de879965b181c329f38cc0f5abdad3e7b75e0c7 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-shell-cmd.md @@ -0,0 +1,47 @@ +# System Commands + +- **[cpup](kernel-small-debug-shell-cmd-cpup.md)** + +- **[date](kernel-small-debug-shell-cmd-date.md)** + +- **[dmesg](kernel-small-debug-shell-cmd-dmesg.md)** + +- **[exec](kernel-small-debug-shell-cmd-exec.md)** + +- **[free](kernel-small-debug-shell-cmd-free.md)** + +- **[help](kernel-small-debug-shell-cmd-help.md)** + +- **[hwi](kernel-small-debug-shell-cmd-hwi.md)** + +- **[kill](kernel-small-debug-shell-cmd-kill.md)** + +- **[log](kernel-small-debug-shell-cmd-log.md)** + +- **[memcheck](kernel-small-debug-shell-cmd-memcheck.md)** + +- **[oom](kernel-small-debug-shell-cmd-oom.md)** + +- **[pmm](kernel-small-debug-shell-cmd-pmm.md)** + +- **[reset](kernel-small-debug-shell-cmd-reset.md)** + +- **[sem](kernel-small-debug-shell-cmd-sem.md)** + +- **[stack](kernel-small-debug-shell-cmd-stack.md)** + +- **[su](kernel-small-debug-shell-cmd-su.md)** + +- **[swtmr](kernel-small-debug-shell-cmd-swtmr.md)** + +- **[systeminfo](kernel-small-debug-shell-cmd-sysinfo.md)** + +- **[task](kernel-small-debug-shell-cmd-task.md)** + +- **[uname](kernel-small-debug-shell-cmd-uname.md)** + +- **[vmm](kernel-small-debug-shell-cmd-vmm.md)** + +- **[watch](kernel-small-debug-shell-cmd-watch.md)** + + diff --git a/en/device-dev/kernel/kernel-small-debug-shell-details.md b/en/device-dev/kernel/kernel-small-debug-shell-details.md new file mode 100644 index 0000000000000000000000000000000000000000..177f26cb93d388705c5fa93911b377f248451cb5 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-shell-details.md @@ -0,0 +1,13 @@ +# Shell Command Reference + +This chapter describes the functions, syntax, parameter ranges, usage, and examples of key system commands. + +For details about the commands that are not described in this document, see the output of the [help](kernel-small-debug-shell-cmd-help.md) command. You can also use the **-h | --help** option of a command to view the help information about the command. + +- **[System Commands](kernel-small-debug-shell-cmd.md)** + +- **[File Commands](kernel-small-debug-shell-file.md)** + +- **[Network Commands](kernel-small-debug-shell-net.md)** + + diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-abn.md b/en/device-dev/kernel/kernel-small-debug-shell-error.md similarity index 98% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-abn.md rename to en/device-dev/kernel/kernel-small-debug-shell-error.md index 231acdbf8048b1a57510fc481fc5a4b2a5b9223a..617269e698d94e2631313f4f073f59c2278e94fb 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-abn.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-error.md @@ -1,4 +1,4 @@ -# User-Space Exception Information +# User-Space Exception Information During the running of the user space, the following system exception may occur: diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cat.md b/en/device-dev/kernel/kernel-small-debug-shell-file-cat.md similarity index 80% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cat.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-cat.md index db3798fee685ae6eff096a156023177358810019..cf3cd02b30510a4ce088a9537267e59b104f26a6 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cat.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-cat.md @@ -1,8 +1,8 @@ -# cat +# cat - [Command Function](#section16710153391315) - [Syntax](#section1699392313158) -- [Parameter Description](#section1677217374136) +- [Parameters](#section1677217374136) - [Usage](#section186772414131) - [Example](#section12158131814561) - [Output](#section183926225561) @@ -15,9 +15,9 @@ This command is used to display the content of a text file. cat \[_pathname_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

Description

+

Description

Default Value

+

Default Value

Value Range

+

Value Range

-c / --count

Indicates the number of times that the command is executed.

+

Specifies the number of times that the command is executed.

0xFFFFFF

+

0xFFFFFF

(0, 0xFFFFFF]

-n / --interval

Indicates the interval for periodically running the command, in seconds.

+

Specifies the interval for periodically running the command, in seconds.

1s

+

1s

(0, 0xFFFFFF]

-t / -no-title

Disables time display on the top.

+

Disables time display on the top.

N/A

+

N/A

N/A

command

Indicates the command to be monitored.

+

Specifies the command to be monitored.

N/A

+

N/A

N/A

--over

Stops the current command monitoring.

+

Stops the current command monitoring.

N/A

+

N/A

N/A

- @@ -44,10 +44,10 @@ Run the **cat** \[_pathname_\] command to display the content of a text file. ## Example -Enter **cat hello-harmony.txt**. +Run **cat hello-harmony.txt**. ## Output -**Figure 1** Viewing content of the **hello-harmony.txt** file -![](figure/viewing-content-of-the-hello-harmony-txt-file.png "viewing-content-of-the-hello-harmony-txt-file") +**Figure 1** Displaying the content of **hello-harmony.txt** +![](figure/displaying-the-content-of-hello-harmony-txt.png "displaying-the-content-of-hello-harmony-txt") diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cd.md b/en/device-dev/kernel/kernel-small-debug-shell-file-cd.md similarity index 81% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cd.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-cd.md index e901db1567ec14955417acda2be585f1b2ecdaf5..a976797aef18aa45939afdb6f9b97ebf5ca3ef14 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cd.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-cd.md @@ -1,8 +1,8 @@ -# cd +# cd - [Command Function](#section11690184921316) - [Syntax](#section75695409569) -- [Parameter Description](#section71961353181311) +- [Parameters](#section71961353181311) - [Usage](#section3629759111317) - [Example](#section211620301412) - [Output](#section1968117214577) @@ -15,9 +15,9 @@ This command is used to change the current working directory. cd \[_path_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,7 +30,7 @@ cat \[_pathname_\]

pathname

Indicates the file path.

+

Specifies the file path.

An existing file

- - @@ -48,10 +48,10 @@ cd \[_path_\] ## Example -Enter **cd ..**. +Run **cd**. ## Output -**Figure 1** Directory switching result -![](figure/directory-switching-result.png "directory-switching-result") +**Figure 1** Changing the directory +![](figure/changing-the-directory.png "changing-the-directory") diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chgrp.md b/en/device-dev/kernel/kernel-small-debug-shell-file-chgrp.md similarity index 89% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chgrp.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-chgrp.md index b9fdfe09c32a883f3fdec32d4f421c0975f1b4f5..ab9601350d0a7a0c65be452a056369957d6d96bf 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chgrp.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-chgrp.md @@ -1,4 +1,4 @@ -# chgrp +# chgrp - [Command Function](#section6103119161418) - [Syntax](#section186958132141) @@ -30,14 +30,14 @@ chgrp \[_group_\] \[_pathname_\] - - @@ -47,11 +47,11 @@ chgrp \[_group_\] \[_pathname_\] ## Usage -By specifying a file group before the file name in this command, you can change the group to which the file belongs. +Specify \[_group_\] to change the file group. ## Example -Enter **chgrp 100 hello-harmony.txt**. +Run **chgrp 100 hello-harmony.txt**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chmod.md b/en/device-dev/kernel/kernel-small-debug-shell-file-chmod.md similarity index 84% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chmod.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-chmod.md index 734b648c4f321c31da9dad7fad892444a5acd8df..b8c6d7e2a5db2ebab3160f22f5e770cb8adefd1d 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chmod.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-chmod.md @@ -1,4 +1,4 @@ -# chmod +# chmod - [Command Function](#section13992936121418) - [Syntax](#section63342439147) @@ -30,14 +30,14 @@ chmod \[_mode_\] \[_pathname_\] - - @@ -47,14 +47,14 @@ chmod \[_mode_\] \[_pathname_\] ## Usage -By specifying the **mode** parameter before the file name, you can change the permission for this file. +Specify \[_mode_\] to change the file permission. ## Example -Enter **chmod 666 hello-harmony.txt**. +Run **chmod 666 hello-harmony.txt**. ## Output -**Figure 1** Changing the permission on the **hello-harmony.txt** file to **666** -![](figure/changing-the-permission-on-the-hello-harmony-txt-file-to-666.png "changing-the-permission-on-the-hello-harmony-txt-file-to-666") +**Figure 1** Changing the permission for the **hello-harmony.txt** file to **666** +![](figure/changing-the-permission-for-the-hello-harmony-txt-file-to-666.png "changing-the-permission-for-the-hello-harmony-txt-file-to-666") diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chown.md b/en/device-dev/kernel/kernel-small-debug-shell-file-chown.md similarity index 83% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chown.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-chown.md index 62683b53615c8e753ec9db80e00b72693ae9f96a..a4832359c403bf144325cd2b0f88d9f49a444394 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chown.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-chown.md @@ -1,8 +1,8 @@ -# chown +# chown - [Command Function](#section247414691513) - [Syntax](#section14773151018159) -- [Parameter Description](#section598731391517) +- [Parameters](#section598731391517) - [Usage](#section16524152071510) - [Example](#section17901152561510) - [Output](#section15513163115816) @@ -15,9 +15,9 @@ This command is used to change the owner and group of a specified file. chown \[_owner_\] \[_group_\] \[_pathname_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,9 +30,9 @@ cd \[_path_\]

path

Indicates the file path.

+

Specifies the file path.

The user must have the execution (search) permission for the specified directory.

+

You must have the execution (search) permission for the specified directory.

group

Indicates the file group.

+

Specifies the file group.

[0, 0xFFFFFFFF]

pathname

Indicates the file path.

+

Specifies the file path.

An existing file

mode

Indicates the permission for a file or directory. The value is an octal number, representing the permission of User (owner), Group (group), or Other (other groups).

+

Specifies the permission for a file or directory. The value is an octal number, representing the permission of User (owner), Group (group), or Other (other groups).

[0, 777]

pathname

Indicates the file path.

+

Specifies the file path.

An existing file

- - - - @@ -55,12 +56,12 @@ chown \[_owner_\] \[_group_\] \[_pathname_\] ## Usage - By specifying the **owner** and **group** parameters in this command, you can change the owner and group of the file. -- If the **owner** or **group** value is **-1**, the owner or group of the file will not be changed. +- If **owner** or **group** is **-1**, the owner or group of the file will not be changed. - The **group** parameter can be left blank. ## Example -Enter **chown 100 200 hello-harmony.txt**. +Run **chown 100 200 hello-harmony.txt**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cp.md b/en/device-dev/kernel/kernel-small-debug-shell-file-cp.md similarity index 83% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cp.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-cp.md index d654bd86f5da5f1dad144220e3955fc67e4a7599..f3409fe9760cd9966a8efb169e5b77987d21ca11 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cp.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-cp.md @@ -1,8 +1,8 @@ -# cp +# cp - [Command Function](#section6841203041513) - [Syntax](#section24286359150) -- [Parameter Description](#section558617385152) +- [Parameters](#section558617385152) - [Usage](#section16128156162) - [Example](#section19354171211618) - [Output](#section16754183195914) @@ -15,9 +15,9 @@ This command is used to create a copy for a file. cp \[_SOURCEFILE_\] \[_DESTFILE_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,21 +30,22 @@ chown \[_owner_\] \[_group_\] \[_pathname_\]

owner

Indicates the file owner.

+

Specifies the file owner.

[0, 0xFFFFFFFF]

group

Indicates the file group.

+

Specifies the file group.

  • Left blank
  • [0, 0xFFFFFFFF]
+

Left blank

+

[0, 0xFFFFFFFF]

pathname

Indicates the file path.

+

Specifies the file path.

An existing file

- - @@ -49,7 +49,7 @@ cp \[_SOURCEFILE_\] \[_DESTFILE_\] - The name of the source file cannot be the same as that of the destination file in the same path. - The source file must exist and cannot be a directory. -- The source file path supports wildcards: asterisks \(\*\) and question marks \(?\). The asterisk \(\*\) indicates any number of characters, and the question mark \(?\) represents a single character. The destination file path does not support wildcards. If the specified source file path matches multiple files, the destination file path must be a directory. +- The source file path supports wildcards asterisk \(\*\) and question mark\(?\). The asterisk \(\*\) indicates any number of characters, and the question mark \(?\) indicates any single character. The destination path does not support wildcards. If the source path matches multiple files, the destination path must be a directory. - If the destination file path is a directory, this directory must exist. In this case, the destination file is named after the source file. - If the destination file path is a file, the directory for this file must exist. In this case, the file copy is renamed. - Currently, this command can be used to copy only one file. If more than two parameters are specified, only the first two parameters take effect. @@ -59,7 +59,7 @@ When important system resources are copied, unexpected results such as a system ## Example -Enter **cp hello-harmony.txt ./tmp/**. +Run **cp hello-harmony.txt ./tmp/**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-format.md b/en/device-dev/kernel/kernel-small-debug-shell-file-format.md similarity index 90% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-format.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-format.md index 06ff11d299af0cae40e548e8da3263cc7aaed5ed..19ea6af44cbff0489acdf586a24b339b5e19dcf1 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-format.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-format.md @@ -1,8 +1,8 @@ -# format +# format - [Command Function](#section1922331919169) - [Syntax](#section249226169) -- [Parameter Description](#section985173416177) +- [Parameters](#section985173416177) - [Usage](#section1510162714162) - [Example](#section25691431161611) - [Output](#section17368112365920) @@ -15,9 +15,9 @@ This command is used to format a disk. format <_dev\_inodename_\> <_sectors_\> <_option_\> \[_label_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,14 +30,14 @@ cp \[_SOURCEFILE_\] \[_DESTFILE_\]

SOURCEFILE

Indicates the path to the source file.

+

Specifies the path to the source file.

Currently, only files are supported. Directories are not supported.

DESTFILE

Indicates the path to the destination file.

+

Specifies the path to the destination file.

Both directories and files are supported.

- - - - @@ -59,11 +59,11 @@ format <_dev\_inodename_\> <_sectors_\> <_option_\> \[_label_\] ## Example -Enter **format /dev/mmcblk0 128 2**. +Run **format /dev/mmcblk0 128 2**. ## Output Formatting result -![](figure/en-us_image_0000001052370307.png) +![](figure/en-us_image_0000001134008686.png) diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-is.md b/en/device-dev/kernel/kernel-small-debug-shell-file-ls.md similarity index 81% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-is.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-ls.md index 20a95c9dcf2ffd4804a13d1d2a9f7d30b1e1b962..868a7c887d1b8fa8172fad127f11e5527075d37b 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-is.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-ls.md @@ -1,8 +1,8 @@ -# ls +# ls - [Command Function](#section6538163771614) - [Syntax](#section45881743111616) -- [Parameter Description](#section17528148171617) +- [Parameters](#section17528148171617) - [Usage](#section041212533166) - [Example](#section986105716167) - [Output](#section2036124918592) @@ -15,9 +15,9 @@ This command is used to display the content of a specified directory. ls \[_path_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -28,24 +28,24 @@ format <_dev\_inodename_\> <_sectors_\> <_option_\> \[_label_\]

dev_inodename

Indicates the device name.

+

Specifies the device name.

sectors

Indicates the size of the allocated memory unit or sector. The value 0 indicates that the parameter is null. (The value must be 0 or a power of 2. For FAT32, the maximum value is 128. If the parameter is set to 0, a proper cluster size is automatically selected. The available cluster size range varies depending on the partition size. If the cluster size is incorrectly specified, the formatting may fail.)

+

Specifies the size of the allocated memory unit or sector. The value 0 indicates that the parameter is null. (The value must be 0 or a power of 2. For FAT32, the maximum value is 128. If the parameter is set to 0, a proper cluster size is automatically selected. The available cluster size range varies depending on the partition size. If the cluster size is incorrectly specified, the formatting may fail.)

option

Indicates the formatting option for selecting the file system type. The options are as follows:
  • 0x01: FMT_FAT
  • 0x02: FMT_FAT32
  • 0x07: FMT_ANY
  • 0x08: FMT_ERASE (not supported by the USB flash drive)
+
Specifies the formatting option for selecting the file system type. The options are as follows:
  • 0x01: FMT_FAT
  • 0x02: FMT_FAT32
  • 0x07: FMT_ANY
  • 0x08: FMT_ERASE (not supported by the USB flash drive)

Other values are invalid. The system will automatically select the formatting mode. If the low-level formatting bit is 1 during the formatting of a USB flash drive, an error message is printed.

label

Indicates the volume label name. This parameter is optional, and the value is a string. If null is specified for this parameter, the previously set volume label name is cleared.

+

Specifies the volume label name. This parameter is optional, and the value is a string. If null is specified for this parameter, the previously set volume label name is cleared.

@@ -45,14 +46,14 @@ ls \[_path_\] - This command can be used to display the content of the current directory. - This command can also display the size of a file. -- The **ls** command with the **proc** directory passed cannot calculate the file size and **0** is displayed in the command output. +- The **ls** command with the **proc** directory passed cannot calculate the file size, and **0** is displayed in the command output. ## Example -Enter **ls**. +Run **ls**. ## Output -**Figure 1** Viewing content of the current directory -![](figure/viewing-content-of-the-current-directory.png "viewing-content-of-the-current-directory") +**Figure 1** Displaying content of the current directory +![](figure/displaying-content-of-the-current-directory.png "displaying-content-of-the-current-directory") diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-isfd.md b/en/device-dev/kernel/kernel-small-debug-shell-file-lsfd.md similarity index 71% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-isfd.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-lsfd.md index 02962165e1e8998171905ffdcc3fea368c973eb6..0c9219d47055ae69f6bc62cb0992ef25a9209004 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-isfd.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-lsfd.md @@ -1,4 +1,4 @@ -# lsfd +# lsfd - [Command Function](#section2053406181716) - [Syntax](#section523771017172) @@ -8,7 +8,7 @@ ## Command Function -This command is used to display the file descriptors and names of currently opened files. +This command is used to display the file descriptors and names of the files that are open. ## Syntax @@ -16,14 +16,14 @@ lsfd ## Usage -Run the **lsfd** command to view file descriptors and names of the opened files. +Run the **lsfd** command to display file descriptors and names of the opened files. ## Example -Enter **lsfd**. +Run **lsfd**. ## Output **Figure 1** Command output -![](figure/command-output-19.png "command-output-19") +![](figure/command-output-24.png "command-output-24") diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mkdir.md b/en/device-dev/kernel/kernel-small-debug-shell-file-mkdir.md similarity index 89% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mkdir.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-mkdir.md index 77106a85f0ff8cea82322cafbaf3a62fd5051f1a..7273ce06945d88ce084947735025e3420a7a08f8 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mkdir.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-mkdir.md @@ -1,8 +1,8 @@ -# mkdir +# mkdir - [Command Function](#section1083613274175) - [Syntax](#section820913118178) -- [Parameter Description](#section1256834121718) +- [Parameters](#section1256834121718) - [Usage](#section1294234115172) - [Example](#section1113345211713) - [Output](#section10142201012) @@ -15,9 +15,9 @@ This command is used to create a directory. mkdir \[_directory_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -35,7 +35,8 @@ ls \[_path_\]

ls error: No such directory

If the path value is a valid directory, the content of this directory is displayed.

-
  • Left blank
  • A valid directory
+

Left blank

+

A valid directory

- @@ -45,7 +45,7 @@ mkdir \[_directory_\] ## Example -Enter **mkdir share**. +Run **mkdir share**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mount.md b/en/device-dev/kernel/kernel-small-debug-shell-file-mount.md similarity index 88% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mount.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-mount.md index 37feb309a276cdc1d5ccb7c8c339c219141b2507..ac758b7aaa5ca144644b6558c1796839bcb2a3ec 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mount.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-mount.md @@ -1,8 +1,8 @@ -# mount +# mount - [Command Function](#section11631837182) - [Syntax](#section1697638111820) -- [Parameter Description](#section1650151221819) +- [Parameters](#section1650151221819) - [Usage](#section124541520171912) - [Example](#section7424625171917) - [Output](#section14757018116) @@ -15,9 +15,9 @@ This command is used to mount a device to a specified directory. mount <_device_\> <_path_\> <_name_\> \[_uid gid_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,7 +30,7 @@ mkdir \[_directory_\]

directory

Indicates the directory to be created.

+

Specifies the directory to create.

N/A

- - - @@ -68,11 +68,11 @@ By specifying the device to be mounted, directory, and file system format in the ## Example -Enter **mount /dev/mmcblk0p0 /bin1/vs/sd vfat**. +Run **mount /dev/mmcblk0p0 /bin1/vs/sd vfat**. ## Output Mounting **/dev/mmcblk0p0** to the **/bin1/vs/sd** directory -![](figure/en-us_image_0000001051690323.png) +![](figure/en-us_image_0000001134008688.png) diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-part.md b/en/device-dev/kernel/kernel-small-debug-shell-file-partinfo.md similarity index 80% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-part.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-partinfo.md index da5b18b5bdd5e36f0fe08c425ded9138dddb6df5..fc78146d8fd81f26128c90f59e6eabda446af7fb 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-part.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-partinfo.md @@ -1,23 +1,23 @@ -# partinfo +# partinfo - [Command Function](#section1777503617199) - [Syntax](#section185501447132114) -- [Parameter Description](#section1304151212252) +- [Parameters](#section1304151212252) - [Usage](#section4566131982520) - [Example](#section4351134942514) - [Output](#section66689331412) ## Command Function -This command is used to query information about multiple partitions of a hard disk or SD card identified by the system. +This command is used to query information about the partitions of a hard disk or SD card identified by the system. ## Syntax partinfo <_dev\_inodename_\> -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,22 +30,22 @@ mount <_device_\> <_path_\> <_name_\> \[_uid gid_\]

device

Indicates the path of the device to be mounted. The format is the path of the device.

+

Specifies the path of the device to be mounted. The format is the path of the device.

A device in the system

path

Indicates the directory of the device.

-

The user must have the execution (search) permission for the specified directory.

+

Specifies the directory of the device.

+

You must have the execution (search) permission for the specified directory.

N/A

name

Indicates the file system type.

+

Specifies the file system type.

vfat, yaffs, jffs, ramfs, nfs, procfs, romfs

- @@ -44,9 +44,9 @@ None ## Example -Enter **partinfo /dev/mmcblk0p0**. +Run **partinfo /dev/mmcblk0p0**. ## Output -![](figure/en-us_image_0000001052370303.png) +![](figure/en-us_image_0000001133848906.png) diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-partion.md b/en/device-dev/kernel/kernel-small-debug-shell-file-partition.md similarity index 91% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-partion.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-partition.md index 837e05d60891cbf73bac965aed673f4f2b341026..92e07a867ffb3d0f89d7eb0e3670d73ea7154da7 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-partion.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-partition.md @@ -1,8 +1,8 @@ -# partition +# partition - [Command Function](#section255095212257) - [Syntax](#section10258056122515) -- [Parameter Description](#section177200581256) +- [Parameters](#section177200581256) - [Usage](#section17866411262) - [Example](#section1927174202610) - [Output](#section11321011223) @@ -15,9 +15,9 @@ This command is used to query flash partition information. partition \[_nand / spinor_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,7 +30,7 @@ partinfo <_dev\_inodename_\>

dev_inodename

Indicates the name of the partition to be queried.

+

Specifies the name of the partition to be queried.

A valid partition name

- - - -

Parameter

@@ -52,11 +52,11 @@ partition \[_nand / spinor_\] ## Example -Enter **partition spinor**. +Run **partition spinor**. ## Output Viewing spinor flash partition information -![](figure/en-us_image_0000001052810300.png) +![](figure/en-us_image_0000001179848349.png) diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-pwd.md b/en/device-dev/kernel/kernel-small-debug-shell-file-pwd.md similarity index 71% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-pwd.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-pwd.md index 9f7182efd733fd05cad0f0a4c8d78f60ac50b074..53c5c94080b19c2089cc1456491ef3ddd8db5d02 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-pwd.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-pwd.md @@ -1,8 +1,8 @@ -# pwd +# pwd - [Command Function](#section197737712267) - [Syntax](#section1544061016267) -- [Parameter Description](#section599112120262) +- [Parameters](#section599112120262) - [Usage](#section66901116152615) - [Example](#section7427181922612) - [Output](#section116313389418) @@ -15,7 +15,7 @@ This command is used to display the current path. pwd -## Parameter Description +## Parameters None @@ -25,10 +25,10 @@ The **pwd** command writes the full path name of the current directory \(from ## Example -Enter **pwd**. +Run **pwd**. ## Output -**Figure 1** Querying the current path -![](figure/querying-the-current-path.png "querying-the-current-path") +**Figure 1** Displaying the current path +![](figure/displaying-the-current-path.png "displaying-the-current-path") diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rm.md b/en/device-dev/kernel/kernel-small-debug-shell-file-rm.md similarity index 91% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rm.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-rm.md index 072bb443e543c0309a97877e7f6a571387b5095f..90b52286a7c5dffb9f2793275675cfbbe9afda8c 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rm.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-rm.md @@ -1,8 +1,8 @@ -# rm +# rm - [Command Function](#section181141523142613) - [Syntax](#section8800926132619) -- [Parameter Description](#section15476229152617) +- [Parameters](#section15476229152617) - [Usage](#section10578163215262) - [Example](#section18548133511263) - [Output](#section1565323814265) @@ -15,9 +15,9 @@ This command is used to delete a file or folder. rm \[_-r_\] \[_dirname / filename_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description - @@ -54,8 +54,8 @@ rm \[_-r_\] \[_dirname / filename_\] Example: -1. Enter **rm log1.txt**. -2. Enter **rm -r sd**. +1. Run **rm log1.txt**. +2. Run **rm -r sd**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rmdir.md b/en/device-dev/kernel/kernel-small-debug-shell-file-rmdir.md similarity index 89% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rmdir.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-rmdir.md index 78b7459cd91a8b17f9a7dcc2770362f6599ca5ec..bdc4ecf057a3e63fc450ad09a10cc3df139121e7 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rmdir.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-rmdir.md @@ -1,8 +1,8 @@ -# rmdir +# rmdir - [Command Function](#section1839611420266) - [Syntax](#section329574512266) -- [Parameter Description](#section15865747102620) +- [Parameters](#section15865747102620) - [Usage](#section107857508261) - [Example](#section11196165315262) - [Output](#section1073811415613) @@ -15,9 +15,9 @@ This command is used to delete a directory. rmdir \[_dir_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -37,7 +37,7 @@ rm \[_-r_\] \[_dirname / filename_\]

dirname/filename

Indicates the name of the file or directory to be deleted. The value can be a path.

+

Specifies the name of the file or directory to be deleted. The value can be a path.

N/A

- @@ -46,7 +46,7 @@ rmdir \[_dir_\] ## Example -Enter **rmdir dir**. +Run **rmdir dir**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sta.md b/en/device-dev/kernel/kernel-small-debug-shell-file-statfs.md similarity index 85% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sta.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-statfs.md index d2dc901d2cd4c7bc8907b3a9dff3a4812ea099ea..59a073c1c6e62c9f34f082134aceb016bb63d5b3 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sta.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-statfs.md @@ -1,8 +1,8 @@ -# statfs +# statfs - [Command Function](#section153921657152613) - [Syntax](#section135391102717) -- [Parameter Description](#section074312314279) +- [Parameters](#section074312314279) - [Usage](#section133816772712) - [Example](#section526149182717) @@ -14,9 +14,9 @@ This command is used to print information about a file system, such as the type, statfs \[_directory_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,7 +30,7 @@ rmdir \[_dir_\]

dir

Indicates the name of the directory to be deleted. The directory must be empty. You can enter a path for this parameter.

+

Specifies the name of the directory to be deleted. The directory must be empty. You can enter a path for this parameter.

N/A

- - @@ -43,9 +43,9 @@ The printed information varies depending on the file system. ## Example -The following uses the NFS file system as an example: +The following uses the NFS as an example: -Enter **statfs /nfs**. +Run **statfs /nfs**. **Figure 1** Output of the statfs command ![](figure/output-of-the-statfs-command.png "output-of-the-statfs-command") diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sync.md b/en/device-dev/kernel/kernel-small-debug-shell-file-sync.md similarity index 69% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sync.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-sync.md index 6c82f8aa6a3f477eb8ecc03d206f6e96240b2572..6e8c72e2860cedbf488af181519fdaebe5f653b6 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sync.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-sync.md @@ -1,21 +1,21 @@ -# sync +# sync - [Command Function](#section1285017122274) - [Syntax](#section4731516162712) -- [Parameter Description](#section9352418122714) +- [Parameters](#section9352418122714) - [Usage](#section10725192142717) - [Example](#section414434814354) - [Output](#section19618121710317) ## Command Function -This command is used to synchronize cached data \(data in the file system\) to the SD card. +This command is used to synchronize cached data \(data in the file system\) to an SD card. ## Syntax sync -## Parameter Description +## Parameters None @@ -26,7 +26,7 @@ None ## Example -Enter **sync**. Data will be synchronized to the SD card when an SD card is available, and no operation will be performed if no SD card is available. +Run **sync**. Data will be synchronized to the SD card if an SD card is available, and no operation will be performed if no SD card is available. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-touch.md b/en/device-dev/kernel/kernel-small-debug-shell-file-touch.md similarity index 88% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-touch.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-touch.md index eef1d51cfac06ed388294a2cf896960faf4510ed..444be360786cae74e8d285b802aaf340d056cdcc 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-touch.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-touch.md @@ -1,8 +1,8 @@ -# touch +# touch - [Command Function](#section17541924112716) - [Syntax](#section866182711274) -- [Parameter Description](#section268912296270) +- [Parameters](#section268912296270) - [Usage](#section412093332714) - [Example](#section414434814354) - [Output](#section1028419515711) @@ -16,9 +16,9 @@ touch \[_filename_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -29,9 +29,9 @@ statfs \[_directory_\]

directory

Indicates the file system directory.

+

Specifies the file system directory.

The file system must exist and support the statfs command. Currently, the following file systems are supported: JFFS2, FAT, and NFS.

+

The file system must exist and support the statfs command. Currently, the file systems JFFS2, FAT, and NFS are supported.

- @@ -41,7 +41,7 @@ touch \[_filename_\] ## Usage -- The **touch** command creates a read-write empty file. +- The **touch** command creates an empty file that is readable and writeable. - The **touch** command creates only one file at a time. >![](../public_sys-resources/icon-notice.gif) **NOTICE:** @@ -50,7 +50,7 @@ touch \[_filename_\] ## Example -Enter **touch file.c**. +Run **touch file.c**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-umount.md b/en/device-dev/kernel/kernel-small-debug-shell-file-umount.md similarity index 85% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-umount.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-umount.md index ad2e4575a2e6bc658144afb407ae1a27fd95e468..d0dfb1adf251c76c1da4a82d5bddadb5c1238f64 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-umount.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-umount.md @@ -1,8 +1,8 @@ -# umount +# umount - [Command Function](#section365125133520) - [Syntax](#section9615254123512) -- [Parameter Description](#section63446577355) +- [Parameters](#section63446577355) - [Usage](#section92931509368) - [Example](#section144311323616) - [Output](#section360525113611) @@ -15,9 +15,9 @@ This command is used to unmount a specified file system. umount \[_dir_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -31,7 +31,7 @@ touch \[_filename_\]

filename

Indicates the name of the file to be created.

+

Specifies the name of the file to be created.

N/A

- - @@ -44,7 +44,7 @@ By specifying the **dir** parameter in the **unmount** command, you can unmo ## Example -Enter **umount /bin1/vs/sd**. +Run **umount /bin1/vs/sd**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-write.md b/en/device-dev/kernel/kernel-small-debug-shell-file-write.md similarity index 85% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-file-write.md rename to en/device-dev/kernel/kernel-small-debug-shell-file-write.md index 5bffaf6a19ae64f27475d646b8982f31c8012d36..4a9dd52448c1131f4fb028f70240cb530c11b37f 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-write.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-file-write.md @@ -1,8 +1,8 @@ -# writeproc +# writeproc - [Command Function](#section366714216619) - [Syntax](#section8833164614615) -- [Parameter Description](#section12809111019453) +- [Parameters](#section12809111019453) - [Usage](#section15935131220717) - [Example](#section79281818476) - [Output](#section12742311179) @@ -15,9 +15,9 @@ This command is used to write data to a specified proc file system. The proc fil writeproc <_data_\> \>\> /proc/<_filename_\> -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,9 +30,9 @@ umount \[_dir_\]

dir

Indicates the directory from which the file system is to be unmounted.

+

Specifies the directory from which the file system is to be unmounted.

Directory to which the file system has been mounted

+

Directory to which the file system is mounted

- - @@ -47,14 +47,14 @@ writeproc <_data_\> \>\> /proc/<_filename_\> ## Usage -The proc file implements its own **write** command. After the **writeproc** command is called, the input parameter will be passed to the **write** command. +The proc file implements its own **write** command. Calling the **writeproc** command will pass the input parameter to the **write** command. >![](../public_sys-resources/icon-note.gif) **NOTE:** ->The proc file system does not support multi-thread access. +>The procfs file system does not support multi-thread access. ## Example -Enter **writeproc test \>\> /proc/uptime**. +Run **writeproc test \>\> /proc/uptime**. ## Output diff --git a/en/device-dev/kernel/kernel-small-debug-shell-file.md b/en/device-dev/kernel/kernel-small-debug-shell-file.md new file mode 100644 index 0000000000000000000000000000000000000000..93d1834422f3ffd47272be9f2c640c547d84ea5d --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-shell-file.md @@ -0,0 +1,45 @@ +# File Commands + +- **[cat](kernel-small-debug-shell-file-cat.md)** + +- **[cd](kernel-small-debug-shell-file-cd.md)** + +- **[chgrp](kernel-small-debug-shell-file-chgrp.md)** + +- **[chmod](kernel-small-debug-shell-file-chmod.md)** + +- **[chown](kernel-small-debug-shell-file-chown.md)** + +- **[cp](kernel-small-debug-shell-file-cp.md)** + +- **[format](kernel-small-debug-shell-file-format.md)** + +- **[ls](kernel-small-debug-shell-file-ls.md)** + +- **[lsfd](kernel-small-debug-shell-file-lsfd.md)** + +- **[mkdir](kernel-small-debug-shell-file-mkdir.md)** + +- **[mount](kernel-small-debug-shell-file-mount.md)** + +- **[partinfo](kernel-small-debug-shell-file-partinfo.md)** + +- **[partition](kernel-small-debug-shell-file-partition.md)** + +- **[pwd](kernel-small-debug-shell-file-pwd.md)** + +- **[rm](kernel-small-debug-shell-file-rm.md)** + +- **[rmdir](kernel-small-debug-shell-file-rmdir.md)** + +- **[statfs](kernel-small-debug-shell-file-statfs.md)** + +- **[sync](kernel-small-debug-shell-file-sync.md)** + +- **[touch](kernel-small-debug-shell-file-touch.md)** + +- **[writeproc](kernel-small-debug-shell-file-write.md)** + +- **[umount](kernel-small-debug-shell-file-umount.md)** + + diff --git a/en/device-dev/kernel/kernel-lite-small-shell-guide.md b/en/device-dev/kernel/kernel-small-debug-shell-guide.md similarity index 67% rename from en/device-dev/kernel/kernel-lite-small-shell-guide.md rename to en/device-dev/kernel/kernel-small-debug-shell-guide.md index 9c984d76ba256de8a9ff82b1f4670c168a0ac19a..588af244e9bdf0bf2a306b9cde20ad577c4bdb1d 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-guide.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-guide.md @@ -1,8 +1,8 @@ -# Shell Command Development Guidelines +# Shell Command Development Guidelines -- [Development Guidelines](#section22071515161018) +- [Development Guidelines](#section13408945163812) -## Development Guidelines +## Development Guidelines You can perform the following operations to add shell commands: @@ -36,46 +36,45 @@ You can perform the following operations to add shell commands: - - - - -

Parameter

@@ -30,14 +30,14 @@ writeproc <_data_\> \>\> /proc/<_filename_\>

data

Indicates the string to be entered, which ends with a space. If you need to enter a space, use "" to enclose the space.

+

Specifies the string to be entered, which ends with a space. If you need to enter a space, use "" to enclose the space.

N/A

filename

Indicates the proc file to which data is to be passed.

+

Specifies the proc file to which data is to be passed.

N/A

l

Indicates the global variable name to be passed during the static registration. Note that the name cannot be the same as other symbol names in the system.

+

Specifies the global variable name passed in static registration. Note that the name cannot be the same as other symbol names in the system.

cmdType

Indicates the command type.

-
  • CMD_TYPE_EX: does not support standard command parameters and will mask the command keywords you entered. For example, if you enter ls /ramfs, only /ramfs will be passed to the registration function, and the ls command keyword will be masked.

    +

Specifies the command type, which can be any of the following:

+
  • CMD_TYPE_EX: does not support standard command parameters and will mask the command keywords you entered. For example, if you enter ls /ramfs, only /ramfs will be passed to the registration function, and ls will be masked.

  • CMD_TYPE_STD: supports standard command parameters. All the characters you entered will be passed to the registration function after being parsed.

cmdKey

Indicates the command keyword, which is the name used to access a shell function.

+

Specifies the command keyword, which is the name used to access a shell function.

paraNum

Indicates the maximum number of input parameters in the execution function to be invoked. This parameter is not supported currently.

+

Specifies the maximum number of input parameters in the execution function to be called. This parameter is not supported currently.

cmdHook

Indicates the address of the execution function, that is, the function that is actually executed by the command.

+

Specifies the address of the execution function, that is, the function executed by the command.

- For example: + Example: ``` SHELLCMD_ENTRY(ls_shellcmd, CMD_TYPE_EX, "ls", XARGS, (CMD_CBK_FUNC)osShellCmdLs) ``` - 2. Add the required options to the **build/mk/liteos\_tables\_ldflags.mk** file. + 2. Add options to the **build/mk/liteos\_tables\_ldflags.mk** file. For example, when registering the **ls** command, add **-uls\_shellcmd** to the **build/mk/liteos\_tables\_ldflags.mk** file. **-u** is followed by the first parameter of **SHELLCMD\_ENTRY**. - 2. Dynamic registration: The prototype of the function to register is as follows: @@ -95,39 +94,38 @@ You can perform the following operations to add shell commands:

cmdType

Indicates the command type.

-
  • CMD_TYPE_EX: does not support standard command parameters and will mask the command keywords you entered. For example, if you enter ls /ramfs, only /ramfs will be passed to the registration function, and the ls command keyword will be masked.

    -
  • CMD_TYPE_STD: supports standard command parameters. All the characters you entered will be passed to the registration function after being parsed.

    +

Specifies the command type, which can be any of the following:

+
  • CMD_TYPE_EX: does not support standard command parameters and will mask the command keywords you entered. For example, if you enter ls /ramfs, only /ramfs will be passed to the registration function, and ls will be masked.

    +
  • CMD_TYPE_STD: supports standard command parameters. All the characters you entered will be passed to the registration function after being parsed.

cmdKey

Indicates the command keyword, which is the name used to access a shell function.

+

Specifies the command keyword, which is the name used to access a shell function.

paraNum

Indicates the maximum number of input parameters in the execution function to be invoked. This parameter is not supported currently. The default value is XARGS(0xFFFFFFFF).

+

Specifies the maximum number of input parameters in the execution function to be called. This parameter is not supported currently. The default value is XARGS(0xFFFFFFFF).

cmdHook

Indicates the address of the execution function, that is, the function that is actually executed by the command.

+

Specifies the address of the execution function, that is, the function executed by the command.

- For example: + Example: ``` osCmdReg(CMD_TYPE_EX, "ls", XARGS, (CMD_CBK_FUNC)osShellCmdLs) ``` - >![](../public_sys-resources/icon-note.gif) **NOTE:** - >The command keyword must be unique. Specifically, two different commands cannot share the same command keyword. Otherwise, only one command is executed. + >The command keyword must be unique. That is, two different commands cannot share the same command keyword. Otherwise, only one command is executed. >When executing user commands sharing the same keyword, the shell executes only the first command in the **help** commands. 3. Use the following function prototype to add built-in commands: @@ -139,29 +137,29 @@ You can perform the following operations to add shell commands: **Table 3** Parameters of osShellCmdLs -

Parameter

+ - - - - -

Parameter

Description

+

Description

argc

+

argc

Indicates the number of parameters in the shell command.

+

Specifies the number of parameters in the shell command.

argv

+

argv

Indicates a pointer array, where each element points to a string. You can determine whether to pass the command keyword to the registration function by specifying the command type.

+

Specifies a pointer array, where each element points to a string. You can determine whether to pass the command keyword to the registration function by specifying the command type.

4. Enter the shell command in either of the following methods: - - Enter the shell command in the serial port tool. + - Enter the shell command in a serial port tool. - - Enter the shell command in the Telnet tool. For details, see [telnet](kernel-lite-small-shell-cmd-net-tel.md). + - Enter the shell command in the Telnet tool. For details, see [telnet](kernel-small-debug-shell-net-telnet.md). diff --git a/en/device-dev/kernel/kernel-small-debug-shell-magickey.md b/en/device-dev/kernel/kernel-small-debug-shell-magickey.md new file mode 100644 index 0000000000000000000000000000000000000000..efe0e7d795c8d3ffda3c0050238050cf200cfc45 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-shell-magickey.md @@ -0,0 +1,44 @@ +# Magic Key + +- [When to Use](#section2350114718546) +- [How to Use](#section3305151511559) + +## When to Use + +When the system does not respond, you can use the magic key to check whether the system is locked and interrupted \(the magic key also does not respond\) or view the system task running status. + +If an interrupt is responded, you can use the magic key to check the task CPU usage \(**cpup**\) and find out the task with the highest CPU usage. Generally, the task with a higher priority preempts the CPU. + +## How to Use + +1. Configure the macro **LOSCFG\_ENABLE\_MAGICKEY**. + +The magic key depends on the **LOSCFG\_ENABLE\_MAGICKEY** macro. Before using the magic key, select **Enable MAGIC KEY** on **menuconfig**. + +**Enable MAGIC KEY**: **Debug** ---\> **Enable MAGIC KEY** + +The magic key cannot be used if this macro is disabled. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>On **menuconfig**, you can move the cursor to **LOSCFG\_ENABLE\_MAGICKEY** and enter a question mark \(?\) to view help information. + +2. Press **Ctrl+R** to enable the magic key. + +When the UART or USB-to-virtual serial port is connected, press **Ctrl+R**. If "Magic key on" is displayed, the magic key is enabled. + +To disable the magic key, press **Ctrl+R** again. If "Magic key off" is displayed, the magic key is disabled. + +You can use the magic key combinations as follows: + +- **Ctrl+Z**: displays help information about the related magic keys. + +- **Ctrl+T**: displays task information. + +- **Ctrl+P**: allows the system to proactively enter the panic state. After the panic-related information is printed, the system is suspended. + +- **Ctrl+E**: Checks the integrity of the memory pool. If an error is detected, the system displays an error message. If no error is detected, the system displays "system memcheck over, all passed!". + + +>![](../public_sys-resources/icon-notice.gif) **NOTICE:** +>If special characters need to be entered through the UART or USB-to-virtual serial port if magic key is enabled, avoid using characters the same as the magic keys. Otherwise, the magic key may be triggered by mistake, causing errors in the original design. + diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-arp.md b/en/device-dev/kernel/kernel-small-debug-shell-net-arp.md similarity index 69% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-arp.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-arp.md index b0267af58de2fbc692cabe60efe2f02ba0c367ad..f9fdd97cf1529bf514a88b99ef00a1f6350190c9 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-arp.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-arp.md @@ -1,8 +1,8 @@ -# arp +# arp - [Command Function](#section201149459368) - [Syntax](#section579813484364) -- [Parameter Description](#section168065311366) +- [Parameters](#section168065311366) - [Usage](#section19190125723612) - [Example](#section10383416372) @@ -18,44 +18,44 @@ arp \[_-i IF_\] -s _IPADDR HWADDR_ arp \[_-i IF_\] -d _IPADDR_ -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

+ - - - - - - - - - @@ -72,7 +72,7 @@ arp \[_-i IF_\] -d _IPADDR_ Example: -1. Enter **arp**. +1. Run **arp**. **Figure 1** Printing the entire ARP cache table @@ -90,17 +90,17 @@ Example: - - - - - - - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ntp.md b/en/device-dev/kernel/kernel-small-debug-shell-net-ntpdate.md similarity index 83% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ntp.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-ntpdate.md index b7f6a6bb9656b87599c30b7932c7471a23140ef4..b2ad34fa981fec5863e88f049cef48fdf6916e8c 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ntp.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-ntpdate.md @@ -1,8 +1,8 @@ -# ntpdate +# ntpdate - [Command Function](#section38494293815) - [Syntax](#section5503114413387) -- [Parameter Description](#section136934472383) +- [Parameters](#section136934472383) - [Usage](#section121401651173816) - [Example](#section3431554203811) - [Output](#section18638194610115) @@ -15,9 +15,9 @@ This command is used to synchronize system time from the server. ntpdate \[_SERVER\_IP1_\] \[_SERVER\_IP2_\]... -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

Description

+

Description

Value Range

No parameter

+

No parameter

Prints the content of the entire ARP cache table.

+

Prints the content of the entire ARP cache table.

N/A

-i IF

+

-i IF

Indicates the network interface. This parameter is optional.

+

Specifies the network port. This parameter is optional.

N/A

-s IPADDR

+

-s IPADDR

HWADDR

Adds an ARP entry. The second parameter is the IP address and MAC address of the other host on the LAN.

+

Adds an ARP entry. The second parameter is the IP address and MAC address of the other host on the LAN.

N/A

-d IPADDR

+

-d IPADDR

Deletes an ARP entry.

+

Deletes an ARP entry.

N/A

Address

Indicates the IPv4 address of a network device.

+

IPv4 address of a network device.

HWaddress

Indicates the MAC address of a network device.

+

MAC address of a network device.

Iface

Indicates the name of the interface used by the ARP entry.

+

Name of the port used by the ARP entry.

Type

diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-dh.md b/en/device-dev/kernel/kernel-small-debug-shell-net-dhclient.md similarity index 93% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-dh.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-dhclient.md index fd93fad650c847384d2b77405089bf6c8780d450..11b8dc8ebd7df08eef4b25848803b5a7884c0cc1 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-dh.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-dhclient.md @@ -1,8 +1,8 @@ -# dhclient +# dhclient - [Command Function](#section366714216619) - [Syntax](#section8833164614615) -- [Parameter Description](#section12809111019453) +- [Parameters](#section12809111019453) - [Usage](#section15935131220717) - [Example](#section79281818476) - [Output](#section12742311179) @@ -27,9 +27,9 @@ dhclient -gd <_index_\> dhclient -sd <_dns\_ip_\> -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description - @@ -110,7 +110,7 @@ dhclient -sd 8.8.8.8 ## Example -![](figure/en-us_image_0000001053224218.png) +![](figure/en-us_image_0000001179848731.png) ## Output @@ -125,12 +125,12 @@ dhclient -sd 8.8.8.8 - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-dns.md b/en/device-dev/kernel/kernel-small-debug-shell-net-dns.md similarity index 87% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-dns.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-dns.md index 58c31e4099975537f0d1c3ba43c64d5a83aa0008..cceeb610f5064be74286875e37c2a55a11ea06f7 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-dns.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-dns.md @@ -1,8 +1,8 @@ -# dns +# dns - [Command Function](#section997513673713) - [Syntax](#section146015943711) -- [Parameter Description](#section5732111163716) +- [Parameters](#section5732111163716) - [Usage](#section15642141417371) - [Example](#section1995841617370) - [Output](#section1114210258917) @@ -17,9 +17,9 @@ dns <_1-2_\> <_IP_\> dns _-a_ -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -84,7 +84,7 @@ dhclient -sd <_dns\_ip_\>

-sd <dns_ip>

Indicates the IP address of the active DNS server.

+

Specifies the IP address of the active DNS server.

IP address of the DNS server

dhclient: set vendor info [MFSI] success

Indicates that the MFSI information is successfully set.

+

The MFSI information is successfully set.

dns[0]: 192.168.1.100

Indicates that the IP address of the DNS server is 192.168.1.100.

+

The IP address of the DNS server is 192.168.1.100.

- - @@ -63,12 +63,12 @@ None Example: 1. Check the current DNS settings. -2. Set the IP address of the second DNS server. -3. Verify the setting. +2. Set the IP address of the alternate DNS server. +3. Check the settings. ## Output -1. Checking the current DNS settings: +1. Check the current DNS settings: ``` OHOS # dns -a @@ -76,13 +76,13 @@ Example: dns2: 0.0.0.0 ``` -2. Setting the IP address of the second DNS server: +2. Set the IP address of the alternate DNS server: ``` OHOS # dns 2 192.168.1.2 ``` -3. Verifying the setting: +3. Check the settings: ``` OHOS # dns -a diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipc.md b/en/device-dev/kernel/kernel-small-debug-shell-net-ifconfig.md similarity index 54% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipc.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-ifconfig.md index 4b411d67d390b7f16f8776fe24c938a385225118..bcbc940468be426ba8363301472adcb31b650f19 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipc.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-ifconfig.md @@ -1,15 +1,18 @@ -# ifconfig +# ifconfig - [Command Function](#section174940284379) - [Syntax](#section136073203715) -- [Parameter Description](#section6493235203710) +- [Parameters](#section6493235203710) - [Usage](#section05763403371) - [Example](#section168802042123717) - [Output](#section124638211109) ## Command Function -This command is used to query and set parameters of a NIC, such as the IP address, subnet mask, gateway, and MAC address, and enable or disable the NIC. +This command can be used to: + +- Query and set network interface card \(NIC\) parameters, such as the IP address, network mask, gateway, and MAC address. +- Disable or enable a NIC. ## Syntax @@ -27,103 +30,103 @@ ifconfig \[_up|down_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description -

Parameter

@@ -32,14 +32,14 @@ dns _-a_

<1-2>

Indicates the DNS server to set the IP address.

+

Specifies the DNS server to set the IP address.

1 or 2

<IP>

Indicates the IP address of the server.

+

Specifies the IP address of the server.

N/A

- - - - - - - - -

Parameter

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -143,7 +146,7 @@ ifconfig ## Output -1. Setting network parameters: +1. Set network parameters. ``` OHOS # ifconfig eth0 192.168.100.31 netmask 255.255.255.0 gateway 192.168.100.1 hw ether 00:49:cb:6c:a1:31 @@ -168,27 +171,27 @@ ifconfig - - - - - - -

Parameter

Description

+

Description

Value Range

+

Value Range

No parameter

+

No parameter

Displays information about all NICs, including the IP addresses, subnet masks, gateways, MAC addresses, maximum transmission units (MTUs), and running statuses.

+

Displays the IP addresses, network masks, gateway, MAC addresses, MTU, and running status of all NICs.

N/A

+

N/A

-a

+

-a

Displays data sent and received by the protocol stack.

+

Displays data sent and received by the protocol stack.

N/A

+

N/A

interface

+

interface

Indicates the NIC name, for example, eth0.

+

Specifies the NIC name, for example, eth0.

N/A

+

N/A

address

+

address

Indicates the IP address, for example, 192.168.1.10. The NIC name must be specified.

+

Specifies the IP address, for example, 192.168.1.10. The NIC name must be specified.

N/A

+

N/A

netmask

+

netmask

Indicates the subnet mask, for example, 255.255.255.0.

+

Specifies the subnet mask, for example, 255.255.255.0.

N/A

+

N/A

gateway

+

gateway

Indicates the gateway, for example, 192.168.1.1.

+

Specifies the gateway, for example, 192.168.1.1.

N/A

+

N/A

hw ether

+

hw ether

Indicates the MAC address, for example, 00:11:22:33:44:55. Currently, only the ether hardware type is supported.

+

Specifies the MAC address, for example, 00:11:22:33:44:55. Currently, only the ether hardware type is supported.

N/A

+

N/A

mtu

+

mtu

Indicates the MTU size, for example, 1000.

+

Specifies the maximum transmission unit (MTU) size, for example, 1000.

  • For IPv4:

    [68,1500]

    +
  • For IPv4:

    [68,1500]

  • For IPv6:

    [1280, 1500]

add

+

add

Indicates the IPv6 address, for example, 2001:a:b:c:d:e:f:d. The NIC name and inet6 must be specified.

+

Specifies the IPv6 address, for example, 2001:a:b:c:d:e:f:d. The NIC name and inet6 must be specified.

N/A

+

N/A

del

+

del

Deletes an IPv6 address. The NIC name and inet6 must be specified.

+

Deletes an IPv6 address. The NIC name and inet6 must be specified.

N/A

+

N/A

up

+

up

Enables the data processing function of the NIC. The NIC name must be specified.

+

Enables the data processing function of the NIC. The NIC name must be specified.

N/A

+

N/A

down

+

down

Disables the data processing function of the NIC. The NIC name must be specified.

+

Disables the data processing function of the NIC. The NIC name must be specified.

N/A

+

N/A

ip

Indicates the IP address of the board.

+

IP address of the board

netmask

Indicates the subnet mask.

+

Subnet mask

gateway

Indicates the gateway.

+

Gateway

HWaddr

Indicates the MAC address of the board.

+

MAC address of the board

MTU

Indicates the MTU.

+

Maximum transmission unit

Running/Stop

@@ -198,18 +201,18 @@ ifconfig

Default

Indicates that the NIC is connected to the default gateway.

+

The NIC is connected to the default gateway.

Link UP/Down

Indicates the connection status of the NIC.

+

Connection status of the NIC

-2. Obtaining protocol stack statistics: +2. Obtain protocol stack statistics. ``` OHOS # ifconfig -a @@ -232,42 +235,42 @@ ifconfig

RX packets

Indicates the number of normal packets that have been received at the IP layer.

+

Number of normal packets received at the IP layer.

RX error

Indicates the number of error packets that have been received at the IP layer. The errors include the length, verification, IP option, and IP header protocol errors.

+

Number of error packets received at the IP layer. The errors include the length, verification, IP option, and IP header protocol errors.

RX dropped

Indicates the number of packets that have been discarded at the IP layer. Packets may be discarded due to packet errors, packet forwarding failures, and disabled local NICs.

+

Number of packets discarded at the IP layer. Packets are discarded due to packet errors, packet forwarding failures, and disabled local NICs.

RX overrun

Indicates the number of packets that the MAC layer fails to deliver to the upper-layer protocol stack. The failure is mainly caused by resource insufficiency at the protocol stack.

+

Number of packets that the MAC layer fails to deliver to the upper-layer protocol stack. The failure is mainly caused by resource insufficiency at the protocol stack.

RX bytes

Indicates the total length of normal packets that have been received at the IP layer, excluding the length of the fragments that are not reassembled.

+

Total length of normal packets received at the IP layer, excluding the length of the fragments that are not reassembled.

TX packets

Indicates the number of packets that have been normally sent or forwarded at the IP layer.

+

Number of packets that have been normally sent or forwarded at the IP layer.

TX error

Indicates the number of packets that the IP layer fails to send. Packets may fail to be sent because the packets cannot be routed or the packets fail to be processed in the protocol stack.

+

Number of packets that the IP layer fails to send. Packets may fail to be sent because the packets cannot be routed or the packets fail to be processed in the protocol stack.

TX dropped

Indicates the number of packets that the MAC layer discards due to sending failures, for example, the NIC driver fails to process the packets.

+

Number of packets that the MAC layer discards due to sending failures, for example, the NIC driver fails to process the packets.

TX overrun

@@ -277,13 +280,13 @@ ifconfig

TX bytes

Indicates the total length of the packets that the IP layer has successfully sent or forwarded.

+

Total length of the packets successfully sent or forwarded at the IP layer.

-3. Setting the IPv6 address information: +3. Set the IPv6 address information. ``` OHOS # ifconfig eth0 inet6 add 2001:a:b:c:d:e:f:d @@ -298,7 +301,7 @@ ifconfig HWaddr 00 MTU:16436 Running Link UP ``` -4. Deleting the IPv6 address information: +4. Delete the IPv6 address information. ``` OHOS # ifconfig eth0 inet6 del 2001:a:b:c:d:e:f:d diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipd.md b/en/device-dev/kernel/kernel-small-debug-shell-net-ipdebug.md similarity index 95% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipd.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-ipdebug.md index 2b69aa299120348f5dc38b73b7b5431762dadcb6..2c6a01fe5cef6cdc4ce38e16a53e4d07a5dd869b 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipd.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-ipdebug.md @@ -1,4 +1,4 @@ -# ipdebug +# ipdebug - [Command Function](#section10191115553720) - [Syntax](#section124061758123713) @@ -15,7 +15,7 @@ ipdebug ## Usage -Enter the **ipdebug** command. +Run the **ipdebug** command. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-net.md b/en/device-dev/kernel/kernel-small-debug-shell-net-netstat.md similarity index 85% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-net.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-netstat.md index 362fa9a4301ca48b86cab9e2732fcfdfd9a89c4e..3f767f81c21cd85af3d9b91b026c64b3cbdb720b 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-net.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-netstat.md @@ -1,8 +1,8 @@ -# netstat +# netstat - [Command Function](#section13469162113816) - [Syntax](#section795712373812) -- [Parameter Description](#section17629431193817) +- [Parameters](#section17629431193817) - [Usage](#section5277153519380) - [Example](#section108141437163820) - [Output](#section1357015107117) @@ -15,7 +15,7 @@ The **netstat** command is a console command and is used for monitoring the TC netstat -## Parameter Description +## Parameters None @@ -25,12 +25,12 @@ Run the command directly. ## Example -Enter **netstat**. +Run **netstat**. **Figure 1** Output information -![](figure/snipaste_2021-01-26_10-38-58-20.png) +![](figure/snipaste_2021-01-26_10-38-58-25.png) ## Output @@ -45,13 +45,13 @@ Enter **netstat**.

Proto

Indicates the protocol type.

+

Protocol type.

Recv-Q

Indicates the amount of data that is not read by the user.

-

For Listen TCP, the value indicates the number of TCP connections that have completed three-way handshake but are not accepted by users.

+

Amount of data that is not read by the user.

+

For Listen TCP, the value indicates the number of TCP connections that have finished three-way handshake but are not accepted by users.

Send-Q

@@ -62,17 +62,17 @@ Enter **netstat**.

Local Address

Indicates the local IP address and port number.

+

Local IP address and port number.

Foreign Address

Indicates the remote IP address and port number.

+

Remote IP address and port number.

State

Indicates the TCP connection status. This parameter is meaningless for UDP.

+

TCP connection status. This parameter is meaningless for UDP.

- @@ -44,7 +44,7 @@ Run the **ntpdate **\[_SERVER\_IP1_\] \[_SERVER\_IP2_\]... command. **ntpdate* ## Example -To update the system time, run **ntpdate 192.168.1.3**. +Run **ntpdate 192.168.1.3 **to update the system time. ## Output @@ -53,5 +53,5 @@ OHOS # ntpdate 192.168.1.3 time server 192.168.1.3: Mon Jun 13 09:24:25 2016 ``` -The time zone of the board is different from that of the server. Therefore, the displayed time may be several hours different from the obtained server time. +If the time zone of the board is different from that of the server, the displayed time may be several hours different from the obtained server time. diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping.md b/en/device-dev/kernel/kernel-small-debug-shell-net-ping.md similarity index 84% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-ping.md index 0d83722cacc365360530ae1ea7d9e141cb86155c..7f71d8e4bec03303186053fc9cb019e13a05f786 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-ping.md @@ -1,15 +1,15 @@ -# ping +# ping - [Command Function](#section119672573385) - [Syntax](#section869419010390) -- [Parameter Description](#section9877183173918) +- [Parameters](#section9877183173918) - [Usage](#section1097046193914) - [Example](#section14564129113911) - [Output](#section1621732891215) ## Command Function -This command is used to test whether the network connection is normal. +This command is used to test an IPv4 network connection. ## Syntax @@ -19,9 +19,9 @@ ping \[_-t_\] \[_-w interval_\] __ ping _-k_ -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,7 +30,7 @@ ntpdate \[_SERVER\_IP1_\] \[_SERVER\_IP2_\]...

SERVER_IP

Indicates the IP address of the NTP server.

+

Specifies the IP address of the NTP server.

N/A

- - - - - @@ -87,12 +86,12 @@ ping _-k_ ## Example -Enter **ping 192.168.1.10**. +Run **ping 192.168.1.10**. ## Output **Figure 1** Output of pinging the IP address of the TFTP server -![](figure/snipaste_2021-01-26_10-38-58-21.png) +![](figure/snipaste_2021-01-26_10-38-58-26.png) diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping6.md b/en/device-dev/kernel/kernel-small-debug-shell-net-ping6.md similarity index 93% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping6.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-ping6.md index 94d42b51b9cdcc29c44548d33b27436b0ee884ee..4c91d848aafb7606eec15903923744764d4b8b42 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping6.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-ping6.md @@ -1,23 +1,23 @@ -# ping6 +# ping6 - [Command Function](#section1057291313393) - [Syntax](#section199901315123919) -- [Parameter Description](#section4679319113919) +- [Parameters](#section4679319113919) - [Usage](#section1127917226399) - [Example](#section7211192553917) - [Output](#section4846145221215) ## Command Function -This command is used to test whether the IPv6 network connection is normal. +This command is used to test an IPv6 network connection. ## Syntax ping6 _\[-c count\] \[-I interface / sourceAddress\] destination_ -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -34,36 +34,35 @@ ping _-k_

IP

Indicates the IPv4 address whose network connectivity is to be tested.

+

Specifies the IPv4 address whose network connectivity is to be tested.

N/A

-n cnt

Indicates the number of execution times. If this parameter is not specified, the default value is 4.

+

Specifies the number of execution times. If this parameter is not specified, the default value is 4.

1-65535

-w interval

Indicates the interval between two ping packets, in ms.

+

Specifies the interval (in ms) between two ping packets.

>0

-l data_len

Indicates the length of the ping packet, that is, the ICMP echo request packet.

-

The ICMP packet header is not included.

+

Specifies the data length of the ICMP echo request packet, excluding the ICMP packet header.

0-65500

-t

Indicates a permanent ping thread, which will be killed until the ping -k command is executed.

+

Specifies a permanent ping thread, which will be killed until the ping -k command is executed.

N/A

- @@ -44,14 +44,14 @@ ping6 _\[-c count\] \[-I interface / sourceAddress\] destination_ - - diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tel.md b/en/device-dev/kernel/kernel-small-debug-shell-net-telnet.md similarity index 91% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tel.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-telnet.md index 30c190696e0d3b2ef1a2ead7cc8d1e25997909b3..af27c72b2812feca8e3281fb12eeff521d831342 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tel.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-telnet.md @@ -1,8 +1,8 @@ -# telnet +# telnet - [Command Function](#section3551830123913) - [Syntax](#section14897133233918) -- [Parameter Description](#section977718353392) +- [Parameters](#section977718353392) - [Usage](#section134991538183916) - [Example](#section1097414426398) - [Output](#section11846624191310) @@ -15,9 +15,9 @@ This command is used to enable or disable the Telnet server service. telnet \[_on | off_\] -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description

Parameter

@@ -30,7 +30,7 @@ ping6 _\[-c count\] \[-I interface / sourceAddress\] destination_

-c count

Indicates the number of execution times. If this parameter is not specified, the default value is 4.

+

Specifies the number of execution times. If this parameter is not specified, the default value is 4.

1~65535

-I sourceAddress

Indicates the source IPv6 address to be pinged.

+

Specifies the source IPv6 address.

N/A

destination

Indicates the IP address of the destination host.

+

Specifies the IP address of the destination host.

N/A

- - - - - - -

Parameter

@@ -51,12 +51,12 @@ telnet \[_on | off_\] - Currently, multiple clients \(Telnet + IP\) cannot connect to the development board at the same time. >![](../public_sys-resources/icon-notice.gif) **NOTICE:** - >Telnet is under debugging and disabled by default. Do not use it in formal products. + >Telnet is used for debugging and disabled by default. Do not use it in formal products. ## Example -Enter **telnet on**. +Run **telnet on**. ## Output diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tftp.md b/en/device-dev/kernel/kernel-small-debug-shell-net-tftp.md similarity index 89% rename from en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tftp.md rename to en/device-dev/kernel/kernel-small-debug-shell-net-tftp.md index 3da40ac274b26ac660065256ad5d8a99c9da8468..21983306a479c883a6da6914cb80bbd9007cf0cf 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tftp.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-net-tftp.md @@ -1,8 +1,8 @@ -# tftp +# tftp - [Command Function](#section15142134573911) - [Syntax](#section20958174917394) -- [Parameter Description](#section576613532395) +- [Parameters](#section576613532395) - [Usage](#section149795134408) - [Example](#section148921918114015) - [Output](#section7872155631313) @@ -11,15 +11,15 @@ Trivial File Transfer Protocol \(TFTP\) is a protocol in the TCP/IP protocol suite for transferring files between clients and servers. TFTP provides simple and low-overhead file transfer services. The port number is 69. -The **tftp** command is used to download files from the TFTP server. +The **tftp** command is used to transfer files with a TFTP server. ## Syntax ./bin/tftp _<-g/-p\>_ _-l_ _\[FullPathLocalFile\] -r \[RemoteFile\] \[Host\]_ -## Parameter Description +## Parameters -**Table 1** Parameters +**Table 1** Parameter description - - - - @@ -69,7 +69,7 @@ The **tftp** command is used to download files from the TFTP server. 3. The size of the file to be transferred cannot exceed 32 MB. >![](../public_sys-resources/icon-notice.gif) **NOTICE:** - >TFTP is under debugging and disabled by default. Do not use it in formal products. + >TFTP is used for debugging and disabled by default. Do not use it in formal products. ## Example diff --git a/en/device-dev/kernel/kernel-small-debug-shell-net.md b/en/device-dev/kernel/kernel-small-debug-shell-net.md new file mode 100644 index 0000000000000000000000000000000000000000..3b0fc77fc7e3e5617a7735da4fabf4d69b0fb73a --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-shell-net.md @@ -0,0 +1,25 @@ +# Network Commands + +- **[arp](kernel-small-debug-shell-net-arp.md)** + +- **[dhclient](kernel-small-debug-shell-net-dhclient.md)** + +- **[dns](kernel-small-debug-shell-net-dns.md)** + +- **[ifconfig](kernel-small-debug-shell-net-ifconfig.md)** + +- **[ipdebug](kernel-small-debug-shell-net-ipdebug.md)** + +- **[netstat](kernel-small-debug-shell-net-netstat.md)** + +- **[ntpdate](kernel-small-debug-shell-net-ntpdate.md)** + +- **[ping](kernel-small-debug-shell-net-ping.md)** + +- **[ping6](kernel-small-debug-shell-net-ping6.md)** + +- **[telnet](kernel-small-debug-shell-net-telnet.md)** + +- **[tftp](kernel-small-debug-shell-net-tftp.md)** + + diff --git a/en/device-dev/kernel/kernel-lite-small-shell-des.md b/en/device-dev/kernel/kernel-small-debug-shell-overview.md similarity index 55% rename from en/device-dev/kernel/kernel-lite-small-shell-des.md rename to en/device-dev/kernel/kernel-small-debug-shell-overview.md index 2bbbee37a67679fd6818ef68463549b4841ac47e..5f10425f3a54aa66aeab753271424eb608f46d53 100644 --- a/en/device-dev/kernel/kernel-lite-small-shell-des.md +++ b/en/device-dev/kernel/kernel-small-debug-shell-overview.md @@ -1,16 +1,16 @@ -# Introduction to the Shell +# Introduction to the Shell - [Important Notes](#section12298165312328) -The Shell provided by the OpenHarmony kernel supports commonly used commissioning commands, including those related to the system, files, networks, and dynamic loading. In addition, you can add custom commands to the shell of the OpenHarmony kernel to address your service needs. +The shell provided by the OpenHarmony kernel supports commonly used debugging commands. You can also add and custom commands to the shell of the OpenHarmony kernel to address your service needs. The common debugging commands include the following: -- System-related commands: querying information about system tasks, kernel semaphores, system software timers, CPU usage, and current interrupts +- System commands: commands used to query information, such as system tasks, semaphores, system software timers, CPU usage, and interrupts. -- File-related commands: basic functions such as **ls** and **cd** +- File commands: commands used to manage files and directories, such as **ls** and **cd**. -- Network-related commands: querying the IP addresses of other devices connected to the development board, querying the IP address of the local device, testing the network connectivity, and setting the access point \(AP\) and station modes of the development board +- Network commands: commands used to query the IP addresses of other devices connected to the development board, querying the IP address of the local device, testing network connectivity, and setting the access point \(AP\) and station modes of the development board. - For details about the process of adding commands, see [Shell Command Development Guidelines](kernel-lite-small-shell-guide.md) and [Shell Command Programming Example](kernel-lite-small-shell-sample.md). + For details about how to add a command, [Shell Command Development Guidelines](kernel-small-debug-shell-guide.md) and [Shell Command Programming Example](kernel-small-debug-shell-build.md). ## Important Notes @@ -18,7 +18,7 @@ The Shell provided by the OpenHarmony kernel supports commonly used commissionin Note the following when using the shell: - You can use the **exec** command to run executable files. -- The shell supports English input in default mode. If you enter Chinese characters in the UTF-8 format, you can delete them only by pressing the backspace key for three times. +- The shell supports English input by default. To delete the Chinese characters entered in UTF-8 format, press the backspace key for three times. - When entering shell commands, file names, and directory names, you can press **Tab** to enable automatic completion. If there are multiple completions, multiple items are printed based on the same characters they have. If more than 24 lines of completions are available, the system displays message "Display all num possibilities?\(y/n\)", asking you to determine whether to print all items. You can enter **y** to print all items or enter **n** to exit the printing. If more than 24 lines are printed after your selection, the system displays "--More--". In this case, you can press **Enter** to continue the printing or press **q** \(or **Ctrl+c**\) to exit. @@ -28,9 +28,9 @@ Note the following when using the shell: - You are not advised to run shell commands to perform operations on device files in the **/dev** directory, which may cause unexpected results. -- The shell functions do not comply with the POSIX standards and are used only for commissioning. +- The shell functions do not comply with the POSIX standards and are used only for debugging. >![](../public_sys-resources/icon-notice.gif) **NOTICE:** - >The shell functions are used for commissioning only and can be enabled only in the Debug version \(by enabling the **LOSCFG\_DEBUG\_VERSION** configuration item using **menuconfig**\). + >The shell functions are used for debugging only and can be enabled only in the Debug version \(by enabling the **LOSCFG\_DEBUG\_VERSION** configuration item using **menuconfig**\). diff --git a/en/device-dev/kernel/kernel-small-debug-shell.md b/en/device-dev/kernel/kernel-small-debug-shell.md new file mode 100644 index 0000000000000000000000000000000000000000..796f47741804807b1446360509d2febd05c994c6 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-shell.md @@ -0,0 +1,15 @@ +# Shell + +- **[Introduction to the Shell](kernel-small-debug-shell-overview.md)** + +- **[Shell Command Development Guidelines](kernel-small-debug-shell-guide.md)** + +- **[Shell Command Programming Example](kernel-small-debug-shell-build.md)** + +- **[Shell Command Reference](kernel-small-debug-shell-details.md)** + +- **[Magic Key](kernel-small-debug-shell-magickey.md)** + +- **[User-Space Exception Information](kernel-small-debug-shell-error.md)** + + diff --git a/en/device-dev/kernel/kernel-small-debug-trace-other-faqs.md b/en/device-dev/kernel/kernel-small-debug-trace-other-faqs.md new file mode 100644 index 0000000000000000000000000000000000000000..eeaa4efd5a926c469388fb26a9d1ac4da48342b6 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-trace-other-faqs.md @@ -0,0 +1,36 @@ +# Common Fault Locating Methods + +- [Locating the Fault based on Exception Information](#section695838161711) +- [Checking Memory Pool Integrity](#section362917569179) +- [Locating Memory Overwriting for a Global Variable](#section18971311121816) + +## Locating the Fault based on Exception Information + +When the system is suspended unexpectedly, information about key registers is displayed on the serial port, as shown in the following figure. The information can be used to locate the function where the exception occurs and the related call stack. + +Exception information + +![](figure/en-us_image_0000001173429547.png) + +The exception information in the preceding figure is described as follows: + +①: indicates that the exception occurs in the kernel space. + +②: indicates the exception type. The value of **far** is the address accessed by the CPU when the exception occurs. + +③: The **pc** value indicates the location of the instruction being executed when the exception occurs. The **klr** value indicates the next instruction to be executed. \(Note: You do not need to pay attention to the value of **klr** if **traceback 0 lr** in ④ has a value.\) + +④: The **lr** values indicate the locations of the instructions to be executed by the program counter in sequence in normal cases. + +You also need to check the **OHOS\_Image.asm** file \(assembly file corresponding to the burnt system image **OHOS\_Image.bin**\) in the **out** directory to determine the locations of the instructions corresponding to **pc** and **lr**. Based on the locations of the instructions, determine the functions using the instructions and the functions where **lr**s are located in sequence. In this way, you can obtain the function call relationships when the exception occurs. + +## Checking Memory Pool Integrity + +You may not directly locate the fault only with the exception information. Sometimes, the fault cannot be located due to incorrect register values. If you suspect that the fault is caused by heap memory overwriting, you can call **LOS\_MemIntegrityCheck** to check the memory pool integrity. The **LOS\_MemIntegrityCheck** function traverses all nodes in the dynamic memory pool of the system. If all nodes are normal, the function returns **0** and no information is printed. Otherwise, error information is printed. This function uses **\(VOID \*\)OS\_SYS\_MEM\_ADDR** as the input parameter. + +Generally, **LOS\_MemIntegrityCheck** is called before and after the suspected service logic code to locate the heap memory overwriting. If the service code is correct, **LOS\_MemIntegrityCheck** can be called successfully. By doing this, you can narrow down and locate the fault. + +## Locating Memory Overwriting for a Global Variable + +If the memory of a global variable is illegally accessed, locate the address of the global variable in the **OHOS\_Image.map** file and pay special attention to the variables recently used before the address. There is a high probability that memory overwriting occurs when the preceding variables \(especially variables of the array type or variables that are forcibly converted to other types\) are used. + diff --git a/en/device-dev/kernel/kernel-small-debug-trace-other-lastwords.md b/en/device-dev/kernel/kernel-small-debug-trace-other-lastwords.md new file mode 100644 index 0000000000000000000000000000000000000000..632809b2a3627e961615a427613cfb0e17ef0567 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-trace-other-lastwords.md @@ -0,0 +1,96 @@ +# Dying Gasp + +- [When to Use](#section158501652121514) +- [Available APIs](#section1186411122215) +- [Parameters](#section1083765723015) +- [How to Develop](#section783435801510) + +## When to Use + +For a device without a serial port, save the exception information to a non-volatile storage medium to facilitate fault location during system running. + +## Available APIs + +The system provides a mechanism to save printed exception information to a non-volatile storage medium. You can register the hook functions for printing information when the read and write operations are abnormal. In this way, fault information can be saved on different storage media, facilitating fault locating for devices without serial ports. The API is **LOS\_ExcInfoRegHook**. This function is declared in **los\_config.h**. The function prototype is as follows: + +``` +typedef VOID (*log_read_write_fn)(UINT32 startAddr, UINT32 space, UINT32 rwFlag, CHAR *buf); +... +VOID LOS_ExcInfoRegHook(UINT32 startAddr, UINT32 space, CHAR *buf, log_read_write_fn hook); +``` + +## Parameters + +**Table 1** LOS\_ExcInfoRegHook parameter description + + +

Parameter

@@ -32,7 +32,7 @@ The **tftp** command is used to download files from the TFTP server.

-g/-p

Indicates the file transfer direction.

+

Specifies the file transfer direction.

  • -g: downloads files from the TFTP server.
  • -p: uploads files to the TFTP server.

N/A

@@ -40,21 +40,21 @@ The **tftp** command is used to download files from the TFTP server.

-l FullPathLocalFile

Indicates the complete path of a local file.

+

Specifies the complete path of a local file.

N/A

-r RemoteFile

Indicates the file name on the server.

+

Specifies the file name on the server.

N/A

Host

Indicates the server IP address.

+

Specifies the server IP address.

N/A

+ + + + + + + + + + + + + + + + +

Parameter

+

Description

+

startAddr

+

Start address of the physical medium to be got or set

+

space

+

Size of the space

+

buf

+

Memory buffer used to get or set the exception information

+

log_read_write_fn

+

Function used to get or set the exception information

+
+ +**Table 2** log\_read\_write\_fn parameter description + + + + + + + + + + + + + + + + + + + +

Parameter

+

Description

+

startAddr

+

Start address of the physical medium to be got or set

+

space

+

Size of the space

+

rwFlag

+

Read/Write flag. The value 0 indicates write, and the value 1 indicates read.

+

buf

+

Memory buffer used to get or set the exception information

+
+ +## How to Develop + +The dying gasp function depends on the macro **LOSCFG\_SAVE\_EXCINFO**. Before using this function, choose **Debug**-\> **Enable Saving Exception Information** in the configuration items to enable this macro. If this macro is disabled, this function cannot be used. Then, call **LOS\_ExcInfoRegHook** in **SystemInit** to register the position, size, memory buffer, and access function for accessing the exception information. When an exception occurs in the system, the system saves the exception information in the memory buffer passed in the registration, and then calls the registered access function to write the exception information to the physical storage medium. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The location registered to storing the exception information cannot overlap with other storage locations. +>- The registered memory buffer should be greater than or equal to 16 KiB. Otherwise, the exception information stored may be incomplete. +>- The exception information can be accessed successfully only when the driver of the storage medium corresponding to the registered read/write function is normal. + diff --git a/en/device-dev/kernel/kernel-small-debug-trace.md b/en/device-dev/kernel/kernel-small-debug-trace.md new file mode 100644 index 0000000000000000000000000000000000000000..45045314597e00a52cafd133d61f0a8ac837ec47 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug-trace.md @@ -0,0 +1,102 @@ +# Trace + +- [Basic Concepts](#section531482192018) +- [Working Principles](#section5125124532010) +- [Usage](#section1381714413216) + +## Basic Concepts + +Trace is a functional framework provided by the kernel for tracing key processes of modules. You can implement trace at key positions for modules based on mechanism requirements, and export the traced information as files or in other modes for further analysis. + +The requirements for trace are as follows: + +1. The information needs to be recorded as soon as possible to minimize the impact on the system time sequence. +2. Use as little space as possible to store as much as possible data to reduce memory consumption. + +## Working Principles + +Initialize the trace function at the beginning of the kernel startup. When the modules that support the trace function are initialized, register the trace type and callback functions. The position of the trace point that triggers trace recording can be determined by each module. + +When a trace point is triggered, the trace module encapsulates the input information and adds the trace frame header information, including the trace type, ID of the running CPU, ID of the running task, relative timestamp of the running task, and ID of the running process. Then, the trace frame is recorded in a pre-requested cyclic buffer. + +If too many frames are recorded in the cyclic buffer, earlier frames will be overwritten to ensure that the information in the buffer is always the latest. The traced data in the cyclic buffer can be exported, for example, by using file dumping, for further analysis. The exported files are sorted by timestamp. + +![](figure/en-us_image_0000001127390512.png) + +## Usage + +1. Configure the trace macro **LOSCFG\_KERNEL\_TRACE**, which is disabled by default. You can enable it by choosing **Kernel** \> **Enable Trace Feature** on the **menuconfig**. +2. Call **OsTraceInit** to complete trace initialization. +3. Define the traceframe structure of the module in **los\_trace\_frame.h**, and implement the trace callback function of the module in **los\_trace\_frame.c**. +4. Call **LOS\_TraceReg** to register trace in the initialization or earlier phase for the modules to be traced. +5. Enable the trace function at the position where the tracing starts and disable the trace function at the position where the tracing stops. +6. Call **LOS\_Trace2File** to export traced data to a file. +7. Perform further data analysis based on the frame header and frame body structure. + +**Available APIs** + +The following table describes APIs available for the OpenHarmony LiteOS-A trace framework. For more details about the APIs, see the API reference. + +**Table 1** Trace Interface Description + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Category

+

API

+

Description

+

Tracing information

+

LOS_Trace

+

Traces information.

+

Registration and unregistration

+

LOS_TraceReg

+

Registers the trace type.

+

LOS_TraceUnreg

+

Unregisters the trace type.

+

Switch

+

LOS_TraceTypeSwitch

+

Enables or disables the specified type of trace.

+

LOS_TraceSwitch

+

Enables or disables the trace function.

+

Data export

+

LOS_TraceBufDataGet

+

Exports trace data to the heap cache. (The cache space is allocated internally and must be released explicitly.)

+

LOS_Trace2File

+

Saves the trace data to the file system (depending on the file system).

+
+ +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>- The frame buffer is a cyclic buffer. When it is full, a subsequent write will cause overwrite of the oldest data. You can configure the buffer size in the **LOS\_TRACE\_BUFFER\_SIZE** macro in **los\_config.h**. The default size is **512** KiB. +>- Although trace has completed the assembly and recording as soon as possible, it still has impact on the overall performance of the system. +>- Trace supports concurrent recording of multiple modules. You can reduce the data analysis volume by enabling or disabling the trace function for different modules on demand. +>- The task, memory, and liteipc modules of the kernel support the trace recording function. + diff --git a/en/device-dev/kernel/kernel-small-debug.md b/en/device-dev/kernel/kernel-small-debug.md new file mode 100644 index 0000000000000000000000000000000000000000..a9ffe18bdfc44fa18085feeb472e35d25fdbeeda --- /dev/null +++ b/en/device-dev/kernel/kernel-small-debug.md @@ -0,0 +1,13 @@ +# Debugging and Tools + +- **[Shell](kernel-small-debug-shell.md)** + +- **[Trace](kernel-small-debug-trace.md)** + +- **[Process Commissioning](kernel-small-debug-process.md)** + +- **[Memory Debugging](kernel-small-debug-memory.md)** + +- **[Other Kernel Debugging Methods](kernel-small-debug-other.md)** + + diff --git a/en/device-dev/kernel/kernel-small-overview.md b/en/device-dev/kernel/kernel-small-overview.md new file mode 100644 index 0000000000000000000000000000000000000000..a4590c1e88c1f99497dad219c0cb7e98bb1574eb --- /dev/null +++ b/en/device-dev/kernel/kernel-small-overview.md @@ -0,0 +1,97 @@ +# Kernel Overview + +- [Overview](#section6614133913129) +- [Kernel Architecture](#section827143517385) + +## Overview + +The OpenHarmony lightweight kernel is a next-generation kernel developed based on the lightweight IoT operating system Huawei LiteOS. Two types of kernels are available: LiteOS-M and LiteOS-A. The LiteOS-M kernel is designed for lightweight systems, which support MCU memory of hundreds of KB and MPU isolation. FreeRTOS and ThreadX are counterparts in the industry. The LiteOS-A kernel is ideal for small systems, which support memory in MB and MMU isolation. Similar kernels include Zircon and Darwin. This development guide applies to the LiteOS-A kernel. + +To adapt to the rapid development of the IoT industry, the OpenHarmony lightweight kernel is continuously optimized and expanded to provide application developers with friendly development experience and unified and open ecosystem capabilities. The LiteOS-A has the following new features: + +- Diversified kernel mechanisms + + Mechanisms such as virtual memory, system calling, multi-core, lightweight Inter-Process Communication \(IPC\), and Discretionary Access Control \(DAC\) are added to enrich kernel capabilities. To improve compatibility with software and developer experience, multiple processes are supported to isolate memory between applications and improve system robustness. + +- Unified hardware driver foundation \(HDF\) + + The HDF provides unified driver standards and access mode for device vendors. This simplifies porting of drivers and allows one-time development for multi-device deployment. + +- 1200+ standard POSIX APIs + + The kernel supports more Portable Operating System Interface \(POSIX\) APIs, which facilitate software development and porting and improve developers' experience. + +- Decoupling between the kernel and hardware + + The lightweight kernel is highly decoupled from the hardware. New board can be added without modifying the kernel code. + + +## Kernel Architecture + +The lightweight kernel consists of the basic kernel, extension components, HDF, and POSIX interface. Different from the microkernel which is running in the user space, the extended functions, such as file system and network protocols, of the lightweight kernel are running in the kernel address space. The direct function calling between components is much faster than inter-process communication \(IPC\) or remote procedure calls \(RPCs\). + +**Figure 1** Architecture of the OpenHarmony LiteOS-A kernel + + +![](figure/en-us_image_0000001191018697.png) + +- The basic kernel implements basic kernel mechanisms, such as scheduling, memory management, and interrupts. +- Extended components include file systems, network protocols, and security functions. +- The HDF provides a unified standard framework for peripheral drivers. +- The POSIX interface allows POSIX-compliant applications to be easily ported to the OpenHarmony. + +**Basic Kernel** + +The basic kernel implements the following mechanisms: + +- Process management: supports processes and threads and task-based process implementation. Processes have independent 4 GB address space. +- Multi-core scheduling: supports task and affinity-based interrupt-core binding settings. +- Real-time scheduling: Tasks are scheduled based on priorities. The tasks of the same priority are scheduled by using the time slice round-robin. +- Virtual memory: supports page fault. The kernel space is statically mapped to 0-1 GiB addresses, and the user space is mapped to 1-4 GiB addresses. +- Kernel communication: supports events, semaphores, mutexes, and queues. +- Time management: supports software timers and system clock. + +**File systems** + +The LiteOS-A supports multiple file systems, such as FAT, JFFS2, NFS, ramfs, and procfs, and provides complete POSIX standard APIs externally. The VFS layer is used as the unified adaptation layer framework, which facilitates the porting of new file systems. Each file system can automatically use the rich functions provided by the VFS layer. + +The following features are supported: + +- Complete POSIX API support +- File-level cache \(page cache\) +- Disk-level cache \(Bcache\) +- Directory cache \(path cache\) +- DAC capability +- Nested mounting and file system stacking +- Feature tailoring and flexible configuration of resource usage + +**Network Protocols** + +The LiteOS-A network protocols are constructed based on the open-source lightweight IP \(lwIP\) and have also optimized the RAM usage and improved the transmission performance over LWIP. + +- Protocols: IP, IPv6, ICMP, ND, MLD, UDP, TCP, IGMP, ARP, PPPoS, and PPPoE +- API: socket API +- Extended features: IP forwarding based on multiple network ports, TCP congestion control, round-trip time \(RTT\) estimation, and fast recovery/retransmission +- Application programs: HTTP\(S\) service, SNTP client, SMTP\(S\) client, ping tool, NetBIOS name service, mDNS response program, MQTT client, TFTP service, DHCP client, DNS client, AutoIP/APIPA \(zero configuration\), and SNMP agent + +**HDF** + +The LiteOS-A integrates the HDF framework. The HDF framework provides a more precise and efficient development environment, aiming to realize one-time development for multi-device deployment. The HDF supports: + +- Multi-kernel platform +- User-mode drivers +- Configurable component-based driver model +- Message-based driver interface model +- Object-based driver and device management +- Unified hardware driver interface \(HDI\) +- Power management and plug and play \(PnP\) + +**Extension Components** + +Extension components provide optional but important mechanism for extending kernel functions. + +- Dynamic linking: supports standard Executable and Linkable Format \(ELF\) execution and randomization of loading addresses. +- IPC: supports LiteIPC and standard mechanisms such as Mqueue, Pipe, Fifo, and Signal. +- System calling: supports 170+ system calls and the virtual dynamic shared object \(vDSO\) mechanism. +- Permission management: supports process-based privilege division and control, and file owner, group, and owner \(UGO\) permission configuration. + diff --git a/en/device-dev/kernel/kernel-small-start-kernel.md b/en/device-dev/kernel/kernel-small-start-kernel.md new file mode 100644 index 0000000000000000000000000000000000000000..e097647772e780ff29d9d502f0fda6b98ad9e4d9 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-start-kernel.md @@ -0,0 +1,135 @@ +# Startup in Kernel Space + +- [Kernel Startup Process](#section9882154318299) +- [Programming Example](#section19145114703217) + - [Example Description](#section1045483642518) + + +## Kernel Startup Process + +The kernel startup process consists of the assembly startup and C language startup, as shown in the following figure. The assembly startup involves initializing CPU settings, disabling dCache/iCache, enabling the FPU and NEON, setting the MMU to establish the virtual-physical address mapping, setting the system stack, clearing the BSS segment, and calling the main function of the C language. The C language startup involves starting the OsMain function and starting scheduling. As shown in the following figure, the OsMain function is used for basic kernel initialization and architecture- and board-level initialization. The kernel startup framework leads the initialization process. The right part of the figure shows the phase in which external modules can register with the kernel startup framework and starts. The following table describes each phase. + +**Figure 1** Kernel startup process + + +![](figure/en-us_image_0000001178856385.png) + +**Table 1** Startup framework levels + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Level

+

Description

+

LOS_INIT_LEVEL_EARLIEST

+

Earliest initialization.

+

The initialization is architecture-independent. The board and subsequent modules initialize the pure software modules on which they depend.

+

Example: trace module

+

LOS_INIT_LEVEL_ARCH_EARLY

+

Early initialization of the architecture.

+

The initialization is architecture-dependent. Subsequent modules initialize the modules on which they depend. It is recommended that functions not required for startup be placed at LOS_INIT_LEVEL_ARCH.

+

LOS_INIT_LEVEL_PLATFORM_EARLY

+

Early initialization of the platform.

+

The initialization depends on the board platform and drivers. Subsequent modules initialize the modules on which they depend. It is recommended that functions required for startup be placed at LOS_INIT_LEVEL_PLATFORM.

+

Example: UART module

+

LOS_INIT_LEVEL_KMOD_PREVM

+

Kernel module initialization before memory initialization.

+

Initialize the modules that need to be enabled before memory initialization.

+

LOS_INIT_LEVEL_VM_COMPLETE

+

Initialization after the basic memory is ready.

+

After memory initialization, initialize the modules that need to be enabled and do not depend on inter-process communication (IPC) and system processes.

+

Example: shared memory function

+

LOS_INIT_LEVEL_ARCH

+

Late initialization of the architecture.

+

The initialization is related to the architecture extension functions. Subsequent modules initialize the modules on which they depend.

+

LOS_INIT_LEVEL_PLATFORM

+

Late initialization of the platform.

+

The initialization depends on the board platform and drivers. Subsequent modules initialize the modules on which they depend.

+

Example: initialization of the driver kernel abstraction layer (MMC and MTD)

+

LOS_INIT_LEVEL_KMOD_BASIC

+

Initialization of the kernel basic modules.

+

Initialize the basic modules that can be detached from the kernel.

+

Example: VFS initialization

+

LOS_INIT_LEVEL_KMOD_EXTENDED

+

Initialization of the kernel extended modules.

+

Initialize the extended modules that can be detached from the kernel.

+

Example: initialization of system call, ProcFS, Futex, HiLog, HiEvent, and LiteIPC

+

LOS_INIT_LEVEL_KMOD_TASK

+

Kernel task creation

+

Create kernel tasks (kernel thread and software timer tasks).

+

Example: creation of the resident resource reclaiming task, SystemInit task, and CPU usage statistics task.

+
+ +## Programming Example + +### Example Description + +Add a kernel module and register the initialization function of the module to the kernel startup process to complete the module initialization during the kernel initialization process. + +**Sample Code** + +``` +/* Header file of the kernel startup framework */ +#include "los_init.h" +... + +/* Initialization function of the new module */ +unsigned int OsSampleModInit(void) +{ + PRINTK("OsSampleModInit SUCCESS!\n"); + ...... +} +... +/* Register the new module at the target level of the startup framework. */ +LOS_MODULE_INIT(OsSampleModInit, LOS_INIT_LEVEL_KMOD_EXTENDED); +``` + +**Verification** + +``` +main core booting up... +OsSampleModInit SUCCESS! +releasing 1 secondary cores +cpu 1 entering scheduler +cpu 0 entering scheduler +``` + +According to the information displayed during the system startup, the kernel calls the initialization function of the registered module during the startup to initialize the module. + +>![](../public_sys-resources/icon-note.gif) **NOTE:** +>Modules at the same level cannot depend on each other. It is recommended that a new module be split based on the preceding startup phase and be registered and started as required. +>You can view the symbol table in the **.rodata.init.kernel.\*** segment of the **OHOS\_Image.map** file generated after the build is complete, so as to learn about the initialization entry of each module that has been registered with the kernel startup framework and check whether the newly registered initialization entry takes effect. + diff --git a/en/device-dev/kernel/kernel-small-start-user.md b/en/device-dev/kernel/kernel-small-start-user.md new file mode 100644 index 0000000000000000000000000000000000000000..106e557d153e9cb1b33a2567fe42d68a736f007d --- /dev/null +++ b/en/device-dev/kernel/kernel-small-start-user.md @@ -0,0 +1,82 @@ +# Startup in User Space + +- [Startup of the Root Process in User Space](#section79911135647) + - [Startup Process of the Root Process](#section1184317581349) + - [Responsibilities of the Root Process](#section1590220321759) + +- [Running Programs in User Space](#section194576310611) + +## Startup of the Root Process in User Space + +The root process is the first user-space process in the system. The process ID is 1. The root process is the ancestor of all user-space processes. + +**Figure 1** Process tree +![](figure/process-tree.png "process-tree") + +### Startup Process of the Root Process + +Use the link script to place the following init startup code to the specified location in the system image. + +``` +#define LITE_USER_SEC_ENTRY __attribute__((section(".user.entry"))) +LITE_USER_SEC_ENTRY VOID OsUserInit(VOID *args) +{ +#ifdef LOSCFG_KERNEL_DYNLOAD + sys_call3(__NR_execve, (UINTPTR)g_initPath, 0, 0); +#endif + while (true) { + } +} +``` + +During system startup, **OsUserInitProcess** is called to start the **init** process. The process is as follows: + +1. The kernel calls **OsLoadUserInit** to load the code. +2. A process space is created to start the **/bin/init** process. + +### Responsibilities of the Root Process + +- Starts key system programs or services, such as shell. + + >![](../public_sys-resources/icon-note.gif) **NOTE:** + >In OpenHarmony, the **init** process reads the **/etc/init.cfg** file and runs specified commands or starts specified processes based on configurations. For details, see [init Module](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/subsys-boot-init.md). + + +- Monitors the process for reclaiming the orphan process and clears the zombie processes in child processes. + +## Running Programs in User Space + +Common compilation modes of user-space programs include: + +1. [Compilation using the framework](https://gitee.com/openharmony/docs/blob/master/en/device-dev/quick-start/quickstart-lite-steps-board3516-running.md) +2. Manual compilation + + Example: + + ``` + clang --target=arm-liteos --sysroot=prebuilts/lite/sysroot -o helloworld helloworld.c + ``` + + Before running the **clang** command, install the LLVM compiler. For details, see [Installing LLVM](https://gitee.com/openharmony/docs/blob/master/en/device-dev/quick-start/quickstart-lite-env-setup-lin.md). + + **--target=arm-liteos**: specifies that the compilation platform is arm-liteos. + + **--sysroot=$\{YOUR\_ROOT\_PATH\}/prebuilts/lite/sysroot**: specifies the directory in which you can search for the header file and the dependent standard libraries. + + +A user-space program can be started in either of the following ways: + +- Run the shell command to start the process. + + ``` + OHOS $ exec helloworld + OHOS $ ./helloworld + OHOS $ /bin/helloworld + ``` + + +- Start a new process by calling the POSIX API. + + Use the **Fork\(\)** method to create a process, and call the **exec\(\)** method to execute a new process. + + diff --git a/en/device-dev/kernel/kernel-small-start.md b/en/device-dev/kernel/kernel-small-start.md new file mode 100644 index 0000000000000000000000000000000000000000..2e297b9b9a60c926b1f71a1bf571663ddd92e2f9 --- /dev/null +++ b/en/device-dev/kernel/kernel-small-start.md @@ -0,0 +1,7 @@ +# Kernel Startup + +- **[Startup in Kernel Space](kernel-small-start-kernel.md)** + +- **[Startup in User Space](kernel-small-start-user.md)** + + diff --git a/en/device-dev/kernel/kernel-standard-des.md b/en/device-dev/kernel/kernel-standard-overview.md similarity index 100% rename from en/device-dev/kernel/kernel-standard-des.md rename to en/device-dev/kernel/kernel-standard-overview.md diff --git a/en/device-dev/kernel/kernel-standard.md b/en/device-dev/kernel/kernel-standard.md index cdbdf659c166ba32ea9b47e15b06e57184149032..3e0b536437a642bf5013f1a4bc5c46569ae5eb78 100644 --- a/en/device-dev/kernel/kernel-standard.md +++ b/en/device-dev/kernel/kernel-standard.md @@ -1,6 +1,6 @@ # Kernel for Standard Systems -- **[Linux Kernel Overview](kernel-standard-des.md)** +- **[Linux Kernel Overview](kernel-standard-overview.md)** - **[Guidelines for Using Patches on OpenHarmony Development Boards](kernel-standard-patch.md)** diff --git a/en/device-dev/porting/Readme-EN.md b/en/device-dev/porting/Readme-EN.md index abfe82c4f402c993526c03799b02f8147ef27936..04ed726f9d1b60bc7c61b4707f4e606e7d3bf4ed 100644 --- a/en/device-dev/porting/Readme-EN.md +++ b/en/device-dev/porting/Readme-EN.md @@ -1,33 +1,34 @@ # Porting Guide -- [Third-Party Library Porting Guide](transplant-thirdparty.md) - - [Overview](transplant-thirdparty-overview.md) - - [Porting a Library Built Using CMake](transplant-thirdparty-cmake.md) - - [Porting a Library Built Using Makefile](transplant-thirdparty-makefile.md) -- [Mini System SoC Porting Guide](transplant-minichip.md) - - [Porting Preparations](transplant-chip-prepare.md) - - [Before You Start](transplant-chip-prepare-knows.md) - - [Building Adaptation Process](transplant-chip-prepare-process.md) - - [Kernel Porting](transplant-chip-kernel.md) - - [Overview](transplant-chip-kernel-overview.md) - - [Basic Kernel Adaptation](transplant-chip-kernel-adjustment.md) - - [Kernel Porting Verification](transplant-chip-kernel-verify.md) - - [Board-Level OS Porting](transplant-chip-board.md) - - [Overview](transplant-chip-board-overview.md) - - [Board-Level Driver Adaptation](transplant-chip-board-drive.md) - - [Implementation of APIs at the HAL](transplant-chip-board-hal.md) - - [System Modules](transplant-chip-board-component.md) - - [Third-party Module Adaptation](transplant-chip-board-bundle.md) - - [XTS](transplant-chip-board-xts.md) - - [FAQ](transplant-chip-faqs.md) -- [Small System SoC Porting Guide](transplant-smallchip.md) - - [Porting Preparations](transplant-smallchip-prepare.md) - - [Before You Start](transplant-smallchip-prepare-needs.md) - - [Compilation and Building](transplant-smallchip-prepare-building.md) - - [Kernel Porting](transplant-smallchip-kernel.md) - - [LiteOS Cortex-A](transplant-smallchip-kernel-a.md) - - [Linux Kernel](transplant-smallchip-kernel-linux.md) - - [Driver Porting](transplant-smallchip-drive.md) - - [Overview](transplant-smallchip-drive-des.md) - - [Platform Driver Porting](transplant-smallchip-drive-plat.md) - - [Device Driver Porting](transplant-smallchip-drive-oom.md) \ No newline at end of file +- [Third-Party Library Porting Guide](porting-thirdparty.md) + - [Overview](porting-thirdparty-overview.md) + - [Porting a Library Built Using CMake](porting-thirdparty-cmake.md) + - [Porting a Library Built Using Makefile](porting-thirdparty-makefile.md) +- [Mini System SoC Porting Guide](porting-minichip.md) + - [Porting Preparations](porting-chip-prepare.md) + - [Before You Start](porting-chip-prepare-knows.md) + - [Building Adaptation Process](porting-chip-prepare-process.md) + - [Kernel Porting](porting-chip-kernel.md) + - [Overview](porting-chip-kernel-overview.md) + - [Basic Kernel Adaptation](porting-chip-kernel-adjustment.md) + - [Kernel Porting Verification](porting-chip-kernel-verify.md) + - [Board-Level OS Porting](porting-chip-board.md) + - [Overview](porting-chip-board-overview.md) + - [Board-Level Driver Adaptation](porting-chip-board-driver.md) + - [Implementation of APIs at the HAL](porting-chip-board-hal.md) + - [System Modules](porting-chip-board-component.md) + - [Third-party Module Adaptation](porting-chip-board-bundle.md) + - [XTS](porting-chip-board-xts.md) + - [FAQ](porting-chip-faqs.md) +- [Small System SoC Porting Guide](porting-smallchip.md) + - [Porting Preparations](porting-smallchip-prepare.md) + - [Before You Start](porting-smallchip-prepare-needs.md) + - [Compilation and Building](porting-smallchip-prepare-building.md) + - [Kernel Porting](porting-smallchip-kernel.md) + - [LiteOS Cortex-A](porting-smallchip-kernel-a.md) + - [Linux Kernel](porting-smallchip-kernel-linux.md) + - [Driver Porting](porting-smallchip-driver.md) + - [Overview](porting-smallchip-driver-overview.md) + - [Platform Driver Porting](porting-smallchip-driver-plat.md) + - [Device Driver Porting](porting-smallchip-driver-oom.md) +- [Standard System SoC Porting Guide](standard-system-porting-guide.md) \ No newline at end of file diff --git a/en/device-dev/porting/transplant-chip-board-bundle.md b/en/device-dev/porting/porting-chip-board-bundle.md similarity index 99% rename from en/device-dev/porting/transplant-chip-board-bundle.md rename to en/device-dev/porting/porting-chip-board-bundle.md index 1f0a46c450c150796b2c8e385981dcfea044944a..1553650f3b59367a186accf7a8795c2c5432efc7 100644 --- a/en/device-dev/porting/transplant-chip-board-bundle.md +++ b/en/device-dev/porting/porting-chip-board-bundle.md @@ -19,7 +19,6 @@ To use third-party modules in the **third\_party** directory, you may need to } ``` - You are advised to make the preceding modifications in a new **config.h** file or **_xxx_\_alt.c** file. Do not directly edit the code in the original file. Intrusive modifications may cause a large number of scattered conflicts during subsequent version updates, increasing the update maintenance costs. 2. Create a patch. diff --git a/en/device-dev/porting/transplant-chip-board-component.md b/en/device-dev/porting/porting-chip-board-component.md similarity index 100% rename from en/device-dev/porting/transplant-chip-board-component.md rename to en/device-dev/porting/porting-chip-board-component.md diff --git a/en/device-dev/porting/transplant-chip-board-drive.md b/en/device-dev/porting/porting-chip-board-driver.md similarity index 100% rename from en/device-dev/porting/transplant-chip-board-drive.md rename to en/device-dev/porting/porting-chip-board-driver.md diff --git a/en/device-dev/porting/transplant-chip-board-hal.md b/en/device-dev/porting/porting-chip-board-hal.md similarity index 100% rename from en/device-dev/porting/transplant-chip-board-hal.md rename to en/device-dev/porting/porting-chip-board-hal.md diff --git a/en/device-dev/porting/transplant-chip-board-overview.md b/en/device-dev/porting/porting-chip-board-overview.md similarity index 93% rename from en/device-dev/porting/transplant-chip-board-overview.md rename to en/device-dev/porting/porting-chip-board-overview.md index 036de7066aee8df287fba20aec2d8f6c83b2a440..926dbb66fe05b2eb8e834900388417ac7962af57 100644 --- a/en/device-dev/porting/transplant-chip-board-overview.md +++ b/en/device-dev/porting/porting-chip-board-overview.md @@ -17,7 +17,7 @@ After the minimum system is ported, you can port the board-level system by: ## Board-Level Directory Specifications -For details about board-level system building adaptation, see [Compilation and Building Subsystem](transplant-chip-prepare-process.md). The board-related drivers, software development software kits \(SDKs\), directories, and HAL implementation are stored in the **device** directory. The directory structure and its description are as follows: +For details about board-level system building adaptation, see [Compilation and Building Subsystem](porting-chip-prepare-process.md). The board-related drivers, software development software kits \(SDKs\), directories, and HAL implementation are stored in the **device** directory. The directory structure and its description are as follows: ``` . diff --git a/en/device-dev/porting/transplant-chip-board-xts.md b/en/device-dev/porting/porting-chip-board-xts.md similarity index 100% rename from en/device-dev/porting/transplant-chip-board-xts.md rename to en/device-dev/porting/porting-chip-board-xts.md diff --git a/en/device-dev/porting/porting-chip-board.md b/en/device-dev/porting/porting-chip-board.md new file mode 100644 index 0000000000000000000000000000000000000000..62d22e9cbd2b4ce109b68b685557713c16c91d9c --- /dev/null +++ b/en/device-dev/porting/porting-chip-board.md @@ -0,0 +1,15 @@ +# Board-Level OS Porting + +- **[Overview](porting-chip-board-overview.md)** + +- **[Board-Level Driver Adaptation](porting-chip-board-driver.md)** + +- **[Implementation of APIs at the HAL](porting-chip-board-hal.md)** + +- **[System Modules](porting-chip-board-component.md)** + +- **[Third-party Module Adaptation](porting-chip-board-bundle.md)** + +- **[XTS](porting-chip-board-xts.md)** + + diff --git a/en/device-dev/porting/transplant-chip-faqs.md b/en/device-dev/porting/porting-chip-faqs.md similarity index 100% rename from en/device-dev/porting/transplant-chip-faqs.md rename to en/device-dev/porting/porting-chip-faqs.md diff --git a/en/device-dev/porting/transplant-chip-kernel-adjustment.md b/en/device-dev/porting/porting-chip-kernel-adjustment.md similarity index 100% rename from en/device-dev/porting/transplant-chip-kernel-adjustment.md rename to en/device-dev/porting/porting-chip-kernel-adjustment.md diff --git a/en/device-dev/porting/transplant-chip-kernel-overview.md b/en/device-dev/porting/porting-chip-kernel-overview.md similarity index 100% rename from en/device-dev/porting/transplant-chip-kernel-overview.md rename to en/device-dev/porting/porting-chip-kernel-overview.md diff --git a/en/device-dev/porting/transplant-chip-kernel-verify.md b/en/device-dev/porting/porting-chip-kernel-verify.md similarity index 98% rename from en/device-dev/porting/transplant-chip-kernel-verify.md rename to en/device-dev/porting/porting-chip-kernel-verify.md index 56aa1d19d06af1d3a2c994a64b898045e0270484..0c22a72f8d19cd9505cf39c0318a2123f0605a86 100644 --- a/en/device-dev/porting/transplant-chip-kernel-verify.md +++ b/en/device-dev/porting/porting-chip-kernel-verify.md @@ -55,5 +55,5 @@ LITE_OS_SEC_TEXT_INIT int main(void) } ``` -If the first task is executed properly, the core process of the minimum system is valid. Due to the XTS framework's dependency on the link scripts of Utils and Bootstrap as well as the building framework, testing the kernel by executing the XTS is not supported. You can test whether the minimum system is completely ported in [XTS](transplant-chip-board-xts.md). +If the first task is executed properly, the core process of the minimum system is valid. Due to the XTS framework's dependency on the link scripts of Utils and Bootstrap as well as the building framework, testing the kernel by executing the XTS is not supported. You can test whether the minimum system is completely ported in [XTS](porting-chip-board-xts.md). diff --git a/en/device-dev/porting/porting-chip-kernel.md b/en/device-dev/porting/porting-chip-kernel.md new file mode 100644 index 0000000000000000000000000000000000000000..aa981df63825d4ffe3a7de3dedff4e60194dba2d --- /dev/null +++ b/en/device-dev/porting/porting-chip-kernel.md @@ -0,0 +1,9 @@ +# Kernel Porting + +- **[Overview](porting-chip-kernel-overview.md)** + +- **[Basic Kernel Adaptation](porting-chip-kernel-adjustment.md)** + +- **[Kernel Porting Verification](porting-chip-kernel-verify.md)** + + diff --git a/en/device-dev/porting/transplant-chip-prepare-knows.md b/en/device-dev/porting/porting-chip-prepare-knows.md similarity index 96% rename from en/device-dev/porting/transplant-chip-prepare-knows.md rename to en/device-dev/porting/porting-chip-prepare-knows.md index 731df255c420f947b4be298bca7b9ce89b6b5215..7de3a048b0efbc10bb17984f495b16d971dc1d34 100644 --- a/en/device-dev/porting/transplant-chip-prepare-knows.md +++ b/en/device-dev/porting/porting-chip-prepare-knows.md @@ -33,7 +33,7 @@ The implementation of the OpenHarmony project directories and functions relies o

/device

Board-level code implementation, which is provided by third-party vendors based on the OpenHarmony specifications. For detailed structure about the device directory and porting process, see Board-Level OS Porting.

+

Board-level code implementation, which is provided by third-party vendors based on the OpenHarmony specifications. For detailed structure about the device directory and porting process, see Board-Level OS Porting.

/vendor

@@ -80,5 +80,5 @@ The **device** directory of OpenHarmony is the adaptation directory for the ba ## Porting Specifications - The porting must comply with the basic OpenHarmony principles described in [Contribution](https://gitee.com/openharmony/docs/blob/master/en/contribute/contribution.md). -- The code required for third-party SoC adaptation is stored in the **device**, **vendor**, and **arch** directories. Naming and usage of these directories must comply with specified naming and usage specifications. For details, see [Directory Specifications](transplant-chip-kernel-overview.md) and [Board-Level Directory Specifications](transplant-chip-board-overview.md#section6204129143013). +- The code required for third-party SoC adaptation is stored in the **device**, **vendor**, and **arch** directories. Naming and usage of these directories must comply with specified naming and usage specifications. For details, see [Directory Specifications](porting-chip-kernel-overview.md) and [Board-Level Directory Specifications](porting-chip-board-overview.md#section6204129143013). diff --git a/en/device-dev/porting/transplant-chip-prepare-process.md b/en/device-dev/porting/porting-chip-prepare-process.md similarity index 99% rename from en/device-dev/porting/transplant-chip-prepare-process.md rename to en/device-dev/porting/porting-chip-prepare-process.md index 4cca1dbced756b652287da3c919603e9f92f025a..7c02930ff628e8c22a9fc8e2b2b283acb1c64d51 100644 --- a/en/device-dev/porting/transplant-chip-prepare-process.md +++ b/en/device-dev/porting/porting-chip-prepare-process.md @@ -25,7 +25,6 @@ You need to create a directory for the development board. Taking the **RTL8720* The corresponding **config.gni** file will be loaded based on the development board selected by the product. The variables in this file are globally visible to system components. - Taking the RTL8720 development board of Realtek as an example, the **device/realtek/rtl8720/liteos\_m/config.gni** file is configured as follows: ``` diff --git a/en/device-dev/porting/porting-chip-prepare.md b/en/device-dev/porting/porting-chip-prepare.md new file mode 100644 index 0000000000000000000000000000000000000000..54aa1a6aa754194a6cff9b5207bab3444102c7fb --- /dev/null +++ b/en/device-dev/porting/porting-chip-prepare.md @@ -0,0 +1,7 @@ +# Porting Preparations + +- **[Before You Start](porting-chip-prepare-knows.md)** + +- **[Building Adaptation Process](porting-chip-prepare-process.md)** + + diff --git a/en/device-dev/porting/porting-minichip.md b/en/device-dev/porting/porting-minichip.md new file mode 100644 index 0000000000000000000000000000000000000000..41894c11a4bafd4b013c8f98e6fc5fe07aace01a --- /dev/null +++ b/en/device-dev/porting/porting-minichip.md @@ -0,0 +1,11 @@ +# Mini System SoC Porting Guide + +- **[Porting Preparations](porting-chip-prepare.md)** + +- **[Kernel Porting](porting-chip-kernel.md)** + +- **[Board-Level OS Porting](porting-chip-board.md)** + +- **[FAQ](porting-chip-faqs.md)** + + diff --git a/en/device-dev/porting/transplant-smallchip-drive-oom.md b/en/device-dev/porting/porting-smallchip-driver-oom.md similarity index 100% rename from en/device-dev/porting/transplant-smallchip-drive-oom.md rename to en/device-dev/porting/porting-smallchip-driver-oom.md diff --git a/en/device-dev/porting/transplant-smallchip-drive-des.md b/en/device-dev/porting/porting-smallchip-driver-overview.md similarity index 100% rename from en/device-dev/porting/transplant-smallchip-drive-des.md rename to en/device-dev/porting/porting-smallchip-driver-overview.md diff --git a/en/device-dev/porting/transplant-smallchip-drive-plat.md b/en/device-dev/porting/porting-smallchip-driver-plat.md similarity index 100% rename from en/device-dev/porting/transplant-smallchip-drive-plat.md rename to en/device-dev/porting/porting-smallchip-driver-plat.md diff --git a/en/device-dev/porting/porting-smallchip-driver.md b/en/device-dev/porting/porting-smallchip-driver.md new file mode 100644 index 0000000000000000000000000000000000000000..62033a430c23b438d4966b61ba2403254ed86169 --- /dev/null +++ b/en/device-dev/porting/porting-smallchip-driver.md @@ -0,0 +1,9 @@ +# Driver Porting + +- **[Overview](porting-smallchip-driver-overview.md)** + +- **[Platform Driver Porting](porting-smallchip-driver-plat.md)** + +- **[Device Driver Porting](porting-smallchip-driver-oom.md)** + + diff --git a/en/device-dev/porting/transplant-smallchip-kernel-a.md b/en/device-dev/porting/porting-smallchip-kernel-a.md similarity index 99% rename from en/device-dev/porting/transplant-smallchip-kernel-a.md rename to en/device-dev/porting/porting-smallchip-kernel-a.md index f64a0e832b18161a3cfd6339962f21b7776f45a8..6248678a89d3462277941b6b6f2dc1c5f3bd9526 100644 --- a/en/device-dev/porting/transplant-smallchip-kernel-a.md +++ b/en/device-dev/porting/porting-smallchip-kernel-a.md @@ -259,5 +259,6 @@ mount netstat oom partinfo partition ping pwd reset rm rmdir sem shm stack statfs su swtmr sync systeminfo task telnet touch umount uname v2p virstatfs vmm watch writeproc + ``` diff --git a/en/device-dev/porting/transplant-smallchip-kernel-linux.md b/en/device-dev/porting/porting-smallchip-kernel-linux.md similarity index 99% rename from en/device-dev/porting/transplant-smallchip-kernel-linux.md rename to en/device-dev/porting/porting-smallchip-kernel-linux.md index 3296d239e64311a2712ab66746be2f2e86c0fed2..b6f247ff9d6bbdd72e84dbdba3b8574cfdab851a 100644 --- a/en/device-dev/porting/transplant-smallchip-kernel-linux.md +++ b/en/device-dev/porting/porting-smallchip-kernel-linux.md @@ -87,7 +87,6 @@ Based on the preceding process, the recommended verification procedure is as fol In the **_vendor_/\{_company_\}/\{_product_\}/init\_configs/etc** directory, configure startup settings, including the **fstab**, **rsS**, and **S_xxx_** files. Configure the startup settings as needed. - After the build is complete, check the **rootfs** content in the product compilation output directory to determine whether the generated **rootfs.img** file meets the expectation. 2. Debug the init process and shell. diff --git a/en/device-dev/porting/porting-smallchip-kernel.md b/en/device-dev/porting/porting-smallchip-kernel.md new file mode 100644 index 0000000000000000000000000000000000000000..9e53fe2d2fab601db282858f9f93f34e7632f441 --- /dev/null +++ b/en/device-dev/porting/porting-smallchip-kernel.md @@ -0,0 +1,7 @@ +# Kernel Porting + +- **[LiteOS Cortex-A](porting-smallchip-kernel-a.md)** + +- **[Linux Kernel](porting-smallchip-kernel-linux.md)** + + diff --git a/en/device-dev/porting/transplant-smallchip-prepare-building.md b/en/device-dev/porting/porting-smallchip-prepare-building.md similarity index 100% rename from en/device-dev/porting/transplant-smallchip-prepare-building.md rename to en/device-dev/porting/porting-smallchip-prepare-building.md diff --git a/en/device-dev/porting/transplant-smallchip-prepare-needs.md b/en/device-dev/porting/porting-smallchip-prepare-needs.md similarity index 100% rename from en/device-dev/porting/transplant-smallchip-prepare-needs.md rename to en/device-dev/porting/porting-smallchip-prepare-needs.md diff --git a/en/device-dev/porting/porting-smallchip-prepare.md b/en/device-dev/porting/porting-smallchip-prepare.md new file mode 100644 index 0000000000000000000000000000000000000000..dbb8cea8f288e1c7cee7219f346518f8e0d0009d --- /dev/null +++ b/en/device-dev/porting/porting-smallchip-prepare.md @@ -0,0 +1,7 @@ +# Porting Preparations + +- **[Before You Start](porting-smallchip-prepare-needs.md)** + +- **[Compilation and Building](porting-smallchip-prepare-building.md)** + + diff --git a/en/device-dev/porting/porting-smallchip.md b/en/device-dev/porting/porting-smallchip.md new file mode 100644 index 0000000000000000000000000000000000000000..bfbe8b6af1bb60858013d9b7a4cf6600846a955e --- /dev/null +++ b/en/device-dev/porting/porting-smallchip.md @@ -0,0 +1,9 @@ +# Small System SoC Porting Guide + +- **[Porting Preparations](porting-smallchip-prepare.md)** + +- **[Kernel Porting](porting-smallchip-kernel.md)** + +- **[Driver Porting](porting-smallchip-driver.md)** + + diff --git a/en/device-dev/porting/transplant-thirdparty-cmake.md b/en/device-dev/porting/porting-thirdparty-cmake.md similarity index 100% rename from en/device-dev/porting/transplant-thirdparty-cmake.md rename to en/device-dev/porting/porting-thirdparty-cmake.md diff --git a/en/device-dev/porting/transplant-thirdparty-makefile.md b/en/device-dev/porting/porting-thirdparty-makefile.md similarity index 98% rename from en/device-dev/porting/transplant-thirdparty-makefile.md rename to en/device-dev/porting/porting-thirdparty-makefile.md index a6d80725a238b519b3b72950255ccfb1ed9050df..738914976b998f329cdd023beedbb6a2ba8997dc 100644 --- a/en/device-dev/porting/transplant-thirdparty-makefile.md +++ b/en/device-dev/porting/porting-thirdparty-makefile.md @@ -148,7 +148,7 @@ The following steps show how to configure and modify the toolchains for cross-co ## Library Test -The test procedure for the yxml library is similar to that for the double-conversion library. For details, see the procedure described in [Porting a Library Built Using CMake](transplant-thirdparty-cmake.md#section6686144293611). The following describes how to use the test cases of the yxml library. +The test procedure for the yxml library is similar to that for the double-conversion library. For details, see the procedure described in [Porting a Library Built Using CMake](porting-thirdparty-cmake.md#section6686144293611). The following describes how to use the test cases of the yxml library. **Table 3** Directory structure of the test directory @@ -236,7 +236,7 @@ The following operations are performed based on the assumption that the OpenHarm ## Adding the Compiled yxml Library to the OpenHarmony Project -The procedure for adding the yxml library is almost the same as that for adding the double-conversion library, except that the implementation of **build.gn** and **config.gni** files. For details, see the procedure described in [Porting a Library Built Using CMake](transplant-thirdparty-cmake.md#section1651053153715). +The procedure for adding the yxml library is almost the same as that for adding the double-conversion library, except that the implementation of **build.gn** and **config.gni** files. For details, see the procedure described in [Porting a Library Built Using CMake](porting-thirdparty-cmake.md#section1651053153715). - The implementation of the newly added **BUILD.gn** file in the yxml library is as follows: diff --git a/en/device-dev/porting/transplant-thirdparty-overview.md b/en/device-dev/porting/porting-thirdparty-overview.md similarity index 100% rename from en/device-dev/porting/transplant-thirdparty-overview.md rename to en/device-dev/porting/porting-thirdparty-overview.md diff --git a/en/device-dev/porting/porting-thirdparty.md b/en/device-dev/porting/porting-thirdparty.md new file mode 100644 index 0000000000000000000000000000000000000000..5d53a8779755894b060177bac14e50b8fd30df2a --- /dev/null +++ b/en/device-dev/porting/porting-thirdparty.md @@ -0,0 +1,9 @@ +# Third-Party Library Porting Guide + +- **[Overview](porting-thirdparty-overview.md)** + +- **[Porting a Library Built Using CMake](porting-thirdparty-cmake.md)** + +- **[Porting a Library Built Using Makefile](porting-thirdparty-makefile.md)** + + diff --git a/en/device-dev/porting/porting.md b/en/device-dev/porting/porting.md new file mode 100644 index 0000000000000000000000000000000000000000..ef03a9bae819fe756b3faf442d749b06840cad45 --- /dev/null +++ b/en/device-dev/porting/porting.md @@ -0,0 +1,9 @@ +# Porting + +- **[Third-Party Library Porting Guide](porting-thirdparty.md)** + +- **[Mini System SoC Porting Guide](porting-minichip.md)** + +- **[Small System SoC Porting Guide](porting-smallchip.md)** + + diff --git a/en/device-dev/porting/standard-system-porting-guide.md b/en/device-dev/porting/standard-system-porting-guide.md new file mode 100644 index 0000000000000000000000000000000000000000..2cf403d1ae2bdcece07a99cce0eaeac708826b44 --- /dev/null +++ b/en/device-dev/porting/standard-system-porting-guide.md @@ -0,0 +1,377 @@ +# Standard System Porting Guide + + + + + +- [Defining a Development Board](#Defining-a-Development-Board) + - [1. Defining an SoC](#1-Defining-an-SoC) + - [2. Defining a Product](#2-Defining-a-Product) + - [3. Verifying the Porting](#3-Verifying-the-Porting) +- [Porting the Kernel](#Porting-the-Kernel) + - [1. Adding a Kernel-built Subsystem to the SoC](#1-Adding-a-Kernel-built-Subsystem-to-the-SoC) + - [2. Building the Kernel](#2-Building-the-Kernel) + - [3. Verifying the Porting](#3-Verifying-the-Porting-1) +- [Porting the HDF Driver](#Porting-the-HDF-Driver) + - [1. LCD](#1-lcd) + - [2. Touchscreen](#2-Touchscreen) + - [3. WLAN](#3-wlan) + + + +This document describes the general process for porting a development board, rather than the porting process specific to a System on Chip (SoC). In the future, the community will provide more development board porting examples for your reference. + +## Defining a Development Board + +This document uses the process of porting a development board named **MyProduct** as an example. This development board is provided by **MyProductVendor** and uses the SoC **MySOC** produced by **MySoCVendor**. + +### 1. Defining an SoC + +Create a JSON file named after the SoC name in the **//productdefine/common/device** directory and specify the CPU architecture. + +For example, to port **MySOC**, which uses a 32-bit ARM kernel, configure the file as follows: + +`//productdefine/common/device/MySOC.json` +```json +{ + "target_os": "ohos", + "target_cpu": "arm" +} +``` +Currently, **target_cpu** can be set to **arm** only. In the future, you can set the value depending on the CPU architecture, such as **arm64**, **riscv**, or **x86**. + +### 2. Defining a Product + +Create a JSON file named after the product name in the **//productdefine/common/products** directory. This file is used to describe the SoC used by the product and the required subsystems. +Configure the file as follows: +`//productdefine/common/products/MyProduct.json` +```json +{ + "product_name": "MyProduct", + "product_company" : "MyProductVendor", + "product_device": "MySOC", + "version": "2.0", + "type": "standard", + "parts":{ + "ace:ace_engine_standard":{}, + "ace:napi":{}, + ... + "xts:phone_tests":{} + } +} + +``` +The main configurations are as follows: + +1. **product_device**: SoC used by the product. +2. **type**: system level. In this example, set it to **standard**. +3. **parts**: subsystems to enable. A subsystem can be treated as an independently built functional block. + +You can find available subsystems in **//build/subsystem_config.json**. You can also customize subsystems. + +You are advised to copy the configuration file of Hi3516D V300 and delete the **hisilicon_products** subsystem, which is used to compile the kernel for Hi3516D V300. + +### 3. Verifying the Porting + +Run the following command to start the build of your product: + +`./build.sh --product-name MyProduct ` + +After the build is complete, you can view the built OpenHarmony image file in the following directory: + +`//out/ohos-arm-release/packages/phone/images` + +## Porting the Kernel + +Now, you need to port the Linux kernel to enable it to run successfully. + +### 1. Adding a Kernel-built Subsystem to the SoC + +Add the following subsystem configuration to the **//build/subsystem_config.json** file: + +```json + "MySOCVendor_products": { + "project": "hmf/MySOCVendor_products", + "path": "device/MySOCVendor/MySOC/build", + "name": "MySOCVendor_products", + "dir": "device/MySOCVendor" + }, +``` + +Then, open the configuration file **//productdefine/common/products/MyProduct.json**, which is used to define the product, and add the new subsystem to the product. + +### 2. Building the Kernel + +The path for building the subsystem is defined when you define the subsystem in the previous step. The path is **//device/MySOCVendor/MySOC/build**. Now, you need to create a build script in this path to instruct the build system to build the kernel. + +Currently, the OpenHarmony source code provides the Linux kernel 4.19, which is archived in **//kernel/linux-4.19**. You are advised to use this kernel. However, if the SoC vendor does not provide the kernel of this version, use that provided by the vendor. +You are advised to use patches to modify or extend the SoC kernel. + +The recommended directory structure is as follows: +``` +├── build +│   ├── kernel +│   │ ├── linux +│   │ ├──standard_patch_for_4_19.patch +│   ├── BUILD.gn +│   ├── ohos.build +``` +The **BUILD.gn** file is the only entry for building the subsystem. + +The expected build result is as follows: + +| File| Description| +|------|------| +|$root_build_dir/packages/phone/images/uImage| Kernel image| +|$root_build_dir/packages/phone/images/uboot | Bootloader image| + +### 3. Verifying the Porting + +Now start build, and check whether the kernel image is generated as expected. + +## Porting the HDF Driver + +### 1. LCD +This section describes how to port a Liquid Crystal Display (LCD) driver. The hardware driver framework (HDF) designs a driver model for the LCD. To support an LCD, you must compile a driver, generate a model instance in the driver, and register the instance. + +The LCD drivers are stored in the **//drivers/framework/model/display/driver/panel** directory. + +- Create a panel driver. + +In the **Init** method of the driver, call **RegisterPanel** to register the model instance. +```C +int32_t XXXInit(struct HdfDeviceObject *object) +{ + struct PanelData *panel = CreateYourPanel(); + + // Register the model instance. + if (RegisterPanel(panel) != HDF_SUCCESS) { + HDF_LOGE("%s: RegisterPanel failed", __func__); + return HDF_FAILURE; + } + return HDF_SUCCESS; +} + +struct HdfDriverEntry g_xxxxDevEntry = { + .moduleVersion = 1, + .moduleName = "LCD_XXXX", + .Init = XXXInit, +}; + +HDF_INIT(g_xxxxDevEntry); +``` + +- Configure and load the panel driver. +All device information about the product is defined in the **//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs** file. Modify the file by adding configurations for the device named **device_lcd** to the host named **display**. +Note: The value of **moduleName** must be the same as that in the panel driver. + +```hcs +root { + ... + display :: host { + device_lcd :: device { + deviceN :: deviceNode { + policy = 0; + priority = 100; + preload = 2; + moduleName = "LCD_XXXX"; + } + } + } +} +``` + +For details about driver development, see [LCD](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-lcd-des.md). + +### 2. Touchscreen +This section describes how to port a touchscreen driver. The touchscreen driver is stored in the **//drivers/framework/model/input/driver/touchscreen** directory. To port a touchscreen driver, register a **ChipDevice** model instance. + +- Create a touchscreen driver. + +Create the **touch_ic_name.c** file in the directory. Replace **ic_name** with the name of your chip. The file template is as follows: + +```C +#include "hdf_touch.h" + +static int32_t HdfXXXXChipInit(struct HdfDeviceObject *device) +{ + ChipDevice *tpImpl = CreateXXXXTpImpl(); + if(RegisterChipDevice(tpImpl) != HDF_SUCCESS) { + ReleaseXXXXTpImpl(tpImpl); + return HDF_FAILURE; + } + return HDF_SUCCESS; +} + +struct HdfDriverEntry g_touchXXXXChipEntry = { + .moduleVersion = 1, + .moduleName = "HDF_TOUCH_XXXX", + .Init = HdfXXXXChipInit, +}; + +HDF_INIT(g_touchXXXXChipEntry); +``` + +Implement the following interfaces in **ChipDevice**: +| Interface| Description| +|------|------| +|int32_t (*Init)(ChipDevice *device)| Initializes a touchscreen.| +|int32_t (*Detect)(ChipDevice *device)| Detects a touchscreen.| +|int32_t (*Suspend)(ChipDevice *device)| Suspends a touchscreen.| +|int32_t (*Resume)(ChipDevice *device)| Resumes a touchscreen.| +|int32_t (*DataHandle)(ChipDevice *device)| Reads data from a touchscreen and writes the touch point data to **device > driver > frameData**.| +|int32_t (*UpdateFirmware)(ChipDevice *device)| Upgrades the firmware.| + +- Configure the product and load the driver. + +All device information about the product is defined in the **//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs** file. Modify the file by adding configurations for the device named **device_touch_chip** to the host named **input**. +Note: The value of **moduleName** must be the same as that in the touchscreen driver. + +```hcs + deviceN :: deviceNode { + policy = 0; + priority = 130; + preload = 0; + permission = 0660; + moduleName = "HDF_TOUCH_XXXX"; + deviceMatchAttr = "touch_XXXX_configs"; + } +``` + +For details about driver development, see [TOUCHSCREEN](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/driver-peripherals-touch-des.md). + + +### 3. WLAN + +The WLAN driver is divided into two parts. One of the parts manages WLAN devices, and the other part manages WLAN traffic. **HDF WLAN** provides abstraction for the two parts. Currently, only the WLAN with the SDIO interface is supported. + +WLAN structure + +To support a chip, implement a **ChipDriver** for it. The major task is to implement the following interfaces provided by **HDF_WLAN_CORE** and **NetDevice**. + +| Interface| Header File| Description| +|------|------|------| +| HdfChipDriverFactory| `//drivers/framework/include/wifi/hdf_wlan_chipdriver_manager.h`| Factory of the **ChipDriver**, which is used to support multiple WLAN interfaces of a chip.| +| HdfChipDriver | `//drivers/framework/include/wifi/wifi_module.h`| Manages a specific WLAN interface. Each WLAN interface corresponds to an **HdfChipDriver**.| +|NetDeviceInterFace| `//drivers/framework/include/wifi/net_device.h`| Communicates with the protocol stack, such as sending data and setting the status of network interfaces.| + +To port a WLAN driver, perform the following steps: + +1. Create an HDF driver. + +You are advised to place the code file in the **//device/MySoCVendor/peripheral/wifi/chip_name/** directory. +The file template is as follows: + +```C +static int32_t HdfWlanHisiChipDriverInit(struct HdfDeviceObject *device) { + static struct HdfChipDriverFactory factory = CreateChipDriverFactory(); + struct HdfChipDriverManager *driverMgr = HdfWlanGetChipDriverMgr(); + if (driverMgr->RegChipDriver(&factory) != HDF_SUCCESS) { + HDF_LOGE("%s fail: driverMgr is NULL!", __func__); + return HDF_FAILURE; + } + return HDF_SUCCESS; +} + +struct HdfDriverEntry g_hdfXXXChipEntry = { + .moduleVersion = 1, + .Init = HdfWlanXXXChipDriverInit, + .Release = HdfWlanXXXChipRelease, + .moduleName = "HDF_WIFI_CHIP_XXX" +}; + +HDF_INIT(g_hdfXXXChipEntry); +``` + +Create an **HdfChipDriverFactory** in the **CreateChipDriverFactory**. The interfaces are as follows: +| Interface| Description| +|------|------| +|const char *driverName| Indicates the driver name.| +|int32_t (*InitChip)(struct HdfWlanDevice *device)| Initializes a chip.| +|int32_t (*DeinitChip)(struct HdfWlanDevice *device)| Deinitializes a chip.| +|void (*ReleaseFactory)(struct HdfChipDriverFactory *factory)| Releases the **HdfChipDriverFactory** object.| +|struct HdfChipDriver *(*Build)(struct HdfWlanDevice *device, uint8_t ifIndex)|Creates an **HdfChipDriver**. In the input parameters, **device** indicates the device information, and **ifIndex** indicates the sequence number of this interface in the chip.| +|void (*Release)(struct HdfChipDriver *chipDriver)| Releases the **HdfChipDriver**. +|uint8_t (*GetMaxIFCount)(struct HdfChipDriverFactory *factory)| Obtains the maximum number of interfaces supported by the current chip.| + +Implement the following interfaces in the **HdfChipDriver**. + +|Interface| Description| +|------|------| +|int32_t (*init)(struct HdfChipDriver *chipDriver, NetDevice *netDev)| Initializes the current network interface. The **NetDeviceInterFace** needs to be provided for the **netDev**.| +|int32_t (*deinit)(struct HdfChipDriver *chipDriver, NetDevice *netDev)| Deinitializes the current network interface.| +|struct HdfMac80211BaseOps *ops| Provides the WLAN basic capability interface set.| +|struct HdfMac80211STAOps *staOps| Provides the interface set required for supporting the standalone (STA) mode.| +|struct HdfMac80211APOps *apOps| Provides the interface set required for supporting the access point (AP) mode.| + + + +2. Compile the configuration file to describe the devices supported by the driver. + +Create the chip configuration file **//vendor/MyProductVendor/MyProduct/config/wifi/wlan_chip_chip_name.hcs** in the product configuration directory. +Replace **MyProductVendor**, **MyProduct**, and **chip_name** in the path with the actual names. +The sample code is as follows: +```hcs +root { + wlan_config { + chip_name :& chipList { + chip_name :: chipInst { + match_attr = "hdf_wlan_chips_chip_name"; /* Configure the matching attribute, which is used to provide the configuration root of the driver.*/ + driverName = "driverName"; /* The value must be the same as that of driverName in HdfChipDriverFactory.*/ + sdio { + vendorId = 0x0296; + deviceId = [0x5347]; + } + } + } + } +} +``` + +3. Edit the configuration file and load the driver. + +All device information about the product is defined in the **//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs** file. Modify the file by adding configurations for the device named **device_wlan_chips** to the host named **network**. +Note: The value of **moduleName** must be the same as that in the touchscreen driver. +The sample code is as follows: + +```hcs + deviceN :: deviceNode { + policy = 0; + preload = 2; + moduleName = "HDF_WLAN_CHIPS"; + deviceMatchAttr = "hdf_wlan_chips_chip_name"; + serviceName = "driverName"; + } +``` + +4. Build the driver. + +- Create a kernel configuration menu. +Create a **Kconfig** file in the **//device/MySoCVendor/peripheral** directory. The file template is as follows: +``` +config DRIVERS_WLAN_XXX + bool "Enable XXX WLAN Host driver" + default n + depends on DRIVERS_HDF_WIFI + help + Answer Y to enable XXX Host driver. Support chip xxx +``` + +Add the following sample code to the end of the **//drivers/adapter/khdf/linux/model/network/wifi/Kconfig** file to add the configuration menu to the kernel: +``` +source "../../../../../device/MySoCVendor/peripheral/Kconfig" +``` + +- Create a build script. + +Add the following configuration to the end of the **//drivers/adapter/khdf/linux/model/network/wifi/Makefile** file: + +``` +HDF_DEVICE_ROOT := $(HDF_DIR_PREFIX)/../device +obj-$(CONFIG_DRIVERS_WLAN_XXX) += $(HDF_DEVICE_ROOT)/MySoCVendor/peripheral/build/standard/ +``` + +When **DRIVERS_WLAN_XXX** is enabled in the kernel, **makefile** in **//device/MySoCVendor/peripheral/build/standard/** is called. + + +For more details, see [WLAN Development](https://gitee.com/openharmony/docs/blob/master/en/device-dev/guide/device-wifi.md). diff --git a/en/device-dev/porting/transplant-chip-board.md b/en/device-dev/porting/transplant-chip-board.md deleted file mode 100644 index 4800ddd71c39115f9e9e2b0358eb699e33454f97..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant-chip-board.md +++ /dev/null @@ -1,15 +0,0 @@ -# Board-Level OS Porting - -- **[Overview](transplant-chip-board-overview.md)** - -- **[Board-Level Driver Adaptation](transplant-chip-board-drive.md)** - -- **[Implementation of APIs at the HAL](transplant-chip-board-hal.md)** - -- **[System Modules](transplant-chip-board-component.md)** - -- **[Third-party Module Adaptation](transplant-chip-board-bundle.md)** - -- **[XTS](transplant-chip-board-xts.md)** - - diff --git a/en/device-dev/porting/transplant-chip-kernel.md b/en/device-dev/porting/transplant-chip-kernel.md deleted file mode 100644 index 7f9366086a58c40a65915482a8891469bdc1b12c..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant-chip-kernel.md +++ /dev/null @@ -1,9 +0,0 @@ -# Kernel Porting - -- **[Overview](transplant-chip-kernel-overview.md)** - -- **[Basic Kernel Adaptation](transplant-chip-kernel-adjustment.md)** - -- **[Kernel Porting Verification](transplant-chip-kernel-verify.md)** - - diff --git a/en/device-dev/porting/transplant-chip-prepare.md b/en/device-dev/porting/transplant-chip-prepare.md deleted file mode 100644 index f981ad0f6d0e48e56db1e5673c30b86ee3e5808f..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant-chip-prepare.md +++ /dev/null @@ -1,7 +0,0 @@ -# Porting Preparations - -- **[Before You Start](transplant-chip-prepare-knows.md)** - -- **[Building Adaptation Process](transplant-chip-prepare-process.md)** - - diff --git a/en/device-dev/porting/transplant-minichip.md b/en/device-dev/porting/transplant-minichip.md deleted file mode 100644 index 38a8e78dc15a0880b33aa775c6b13056f4aecc7c..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant-minichip.md +++ /dev/null @@ -1,11 +0,0 @@ -# Mini System SoC Porting Guide - -- **[Porting Preparations](transplant-chip-prepare.md)** - -- **[Kernel Porting](transplant-chip-kernel.md)** - -- **[Board-Level OS Porting](transplant-chip-board.md)** - -- **[FAQ](transplant-chip-faqs.md)** - - diff --git a/en/device-dev/porting/transplant-smallchip-drive.md b/en/device-dev/porting/transplant-smallchip-drive.md deleted file mode 100644 index a79db8073393aeffdbaf19445f95dee3cefb9218..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant-smallchip-drive.md +++ /dev/null @@ -1,9 +0,0 @@ -# Driver Porting - -- **[Overview](transplant-smallchip-drive-des.md)** - -- **[Platform Driver Porting](transplant-smallchip-drive-plat.md)** - -- **[Device Driver Porting](transplant-smallchip-drive-oom.md)** - - diff --git a/en/device-dev/porting/transplant-smallchip-kernel.md b/en/device-dev/porting/transplant-smallchip-kernel.md deleted file mode 100644 index cd252f8b951795654a29ecdc06cc83f1a9342c5b..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant-smallchip-kernel.md +++ /dev/null @@ -1,7 +0,0 @@ -# Kernel Porting - -- **[LiteOS Cortex-A](transplant-smallchip-kernel-a.md)** - -- **[Linux Kernel](transplant-smallchip-kernel-linux.md)** - - diff --git a/en/device-dev/porting/transplant-smallchip-prepare.md b/en/device-dev/porting/transplant-smallchip-prepare.md deleted file mode 100644 index 91c9cecaa0bb12598425d416c72a58c4b0f992c7..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant-smallchip-prepare.md +++ /dev/null @@ -1,7 +0,0 @@ -# Porting Preparations - -- **[Before You Start](transplant-smallchip-prepare-needs.md)** - -- **[Compilation and Building](transplant-smallchip-prepare-building.md)** - - diff --git a/en/device-dev/porting/transplant-smallchip.md b/en/device-dev/porting/transplant-smallchip.md deleted file mode 100644 index 818a9af1211dce6f85ee8d5c584fa0de10dfe3ad..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant-smallchip.md +++ /dev/null @@ -1,9 +0,0 @@ -# Small System SoC Porting Guide - -- **[Porting Preparations](transplant-smallchip-prepare.md)** - -- **[Kernel Porting](transplant-smallchip-kernel.md)** - -- **[Driver Porting](transplant-smallchip-drive.md)** - - diff --git a/en/device-dev/porting/transplant-thirdparty.md b/en/device-dev/porting/transplant-thirdparty.md deleted file mode 100644 index c8b071004faf57fb2255574649181cd04e7c12aa..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant-thirdparty.md +++ /dev/null @@ -1,9 +0,0 @@ -# Third-Party Library Porting Guide - -- **[Overview](transplant-thirdparty-overview.md)** - -- **[Porting a Library Built Using CMake](transplant-thirdparty-cmake.md)** - -- **[Porting a Library Built Using Makefile](transplant-thirdparty-makefile.md)** - - diff --git a/en/device-dev/porting/transplant.md b/en/device-dev/porting/transplant.md deleted file mode 100644 index 059e5ea0f84e85155b49e626989d2585c81a56e4..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/transplant.md +++ /dev/null @@ -1,9 +0,0 @@ -# Porting - -- **[Third-Party Library Porting Guide](transplant-thirdparty.md)** - -- **[Mini System SoC Porting Guide](transplant-minichip.md)** - -- **[Small System SoC Porting Guide](transplant-smallchip.md)** - - diff --git a/en/device-dev/quick-start/figure/2021-01-27_170334-17.png b/en/device-dev/quick-start/figure/2021-01-27_170334-17.png deleted file mode 100644 index 1e7dd2cdb515e871a1c5d34b3332b097bc02351b..0000000000000000000000000000000000000000 Binary files a/en/device-dev/quick-start/figure/2021-01-27_170334-17.png and /dev/null differ diff --git a/en/device-dev/quick-start/figure/2021-01-27_170334-18.png b/en/device-dev/quick-start/figure/2021-01-27_170334-18.png index 5b573a4ddfe89fe25cb1b567736823244fdb9e97..1e7dd2cdb515e871a1c5d34b3332b097bc02351b 100644 Binary files a/en/device-dev/quick-start/figure/2021-01-27_170334-18.png and b/en/device-dev/quick-start/figure/2021-01-27_170334-18.png differ diff --git a/en/device-dev/quick-start/figure/2021-01-27_170334-19.png b/en/device-dev/quick-start/figure/2021-01-27_170334-19.png new file mode 100644 index 0000000000000000000000000000000000000000..5b573a4ddfe89fe25cb1b567736823244fdb9e97 Binary files /dev/null and b/en/device-dev/quick-start/figure/2021-01-27_170334-19.png differ diff --git "a/en/device-dev/quick-start/figure/3516\346\255\243\351\235\242-17.png" "b/en/device-dev/quick-start/figure/3516\346\255\243\351\235\242-17.png" new file mode 100644 index 0000000000000000000000000000000000000000..1ccb47f20022261cc291e8b435f263c00e8d4a27 Binary files /dev/null and "b/en/device-dev/quick-start/figure/3516\346\255\243\351\235\242-17.png" differ diff --git a/en/device-dev/quick-start/quickstart-lite-env-setup-lin.md b/en/device-dev/quick-start/quickstart-lite-env-setup-lin.md index a5ec9aa0dae52356baeb3ba311efe54a00742619..2af1f471f0a4929f940cd0e773601073a3aa9e46 100644 --- a/en/device-dev/quick-start/quickstart-lite-env-setup-lin.md +++ b/en/device-dev/quick-start/quickstart-lite-env-setup-lin.md @@ -29,7 +29,7 @@ Perform the following steps to set up the build environment: >![](../public_sys-resources/icon-notice.gif) **NOTICE:** >- Docker is provided for the Ubuntu build environment, which encapsulates related build tools. If you use Docker to prepare the build environment, you do not need to perform the following steps in this section. Instead, refer to [Using Docker to Prepare the Build Environment](../get-code/gettools-acquire.md). >- By default, basic software, such as Samba and Vim, is installed in the system. Adaptation on the software is required to support file sharing between the Linux server and the Windows workstation. ->- For details about the compilation and building subsystem of OpenHarmony, see [Compilation and Building Overview](../subsystems/subsys-build-mini-lite.md). +>- For details about the compilation and building subsystem of OpenHarmony, see [Compilation and Building Overview](../subsystems/subsys-build.md). ## Obtaining Source Code and Tools @@ -160,7 +160,6 @@ You need to acquire [source code](../get-code/sourcecode-acquire.md), download ``` - 3. Set the soft link of **python** and **python3** to **python3.8**. ``` diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3861-running.md b/en/device-dev/quick-start/quickstart-lite-steps-board3861-running.md index d33056d84f2597bcabd5c97a8244ee4bcf3501a3..573245e7e223f25163185110666b9344339cf7ed 100644 --- a/en/device-dev/quick-start/quickstart-lite-steps-board3861-running.md +++ b/en/device-dev/quick-start/quickstart-lite-steps-board3861-running.md @@ -47,7 +47,7 @@ The source code needs to be modified when fixing bugs or compiling a new service SYS_RUN(HelloWorld); ``` -3. Add the **BUILD.gn** file for building services into a static library. +3. Compile the **BUILD.gn** file for building services into a static library. Create the **BUILD.gn** file in **./applications/sample/wifi-iot/app/my\_first\_app** and fill in three parts \(target, source file, and header file path\) of the **BUILD.gn** file. @@ -66,7 +66,7 @@ The source code needs to be modified when fixing bugs or compiling a new service - Specify the .c file on which a file depends and its path in **sources**. The path that contains **//** represents an absolute path \(the code root path\), otherwise it is a relative path. - Specify the path of .h file on which **sources** depends in **include\_dirs**. -4. Modify the **BUILD.gn** file and specify the feature modules to be built. +4. Compile the **BUILD.gn** file and specify the feature modules to be built. Configure the **./applications/sample/wifi-iot/app/BUILD.gn** file and add an index to the **features** field to enable the target to be involved in compilation. Specify the path and target of a service module in **features**. The following uses **my\_first\_app** as an example and the **features** is configured as follows: diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3861-setting.md b/en/device-dev/quick-start/quickstart-lite-steps-board3861-setting.md index 92d567cd5d954a195ccde7826cbfc997f585505f..2906ce5118e396068b489c5efa736b322a3a4b76 100644 --- a/en/device-dev/quick-start/quickstart-lite-steps-board3861-setting.md +++ b/en/device-dev/quick-start/quickstart-lite-steps-board3861-setting.md @@ -142,13 +142,11 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev sudo pip3 install kconfiglib ``` - - **Installation package:** 1. Download the **.whl** file \(for example, **kconfiglib-13.2.0-py2.py3-none-any.whl**\). Download path: [https://pypi.org/project/kconfiglib\#files](https://pypi.org/project/kconfiglib#files) - 1. Install the **.whl** file. ``` @@ -156,7 +154,6 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev ``` - 3. Install **PyCryptodome** using either of the following methods: Install the Python component packages on which the file signature depends, including PyCryptodome, six, and ecdsa. As the installation of **ecdsa** depends on that of **six**, install **six** first. @@ -172,7 +169,6 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev Download path: [https://pypi.org/project/pycryptodome/\#files](https://pypi.org/project/pycryptodome/#files) - 1. Install the **.whl** file. ``` @@ -180,7 +176,6 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev ``` - 4. Install **six** using either of the following methods: - **Command line:** @@ -188,13 +183,11 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev sudo pip3 install six --upgrade --ignore-installed six ``` - - **Installation package:** 1. Download the **.whl** file, for example, **six-1.12.0-py2.py3-none-any.whl**. Download path: [https://pypi.org/project/six/\#files](https://pypi.org/project/six/#files) - 1. Install the **.whl** file. ``` @@ -202,7 +195,6 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev ``` - 5. Install **ecdsa** using either of the following methods: - **Command line:** @@ -215,7 +207,6 @@ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev Download path: [https://pypi.org/project/ecdsa/\#files](https://pypi.org/project/ecdsa/#files) - 1. Install the **.whl** file. ``` diff --git a/en/device-dev/quick-start/quickstart-standard-burn.md b/en/device-dev/quick-start/quickstart-standard-burn.md index 5cfe9fccf987772fa26e2d64144c0416f7897dcc..01f052b9dd8e9918f6ecf4b765a57be12019e1ac 100644 --- a/en/device-dev/quick-start/quickstart-standard-burn.md +++ b/en/device-dev/quick-start/quickstart-standard-burn.md @@ -32,7 +32,7 @@ The Hi3516DV300 supports programming through the network port in Windows or Linu 3. Open DevEco Device Tool and go to **Projects** \> **Settings**. - ![](figure/2021-01-27_170334-17.png) + ![](figure/2021-01-27_170334-18.png) 4. On the **Partition Configuration** tab page, enter the information about the files to be programmed, including the following. @@ -186,7 +186,7 @@ The Hi3516DV300 supports programming through the network port in Windows or Linu ![](figure/en-us_image_0000001117463460.png) 8. When you finish modifying, click **Save** in the upper right corner. -9. Open the project file, go to ![](figure/2021-01-27_170334-18.png) \> **PROJECT TASKS** \> **fastboot** \> **Erase** to erase U-boot. +9. Open the project file, go to ![](figure/2021-01-27_170334-19.png) \> **PROJECT TASKS** \> **fastboot** \> **Erase** to erase U-boot. ![](figure/en-us_image_0000001163045527.png) @@ -201,5 +201,5 @@ The Hi3516DV300 supports programming through the network port in Windows or Linu ## Next -Congratulations! You have completed the quick start for the standard system. Get yourself familiar with OpenHarmony by a [Development Example for Clock App](../guide/oem_device_clockapp_des.md). +Congratulations! You have completed the quick start for the standard system. Get yourself familiar with OpenHarmony by a [Development Example for Clock App](../guide/device-clock-guide.md). diff --git a/en/device-dev/quick-start/quickstart-standard-description.md b/en/device-dev/quick-start/quickstart-standard-description.md index 75e796ec2168131936342f92c6247a2478a8ba24..8c4a158c8b95ad79217216b1a81ead279a67917e 100644 --- a/en/device-dev/quick-start/quickstart-standard-description.md +++ b/en/device-dev/quick-start/quickstart-standard-description.md @@ -22,7 +22,7 @@ Hi3516D V300 is a next-generation system on chip \(SoC\) designed for the indust **Figure 2** Hi3516D V300 front view -![](figure/3516正面.png) +![](figure/3516正面-17.png) ## Development Board Specifications diff --git a/en/device-dev/quick-start/quickstart-standard-docker-environment.md b/en/device-dev/quick-start/quickstart-standard-docker-environment.md index c9f27fb455f3de13052fbdf2e7454ff88d280fc7..c8cc2135d3defbd163ec02d1833fead4596cdcf3 100644 --- a/en/device-dev/quick-start/quickstart-standard-docker-environment.md +++ b/en/device-dev/quick-start/quickstart-standard-docker-environment.md @@ -19,7 +19,7 @@ The standard OpenHarmony system provides a Docker environment which encapsulates 1. Register your account with Gitee. 2. Register an SSH public key for access to Gitee. -3. Install the [git client](http://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading)), and configure basic user information. +3. Install the [git client](http://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information. ``` git config --global user.name "yourname" diff --git a/en/device-dev/quick-start/quickstart-standard-package-environment.md b/en/device-dev/quick-start/quickstart-standard-package-environment.md index ee9049108fbefa96530e67bdc8ecb2211296cd21..4ea30679f861982622088884015018ce15b9c4f0 100644 --- a/en/device-dev/quick-start/quickstart-standard-package-environment.md +++ b/en/device-dev/quick-start/quickstart-standard-package-environment.md @@ -25,7 +25,7 @@ sudo apt-get update && sudo apt-get install binutils git git-lfs gnupg flex biso 1. Register your account with Gitee. 2. Register an SSH public key for access to Gitee. -3. Install the [git client](http://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading)), and configure basic user information. +3. Install the [git client](http://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure basic user information. ``` git config --global user.name "yourname" @@ -92,7 +92,7 @@ Perform the following operations in the Linux environment: Files generated during the build are stored in the **out/ohos-arm-release/** directory, and the generated image is stored in the **out/ohos-arm-release/packages/phone/images/** directory. >![](../public_sys-resources/icon-note.gif) **NOTE:** - >For details about module-specific build operations, see [Building Guidelines](../subsystems/subsys-build-standard-large.md). + >For details about module-specific build operations, see [Building Guidelines](../subsystems/subsys-build.md). 3. Burn the image. For details, see [Burning Images](quickstart-standard-burn.md). diff --git a/en/device-dev/security/Readme-EN.md b/en/device-dev/security/Readme-EN.md index 09b0d20c4425a17dd609cffa530aaf54d0691c01..fc9af4847b9bda95751f1e61f5e72aef7ab8b3d8 100644 --- a/en/device-dev/security/Readme-EN.md +++ b/en/device-dev/security/Readme-EN.md @@ -1,5 +1,5 @@ # Privacy and Security -- [Privacy Protection](oem_security_privacy.md) -- [Security Guidelines](safety-safeguide-security.md) +- [Privacy Protection](security-privacy-protection.md) +- [Security Guidelines](security-guidelines-overall.md) diff --git a/en/device-dev/security/safety.md b/en/device-dev/security/safety.md new file mode 100644 index 0000000000000000000000000000000000000000..95d81080547fa0cb91a99a47aa7fdb83c39163b7 --- /dev/null +++ b/en/device-dev/security/safety.md @@ -0,0 +1,7 @@ +# Privacy and Security + +- **[Privacy Protection](security-privacy-protection.md)** + +- **[Security Guidelines](security-guidelines-overall.md)** + + diff --git a/en/device-dev/security/safety-safeguide-security.md b/en/device-dev/security/security-guidelines-overall.md similarity index 100% rename from en/device-dev/security/safety-safeguide-security.md rename to en/device-dev/security/security-guidelines-overall.md diff --git a/en/device-dev/security/oem_security_privacy.md b/en/device-dev/security/security-privacy-protection.md similarity index 99% rename from en/device-dev/security/oem_security_privacy.md rename to en/device-dev/security/security-privacy-protection.md index 0a3e53c1d8258693bb07dfe0637e3ea40f6e08ae..13eaf6a552864bdb4839187a0c641567964d8042 100644 --- a/en/device-dev/security/oem_security_privacy.md +++ b/en/device-dev/security/security-privacy-protection.md @@ -195,9 +195,9 @@ You shall obtain consent from users and comply with applicable laws and regulati Data processing security shall be ensured in technical terms, which include encrypted data storage and secure data transfer. Security mechanisms or measures shall be enabled by default for a system. -- A protection mechanism shall be available for personal data access, including identity authentication and access control. Identity authentication \(such as username and password\) allows only authenticated users to access data in multi-user scenarios. Access control \(for example, [permission control](security/safety-safeguide-security.md#li201725506375)\) can be applied to restrict access to applications. +- A protection mechanism shall be available for personal data access, including identity authentication and access control. Identity authentication \(such as username and password\) allows only authenticated users to access data in multi-user scenarios. Access control \(for example, [permission control](security-guidelines-overall.md#li201725506375)\) can be applied to restrict access to applications. - Secure storage of personal data on distributed devices must meet Huawei Universal Keystore \(HUKS\) requirements, including secure storage of keys and data. -- The transfer of personal data between distributed devices must meet the trust binding relationship between devices and security requirements of data transmission channels. For details, see [Security Guidelines](security/safety-safeguide-security.md#section26153183616). +- The transfer of personal data between distributed devices must meet the trust binding relationship between devices and security requirements of data transmission channels. For details, see [Security Guidelines](security-guidelines-overall.md#section26153183616). - Authentication data \(such as passwords and fingerprints\) shall be encrypted before being stored. **Localization** diff --git a/en/device-dev/subsystems/Readme-EN.md b/en/device-dev/subsystems/Readme-EN.md index 0b5b089be53af344a0d020fcb114ed8d829c76fd..86a43cbe70b80e64f7a577fc64cc32e43185b524 100644 --- a/en/device-dev/subsystems/Readme-EN.md +++ b/en/device-dev/subsystems/Readme-EN.md @@ -6,9 +6,9 @@ - [Distributed Remote Startup](subsys-remote-start.md) - [Graphics](subsys-graphics.md) - [Graphics](subsys-graphics-overview.md) - - [Development Guidelines on Container Components](subsys-graphics-bundle-guide1.md) - - [Development Guidelines on Layout Container Components](subsys-graphics-bundle-guide2.md) - - [Development Guidelines on Common Components](subsys-graphics-bundle-guide3.md) + - [Development Guidelines on Container Components](subsys-graphics-container-guide.md) + - [Development Guidelines on Layout Container Components](subsys-graphics-layout-guide.md) + - [Development Guidelines on Common Components](subsys-graphics-common-guide.md) - [Development Guidelines on Animators](subsys-graphics-animation-guide.md) - [Multimedia](subsys-multimedia.md) - [Camera](subsys-multimedia-camera.md) @@ -39,13 +39,13 @@ - [KWS SDK](subsys-aiframework-demo-sdk.md) - [KWS Plug-in](subsys-aiframework-demo-plugin.md) - [KWS Configuration File](subsys-aiframework-demo-conf.md) -- [Sensors](subsys-sensor.md) - - [Sensors Overview](subsys-sensor-overview.md) - - [Sensors Usage Guidelines](subsys-sensor-guide.md) - - [Sensors Usage Example](subsys-sensor-demo.md) +- [Sensors](subsys-densor.md) + - [Sensors Overview](subsys-densor-overview.md) + - [Sensors Usage Guidelines](subsys-densor-guide.md) + - [Sensors Usage Example](subsys-densor-demo.md) - [Application Framework](subsys-application-framework.md) - [Overview](subsys-application-framework-overview.md) - - [Setting Up a Development Environment](subsys-application-framework-builden.md) + - [Setting Up a Development Environment](subsys-application-framework-envbuild.md) - [Development Guidelines](subsys-application-framework-guide.md) - [Development Example](subsys-application-framework-demo.md) - [OTA Upgrade](subsys-ota-guide.md) @@ -68,7 +68,7 @@ - [Development Guidelines on HiLog ](subsys-dfx-hilog-rich.md) - [Development Guidelines on HiLog\_Lite](subsys-dfx-hilog-lite.md) - [Development Guidelines on HiSysEvent](subsys-dfx-hisysevent.md) -- [R&D Tools](subsys-toolchain.md) +- [R&D Tools](subsys-toolchain.md) - [bytrace Usage Guidelines](subsys-toolchain-bytrace-guide.md) - [hdc\_std Usage Guidelines](oem_subsys_toolchain_hdc_guide.md) - [XTS](subsys-xts-guide.md) \ No newline at end of file diff --git a/en/device-dev/subsystems/oem_subsys_utils_guide.md b/en/device-dev/subsystems/oem_subsys_utils_guide.md index 48a566a1a921eb5f3a6fcaadbc2b47a852b0b2aa..53e3b6eaeddb1a0642ba51a250c6e3fe2bc0118d 100644 --- a/en/device-dev/subsystems/oem_subsys_utils_guide.md +++ b/en/device-dev/subsystems/oem_subsys_utils_guide.md @@ -232,7 +232,6 @@ printf("UtilsDeleteValue delete ret = %d\n", ret); } ``` - - Generate a HAP file. - Add resource files in the **res/drawable** directory based on the following directory structure. @@ -241,7 +240,6 @@ printf("UtilsDeleteValue delete ret = %d\n", ret); - Compress the **libLauncher.so**, **config.json**, and resource files into a ZIP package and change the file name extension to **.hap**, for example, **Launcher.hap**. - 2. Connect the development board and send the command for installing the native KV store application to the board through the serial port. ``` diff --git a/en/device-dev/subsystems/subsys-application-framework-builden.md b/en/device-dev/subsystems/subsys-application-framework-envbuild.md similarity index 99% rename from en/device-dev/subsystems/subsys-application-framework-builden.md rename to en/device-dev/subsystems/subsys-application-framework-envbuild.md index c7497eb01035c6d5c8569cfef1ca944cbf444136..26aaaea82d6a99b193d1345d36e4ffda76ec0e62 100644 --- a/en/device-dev/subsystems/subsys-application-framework-builden.md +++ b/en/device-dev/subsystems/subsys-application-framework-envbuild.md @@ -2,6 +2,6 @@ - Development board: Hi3516D V300 -- [Download the source code](../get-code/sourcecode-acquire.md). +- [Download the source code](../get-code/sourcecode-acquire.md) - [Build the application framework](https://gitee.com/openharmony/docs/blob/master/en/readme/application-framework.md). diff --git a/en/device-dev/subsystems/subsys-application-framework-guide.md b/en/device-dev/subsystems/subsys-application-framework-guide.md index a4f37e5be36824b3f229c5f1b178e5a3e8d1197c..e02c08a8b14a8c3549331ad5b947370c9df281cc 100644 --- a/en/device-dev/subsystems/subsys-application-framework-guide.md +++ b/en/device-dev/subsystems/subsys-application-framework-guide.md @@ -334,7 +334,6 @@ This callback is invoked when a Service ability is destroyed. You should override this callback for your Service ability to clear its resources, such as threads and registered listeners. - 4. Override the message handling function. The **MsgHandle** function is used by Service abilities to handle messages sent from clients. **funcId** indicates the type of the message sent from the client, and **request** indicates the pointer to the serialized request parameters sent from the client. If you want to send the result back after the message is handled, serialize the result and write it into **reply**. @@ -392,7 +391,6 @@ Once created, the Service ability keeps running in the background. You can call **StopAbility\(\)** to stop the Service ability. - 7. Connect to a Service ability. - If you need to connect a Service ability to a Page ability or to a Service ability in another application, you should first create a Service ability for connection. A Service ability allows other abilities to connect to it through **ConnectAbility\(\)** by passing a **Want** object that contains information about the target Service ability to the function. You can implement callbacks in **IAbilityConnection** to be invoked when a Service ability is connected or disconnected. The **OnAbilityConnectDone\(\)** callback is invoked when an ability is connected, and **OnAbilityDisconnectDone\(\)** is invoked when an ability is disconnected. diff --git a/en/device-dev/subsystems/subsys-application-framework-overview.md b/en/device-dev/subsystems/subsys-application-framework-overview.md index a199610651dc5f2867adf61d356371d07e70b91a..c7127eddc228435bfaa8921305f0e99e888b9c7a 100644 --- a/en/device-dev/subsystems/subsys-application-framework-overview.md +++ b/en/device-dev/subsystems/subsys-application-framework-overview.md @@ -136,7 +136,6 @@ As shown in the figure, the Ability Manager Service is responsible for displayin - ROM: greater than 300 KB \(for the JS application development framework and related subsystems, such as UIKit and engine\) - - Cortex-A RAM and ROM - RAM: greater than 2 MB \(recommended\) diff --git a/en/device-dev/subsystems/subsys-application-framework.md b/en/device-dev/subsystems/subsys-application-framework.md index aeca8dc7dd6695791adc4204f1c76c88acd96568..d293e2f842b321e985360648f945a4005e0b0081 100644 --- a/en/device-dev/subsystems/subsys-application-framework.md +++ b/en/device-dev/subsystems/subsys-application-framework.md @@ -2,7 +2,7 @@ - **[Overview](subsys-application-framework-overview.md)** -- **[Setting Up a Development Environment](subsys-application-framework-builden.md)** +- **[Setting Up a Development Environment](subsys-application-framework-envbuild.md)** - **[Development Guidelines](subsys-application-framework-guide.md)** diff --git a/en/device-dev/subsystems/subsys-build-mini-lite.md b/en/device-dev/subsystems/subsys-build-mini-lite.md index 5d95a69ed431174a90a4c3c5451b845e349809f2..4cd0b642ab5c7523a7896846ad3cf9e774288561 100644 --- a/en/device-dev/subsystems/subsys-build-mini-lite.md +++ b/en/device-dev/subsystems/subsys-build-mini-lite.md @@ -396,7 +396,6 @@ The key directories and files are described as follows: - $\{root\_path\} - $\{fs\_dir\_name\} - >![](../public_sys-resources/icon-note.gif) **NOTE:** >**fs.yml** is optional and does not need to be configured for devices without a file system. diff --git a/en/device-dev/subsystems/subsys-sensor-demo.md b/en/device-dev/subsystems/subsys-densor-demo.md similarity index 100% rename from en/device-dev/subsystems/subsys-sensor-demo.md rename to en/device-dev/subsystems/subsys-densor-demo.md diff --git a/en/device-dev/subsystems/subsys-sensor-guide.md b/en/device-dev/subsystems/subsys-densor-guide.md similarity index 100% rename from en/device-dev/subsystems/subsys-sensor-guide.md rename to en/device-dev/subsystems/subsys-densor-guide.md diff --git a/en/device-dev/subsystems/subsys-sensor-overview.md b/en/device-dev/subsystems/subsys-densor-overview.md similarity index 100% rename from en/device-dev/subsystems/subsys-sensor-overview.md rename to en/device-dev/subsystems/subsys-densor-overview.md diff --git a/en/device-dev/subsystems/subsys-densor.md b/en/device-dev/subsystems/subsys-densor.md new file mode 100644 index 0000000000000000000000000000000000000000..590bc4c9665c51548ee59cd1761c075a1cb71d3d --- /dev/null +++ b/en/device-dev/subsystems/subsys-densor.md @@ -0,0 +1,9 @@ +# Sensors + +- **[Sensors Overview](subsys-densor-overview.md)** + +- **[Sensors Usage Guidelines](subsys-densor-guide.md)** + +- **[Sensors Usage Example](subsys-densor-demo.md)** + + diff --git a/en/device-dev/subsystems/subsys-dfx-hisyseventread.md b/en/device-dev/subsystems/subsys-dfx-hisyseventread.md deleted file mode 100644 index bd59a05b8727eb3b84857d700c04bdf98cb46bbe..0000000000000000000000000000000000000000 --- a/en/device-dev/subsystems/subsys-dfx-hisyseventread.md +++ /dev/null @@ -1,103 +0,0 @@ -# HiSysEvent订阅指导 - -- [概述](#section315316685112) -- [接口说明](#section0342191810519) -- [开发实例](#section123181432175110) - -## 概述 - -The HiSysEvent provides the cross-process subscription mechanism. You can register the subscription interface. - -## 接口说明 - -**Table 1** HiSysEvent订阅接口 - - - - - - - - - - - - - -

接口名

-

描述

-

int ISysEventService::AddListener(in SysEventRule[] rules, in ISysEventCallback callback)

-

接口功能:订阅HiSysEvent事件。

-

输入参数:

-
  • rules:事件订阅规则
  • callback:订阅回调对象
-

返回值:

-
  • 0:订阅成功,重复订阅
  • 1:订阅成功,初次订阅
  • 其他返回值:订阅失败
-

void ISysEventCallback::Handle(in String domain, in String eventName, in int eventType, in String eventDetail)

-

接口功能:订阅事件的回调接口。

-

输入参数:

-
  • domain:事件所属领域
  • eventName:事件的名称
  • eventType:事件类型
  • eventDetail:包含事件相关信息的字符串,以json的形式体现
-

返回值:无。

-
- -**Table 2** SysEventRule订阅规则对象 - - - - - - - - - - - - - - - - -

属性名称

-

描述

-

uint32_t ruleType

-

规则类型(匹配范围包括domain以及eventName):

-
  • 1:全字符匹配
  • 2:前缀匹配
  • 3:正则表达式匹配
  • 其他值:无效的匹配方式
-

std::string domain;

-
  • domain:事件所属领域,如果传入的是空字符串,则默认事件领域字段匹配成功
-

std::string eventName

-
  • eventName:事件的名称,如果传入的是空字符串,则默认事件名称字段匹配成功
-
- -## 开发实例 - -1. 源代码开发: - - 引入对应的aidl文件,包括:ISysEventService.aidl、SysEventRule.aidl、ISysEventCallback.aidl。 - - 在相应的业务逻辑里面调用ISysEventService::AddListener\(in SysEventRule\[\] rules, in ISysEventCallback callback\)接口。 - - 实现对应的回调对象: - - ISysEventCallback::Handle\(in String domain, in String eventName, in int eventType, in String eventDetail\) - - -1. 源代码开发: - - 引入对应的aidl文件,包括:ISysEventService.aidl、SysEventRule.aidl、ISysEventCallback.aidl。 - - 在相应的业务逻辑里面调用ISysEventService::AddListener\(in SysEventRule\[\] rules, in ISysEventCallback callback\)接口。 - - 实现对应的回调对象: - - ISysEventCallback::Handle\(in String domain, in String eventName, in int eventType, in String eventDetail\) - -2. 编译设置: - -在编译子系统里面,需要依赖libbinder模块 - -aosp\_deps = \[ "shared\_library:libbinder", \] - -- **[bytrace Usage Guidelines](subsys-toolchain-bytrace-guide.md)** - -- **[hdc\_std Usage Guidelines](oem_subsys_toolchain_hdc_guide.md)** - - diff --git a/en/device-dev/subsystems/subsys-graphics-bundle-guide3.md b/en/device-dev/subsystems/subsys-graphics-common-guide.md similarity index 100% rename from en/device-dev/subsystems/subsys-graphics-bundle-guide3.md rename to en/device-dev/subsystems/subsys-graphics-common-guide.md diff --git a/en/device-dev/subsystems/subsys-graphics-bundle-guide1.md b/en/device-dev/subsystems/subsys-graphics-container-guide.md similarity index 100% rename from en/device-dev/subsystems/subsys-graphics-bundle-guide1.md rename to en/device-dev/subsystems/subsys-graphics-container-guide.md diff --git a/en/device-dev/subsystems/subsys-graphics-bundle-guide2.md b/en/device-dev/subsystems/subsys-graphics-layout-guide.md similarity index 100% rename from en/device-dev/subsystems/subsys-graphics-bundle-guide2.md rename to en/device-dev/subsystems/subsys-graphics-layout-guide.md diff --git a/en/device-dev/subsystems/subsys-graphics.md b/en/device-dev/subsystems/subsys-graphics.md index bf96041837411ebf1c96ea894d70fdae2846b2ca..33ec9d2591be8e49ea9f039a09b4382c7f85d464 100644 --- a/en/device-dev/subsystems/subsys-graphics.md +++ b/en/device-dev/subsystems/subsys-graphics.md @@ -2,11 +2,11 @@ - **[Graphics](subsys-graphics-overview.md)** -- **[Development Guidelines on Container Components](subsys-graphics-bundle-guide1.md)** +- **[Development Guidelines on Container Components](subsys-graphics-container-guide.md)** -- **[Development Guidelines on Layout Container Components](subsys-graphics-bundle-guide2.md)** +- **[Development Guidelines on Layout Container Components](subsys-graphics-layout-guide.md)** -- **[Development Guidelines on Common Components](subsys-graphics-bundle-guide3.md)** +- **[Development Guidelines on Common Components](subsys-graphics-common-guide.md)** - **[Development Guidelines on Animators](subsys-graphics-animation-guide.md)** diff --git a/en/device-dev/subsystems/subsys-multimedia-camera-overview.md b/en/device-dev/subsystems/subsys-multimedia-camera-overview.md index 363f36457acbce8ac0ea1a8046c08920bde4807c..f09aab69ccc7177500a81ab64260af1d5ae614da 100644 --- a/en/device-dev/subsystems/subsys-multimedia-camera-overview.md +++ b/en/device-dev/subsystems/subsys-multimedia-camera-overview.md @@ -102,7 +102,6 @@ It is considered good practice that you understand the following concepts before ![](figure/en-us_image_0000001054101094.png) - 1. Taking a video/Previewing This process creates a **Camera** instance via **CameraKit**, and configures frame attributes via **FrameConfig** for recording or previewing. The following figure shows the time sequence. diff --git a/en/device-dev/subsystems/subsys-sensor.md b/en/device-dev/subsystems/subsys-sensor.md deleted file mode 100644 index 937d03221f56bff810edbf42b2697710d1df131f..0000000000000000000000000000000000000000 --- a/en/device-dev/subsystems/subsys-sensor.md +++ /dev/null @@ -1,9 +0,0 @@ -# Sensors - -- **[Sensors Overview](subsys-sensor-overview.md)** - -- **[Sensors Usage Guidelines](subsys-sensor-guide.md)** - -- **[Sensors Usage Example](subsys-sensor-demo.md)** - - diff --git a/en/device-dev/subsystems/subsys-testguide-test.md b/en/device-dev/subsystems/subsys-testguide-test.md index 215b683bd1ccb771b45c32a5256989b67af595ae..8f0986282259793864196b36b043dcab97ad999a 100644 --- a/en/device-dev/subsystems/subsys-testguide-test.md +++ b/en/device-dev/subsystems/subsys-testguide-test.md @@ -466,7 +466,6 @@ The testing framework integrates the open-source unit testing framework and expa } ``` - 6. Create a resource configuration file for the test case to use static resources. 1. Create the **resource** directory in the **test** directory of a component or module. 2. Create a directory for a device type, for example, **phone**, in the **resource** directory. @@ -618,7 +617,6 @@ The code repository of the testing subsystem provides complete demo cases, which ``` - 3. \(Optional\) Modify the Developertest configuration. If a test case has been compiled, specify the compilation output path of the test case. In this case the test platform will not recompile the test case. Modify the **config/user\_config.xml** file. @@ -640,7 +638,6 @@ The code repository of the testing subsystem provides complete demo cases, which ``` - 4. \(Optional\) Prepare the test environment. If devices to be tested support only serial ports, check whether the environment is ready: - The system image and file system have been burnt into the development board and are running properly on it. For example, in system mode, if the device prompt **OHOS\#** when you log in with the shell, the system is running properly. - The development host has been connected to the serial port of the development board and the network port. @@ -661,14 +658,13 @@ The code repository of the testing subsystem provides complete demo cases, which ./start.sh ``` - - Select a device type. - + Configure the device type based on the development board in the configuration file, for example, **developertest/config/framework\_config.xml**. - + - Run test commands. 1. To query the subsystems, modules, product form, and test types supported by test cases, run the **show** commands. - + ``` Usage: show productlist Query supported product forms @@ -676,15 +672,15 @@ The code repository of the testing subsystem provides complete demo cases, which show subsystemlist Query supported subsystems show modulelist Query supported modules ``` - + 2. Run test commands. **-t** is mandatory, and **-ss** and **-tm** are optional. The following is an example: - + ``` run -t ut -ss subsystem_examples -tm calculator ``` - + 3. Specify the arguments to execute the test suite for a specific feature or module. - + ``` usage: run [-h] [-p PRODUCTFORM] [-t [TESTTYPE [TESTTYPE ...]]] [-ss SUBSYSTEM] [-tm TESTMODULE] [-ts TESTSUIT] @@ -702,24 +698,22 @@ The code repository of the testing subsystem provides complete demo cases, which -tl TESTLEVEL, --testlevel TESTLEVEL Specify test level ``` - - View the test framework help if needed. - + Run the following command query test commands that are supported by the test platform: - + ``` help ``` - + - Exit the test platform. - + Run the following command to exit the test platform: - + ``` quit ``` - 6. View the test result and logs. The test logs and reports are generated in the **developertest/reports** directory after you run the test commands. - The test result is displayed on the console. The root path of the test result is as follows: @@ -751,9 +745,8 @@ The code repository of the testing subsystem provides complete demo cases, which details_report.html ``` - - The log directory of the test platform is as follows: - + ``` reports/platform_log_xxxx-xx-xx-xx-xx-xx.log ``` diff --git a/en/device-dev/subsystems/subsys-toolchain.md b/en/device-dev/subsystems/subsys-toolchain.md index 29f4d588550d44b6260b133f5df92fb29be79db2..193fb093ce8836530a90726e93a5c7aa1a226ce6 100644 --- a/en/device-dev/subsystems/subsys-toolchain.md +++ b/en/device-dev/subsystems/subsys-toolchain.md @@ -1,6 +1,7 @@ -# R&D Tools +# R&D Tools -- [bytrace Usage Guidelines](subsys-toolchain-bytrace-guide.md) -- [hdc\_std Usage Guidelines](oem_subsys_toolchain_hdc_guide.md) +- **[bytrace Usage Guidelines](subsys-toolchain-bytrace-guide.md)** + +- **[hdc\_std Usage Guidelines](oem_subsys_toolchain_hdc_guide.md)** diff --git a/en/device-dev/subsystems/subsys-xts-guide.md b/en/device-dev/subsystems/subsys-xts-guide.md index 8c39f59591f073526f2b2f269e93e5a724fa48cc..994ff8b60961d5c44e33c6e3a3c27f62606f1d8f 100644 --- a/en/device-dev/subsystems/subsys-xts-guide.md +++ b/en/device-dev/subsystems/subsys-xts-guide.md @@ -696,7 +696,6 @@ Install Python 3.7 or a later version on a Windows environment and ensure that t ![](figure/en-us_image_0000001119924146.gif) - - Execute the test cases of a module \(view specific module information in **\\acts\\testcases\\**\). ``` @@ -705,7 +704,6 @@ Install Python 3.7 or a later version on a Windows environment and ensure that t ![](figure/en-us_image_0000001166643927.jpg) - Wait until the test case is complete. diff --git a/en/device-dev/subsystems/subsys.md b/en/device-dev/subsystems/subsys.md index 9d1d0bdfb4c6b26ee49e9c93cec6e649f02940f7..d6cdc8fccd7c05d497089ddff01479ce29691b37 100644 --- a/en/device-dev/subsystems/subsys.md +++ b/en/device-dev/subsystems/subsys.md @@ -12,7 +12,7 @@ - **[AI Framework](subsys-aiframework.md)** -- **[Sensors](subsys-sensor.md)** +- **[Sensors](subsys-densor.md)** - **[Application Framework](subsys-application-framework.md)** @@ -26,7 +26,7 @@ - **[DFX](subsys-dfx.md)** -- **[HiSysEvent订阅指导](subsys-dfx-hisyseventread.md)** +- **[R&D Tools](subsys-toolchain.md)** - **[XTS](subsys-xts-guide.md)** diff --git a/en/readme.md b/en/readme.md index 1dd86e1a5ddda7bfcf0140edc7ef2faa5bd3de6f..72bcf19fab958be841293c2d6dcea9891ea404bf 100644 --- a/en/readme.md +++ b/en/readme.md @@ -1,4 +1,4 @@ -# WELCOME TO OPENHARMONY +# Overview This project stores OpenHarmony documentation, including the quick start guide, development guides, and API reference. We appreciate your contribution to the OpenHarmony documentation. @@ -7,23 +7,24 @@ This project stores OpenHarmony documentation, including the quick start guide, - [OpenHarmony Overview](OpenHarmony-Overview.md) - Mini and Small System Development Guidelines \(Reference Memory < 128 MB\) - Device development - - **overview**: [device development overview](device-dev/overview.md) + - **overview**: [device development overview](device-dev/Readme-EN.md) - **quick-start**: [quick start guide](device-dev/quick-start/Readme-EN.md) \(covering environment setup, source code acquisition, build, and burning\) - Basic development capabilities - - **Kernel**: [lite kernel](device-dev/kernel/kernel-lite.md) + - **Kernel**: [Kernel for Mini Systems](device-dev/kernel/kernel-lite-mini.md) + - **Kernel:**[Kernel for Small Systems](device-dev/kernel/kernel-lite-small.md) - **Drivers**: [drivers](device-dev/driver/Readme-EN.md) - **Subsystems**: [subsystems](device-dev/subsystems/Readme-EN.md) \(such as compilation and building, graphics, DFX, and XTS\) - **Security**: [privacy and security](device-dev/security/Readme-EN.md) - **guide**: - [WLAN-connected products](device-dev/guide/device-wifi.md) \(LED peripheral control and third-party SDK integration\) - - [Screenless cameras](device-dev/guide/device-iotcamera.md) \(camera control\) + - [Screenless cameras](device-dev/guide/device-iotcamera-control.md) \(camera control\) - [Cameras with a screen](device-dev/guide/device-camera.md) \(screen and camera control, visual application development\) - **porting**: - - [Mini System SoC Porting Guide](device-dev/porting/transplant-minichip.md) - - [Small System SoC Porting Guide](device-dev/porting/transplant-smallchip.md) - - [Third-Party Library Porting Guide](device-dev/porting/transplant-thirdparty.md) + - [Mini System SoC Porting Guide](device-dev/porting/porting-minichip.md) + - [Small System SoC Porting Guide](device-dev/porting/porting-smallchip.md) + - [Third-Party Library Porting Guide](device-dev/porting/porting-thirdparty.md) - **bundles**: - [Development Specifications](device-dev/bundles/bundles-standard-rules.md) @@ -32,22 +33,23 @@ This project stores OpenHarmony documentation, including the quick start guide, - Standard System Development Guidelines \(Reference Memory ≥ 128 MB\) - Device development - - **overview**: [device development overview](device-dev/overview.md) + - **overview**: [device development overview](device-dev/Readme-EN.md) - **quick-start**: [quick start guide](device-dev/quick-start/quickstart-standard.md) \(covering environment setup, source code acquisition, build, and burning\) - Basic development capabilities - - **Kernel**: [Linux kernel](device-dev/kernel/kernel-standard.md) + - **Kernel**: [Kernel for Standard Systems](device-dev/kernel/kernel-standard.md) - **Drivers**: [drivers](device-dev/driver/Readme-EN.md) - **Subsystems**: [subsystems](device-dev/subsystems/Readme-EN.md) \(such as compilation and building, graphics, DFX, and XTS\) - **Security**: [privacy and security](device-dev/security/Readme-EN.md) - **guide**: - - [Clock apps](device-dev/guide/oem_device_clockapp_des.md) + - [Clock apps](device-dev/guide/device-clock-guide.md) - [Platform drivers](device-dev/guide/device-driver-demo.md) - [Peripheral drivers](device-dev/guide/device-outerdriver-demo.md) - **porting**: - [Third-Party Library Porting Guide](device-dev/porting/transplant-thirdparty.md) + - [Third-Party Library Porting Guide](device-dev/porting/porting-thirdparty.md) + - [Standard System SoC Porting Guide](device-dev/porting/standard-system-porting-guide.md) - **bundles**: - [Development Specifications](device-dev/bundles/bundles-standard-rules.md) diff --git a/summary.md b/summary.md deleted file mode 100644 index a36078725aafc4f3ddc139e2e66b19a479eb95ac..0000000000000000000000000000000000000000 --- a/summary.md +++ /dev/null @@ -1,1018 +0,0 @@ -# Summary - -## zh-cn - -- [介绍](zh-cn/readme.md) -- [了解OpenHarmony](zh-cn/OpenHarmony-Overview_zh.md) -- 设备开发 - - [获取源码](zh-cn/device-dev/get-code/Readme-CN.md) - - [获取源码](zh-cn/device-dev/get-code/源码获取.md) - - [获取工具](zh-cn/device-dev/get-code/获取工具.md) - - [快速入门](zh-cn/device-dev/quick-start/Readme-CN.md) - - [导读](zh-cn/device-dev/quick-start/导读.md) - - [轻量和小型系统入门](zh-cn/device-dev/quick-start/轻量和小型系统入门.md) - - [概述](zh-cn/device-dev/quick-start/概述.md) - - [了解开发板](zh-cn/device-dev/quick-start/了解开发板.md) - - [Hi3861开发板介绍](zh-cn/device-dev/quick-start/Hi3861开发板介绍.md) - - [Hi3516开发板介绍](zh-cn/device-dev/quick-start/Hi3516开发板介绍.md) - - [Hi3518开发板介绍](zh-cn/device-dev/quick-start/Hi3518开发板介绍.md) - - [搭建系统环境](zh-cn/device-dev/quick-start/搭建系统环境.md) - - [Windows开发环境准备](zh-cn/device-dev/quick-start/Windows开发环境准备.md) - - [Ubuntu编译环境准备](zh-cn/device-dev/quick-start/Ubuntu编译环境准备.md) - - [常见问题](zh-cn/device-dev/quick-start/常见问题.md) - - [开发步骤](zh-cn/device-dev/quick-start/开发步骤.md) - - [Hi3861开发板](zh-cn/device-dev/quick-start/Hi3861开发板.md) - - [安装开发板环境](zh-cn/device-dev/quick-start/安装开发板环境.md) - - [WLAN联网](zh-cn/device-dev/quick-start/WLAN联网.md) - - [运行Hello World](zh-cn/device-dev/quick-start/运行Hello-World.md) - - [常见问题](zh-cn/device-dev/quick-start/常见问题-0.md) - - [Hi3516开发板](zh-cn/device-dev/quick-start/Hi3516开发板.md) - - [安装开发板环境](zh-cn/device-dev/quick-start/安装开发板环境-1.md) - - [运行Hello OHOS](zh-cn/device-dev/quick-start/运行Hello-OHOS.md) - - [驱动开发示例](zh-cn/device-dev/quick-start/驱动开发示例.md) - - [常见问题](zh-cn/device-dev/quick-start/常见问题-2.md) - - [Hi3518开发板](zh-cn/device-dev/quick-start/Hi3518开发板.md) - - [安装开发板环境](zh-cn/device-dev/quick-start/安装开发板环境-3.md) - - [运行Hello OHOS](zh-cn/device-dev/quick-start/运行Hello-OHOS-4.md) - - [常见问题](zh-cn/device-dev/quick-start/常见问题-5.md) - - [标准系统入门](zh-cn/device-dev/quick-start/标准系统入门.md) - - [概述](zh-cn/device-dev/quick-start/概述-6.md) - - [环境搭建](zh-cn/device-dev/quick-start/环境搭建.md) - - [概述](zh-cn/device-dev/quick-start/概述-7.md) - - [Windows开发环境准备](zh-cn/device-dev/quick-start/Windows开发环境准备-8.md) - - [Ubuntu编译环境准备](zh-cn/device-dev/quick-start/Ubuntu编译环境准备-9.md) - - [常见问题](zh-cn/device-dev/quick-start/常见问题-10.md) - - [开发步骤](zh-cn/device-dev/quick-start/开发步骤-11.md) - - 使用指南 - - [内核](zh-cn/device-dev/kernel/Readme-CN.md) - - [轻内核](zh-cn/device-dev/kernel/轻内核.md) - - [基础功能](zh-cn/device-dev/kernel/OpenHarmony轻内核基础功能.md) - - [进程](zh-cn/device-dev/kernel/进程.md) - - [线程](zh-cn/device-dev/kernel/线程.md) - - [内存](zh-cn/device-dev/kernel/内存.md) - - [网络](zh-cn/device-dev/kernel/网络.md) - - [文件系统](zh-cn/device-dev/kernel/OpenHarmony轻内核文件系统.md) - - [VFS](zh-cn/device-dev/kernel/VFS.md) - - [NFS](zh-cn/device-dev/kernel/NFS.md) - - [RAMFS](zh-cn/device-dev/kernel/RAMFS.md) - - [FAT](zh-cn/device-dev/kernel/FAT.md) - - [JFFS2](zh-cn/device-dev/kernel/JFFS2.md) - - [标准库](zh-cn/device-dev/kernel/标准库.md) - - [标准库](zh-cn/device-dev/kernel/标准库-0.md) - - [与Linux标准库的差异](zh-cn/device-dev/kernel/与Linux标准库的差异.md) - - [调测](zh-cn/device-dev/kernel/调测.md) - - [Shell介绍](zh-cn/device-dev/kernel/Shell介绍.md) - - [Shell命令开发指导](zh-cn/device-dev/kernel/Shell命令开发指导.md) - - [Shell命令编程实例](zh-cn/device-dev/kernel/Shell命令编程实例.md) - - [Shell命令使用详解](zh-cn/device-dev/kernel/Shell命令使用详解.md) - - [系统命令](zh-cn/device-dev/kernel/系统命令.md) - - [cpup](zh-cn/device-dev/kernel/cpup.md) - - [date](zh-cn/device-dev/kernel/date.md) - - [dmesg](zh-cn/device-dev/kernel/dmesg.md) - - [exec](zh-cn/device-dev/kernel/exec.md) - - [free](zh-cn/device-dev/kernel/free.md) - - [help](zh-cn/device-dev/kernel/help.md) - - [hwi](zh-cn/device-dev/kernel/hwi.md) - - [kill](zh-cn/device-dev/kernel/kill.md) - - [log](zh-cn/device-dev/kernel/log.md) - - [memcheck](zh-cn/device-dev/kernel/memcheck.md) - - [oom](zh-cn/device-dev/kernel/oom.md) - - [pmm](zh-cn/device-dev/kernel/pmm.md) - - [reset](zh-cn/device-dev/kernel/reset.md) - - [sem](zh-cn/device-dev/kernel/sem.md) - - [stack](zh-cn/device-dev/kernel/stack.md) - - [su](zh-cn/device-dev/kernel/su.md) - - [swtmr](zh-cn/device-dev/kernel/swtmr.md) - - [systeminfo](zh-cn/device-dev/kernel/systeminfo.md) - - [task](zh-cn/device-dev/kernel/task.md) - - [uname](zh-cn/device-dev/kernel/uname.md) - - [vmm](zh-cn/device-dev/kernel/vmm.md) - - [watch](zh-cn/device-dev/kernel/watch.md) - - [文件命令](zh-cn/device-dev/kernel/文件命令.md) - - [cat](zh-cn/device-dev/kernel/cat.md) - - [cd](zh-cn/device-dev/kernel/cd.md) - - [chgrp](zh-cn/device-dev/kernel/chgrp.md) - - [chmod](zh-cn/device-dev/kernel/chmod.md) - - [chown](zh-cn/device-dev/kernel/chown.md) - - [cp](zh-cn/device-dev/kernel/cp.md) - - [format](zh-cn/device-dev/kernel/format.md) - - [ls](zh-cn/device-dev/kernel/ls.md) - - [lsfd](zh-cn/device-dev/kernel/lsfd.md) - - [mkdir](zh-cn/device-dev/kernel/mkdir.md) - - [mount](zh-cn/device-dev/kernel/mount.md) - - [partinfo](zh-cn/device-dev/kernel/partinfo.md) - - [partition](zh-cn/device-dev/kernel/partition.md) - - [pwd](zh-cn/device-dev/kernel/pwd.md) - - [rm](zh-cn/device-dev/kernel/rm.md) - - [rmdir](zh-cn/device-dev/kernel/rmdir.md) - - [statfs](zh-cn/device-dev/kernel/statfs.md) - - [sync](zh-cn/device-dev/kernel/sync.md) - - [touch](zh-cn/device-dev/kernel/touch.md) - - [writeproc](zh-cn/device-dev/kernel/writeproc.md) - - [umount](zh-cn/device-dev/kernel/umount.md) - - [网络命令](zh-cn/device-dev/kernel/网络命令.md) - - [arp](zh-cn/device-dev/kernel/arp.md) - - [dhclient](zh-cn/device-dev/kernel/dhclient.md) - - [dns](zh-cn/device-dev/kernel/dns.md) - - [ifconfig](zh-cn/device-dev/kernel/ifconfig.md) - - [ipdebug](zh-cn/device-dev/kernel/ipdebug.md) - - [netstat](zh-cn/device-dev/kernel/netstat.md) - - [ntpdate](zh-cn/device-dev/kernel/ntpdate.md) - - [ping](zh-cn/device-dev/kernel/ping.md) - - [ping6](zh-cn/device-dev/kernel/ping6.md) - - [telnet](zh-cn/device-dev/kernel/telnet.md) - - [tftp](zh-cn/device-dev/kernel/tftp.md) - - [魔法键使用方法](zh-cn/device-dev/kernel/魔法键使用方法.md) - - [用户态异常信息说明](zh-cn/device-dev/kernel/用户态异常信息说明.md) - - [Linux内核](zh-cn/device-dev/kernel/Linux内核.md) - - [Linux内核概述](zh-cn/device-dev/kernel/Linux内核概述.md) - - [OpenHarmony开发板Patch使用指导](zh-cn/device-dev/kernel/OpenHarmony开发板Patch使用指导.md) - - [Linux内核编译与构建指导](zh-cn/device-dev/kernel/Linux内核编译与构建指导.md) - - [驱动](zh-cn/device-dev/driver/Readme-CN.md) - - [HDF驱动框架](zh-cn/device-dev/driver/HDF驱动框架.md) - - [HDF开发概述](zh-cn/device-dev/driver/HDF开发概述.md) - - [驱动开发](zh-cn/device-dev/driver/驱动开发.md) - - [驱动服务管理](zh-cn/device-dev/driver/驱动服务管理.md) - - [驱动消息机制管理](zh-cn/device-dev/driver/驱动消息机制管理.md) - - [配置管理](zh-cn/device-dev/driver/配置管理.md) - - [HDF开发实例](zh-cn/device-dev/driver/HDF开发实例.md) - - [驱动平台](zh-cn/device-dev/driver/驱动平台.md) - - [GPIO](zh-cn/device-dev/driver/GPIO.md) - - [GPIO概述](zh-cn/device-dev/driver/GPIO概述.md) - - [GPIO使用指导](zh-cn/device-dev/driver/GPIO使用指导.md) - - [GPIO使用实例](zh-cn/device-dev/driver/GPIO使用实例.md) - - [I2C](zh-cn/device-dev/driver/I2C.md) - - [I2C概述](zh-cn/device-dev/driver/I2C概述.md) - - [I2C使用指导](zh-cn/device-dev/driver/I2C使用指导.md) - - [I2C使用实例](zh-cn/device-dev/driver/I2C使用实例.md) - - [RTC](zh-cn/device-dev/driver/RTC.md) - - [RTC概述](zh-cn/device-dev/driver/RTC概述.md) - - [RTC使用指导](zh-cn/device-dev/driver/RTC使用指导.md) - - [RTC使用实例](zh-cn/device-dev/driver/RTC使用实例.md) - - [SDIO](zh-cn/device-dev/driver/SDIO.md) - - [SDIO概述](zh-cn/device-dev/driver/SDIO概述.md) - - [SDIO使用指导](zh-cn/device-dev/driver/SDIO使用指导.md) - - [SDIO使用实例](zh-cn/device-dev/driver/SDIO使用实例.md) - - [SPI](zh-cn/device-dev/driver/SPI.md) - - [SPI概述](zh-cn/device-dev/driver/SPI概述.md) - - [SPI使用指导](zh-cn/device-dev/driver/SPI使用指导.md) - - [SPI使用实例](zh-cn/device-dev/driver/SPI使用实例.md) - - [UART](zh-cn/device-dev/driver/UART.md) - - [UART概述](zh-cn/device-dev/driver/UART概述.md) - - [UART使用指导](zh-cn/device-dev/driver/UART使用指导.md) - - [UART使用实例](zh-cn/device-dev/driver/UART使用实例.md) - - [WATCHDOG](zh-cn/device-dev/driver/WATCHDOG.md) - - [看门狗概述](zh-cn/device-dev/driver/看门狗概述.md) - - [看门狗使用指导](zh-cn/device-dev/driver/看门狗使用指导.md) - - [看门狗使用实例](zh-cn/device-dev/driver/看门狗使用实例.md) - - [MIPI DSI](zh-cn/device-dev/driver/MIPI-DSI.md) - - [MIPI DSI概述](zh-cn/device-dev/driver/MIPI-DSI概述.md) - - [MIPI DSI使用指导](zh-cn/device-dev/driver/MIPI-DSI使用指导.md) - - [MIPI DSI使用实例](zh-cn/device-dev/driver/MIPI-DSI使用实例.md) - - [外设](zh-cn/device-dev/driver/外设.md) - - [LCD](zh-cn/device-dev/driver/LCD.md) - - [LCD开发概述](zh-cn/device-dev/driver/LCD开发概述.md) - - [LCD开发指导](zh-cn/device-dev/driver/LCD开发指导.md) - - [LCD开发实例](zh-cn/device-dev/driver/LCD开发实例.md) - - [TOUCHSCREEN](zh-cn/device-dev/driver/TOUCHSCREEN.md) - - [Touchscreen开发概述](zh-cn/device-dev/driver/Touchscreen开发概述.md) - - [Touchscreen开发指导](zh-cn/device-dev/driver/Touchscreen开发指导.md) - - [Touchscreen开发实例](zh-cn/device-dev/driver/Touchscreen开发实例.md) - - [SENSOR](zh-cn/device-dev/driver/SENSOR.md) - - [传感器驱动开发概述](zh-cn/device-dev/driver/传感器驱动开发概述.md) - - [传感器驱动开发指导](zh-cn/device-dev/driver/传感器驱动开发指导.md) - - [传感器驱动开发实例](zh-cn/device-dev/driver/传感器驱动开发实例.md) - - [传感器驱动测试指导](zh-cn/device-dev/driver/传感器驱动测试指导.md) - - [WLAN](zh-cn/device-dev/driver/WLAN.md) - - [WLAN开发概述](zh-cn/device-dev/driver/WLAN开发概述.md) - - [WLAN开发指导](zh-cn/device-dev/driver/WLAN开发指导.md) - - [WLAN开发实例](zh-cn/device-dev/driver/WLAN开发实例.md) - - [子系统](zh-cn/device-dev/subsystems/Readme-CN.md) - - [编译构建](zh-cn/device-dev/subsystems/编译构建.md) - - [轻量和小型系统编译构建指导](zh-cn/device-dev/subsystems/轻量和小型系统编译构建指导.md) - - [编译构建概述](zh-cn/device-dev/subsystems/编译构建概述.md) - - [编译构建使用指导](zh-cn/device-dev/subsystems/编译构建使用指导.md) - - [编译构建常见问题](zh-cn/device-dev/subsystems/编译构建常见问题.md) - - [标准系统编译构建指导](zh-cn/device-dev/subsystems/标准系统编译构建指导.md) - - [编译构建概述](zh-cn/device-dev/subsystems/编译构建概述-0.md) - - [编译构建使用指导](zh-cn/device-dev/subsystems/编译构建使用指导-1.md) - - [分布式远程启动](zh-cn/device-dev/subsystems/分布式远程启动.md) - - [图形图像](zh-cn/device-dev/subsystems/图形图像.md) - - [图形图像概述](zh-cn/device-dev/subsystems/图形图像概述.md) - - [容器类组件开发指导](zh-cn/device-dev/subsystems/容器类组件开发指导.md) - - [布局容器类组件开发指导](zh-cn/device-dev/subsystems/布局容器类组件开发指导.md) - - [普通组件开发指导](zh-cn/device-dev/subsystems/普通组件开发指导.md) - - [动画开发指导](zh-cn/device-dev/subsystems/动画开发指导.md) - - [媒体](zh-cn/device-dev/subsystems/媒体.md) - - [相机](zh-cn/device-dev/subsystems/相机.md) - - [相机开发概述](zh-cn/device-dev/subsystems/相机开发概述.md) - - [拍照开发指导](zh-cn/device-dev/subsystems/拍照开发指导.md) - - [录像开发指导](zh-cn/device-dev/subsystems/录像开发指导.md) - - [预览开发指导](zh-cn/device-dev/subsystems/预览开发指导.md) - - [音视频](zh-cn/device-dev/subsystems/音视频.md) - - [音视频开发概述](zh-cn/device-dev/subsystems/音视频开发概述.md) - - [音视频播放开发指导](zh-cn/device-dev/subsystems/音视频播放开发指导.md) - - [音视频录制开发指导](zh-cn/device-dev/subsystems/音视频录制开发指导.md) - - [公共基础](zh-cn/device-dev/subsystems/公共基础.md) - - [公共基础库概述](zh-cn/device-dev/subsystems/公共基础库概述.md) - - [公共基础库开发指导](zh-cn/device-dev/subsystems/公共基础库开发指导.md) - - [公共基础库常见问题](zh-cn/device-dev/subsystems/公共基础库常见问题.md) - - [AI框架](zh-cn/device-dev/subsystems/AI框架.md) - - [AI引擎框架开发指南](zh-cn/device-dev/subsystems/AI引擎框架开发指南.md) - - [搭建环境](zh-cn/device-dev/subsystems/搭建环境.md) - - [技术规范](zh-cn/device-dev/subsystems/技术规范.md) - - [代码管理规范](zh-cn/device-dev/subsystems/代码管理规范.md) - - [命名规范](zh-cn/device-dev/subsystems/命名规范.md) - - [接口开发规范](zh-cn/device-dev/subsystems/接口开发规范.md) - - [开发指导](zh-cn/device-dev/subsystems/开发指导.md) - - [SDK开发过程](zh-cn/device-dev/subsystems/SDK开发过程.md) - - [插件的开发过程](zh-cn/device-dev/subsystems/插件的开发过程.md) - - [配置文件的开发过程](zh-cn/device-dev/subsystems/配置文件的开发过程.md) - - [开发示例](zh-cn/device-dev/subsystems/开发示例.md) - - [唤醒词识别SDK的开发示例](zh-cn/device-dev/subsystems/唤醒词识别SDK的开发示例.md) - - [唤醒词识别插件的开发示例](zh-cn/device-dev/subsystems/唤醒词识别插件的开发示例.md) - - [唤醒词识别配置文件的开发示例](zh-cn/device-dev/subsystems/唤醒词识别配置文件的开发示例.md) - - [Sensor服务](zh-cn/device-dev/subsystems/Sensor服务.md) - - [Sensor服务子系概述](zh-cn/device-dev/subsystems/Sensor服务子系概述.md) - - [Sensor服务子系使用指导](zh-cn/device-dev/subsystems/Sensor服务子系使用指导.md) - - [Sensor服务子系使用实例](zh-cn/device-dev/subsystems/Sensor服务子系使用实例.md) - - [用户程序框架](zh-cn/device-dev/subsystems/用户程序框架.md) - - [概述](zh-cn/device-dev/subsystems/概述.md) - - [搭建环境](zh-cn/device-dev/subsystems/搭建环境-2.md) - - [开发指导](zh-cn/device-dev/subsystems/开发指导-3.md) - - [开发实例](zh-cn/device-dev/subsystems/开发实例.md) - - [OTA升级](zh-cn/device-dev/subsystems/OTA升级.md) - - [安全](zh-cn/device-dev/subsystems/安全.md) - - [概述](zh-cn/device-dev/subsystems/概述-7.md) - - [应用验签开发指导](zh-cn/device-dev/subsystems/应用验签开发指导.md) - - [应用权限管理开发指导](zh-cn/device-dev/subsystems/应用权限管理开发指导.md) - - [IPC通信鉴权开发指导](zh-cn/device-dev/subsystems/IPC通信鉴权开发指导.md) - - [可信设备群组管理开发指导](zh-cn/device-dev/subsystems/可信设备群组管理开发指导.md) - - [启动恢复](zh-cn/device-dev/subsystems/启动恢复.md) - - [启动恢复子系统概述](zh-cn/device-dev/subsystems/启动恢复子系统概述.md) - - [init启动引导组件](zh-cn/device-dev/subsystems/init启动引导组件.md) - - [appspawn应用孵化组件](zh-cn/device-dev/subsystems/appspawn应用孵化组件.md) - - [bootstrap服务启动组件](zh-cn/device-dev/subsystems/bootstrap服务启动组件.md) - - [syspara系统属性组件](zh-cn/device-dev/subsystems/syspara系统属性组件.md) - - [常见问题](zh-cn/device-dev/subsystems/常见问题.md) - - [参考](zh-cn/device-dev/subsystems/参考.md) - - [测试](zh-cn/device-dev/subsystems/测试.md) - - [DFX](zh-cn/device-dev/subsystems/DFX.md) - - [DFX概述](zh-cn/device-dev/subsystems/DFX概述.md) - - [HiLog开发指导](zh-cn/device-dev/subsystems/HiLog开发指导.md) - - [HiLog\_Lite开发指导](zh-cn/device-dev/subsystems/HiLog_Lite开发指导.md) - - [HiSysEvent开发指导](zh-cn/device-dev/subsystems/HiSysEvent开发指导.md) - - [研发工具链](zh-cn/device-dev/subsystems/研发工具链.md) - - [bytrace使用指导](zh-cn/device-dev/subsystems/bytrace使用指导.md) - - [hdc\_std 使用指导](zh-cn/device-dev/subsystems/hdc_std-使用指导.md) - - [XTS](zh-cn/device-dev/subsystems/XTS认证子系统开发指南.md) - - [隐私与安全](zh-cn/device-dev/security/Readme-CN.md) - - [隐私保护](zh-cn/device-dev/security/隐私保护.md) - - [安全指南](zh-cn/device-dev/security/安全指南.md) - - [开发示例](zh-cn/device-dev/guide/Readme-CN.md) - - [WLAN连接类产品](zh-cn/device-dev/guide/WLAN连接类产品.md) - - [LED外设控制](zh-cn/device-dev/guide/LED外设控制.md) - - [概述](zh-cn/device-dev/guide/概述.md) - - [开发](zh-cn/device-dev/guide/开发.md) - - [验证](zh-cn/device-dev/guide/验证.md) - - [集成三方SDK](zh-cn/device-dev/guide/集成三方SDK.md) - - [无屏摄像头类产品](zh-cn/device-dev/guide/无屏摄像头类产品.md) - - [摄像头控制](zh-cn/device-dev/guide/摄像头控制.md) - - [概述](zh-cn/device-dev/guide/概述-0.md) - - [示例开发](zh-cn/device-dev/guide/示例开发.md) - - [拍照开发指导](zh-cn/device-dev/guide/拍照开发指导.md) - - [录像开发指导](zh-cn/device-dev/guide/录像开发指导.md) - - [应用实例](zh-cn/device-dev/guide/应用实例.md) - - [带屏摄像头类产品](zh-cn/device-dev/guide/带屏摄像头类产品.md) - - [屏幕和摄像头控制](zh-cn/device-dev/guide/屏幕和摄像头控制.md) - - [概述](zh-cn/device-dev/guide/概述-1.md) - - [示例开发](zh-cn/device-dev/guide/示例开发-2.md) - - [拍照开发指导](zh-cn/device-dev/guide/拍照开发指导-3.md) - - [录像开发指导](zh-cn/device-dev/guide/录像开发指导-4.md) - - [预览开发指导](zh-cn/device-dev/guide/预览开发指导.md) - - [应用实例](zh-cn/device-dev/guide/应用实例-5.md) - - [视觉应用开发](zh-cn/device-dev/guide/视觉应用开发.md) - - [概述](zh-cn/device-dev/guide/概述-6.md) - - [开发准备](zh-cn/device-dev/guide/开发准备.md) - - [添加页面](zh-cn/device-dev/guide/添加页面.md) - - [开发首页](zh-cn/device-dev/guide/开发首页.md) - - [开发详情页](zh-cn/device-dev/guide/开发详情页.md) - - [调试打包](zh-cn/device-dev/guide/调试打包.md) - - [真机运行](zh-cn/device-dev/guide/真机运行.md) - - [常见问题](zh-cn/device-dev/guide/常见问题.md) - - [时钟应用开发示例](zh-cn/device-dev/guide/时钟应用开发示例.md) - - [概述](zh-cn/device-dev/guide/概述-7.md) - - [开发准备](zh-cn/device-dev/guide/开发准备-8.md) - - [开发步骤](zh-cn/device-dev/guide/开发步骤.md) - - [签名打包](zh-cn/device-dev/guide/签名打包.md) - - [真机运行](zh-cn/device-dev/guide/真机运行-9.md) - - - [平台驱动开发示例](zh-cn/device-dev/guide/平台驱动开发示例.md) - - [概述](zh-cn/device-dev/guide/概述-10.md) - - [环境准备](zh-cn/device-dev/guide/环境准备.md) - - [开发](zh-cn/device-dev/guide/开发-11.md) - - [编译及烧录](zh-cn/device-dev/guide/编译及烧录.md) - - - [外设驱动开发示例](zh-cn/device-dev/guide/外设驱动开发示例.md) - - [概述](zh-cn/device-dev/guide/概述-12.md) - - [硬件资源介绍](zh-cn/device-dev/guide/硬件资源介绍.md) - - [Input模型简介](zh-cn/device-dev/guide/Input模型简介.md) - - - [环境搭建](zh-cn/device-dev/guide/环境搭建.md) - - [TouchScreen器件驱动开发](zh-cn/device-dev/guide/TouchScreen器件驱动开发.md) - - [配置设备描述信息](zh-cn/device-dev/guide/配置设备描述信息.md) - - [配置Touchscreen器件信息](zh-cn/device-dev/guide/配置Touchscreen器件信息.md) - - [适配器件私有驱动](zh-cn/device-dev/guide/适配器件私有驱动.md) - - - [编译及烧录](zh-cn/device-dev/guide/编译及烧录-13.md) - - [调试验证](zh-cn/device-dev/guide/调试验证.md) - - [开机日志分析](zh-cn/device-dev/guide/开机日志分析.md) - - - [Input模型工作流程解析](zh-cn/device-dev/guide/Input模型工作流程解析.md) - - [私有配置信息解析](zh-cn/device-dev/guide/私有配置信息解析.md) - - [管理驱动层初始化及注册驱动至HDF框架](zh-cn/device-dev/guide/管理驱动层初始化及注册驱动至HDF框架.md) - - [公共驱动层初始化及注册驱动至HDF框架](zh-cn/device-dev/guide/公共驱动层初始化及注册驱动至HDF框架.md) - - [器件驱动层初始化及注册驱动至HDF框架](zh-cn/device-dev/guide/器件驱动层初始化及注册驱动至HDF框架.md) - - [具体调用逻辑串联函数](zh-cn/device-dev/guide/具体调用逻辑串联函数.md) - - - - [移植适配](zh-cn/device-dev/porting/Readme-CN.md) - - [三方库移植指导](zh-cn/device-dev/porting/三方库移植指导.md) - - [概述](zh-cn/device-dev/porting/概述.md) - - [CMake方式组织编译的库移植](zh-cn/device-dev/porting/CMake方式组织编译的库移植.md) - - [Makefile方式组织编译的库移植](zh-cn/device-dev/porting/Makefile方式组织编译的库移植.md) - - [三方芯片移植指导](zh-cn/device-dev/porting/三方芯片移植指导.md) - - [移植准备](zh-cn/device-dev/porting/移植准备.md) - - [移植须知](zh-cn/device-dev/porting/移植须知.md) - - [编译构建适配流程](zh-cn/device-dev/porting/编译构建适配流程.md) - - [内核移植](zh-cn/device-dev/porting/内核移植.md) - - [移植概述](zh-cn/device-dev/porting/移植概述.md) - - [内核基础适配](zh-cn/device-dev/porting/内核基础适配.md) - - [内核移植验证](zh-cn/device-dev/porting/内核移植验证.md) - - [板级系统移植](zh-cn/device-dev/porting/板级系统移植.md) - - [移植概述](zh-cn/device-dev/porting/移植概述-0.md) - - [板级驱动适配](zh-cn/device-dev/porting/板级驱动适配.md) - - [HAL层实现](zh-cn/device-dev/porting/HAL层实现.md) - - [系统组件调用](zh-cn/device-dev/porting/系统组件调用.md) - - [XTS认证](zh-cn/device-dev/porting/XTS认证.md) - - [常见问题](zh-cn/device-dev/porting/常见问题.md) - - [组件开发](zh-cn/device-dev/bundles/Readme-CN.md) - - [组件开发规范](zh-cn/device-dev/bundles/组件开发规范.md) - - [概述](zh-cn/device-dev/bundles/概述.md) - - [组件构成](zh-cn/device-dev/bundles/组件构成.md) - - [组件管理](zh-cn/device-dev/bundles/组件管理.md) - - [组件版本](zh-cn/device-dev/bundles/组件版本.md) - - [发行版](zh-cn/device-dev/bundles/发行版.md) - - [环境变量说明](zh-cn/device-dev/bundles/环境变量说明.md) - - [组件开发指南](zh-cn/device-dev/bundles/组件开发指南.md) - - [概述](zh-cn/device-dev/bundles/概述-0.md) - - [准备工作](zh-cn/device-dev/bundles/准备工作.md) - - [组件开发](zh-cn/device-dev/bundles/组件开发.md) - - [组件开发示例](zh-cn/device-dev/bundles/组件开发示例.md) - - [HPM介绍](zh-cn/device-dev/bundles/HPM介绍.md) - - [环境准备](zh-cn/device-dev/bundles/环境准备.md) - - [操作实例](zh-cn/device-dev/bundles/操作实例.md) - - [术语](zh-cn/device-dev/glossary/术语.md) -- 应用开发 - - [入门](zh-cn/application-dev/quick-start/Readme-CN.md) - - [DevEco Studio(OpenHarmony)使用指南](zh-cn/application-dev/quick-start/DevEco-Studio(OpenHarmony)使用指南.md) - - [概述](zh-cn/application-dev/quick-start/概述.md) - - [配置OpenHarmony SDK](zh-cn/application-dev/quick-start/配置OpenHarmony-SDK.md) - - [导入OpenHarmony工程](zh-cn/application-dev/quick-start/导入OpenHarmony工程.md) - - [配置OpenHarmony应用签名信息](zh-cn/application-dev/quick-start/配置OpenHarmony应用签名信息.md) - - [安装运行OpenHarmony应用](zh-cn/application-dev/quick-start/安装运行OpenHarmony应用.md) - - [快速入门](zh-cn/application-dev/quick-start/快速入门.md) - - [开发准备](zh-cn/application-dev/quick-start/开发准备.md) - - [使用JS语言开发](zh-cn/application-dev/quick-start/使用JS语言开发.md) - - - [UI](zh-cn/application-dev/ui/Readme-CN.md) - - [JS UI框架](zh-cn/application-dev/ui/JS-UI框架.md) - - [JS UI框架概述](zh-cn/application-dev/ui/JS-UI框架概述.md) - - [构建用户界面](zh-cn/application-dev/ui/构建用户界面.md) - - [组件介绍](zh-cn/application-dev/ui/组件介绍.md) - - [构建布局](zh-cn/application-dev/ui/构建布局.md) - - [布局说明](zh-cn/application-dev/ui/布局说明.md) - - [添加标题行和文本区域](zh-cn/application-dev/ui/添加标题行和文本区域.md) - - [添加图片区域](zh-cn/application-dev/ui/添加图片区域.md) - - [添加留言区域](zh-cn/application-dev/ui/添加留言区域.md) - - [添加容器](zh-cn/application-dev/ui/添加容器.md) - - [添加交互](zh-cn/application-dev/ui/添加交互.md) - - [动画](zh-cn/application-dev/ui/动画.md) - - [事件](zh-cn/application-dev/ui/事件.md) - - [页面路由](zh-cn/application-dev/ui/页面路由.md) - - [自定义组件](zh-cn/application-dev/ui/自定义组件.md) - - - [媒体](zh-cn/application-dev/media/Readme-CN.md) - - [音频](zh-cn/application-dev/media/音频.md) - - [音频开发概述](zh-cn/application-dev/media/音频开发概述.md) - - - [音频播放开发指导](zh-cn/application-dev/media/音频播放开发指导.md) - - [音频管理开发指导](zh-cn/application-dev/media/音频管理开发指导.md) - - - - [网络与连接](zh-cn/application-dev/connectivity/Readme-CN.md) - - - [IPC与RPC通信](zh-cn/application-dev/connectivity/IPC与RPC通信.md) - - [IPC与RPC通信概述](zh-cn/application-dev/connectivity/IPC与RPC通信概述.md) - - [IPC与RPC通信开发指导](zh-cn/application-dev/connectivity/IPC与RPC通信开发指导.md) - - [远端状态订阅开发实例](zh-cn/application-dev/connectivity/远端状态订阅开发实例.md) - - - [JS参考规范](zh-cn/application-dev/js-reference/Readme-CN.md) - - [框架说明](zh-cn/application-dev/js-reference/框架说明.md) - - [文件组织](zh-cn/application-dev/js-reference/文件组织.md) - - [js标签配置](zh-cn/application-dev/js-reference/js标签配置.md) - - [app.js](zh-cn/application-dev/js-reference/app-js.md) - - [语法](zh-cn/application-dev/js-reference/语法.md) - - [HML语法参考](zh-cn/application-dev/js-reference/HML语法参考.md) - - [CSS语法参考](zh-cn/application-dev/js-reference/CSS语法参考.md) - - [JS语法参考](zh-cn/application-dev/js-reference/JS语法参考.md) - - [组件](zh-cn/application-dev/js-reference/组件.md) - - [通用](zh-cn/application-dev/js-reference/通用.md) - - [组件方法](zh-cn/application-dev/js-reference/组件方法.md) - - [动画样式](zh-cn/application-dev/js-reference/动画样式.md) - - [渐变样式](zh-cn/application-dev/js-reference/渐变样式.md) - - [转场样式](zh-cn/application-dev/js-reference/转场样式.md) - - [自定义字体样式](zh-cn/application-dev/js-reference/自定义字体样式.md) - - [原子布局](zh-cn/application-dev/js-reference/原子布局.md) - - [容器组件](zh-cn/application-dev/js-reference/容器组件.md) - - [badge](zh-cn/application-dev/js-reference/badge.md) - - [dialog](zh-cn/application-dev/js-reference/dialog.md) - - [div](zh-cn/application-dev/js-reference/div.md) - - [list](zh-cn/application-dev/js-reference/list.md) - - [list-item](zh-cn/application-dev/js-reference/list-item.md) - - [list-item-group](zh-cn/application-dev/js-reference/list-item-group.md) - - [panel](zh-cn/application-dev/js-reference/panel.md) - - [popup](zh-cn/application-dev/js-reference/popup.md) - - [refresh](zh-cn/application-dev/js-reference/refresh.md) - - [stack](zh-cn/application-dev/js-reference/stack.md) - - [stepper](zh-cn/application-dev/js-reference/stepper.md) - - [stepper-item](zh-cn/application-dev/js-reference/stepper-item.md) - - [swiper](zh-cn/application-dev/js-reference/swiper.md) - - [tabs](zh-cn/application-dev/js-reference/tabs.md) - - [tab-bar](zh-cn/application-dev/js-reference/tab-bar.md) - - [tab-content](zh-cn/application-dev/js-reference/tab-content.md) - - [基础组件](zh-cn/application-dev/js-reference/基础组件.md) - - [button](zh-cn/application-dev/js-reference/button.md) - - [chart](zh-cn/application-dev/js-reference/chart.md) - - [divider](zh-cn/application-dev/js-reference/divider.md) - - [image](zh-cn/application-dev/js-reference/image.md) - - [image-animator](zh-cn/application-dev/js-reference/image-animator.md) - - [input](zh-cn/application-dev/js-reference/input.md) - - [label](zh-cn/application-dev/js-reference/label.md) - - [marquee](zh-cn/application-dev/js-reference/marquee.md) - - [menu](zh-cn/application-dev/js-reference/menu.md) - - [option](zh-cn/application-dev/js-reference/option.md) - - [picker](zh-cn/application-dev/js-reference/picker.md) - - [picker-view](zh-cn/application-dev/js-reference/picker-view.md) - - [piece](zh-cn/application-dev/js-reference/piece.md) - - [progress](zh-cn/application-dev/js-reference/progress.md) - - [qrcode](zh-cn/application-dev/js-reference/qrcode.md) - - [rating](zh-cn/application-dev/js-reference/rating.md) - - [select](zh-cn/application-dev/js-reference/select.md) - - [slider](zh-cn/application-dev/js-reference/slider.md) - - [span](zh-cn/application-dev/js-reference/span.md) - - [switch](zh-cn/application-dev/js-reference/switch.md) - - [text](zh-cn/application-dev/js-reference/text.md) - - [toolbar](zh-cn/application-dev/js-reference/toolbar.md) - - [toolbar-item](zh-cn/application-dev/js-reference/toolbar-item.md) - - [toggle](zh-cn/application-dev/js-reference/toggle.md) - - [画布组件](zh-cn/application-dev/js-reference/画布组件.md) - - [canvas组件](zh-cn/application-dev/js-reference/canvas组件.md) - - [CanvasRenderingContext2D对象](zh-cn/application-dev/js-reference/CanvasRenderingContext2D对象.md) - - [Image对象](zh-cn/application-dev/js-reference/Image对象.md) - - [CanvasGradient对象](zh-cn/application-dev/js-reference/CanvasGradient对象.md) - - [ImageData对象](zh-cn/application-dev/js-reference/ImageData对象.md) - - [栅格组件\(Rich\)](zh-cn/application-dev/js-reference/栅格组件(Rich).md) - - [基本概念](zh-cn/application-dev/js-reference/基本概念.md) - - [grid-container](zh-cn/application-dev/js-reference/grid-container.md) - - [grid-row](zh-cn/application-dev/js-reference/grid-row.md) - - [grid-col](zh-cn/application-dev/js-reference/grid-col.md) - - [自定义组件](zh-cn/application-dev/js-reference/自定义组件.md) - - [基本用法](zh-cn/application-dev/js-reference/基本用法.md) - - [自定义事件](zh-cn/application-dev/js-reference/自定义事件.md) - - [Props](zh-cn/application-dev/js-reference/Props.md) - - [事件参数](zh-cn/application-dev/js-reference/事件参数.md) - - [组件通用说明](zh-cn/application-dev/js-reference/组件通用说明.md) - - [通用事件](zh-cn/application-dev/js-reference/通用事件.md) - - [通用属性](zh-cn/application-dev/js-reference/通用属性.md) - - [通用样式](zh-cn/application-dev/js-reference/通用样式.md) - - [接口](zh-cn/application-dev/js-reference/接口.md) - - [日志打印](zh-cn/application-dev/js-reference/日志打印.md) - - [应用打点](zh-cn/application-dev/js-reference/应用打点.md) - - [页面路由](zh-cn/application-dev/js-reference/页面路由.md) - - [弹窗](zh-cn/application-dev/js-reference/弹窗.md) - - [定时器](zh-cn/application-dev/js-reference/定时器.md) - - [时间设置](zh-cn/application-dev/js-reference/时间设置.md) - - [音频管理](zh-cn/application-dev/js-reference/音频管理.md) - - [音频播放](zh-cn/application-dev/js-reference/音频播放.md) - - [设备信息](zh-cn/application-dev/js-reference/设备信息.md) - - [系统属性](zh-cn/application-dev/js-reference/系统属性.md) - - [电池和充电属性](zh-cn/application-dev/js-reference/电池和充电属性.md) - - [设置系统屏幕亮度](zh-cn/application-dev/js-reference/设置系统屏幕亮度.md) - - [国际化](zh-cn/application-dev/js-reference/国际化.md) - - [资源管理](zh-cn/application-dev/js-reference/资源管理.md) - - [升级](zh-cn/application-dev/js-reference/升级.md) -## en - - -* [Introduction](en/readme.md) -- [OpenHarmony Overview](en/OpenHarmony-Overview.md) -- Devices Development - - [Source Code Acquisition](en/device-dev/get-code/Readme-EN.md) - - [Source Code Acquisition](en/device-dev/get-code/source-code-acquisition.md) - - [Acquiring Tools](en/device-dev/get-code/tool-acquisition.md) - - [Getting Started](en/device-dev/quick-start/Readme-EN.md) - - [Overview](en/device-dev/quick-start/overview.md) - - [Mini and Small Systems](en/device-dev/quick-start/mini-and-small-systems.md) - - [Overview](en/device-dev/quick-start/overview-0.md) - - [Introduction to the Development Boards](en/device-dev/quick-start/introduction-to-the-development-boards.md) - - [Hi3861 Development Board](en/device-dev/quick-start/hi3861-development-board.md) - - [Hi3516 Development Board](en/device-dev/quick-start/hi3516-development-board.md) - - [Hi3518 Development Board](en/device-dev/quick-start/hi3518-development-board.md) - - [Environment Setup](en/device-dev/quick-start/environment-setup.md) - - [Windows Development Environment](en/device-dev/quick-start/windows-development-environment.md) - - [Ubuntu Build Environment](en/device-dev/quick-start/ubuntu-build-environment.md) - - [FAQ](en/device-dev/quick-start/faq.md) - - [How to Develop](en/device-dev/quick-start/how-to-develop.md) - - [Hi3861](en/device-dev/quick-start/hi3861.md) - - [Setting Up the Environment](en/device-dev/quick-start/setting-up-the-environment.md) - - [WLAN Connection](en/device-dev/quick-start/wlan-connection.md) - - [Running a Hello World Program](en/device-dev/quick-start/running-a-hello-world-program.md) - - [FAQs](en/device-dev/quick-start/faqs.md) - - [Hi3516](en/device-dev/quick-start/hi3516.md) - - [Setting Up the Environment](en/device-dev/quick-start/setting-up-the-environment-1.md) - - [Running a Hello OHOS Program](en/device-dev/quick-start/running-a-hello-ohos-program.md) - - [Developing a Driver](en/device-dev/quick-start/developing-a-driver.md) - - [FAQs](en/device-dev/quick-start/faqs-2.md) - - [Hi3518](en/device-dev/quick-start/hi3518.md) - - [Setting Up the Environment](en/device-dev/quick-start/setting-up-the-environment-3.md) - - [Running a Hello OHOS Program](en/device-dev/quick-start/running-a-hello-ohos-program-4.md) - - [FAQs](en/device-dev/quick-start/faqs-5.md) - - [Standard System](en/device-dev/quick-start/standard-system.md) - - [Overview](en/device-dev/quick-start/overview-6.md) - - [Environment Setup](en/device-dev/quick-start/environment-setup-7.md) - - [Overview](en/device-dev/quick-start/overview-8.md) - - [Windows Development Environment](en/device-dev/quick-start/windows-development-environment-9.md) - - [Ubuntu Build Environment](en/device-dev/quick-start/ubuntu-build-environment-10.md) - - [FAQs](en/device-dev/quick-start/faqs-11.md) - - [How to Develop](en/device-dev/quick-start/how-to-develop-12.md) -- Usage Guidelines - - [Kernel](en/device-dev/kernel/Readme-EN.md) - - [Lite Kernel](en/device-dev/kernel/lite-kernel.md) - - [OpenHarmony Lite Kernel Basic Functions](en/device-dev/kernel/openharmony-lite-kernel-basic-functions.md) - - [Process](en/device-dev/kernel/process.md) - - [Thread](en/device-dev/kernel/thread.md) - - [Memory](en/device-dev/kernel/memory.md) - - [Network](en/device-dev/kernel/network.md) - - [OpenHarmony Lite Kernel File System](en/device-dev/kernel/openharmony-lite-kernel-file-system.md) - - [VFS](en/device-dev/kernel/vfs.md) - - [NFS](en/device-dev/kernel/nfs.md) - - [RAMFS](en/device-dev/kernel/ramfs.md) - - [FAT](en/device-dev/kernel/fat.md) - - [JFFS2](en/device-dev/kernel/jffs2.md) - - [Standard Library](en/device-dev/kernel/standard-library.md) - - [Standard Library](en/device-dev/kernel/standard-library-0.md) - - [Differences from the Linux Standard Library](en/device-dev/kernel/differences-from-the-linux-standard-library.md) - - [Commissioning](en/device-dev/kernel/commissioning.md) - - [Introduction to the Shell](en/device-dev/kernel/introduction-to-the-shell.md) - - [Shell Command Development Guidelines](en/device-dev/kernel/shell-command-development-guidelines.md) - - [Shell Command Programming Example](en/device-dev/kernel/shell-command-programming-example.md) - - [Shell Command Reference](en/device-dev/kernel/shell-command-reference.md) - - [System Commands](en/device-dev/kernel/system-commands.md) - - [cpup](en/device-dev/kernel/cpup.md) - - [date](en/device-dev/kernel/date.md) - - [dmesg](en/device-dev/kernel/dmesg.md) - - [exec](en/device-dev/kernel/exec.md) - - [free](en/device-dev/kernel/free.md) - - [help](en/device-dev/kernel/help.md) - - [hwi](en/device-dev/kernel/hwi.md) - - [kill](en/device-dev/kernel/kill.md) - - [log](en/device-dev/kernel/log.md) - - [memcheck](en/device-dev/kernel/memcheck.md) - - [oom](en/device-dev/kernel/oom.md) - - [pmm](en/device-dev/kernel/pmm.md) - - [reset](en/device-dev/kernel/reset.md) - - [sem](en/device-dev/kernel/sem.md) - - [stack](en/device-dev/kernel/stack.md) - - [su](en/device-dev/kernel/su.md) - - [swtmr](en/device-dev/kernel/swtmr.md) - - [systeminfo](en/device-dev/kernel/systeminfo.md) - - [task](en/device-dev/kernel/task.md) - - [uname](en/device-dev/kernel/uname.md) - - [vmm](en/device-dev/kernel/vmm.md) - - [watch](en/device-dev/kernel/watch.md) - - [File Commands](en/device-dev/kernel/file-commands.md) - - [cat](en/device-dev/kernel/cat.md) - - [cd](en/device-dev/kernel/cd.md) - - [chgrp](en/device-dev/kernel/chgrp.md) - - [chmod](en/device-dev/kernel/chmod.md) - - [chown](en/device-dev/kernel/chown.md) - - [cp](en/device-dev/kernel/cp.md) - - [format](en/device-dev/kernel/format.md) - - [ls](en/device-dev/kernel/ls.md) - - [lsfd](en/device-dev/kernel/lsfd.md) - - [mkdir](en/device-dev/kernel/mkdir.md) - - [mount](en/device-dev/kernel/mount.md) - - [partinfo](en/device-dev/kernel/partinfo.md) - - [partition](en/device-dev/kernel/partition.md) - - [pwd](en/device-dev/kernel/pwd.md) - - [rm](en/device-dev/kernel/rm.md) - - [rmdir](en/device-dev/kernel/rmdir.md) - - [statfs](en/device-dev/kernel/statfs.md) - - [sync](en/device-dev/kernel/sync.md) - - [touch](en/device-dev/kernel/touch.md) - - [writeproc](en/device-dev/kernel/writeproc.md) - - [umount](en/device-dev/kernel/umount.md) - - [Network Commands](en/device-dev/kernel/network-commands.md) - - [arp](en/device-dev/kernel/arp.md) - - [dhclient](en/device-dev/kernel/dhclient.md) - - [dns](en/device-dev/kernel/dns.md) - - [ifconfig](en/device-dev/kernel/ifconfig.md) - - [ipdebug](en/device-dev/kernel/ipdebug.md) - - [netstat](en/device-dev/kernel/netstat.md) - - [ntpdate](en/device-dev/kernel/ntpdate.md) - - [ping](en/device-dev/kernel/ping.md) - - [ping6](en/device-dev/kernel/ping6.md) - - [telnet](en/device-dev/kernel/telnet.md) - - [tftp](en/device-dev/kernel/tftp.md) - - [Magic Key Usage](en/device-dev/kernel/magic-key-usage.md) - - [User-Space Exception Information](en/device-dev/kernel/user-space-exception-information.md) - - [Linux Kernel](en/device-dev/kernel/linux-kernel.md) - - [Linux Kernel Overview](en/device-dev/kernel/linux-kernel-overview.md) - - [Guidelines for Using Patches on OpenHarmony Development Boards](en/device-dev/kernel/guidelines-for-using-patches-on-openharmony-development-boards.md) - - [Guidelines for Compiling and Building the Linux Kernel](en/device-dev/kernel/guidelines-for-compiling-and-building-the-linux-kernel.md) - -- [Drivers](en/device-dev/driver/Readme-EN.md) - - [HDF](en/device-dev/driver/hdf.md) - - [HDF Overview](en/device-dev/driver/hdfoverview.md) - - [Driver Development](en/device-dev/driver/driver-development.md) - - [Driver Service Management](en/device-dev/driver/driver-service-management.md) - - [Driver Message Mechanism Management](en/device-dev/driver/driver-message-mechanism-management.md) - - [Driver Configuration Management](en/device-dev/driver/driver-configuration-management.md) - - [HDF Development Example](en/device-dev/driver/hdfdevelopment-example.md) - - [Driver Platform](en/device-dev/driver/driver-platform.md) - - [GPIO](en/device-dev/driver/gpio.md) - - [GPIO Overview](en/device-dev/driver/gpiooverview.md) - - [GPIO Usage Guidelines](en/device-dev/driver/gpiousage-guidelines.md) - - [GPIO Usage Example](en/device-dev/driver/gpiousage-example.md) - - [I2C](en/device-dev/driver/i2c.md) - - [I2C Overview](en/device-dev/driver/i2c-overview.md) - - [I2C Usage Guidelines](en/device-dev/driver/i2c-usage-guidelines.md) - - [I2C Usage Example](en/device-dev/driver/i2c-usage-example.md) - - [RTC](en/device-dev/driver/rtc.md) - - [RTC Overview](en/device-dev/driver/rtc-overview.md) - - [RTC Usage Guidelines](en/device-dev/driver/rtc-usage-guidelines.md) - - [RTC Usage Example](en/device-dev/driver/rtc-usage-example.md) - - [SDIO](en/device-dev/driver/sdio.md) - - [SDIO Overview](en/device-dev/driver/sdiooverview.md) - - [SDIO Usage Guidelines](en/device-dev/driver/sdiousage-guidelines.md) - - [SDIO Usage Example](en/device-dev/driver/sdiousage-example.md) - - [SPI](en/device-dev/driver/spi.md) - - [SPI Overview](en/device-dev/driver/spioverview.md) - - [SPI Usage Guidelines](en/device-dev/driver/spiusage-guidelines.md) - - [SPI Usage Example](en/device-dev/driver/spiusage-example.md) - - [UART](en/device-dev/driver/uart.md) - - [UART Overview](en/device-dev/driver/uartoverview.md) - - [UART Usage Guidelines](en/device-dev/driver/uartusage-guidelines.md) - - [UART Usage Example](en/device-dev/driver/uartusage-example.md) - - [WATCHDOG](en/device-dev/driver/watchdog.md) - - [Watchdog Overview](en/device-dev/driver/watchdogoverview.md) - - [Watchdog Usage Guidelines](en/device-dev/driver/watchdogusage-guidelines.md) - - [Watchdog Usage Example](en/device-dev/driver/watchdogusage-example.md) - - [MIPI DSI](en/device-dev/driver/mipi-dsi.md) - - [MIPI DSI Overview](en/device-dev/driver/mipi-dsi-overview.md) - - [Usage Guidelines](en/device-dev/driver/usage-guidelines.md) - - [Usage Example](en/device-dev/driver/usage-example.md) - - [Peripherals](en/device-dev/driver/Readme-EN.md) - - [LCD](en/device-dev/driver/lcd.md) - - [LCD Overview](en/device-dev/driver/lcdoverview.md) - - [LCD Development Guidelines](en/device-dev/driver/lcddevelopment-guidelines.md) - - [LCD Development Example](en/device-dev/driver/lcddevelopment-example.md) - - [TOUCHSCREEN](en/device-dev/driver/touchscreen.md) - - [Touchscreen Overview](en/device-dev/driver/touchscreenoverview.md) - - [Touchscreen Development Guidelines](en/device-dev/driver/touchscreendevelopment-guidelines.md) - - [Touchscreen Development Example](en/device-dev/driver/touchscreendevelopment-example.md) - - [SENSOR](en/device-dev/driver/sensor.md) - - [Sensor Driver Overview](en/device-dev/driver/sensor-driver-overview.md) - - [Sensor Driver Development Guidelines](en/device-dev/driver/sensor-driver-development-guidelines.md) - - [Sensor Driver Development Example](en/device-dev/driver/sensor-driver-development-example.md) - - [Sensor Driver Test Guidelines](en/device-dev/driver/sensor-driver-test-guidelines.md) - - [WLAN](en/device-dev/driver/wlan.md) - - [WLAN Overview](en/device-dev/driver/wlanoverview.md) - - [WLAN Development Guidelines](en/device-dev/driver/wlandevelopment-guidelines.md) - - [WLAN Development Example](en/device-dev/driver/wlandevelopment-example.md) - - - [Subsystems](en/device-dev/subsystems/Readme-EN.md) - - [Compilation and Building](en/device-dev/subsystems/compilation-and-building.md) - - [Building Guidelines for Mini and Small Systems](en/device-dev/subsystems/building-guidelines-for-mini-and-small-systems.md) - - [Compilation and Building Overview](en/device-dev/subsystems/compilation-and-building-overview.md) - - [Compilation and Building Guidelines](en/device-dev/subsystems/compilation-and-building-guidelines.md) - - [Compilation and Building FAQ](en/device-dev/subsystems/compilation-and-building-faq.md) - - [Building Guidelines for the Standard System](en/device-dev/subsystems/building-guidelines-for-the-standard-system.md) - - [Compilation and Building Overview](en/device-dev/subsystems/compilation-and-building-overview-0.md) - - [Compilation and Building Guidelines](en/device-dev/subsystems/compilation-and-building-guidelines-1.md) - - - [Distributed Remote Startup](en/device-dev/subsystems/distributed-remote-startup.md) - - [Graphics](en/device-dev/subsystems/graphics.md) - - [Graphics](en/device-dev/subsystems/graphics-2.md) - - [Development Guidelines on Container Components](en/device-dev/subsystems/development-guidelines-on-container-components.md) - - [Development Guidelines on Layout Container Components](en/device-dev/subsystems/development-guidelines-on-layout-container-components.md) - - [Development Guidelines on Common Components](en/device-dev/subsystems/development-guidelines-on-common-components.md) - - [Development Guidelines on Animators](en/device-dev/subsystems/development-guidelines-on-animators.md) - - [Multimedia](en/device-dev/subsystems/multimedia.md) - - [Camera](en/device-dev/subsystems/camera.md) - - [Overview](en/device-dev/subsystems/overview.md) - - [Development Guidelines on Photographing](en/device-dev/subsystems/development-guidelines-on-photographing.md) - - [Development Guidelines on Video Recording](en/device-dev/subsystems/development-guidelines-on-video-recording.md) - - [Development Guidelines on Previewing](en/device-dev/subsystems/development-guidelines-on-previewing.md) - - [Audio/Video](en/device-dev/subsystems/audio-video.md) - - [Overview](en/device-dev/subsystems/overview-3.md) - - [Development Guidelines on Media Playback](en/device-dev/subsystems/development-guidelines-on-media-playback.md) - - [Development Guidelines on Media Recording](en/device-dev/subsystems/development-guidelines-on-media-recording.md) - - [Utils](en/device-dev/subsystems/utils.md) - - [Utils Overview](en/device-dev/subsystems/utils-overview.md) - - [Utils Development Guidelines](en/device-dev/subsystems/utils-development-guidelines.md) - - [Utils FAQ](en/device-dev/subsystems/utils-faq.md) - - [AI Framework](en/device-dev/subsystems/ai-framework.md) - - [AI Engine Framework](en/device-dev/subsystems/ai-engine-framework.md) - - [Development Environment](en/device-dev/subsystems/development-environment.md) - - [Technical Specifications](en/device-dev/subsystems/technical-specifications.md) - - [Code Management](en/device-dev/subsystems/code-management.md) - - [Naming](en/device-dev/subsystems/naming.md) - - [API Development](en/device-dev/subsystems/api-development.md) - - [Development Guidelines](en/device-dev/subsystems/development-guidelines.md) - - [SDK](en/device-dev/subsystems/sdk.md) - - [Plug-in](en/device-dev/subsystems/plug-in.md) - - [Configuration File](en/device-dev/subsystems/configuration-file.md) - - [Development Examples](en/device-dev/subsystems/development-examples.md) - - [KWS SDK](en/device-dev/subsystems/kws-sdk.md) - - [KWS Plug-in](en/device-dev/subsystems/kws-plug-in.md) - - [KWS Configuration File](en/device-dev/subsystems/kws-configuration-file.md) - - [Sensors](en/device-dev/subsystems/sensors.md) - - [Sensors Overview](en/device-dev/subsystems/sensors-overview.md) - - [Sensors Usage Guidelines](en/device-dev/subsystems/sensors-usage-guidelines.md) - - [Sensors Usage Example](en/device-dev/subsystems/sensors-usage-example.md) - - [Application Framework](en/device-dev/subsystems/application-framework.md) - - [Overview](en/device-dev/subsystems/overview-4.md) - - [Setting Up a Development Environment](en/device-dev/subsystems/setting-up-a-development-environment.md) - - [Development Guidelines](en/device-dev/subsystems/development-guidelines-5.md) - - [Development Example](en/device-dev/subsystems/development-example.md) - - [OTA Upgrade](en/device-dev/subsystems/ota-upgrade.md) - - [Security](en/device-dev/subsystems/security.md) - - [Overview](en/device-dev/subsystems/overview-9.md) - - [Development Guidelines on Application Signature Verification](en/device-dev/subsystems/development-guidelines-on-application-signature-verification.md) - - [Development Guidelines on Application Permission Management](en/device-dev/subsystems/development-guidelines-on-application-permission-management.md) - - [Development Guidelines on IPC Authentication](en/device-dev/subsystems/development-guidelines-on-ipc-authentication.md) - - [Development Guidelines on Trusted Device Group Management](en/device-dev/subsystems/development-guidelines-on-trusted-device-group-management.md) - - [Reference](en/device-dev/subsystems/reference.md) - - [Startup](en/device-dev/subsystems/startup.md) - - [Startup](en/device-dev/subsystems/startup-10.md) - - [init Module](en/device-dev/subsystems/init-module.md) - - [appspawn Module](en/device-dev/subsystems/appspawn-module.md) - - [bootstrap Module](en/device-dev/subsystems/bootstrap-module.md) - - [syspara Module](en/device-dev/subsystems/syspara-module.md) - - [FAQs](en/device-dev/subsystems/faqs.md) - - [Reference](en/device-dev/subsystems/reference.md) - - [Testing](en/device-dev/subsystems/testing.md) - - [DFX](en/device-dev/subsystems/dfx.md) - - [DFX](en/device-dev/subsystems/dfx-11.md) - - [Development Guidelines on HiLog ](en/device-dev/subsystems/development-guidelines-on-hilog.md) - - [Development Guidelines on HiLog\_Lite](en/device-dev/subsystems/development-guidelines-on-hilog_lite.md) - - [Development Guidelines on HiSysEvent](en/device-dev/subsystems/development-guidelines-on-hisysevent.md) - - [R&D Tools](en/device-dev/subsystems/r-d-tools.md) - - [bytrace Usage Guidelines](en/device-dev/subsystems/bytrace-usage-guidelines.md) - - [hdc std Usage Guidelines](en/device-dev/subsystems/hdc_std-usage-guidelines.md) - - [XTS](en/device-dev/subsystems/xts.md) - - [Privacy and Security](en/device-dev/security/Readme-EN.md) - - [Privacy Protection](en/device-dev/security/privacy-protection.md) - - [Security Guidelines](en/device-dev/security/security-guidelines.md) - - [Development Examples](en/device-dev/guide/Readme-EN.md) - - [WLAN-connected Products](en/device-dev/guide/wlan-connected-products.md) - - [LED Peripheral Control](en/device-dev/guide/led-peripheral-control.md) - - [Overview](en/device-dev/guide/overview.md) - - [Development](en/device-dev/guide/development.md) - - [Verification](en/device-dev/guide/verification.md) - - [Third-Party SDK Integration](en/device-dev/guide/third-party-sdk-integration.md) - - [Camera Control](en/device-dev/guide/camera-control.md) - - [Overview](en/device-dev/guide/overview-0.md) - - [Development Guidelines](en/device-dev/guide/development-guidelines.md) - - [Photographing](en/device-dev/guide/photographing.md) - - [Video Recording](en/device-dev/guide/video-recording.md) - - [Use Case](en/device-dev/guide/use-case.md) - - [Cameras with a Screen](en/device-dev/guide/cameras-with-a-screen.md) - - [Screen and Camera Control](en/device-dev/guide/screen-and-camera-control.md) - - [Overview](en/device-dev/guide/overview-1.md) - - [Development Guidelines](en/device-dev/guide/development-guidelines-2.md) - - [Photographing](en/device-dev/guide/photographing-3.md) - - [Video Recording](en/device-dev/guide/video-recording-4.md) - - [Previewing](en/device-dev/guide/previewing.md) - - [Use Case](en/device-dev/guide/use-case-5.md) - - [Visual Application Development](en/device-dev/guide/visual-application-development.md) - - [Overview](en/device-dev/guide/overview-6.md) - - [Preparations](en/device-dev/guide/preparations.md) - - [Adding Pages](en/device-dev/guide/adding-pages.md) - - [Building the Home Page](en/device-dev/guide/building-the-home-page.md) - - [Building the Details Page](en/device-dev/guide/building-the-details-page.md) - - [Debugging and Packaging](en/device-dev/guide/debugging-and-packaging.md) - - [Running on the Device](en/device-dev/guide/running-on-the-device.md) - - [FAQs](en/device-dev/guide/faqs.md) - - [Development Example for Clock Apps](en/device-dev/guide/development-example-for-clock-apps.md) - - [Overview](en/device-dev/guide/overview-7.md) - - [Preparations](en/device-dev/guide/preparations-8.md) - - [How to Develop](en/device-dev/guide/how-to-develop.md) - - [Signing and Packaging](en/device-dev/guide/signing-and-packaging.md) - - [Running on the Device](en/device-dev/guide/running-on-the-device-9.md) - - [Development Example for Platform Drivers](en/device-dev/guide/development-example-for-platform-drivers.md) - - [Overview](en/device-dev/guide/overview-10.md) - - [Preparations](en/device-dev/guide/preparations-11.md) - - [Development](en/device-dev/guide/development-12.md) - - [Building and Burning](en/device-dev/guide/building-and-burning.md) - - [Development Example for Peripheral Drivers](en/device-dev/guide/development-example-for-peripheral-drivers.md) - - [Overview](en/device-dev/guide/overview-13.md) - - [Hardware Resources](en/device-dev/guide/hardware-resources.md) - - [Input Driver Model](en/device-dev/guide/input-driver-model.md) - - [Setting Up the Environment](en/device-dev/guide/setting-up-the-environment.md) - - [Developing a Touchscreen Driver](en/device-dev/guide/developing-a-touchscreen-driver.md) - - [Configuring Device Driver Descriptions](en/device-dev/guide/configuring-device-driver-descriptions.md) - - [Configuring the Touchscreen](en/device-dev/guide/configuring-the-touchscreen.md) - - [Adapting to the Private Drivers of the Touchscreen](en/device-dev/guide/adapting-to-the-private-drivers-of-the-touchscreen.md) - - [Building and Burning](en/device-dev/guide/building-and-burning-14.md) - - [Debugging and Verification](en/device-dev/guide/debugging-and-verification.md) - - [Startup Log Analysis](en/device-dev/guide/startup-log-analysis.md) - - [Input Driver Model Workflow Analysis](en/device-dev/guide/input-driver-model-workflow-analysis.md) - - [Parsing Private Configuration Data](en/device-dev/guide/parsing-private-configuration-data.md) - - [Initializing the Input Device Manager and Registering the Driver with the HDF](en/device-dev/guide/initializing-the-input-device-manager-and-registering-the-driver-with-the-hdf.md) - - [Initializing the Input Common Driver and Registering the Driver with the HDF](en/device-dev/guide/initializing-the-input-common-driver-and-registering-the-driver-with-the-hdf.md) - - [Initializing the Input Chip Driver and Registering the Driver with the HDF](en/device-dev/guide/initializing-the-input-chip-driver-and-registering-the-driver-with-the-hdf.md) - - [Function Invocation Logic](en/device-dev/guide/function-invocation-logic.md) - - [Porting Guide](en/device-dev/porting/Readme-EN.md) - - [Third-Party Library Porting Guide](en/device-dev/porting/third-party-library-porting-guide.md) - - [Overview](en/device-dev/porting/overview.md) - - [Porting a Library Built Using CMake](en/device-dev/porting/porting-a-library-built-using-cmake.md) - - [Porting a Library Built Using Makefile](en/device-dev/porting/porting-a-library-built-using-makefile.md) - - [Third-Party SoC Porting Guide](en/device-dev/porting/third-party-soc-porting-guide.md) - - [Porting Preparations](en/device-dev/porting/porting-preparations.md) - - [Before You Start](en/device-dev/porting/before-you-start.md) - - [Building Adaptation Process](en/device-dev/porting/building-adaptation-process.md) - - [Kernel Porting](en/device-dev/porting/kernel-porting.md) - - [Overview](en/device-dev/porting/overview-0.md) - - [Basic Kernel Adaptation](en/device-dev/porting/basic-kernel-adaptation.md) - - [Kernel Porting Verification](en/device-dev/porting/kernel-porting-verification.md) - - [Board-Level OS Porting](en/device-dev/porting/board-level-os-porting.md) - - [Overview](en/device-dev/porting/overview-1.md) - - [Board-Level Driver Adaptation](en/device-dev/porting/board-level-driver-adaptation.md) - - [Implementation of APIs at the HAL](en/device-dev/porting/implementation-of-apis-at-the-hal.md) - - [System Modules](en/device-dev/porting/system-modules.md) - - [XTS](en/device-dev/porting/xts.md) - - [FAQ](en/device-dev/porting/faq.md) - - [Bundle Development](en/device-dev/bundles/Readme-EN.md) - - [Development Specifications](en/device-dev/bundles/development-specifications.md) - - [Overview](en/device-dev/bundles/overview.md) - - [Bundle Composition](en/device-dev/bundles/bundle-composition.md) - - [Bundle Management](en/device-dev/bundles/bundle-management.md) - - [Bundle Version](en/device-dev/bundles/bundle-version.md) - - [Distribution](en/device-dev/bundles/distribution.md) - - [Environment Variables](en/device-dev/bundles/environment-variables.md) - - [Development Guidelines](en/device-dev/bundles/development-guidelines.md) - - [Overview](en/device-dev/bundles/overview-0.md) - - [Preparations](en/device-dev/bundles/preparations.md) - - [Bundle Development](en/device-dev/bundles/bundle-development.md) - - [HPM User Guide](en/device-dev/bundles/hpm-user-guide.md) - - [Introduction](en/device-dev/bundles/introduction.md) - - [Preparations](en/device-dev/bundles/preparations-1.md) - - [Development Example](en/device-dev/bundles/development-example.md) - - [Glossary](en/device-dev/glossary/glossary.md) - -- Application Development - - [DevEco Studio \(OpenHarmony\) User Guide](en/application-dev/quick-start/deveco-studio-(openharmony)-user-guide.md) - - [Overview](en/application-dev/quick-start/overview.md) - - [Configuring the OpenHarmony SDK](en/application-dev/quick-start/configuring-the-openharmony-sdk.md) - - [Configuring the OpenHarmony App Signature](en/application-dev/quick-start/configuring-the-openharmony-app-signature.md) -- [Installing and Running Your OpenHarmony App](en/application-dev/quick-start/installing-and-running-your-openharmony-app.md) - - [Basics ](en/application-dev/quick-start/Readme-EN.md) - - [Getting Started](en/application-dev/quick-start/getting-started.md) - - [Preparations](en/application-dev/quick-start/preparations.md) - - [Getting Started with JavaScript](en/application-dev/quick-start/getting-started-with-javascript.md) - - [UI](en/application-dev/ui/Readme-EN.md) - - [JS UI Framework](en/application-dev/ui/js-ui-framework.md) - - [JS UI Framework Overview](en/application-dev/ui/js-ui-framework-overview.md) - - [Building the UI](en/application-dev/ui/building-the-ui.md) - - [Component Overview](en/application-dev/ui/component-overview.md) - - [Building the Layout](en/application-dev/ui/building-the-layout.md) - - [Layout Description](en/application-dev/ui/layout-description.md) - - [Adding Title and Paragraph Text](en/application-dev/ui/adding-title-and-paragraph-text.md) - - [Adding an Image](en/application-dev/ui/adding-an-image.md) - - [Adding a Comment](en/application-dev/ui/adding-a-comment.md) - - [Adding a Container](en/application-dev/ui/adding-a-container.md) - - [Adding Interactions](en/application-dev/ui/adding-interactions.md) - - [Animation](en/application-dev/ui/animation.md) - - [Event](en/application-dev/ui/event.md) - - [Defining Page Routes](en/application-dev/ui/defining-page-routes.md) - - [Custom Components](en/application-dev/ui/custom-components.md) - - [Media](en/application-dev/media/Readme-EN.md) - - [Audio](en/application-dev/media/audio.md) - - [Audio Overview](en/application-dev/media/audio-overview.md) - - [Development Guidelines on Audio Playback](en/application-dev/media/development-guidelines-on-audio-playback.md) - - [Development Guidelines on Audio Management](en/application-dev/media/development-guidelines-on-audio-management.md) - - [Connectivity](en/application-dev/connectivity/Readme-EN.md) - - [IPC & RPC](en/application-dev/connectivity/ipc-rpc.md) - - [IPC & RPC Overview](en/application-dev/connectivity/ipc-rpc-overview.md) - - [IPC & RPC Development Guidelines](en/application-dev/connectivity/ipc-rpc-development-guidelines.md) - - [Subscribing to State Changes of a Remote Object](en/application-dev/connectivity/subscribing-to-state-changes-of-a-remote-object.md) - - [JS Reference](en/application-dev/js-reference/Readme-EN.md) - - - [Framework](en/application-dev/js-reference/framework.md) - - [File Organization](en/application-dev/js-reference/file-organization.md) - - ["js" Tag](en/application-dev/js-reference/js-tag.md) - - [app.js](en/application-dev/js-reference/app-js.md) - - [Syntax](en/application-dev/js-reference/syntax.md) - - [HML](en/application-dev/js-reference/hml.md) - - [CSS](en/application-dev/js-reference/css.md) - - [JavaScript](en/application-dev/js-reference/javascript.md) - - [Loading Images Based on DPI](en/application-dev/js-reference/loading-images-based-on-dpi.md) - - [Components](en/application-dev/js-reference/components.md) - - [Common](en/application-dev/js-reference/common.md) - - [Component Methods](en/application-dev/js-reference/component-methods.md) - - [Animation Styles](en/application-dev/js-reference/animation-styles.md) - - [Gradient Styles](en/application-dev/js-reference/gradient-styles.md) - - [Transition Styles](en/application-dev/js-reference/transition-styles.md) - - [Custom Font Styles](en/application-dev/js-reference/custom-font-styles.md) - - [Atomic Layout](en/application-dev/js-reference/atomic-layout.md) - - [Container Components](en/application-dev/js-reference/container-components.md) - - [badge](en/application-dev/js-reference/badge.md) - - [dialog](en/application-dev/js-reference/dialog.md) - - [div](en/application-dev/js-reference/div.md) - - [list](en/application-dev/js-reference/list.md) - - [list-item](en/application-dev/js-reference/list-item.md) - - [list-item-group](en/application-dev/js-reference/list-item-group.md) - - [panel](en/application-dev/js-reference/panel.md) - - [popup](en/application-dev/js-reference/popup.md) - - [refresh](en/application-dev/js-reference/refresh.md) - - [stack](en/application-dev/js-reference/stack.md) - - [stepper](en/application-dev/js-reference/stepper.md) - - [stepper-item](en/application-dev/js-reference/stepper-item.md) - - [swiper](en/application-dev/js-reference/swiper.md) - - [tabs](en/application-dev/js-reference/tabs.md) - - [tab-bar](en/application-dev/js-reference/tab-bar.md) - - [tab-content](en/application-dev/js-reference/tab-content.md) - - [Basic Components](en/application-dev/js-reference/basic-components.md) - - [button](en/application-dev/js-reference/button.md) - - [chart](en/application-dev/js-reference/chart.md) - - [divider](en/application-dev/js-reference/divider.md) - - [image](en/application-dev/js-reference/image.md) - - [image-animator](en/application-dev/js-reference/image-animator.md) - - [input](en/application-dev/js-reference/input.md) - - [label](en/application-dev/js-reference/label.md) - - [marquee](en/application-dev/js-reference/marquee.md) - - [menu](en/application-dev/js-reference/menu.md) - - [option](en/application-dev/js-reference/option.md) - - [picker](en/application-dev/js-reference/picker.md) - - [picker-view](en/application-dev/js-reference/picker-view.md) - - [piece](en/application-dev/js-reference/piece.md) - - [progress](en/application-dev/js-reference/progress.md) - - [qrcode](en/application-dev/js-reference/qrcode.md) - - [rating](en/application-dev/js-reference/rating.md) - - [search](en/application-dev/js-reference/search.md) - - [select](en/application-dev/js-reference/select.md) - - [slider](en/application-dev/js-reference/slider.md) - - [span](en/application-dev/js-reference/span.md) - - [switch](en/application-dev/js-reference/switch.md) - - [text](en/application-dev/js-reference/text.md) - - [textarea](en/application-dev/js-reference/textarea.md) - - [toolbar](en/application-dev/js-reference/toolbar.md) - - [toolbar-item](en/application-dev/js-reference/toolbar-item.md) - - [toggle](en/application-dev/js-reference/toggle.md) - - [Canvas Components](en/application-dev/js-reference/canvas-components.md) - - [canvas](en/application-dev/js-reference/canvas.md) - - [CanvasRenderingContext2D](en/application-dev/js-reference/canvasrenderingcontext2d.md) - - [Image](en/application-dev/js-reference/image-0.md) - - [CanvasGradient](en/application-dev/js-reference/canvasgradient.md) - - [ImageData](en/application-dev/js-reference/imagedata.md) - - [Grid Components](en/application-dev/js-reference/grid-components.md) - - [Basic Concepts](en/application-dev/js-reference/basic-concepts.md) - - [grid-container](en/application-dev/js-reference/grid-container.md) - - [grid-row](en/application-dev/js-reference/grid-row.md) - - [grid-col](en/application-dev/js-reference/grid-col.md) - - [Custom Components](en/application-dev/js-reference/custom-components.md) - - [Basic Usage](en/application-dev/js-reference/basic-usage.md) - - [Custom Events](en/application-dev/js-reference/custom-events.md) - - [Props](en/application-dev/js-reference/props.md) - - [Event Parameter](en/application-dev/js-reference/event-parameter.md) - - [Universal Description](en/application-dev/js-reference/universal-description.md) - - [Universal Events](en/application-dev/js-reference/universal-events.md) - - [Universal Attributes](en/application-dev/js-reference/universal-attributes.md) - - [Common Styles](en/application-dev/js-reference/common-styles.md) - - [APIs](en/application-dev/js-reference/apis.md) - - [Console Logs](en/application-dev/js-reference/console-logs.md) - - [HiAppEvent](en/application-dev/js-reference/hiappevent.md) - - [Page Routing](en/application-dev/js-reference/page-routing.md) - - [Pop-up Window](en/application-dev/js-reference/pop-up-window.md) - - [Timer](en/application-dev/js-reference/timer.md) - - [Audio Management](en/application-dev/js-reference/audio-management.md) - - [Audio Playback](en/application-dev/js-reference/audio-playback.md) - - [Device Information](en/application-dev/js-reference/device-information.md) - - [System Attribute](en/application-dev/js-reference/system-attribute.md) - - [Battery and Charging](en/application-dev/js-reference/battery-and-charging.md) - - [Screen Brightness](en/application-dev/js-reference/screen-brightness.md) - - [Globalization](en/application-dev/js-reference/globalization.md) - - [Resource Management](en/application-dev/js-reference/resource-management.md) - - [Updater](en/application-dev/js-reference/updater.md) diff --git a/zh-cn/device-dev/Readme-CN.md b/zh-cn/device-dev/Readme-CN.md index ed7400033a76533a8ebc1e89958475bf7ebbb869..d755ec5d943dc61262fbdafb0fc071b5aa138ae7 100644 --- a/zh-cn/device-dev/Readme-CN.md +++ b/zh-cn/device-dev/Readme-CN.md @@ -69,21 +69,21 @@ OpenHarmony也提供了一系列可选的系统组件,方便设备开发者按

使用OpenHarmony提供的基础能力

+

进阶开发

结合系统能力开发智能设备

+

移植适配

  • 针对特定芯片做移植适配
  • 对三方库进行移植适配
+

贡献Bundle

@@ -139,7 +139,7 @@ OpenHarmony也提供了一系列可选的系统组件,方便设备开发者按

使用OpenHarmony提供的基础能力

+

进阶开发

@@ -153,7 +153,7 @@ OpenHarmony也提供了一系列可选的系统组件,方便设备开发者按

对三方库进行移植适配

+

贡献Bundle

diff --git a/zh-cn/device-dev/bundles/bundles-demo-hpmdescription.md b/zh-cn/device-dev/bundles/bundles-demo-hpmdescription.md index d86b3bac4180c71072a26584f5159a63c1819722..fb91db510fbd8771d117a8d6a37d2e99d42fe846 100644 --- a/zh-cn/device-dev/bundles/bundles-demo-hpmdescription.md +++ b/zh-cn/device-dev/bundles/bundles-demo-hpmdescription.md @@ -1,4 +1,4 @@ # HPM介绍 -HPM是OpenHarmony Bundle的管理和分发工具。HPM主要是面向OpenHarmony开发者,用于获取/定制OpenHarmony源码,执行安装依赖、编译、打包、升级等操作的工具集。本文档将向开发者介绍如何使用HPM工具进行OpenHarmonyBundle的安装、编译、打包等操作。 +HPM全称HarmonyOS Package Manager,是OpenHarmonyBundle的管理和分发工具。HPM主要是面向OpenHarmony开发者,用于获取/定制OpenHarmony源码,执行安装依赖、编译、打包、升级等操作的工具集。本文档将向开发者介绍如何使用HPM工具进行OpenHarmonyBundle的安装、编译、打包等操作。 diff --git a/zh-cn/device-dev/bundles/bundles.md b/zh-cn/device-dev/bundles/bundles.md index 2df2bea589116963c0773237af6d3ff633fc0622..3b1f56198ecf57d112ead07cb544052afbf4abb5 100644 --- a/zh-cn/device-dev/bundles/bundles.md +++ b/zh-cn/device-dev/bundles/bundles.md @@ -1,6 +1,6 @@ # HPM bundle -- **[组件开发规范](oem_bundle_standard_des.md)** +- **[开发规范](oem_bundle_standard_des.md)** - **[开发指南](bundles-guide.md)** diff --git a/zh-cn/device-dev/driver/driver-hdf-development.md b/zh-cn/device-dev/driver/driver-hdf-development.md index 492abc6c66f47310c998d216acf5409cad6ee775..60f3a0918908d3b8d2598926f3a8c142d196ca34 100644 --- a/zh-cn/device-dev/driver/driver-hdf-development.md +++ b/zh-cn/device-dev/driver/driver-hdf-development.md @@ -66,7 +66,6 @@ HDF框架以组件化的驱动模型作为核心设计思路,为开发者提 HDF_INIT(g_sampleDriverEntry); ``` - 2. 驱动编译 - 驱动代码的编译必须要使用HDF框架提供的Makefile模板进行编译。 @@ -86,7 +85,6 @@ HDF框架以组件化的驱动模型作为核心设计思路,为开发者提 LIB_SUBDIRS += #驱动代码Makefile的目录 ``` - 3. 驱动配置 HDF使用HCS作为配置描述源码,HCS详细介绍参考[配置管理](driver-hdf-manage.md)介绍。 diff --git a/zh-cn/device-dev/driver/driver-hdf.md b/zh-cn/device-dev/driver/driver-hdf.md new file mode 100644 index 0000000000000000000000000000000000000000..8c8cb3c3482f81e23937cc64408f039989db86f3 --- /dev/null +++ b/zh-cn/device-dev/driver/driver-hdf.md @@ -0,0 +1,15 @@ +# HDF驱动框架 + +- **[HDF开发概述](driver-hdf-overview.md)** + +- **[驱动开发](driver-hdf-development.md)** + +- **[驱动服务管理](driver-hdf-servicemanage.md)** + +- **[驱动消息机制管理](driver-hdf-news.md)** + +- **[配置管理](driver-hdf-manage.md)** + +- **[HDF开发实例](driver-hdf-sample.md)** + + diff --git a/zh-cn/device-dev/driver/driver-peripherals-lcd-des.md b/zh-cn/device-dev/driver/driver-peripherals-lcd-des.md index 90f54e12fbaa67eab88e46ecb651c4f7fb4bb7d1..95b1bfb103250a7e3e7f4d0a0af69c1a62b10dfd 100644 --- a/zh-cn/device-dev/driver/driver-peripherals-lcd-des.md +++ b/zh-cn/device-dev/driver/driver-peripherals-lcd-des.md @@ -66,7 +66,6 @@ Display驱动模型基于HDF驱动框架、Platform接口及OSAL接口开发, 根据LCD硬件接口,使用Platform接口层提供的I2C、SPI、MIPI等接口,下载LCD初始化序列,初始化参数序列可以参考LCD供应商提供的SPEC。 - 4. 根据需求实现HDF框架其他接口,比如Release接口。 5. 根据需求使用HDF框架可创建其他设备节点,用于业务逻辑或者调试功能。 diff --git a/zh-cn/device-dev/driver/driver-peripherals-touch-des.md b/zh-cn/device-dev/driver/driver-peripherals-touch-des.md index 5f4c46ba8ba7880cc11846b81f618167626bc455..d2e35a9c8822e87d3a8bbdec7be37f0994ca72d8 100644 --- a/zh-cn/device-dev/driver/driver-peripherals-touch-des.md +++ b/zh-cn/device-dev/driver/driver-peripherals-touch-des.md @@ -68,14 +68,13 @@ Touchscreen器件的硬件接口相对简单,根据PIN脚的属性,可以简 通常情况下,touchscreen驱动IC和LCD驱动IC是相互分离的,这种情况下,touchscreen驱动IC一般同时需要1.8v和3.3v两路供电。随着芯片演进,业内已有touchscreen驱动IC和LCD驱动IC集成在一颗IC中的芯片案例,对touchscreen而言,只需要关注1.8v供电即可,其内部需要的3.3v电源,会在驱动IC内部从LCD的VSP电源(典型值5.5V)中分出来。 - 2. **IO控制接口** - Reset:reset管脚,用于在系统休眠、唤醒时,由主机侧对驱动IC进行复位操作。 - INT:中断管脚,需要在驱动初始化时,配置为输入上拉状态。在驱动IC检测到外部触摸信号后,通过操作中断管脚来触发中断,器件驱动则会在中断处理函数中进行报点数据读取等操作。 3. **通信接口** - - I2C:由于touchscreen的报点数据量相对较少,所以一般选用I2C方式传输数据。I2C的具体协议及对应操作接口,可以参考Platform接口层中的[“I2C”使用指南](drive-platform-i2c-des.md#section1695201514281)。 - - SPI:部分厂商,由于需要传递的数据不止报点坐标,而是需要获取基础容值,数据量较大,所以会选用SPI通信方式。SPI的具体协议及对应操作接口,可以参考Platform接口层中的[“SPI” 使用指南](drive-platform-spi-des.md#section71363452477)。 + - I2C:由于touchscreen的报点数据量相对较少,所以一般选用I2C方式传输数据。I2C的具体协议及对应操作接口,可以参考Platform接口层中的[“I2C”使用指南](driver-platform-i2c-des.md#section1695201514281)。 + - SPI:部分厂商,由于需要传递的数据不止报点坐标,而是需要获取基础容值,数据量较大,所以会选用SPI通信方式。SPI的具体协议及对应操作接口,可以参考Platform接口层中的[“SPI” 使用指南](driver-platform-spi-des.md#section71363452477)。 ## 开发指导 @@ -109,7 +108,7 @@ Input驱动模型是基于HDF框架、Platform接口和OSAL接口开发,不区 3. 实现器件差异化适配接口 - 根据硬件单板设计的通信接口,使用Platform接口层提供的管脚操作接口配置对应的复位管脚、中断管脚以及电源操作,对于GPIO的操作,可参考[GPIO操作接口指导](drive-platform-gpio-des.md#section259614242196) + 根据硬件单板设计的通信接口,使用Platform接口层提供的管脚操作接口配置对应的复位管脚、中断管脚以及电源操作,对于GPIO的操作,可参考[GPIO操作接口指导](driver-platform-gpio-des.md#section259614242196) ## 开发实例 diff --git a/zh-cn/device-dev/driver/driver-platform-i2c-des.md b/zh-cn/device-dev/driver/driver-platform-i2c-des.md index 915c5f440eeb70bb1ebff2640306885b272c33e9..ec00c3728c1015b057c0424337e80e1fa350ffe2 100644 --- a/zh-cn/device-dev/driver/driver-platform-i2c-des.md +++ b/zh-cn/device-dev/driver/driver-platform-i2c-des.md @@ -405,7 +405,7 @@ static int32_t TestCaseI2c(void) } OsalMSleep(10); - /* 从TP-IC的0xDO寄存器连续读7字节数据 */ + /* 从TP-IC的0xD5寄存器连续读7字节数据 */ ret = TpI2cReadReg(&tpDevice, 0xD5, bufRead, 7); if (ret != HDF_SUCCESS) { HDF_LOGE("%s: tp i2c read reg fail!:%d", __func__, ret); diff --git a/zh-cn/device-dev/driver/driver-platform-spi-des.md b/zh-cn/device-dev/driver/driver-platform-spi-des.md index 47581f9a40529bf796a1b544cb059d6e8032ff54..b903ae469fc1ff91ea3a0bf0ad2713ea20e0de09 100644 --- a/zh-cn/device-dev/driver/driver-platform-spi-des.md +++ b/zh-cn/device-dev/driver/driver-platform-spi-des.md @@ -224,7 +224,7 @@ int32\_t SpiGetCfg\(DevHandle handle, struct SpiCfg \*cfg\); ``` int32_t ret; struct SpiCfg cfg = {0}; /* SPI配置信息*/ -ret = SpiGetCfg(spiHandle, &cfg); /* 配置SPI设备属性 */ +ret = SpiGetCfg(spiHandle, &cfg); /* 获取SPI设备属性 */ if (ret != 0) { HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret); } diff --git a/zh-cn/device-dev/driver/driver.md b/zh-cn/device-dev/driver/driver.md index a0825c12d1ed8456318aca70316eaf6500251dab..58ee5fe7bc877da89acf3d2c7a5f08d2fd2f0a69 100644 --- a/zh-cn/device-dev/driver/driver.md +++ b/zh-cn/device-dev/driver/driver.md @@ -1,16 +1,6 @@ # 驱动使用指南 -- **[HDF开发概述](driver-hdf-overview.md)** - -- **[驱动开发](driver-hdf-development.md)** - -- **[驱动服务管理](driver-hdf-servicemanage.md)** - -- **[驱动消息机制管理](driver-hdf-news.md)** - -- **[配置管理](driver-hdf-manage.md)** - -- **[HDF开发实例](driver-hdf-sample.md)** +- **[HDF驱动框架](driver-hdf.md)** - **[平台驱动](driver-platform.md)** diff --git a/zh-cn/device-dev/get-code/figure/3-20.png b/zh-cn/device-dev/get-code/figure/3-28.png similarity index 100% rename from zh-cn/device-dev/get-code/figure/3-20.png rename to zh-cn/device-dev/get-code/figure/3-28.png diff --git a/zh-cn/device-dev/get-code/gettools-acquire.md b/zh-cn/device-dev/get-code/gettools-acquire.md index e10ba6af345e93c6a3360298bf7ed99334c4df49..f18b6c2ce05b5d27d95ef2132f181c9a3fa3d8ad 100644 --- a/zh-cn/device-dev/get-code/gettools-acquire.md +++ b/zh-cn/device-dev/get-code/gettools-acquire.md @@ -52,7 +52,7 @@ OpenHarmony为开发者提供了两种Docker环境,以帮助开发者快速完

swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard

0.0.1

+

0.0.2

HPM Docker环境

@@ -287,9 +287,8 @@ docker\_dist是一个[HPM](https://hpm.harmonyos.com/)系统中的模板组件 hpm run docker ``` - 以上两种方式以@ohos/hispark\_taurus为例,执行成功结果如下: - + ``` ...... ohos ipcamera_hispark_taurus build success! diff --git a/zh-cn/device-dev/get-code/gettools-ide.md b/zh-cn/device-dev/get-code/gettools-ide.md index 8217ddc1222045e4633d5cd05289e20169ce90e4..31f93558449c20b4133c964d9dfe576b042a9935 100644 --- a/zh-cn/device-dev/get-code/gettools-ide.md +++ b/zh-cn/device-dev/get-code/gettools-ide.md @@ -9,7 +9,7 @@ HUAWEI DevEco Device Tool是OpenHarmony面向智能设备开发者提供的一 Huawei DevEco Device Tool支持 OpenHarmony设备开发的演进路标如下: -![](figure/3-20.png) +![](figure/3-28.png) ## 获取应用开发工具(HUAWEI DevEco Studio) diff --git a/zh-cn/device-dev/get-code/sourcecode-acquire.md b/zh-cn/device-dev/get-code/sourcecode-acquire.md index 6892d7be6026ddd3c4ee9e2b6707aadb27a7711c..34ec29314c3517c8f4e75c78fce8161fc835e003 100644 --- a/zh-cn/device-dev/get-code/sourcecode-acquire.md +++ b/zh-cn/device-dev/get-code/sourcecode-acquire.md @@ -21,9 +21,6 @@ OpenHarmony是由开放原子开源基金会(OpenAtom Foundation)孵化及 开源代码仓库地址:[https://openharmony.gitee.com](https://openharmony.gitee.com) ->![](../public_sys-resources/icon-note.gif) **说明:** ->当前的OpenHarmony源代码仅支持在Linux环境下编译。 - ## 源码获取概述 本文档将介绍如何获取OpenHarmony源码并说明OpenHarmony的源码目录结构。OpenHarmony的代码以[组件](../bundles/oem_bundle_standard_des.md)的形式开放,开发者可以通过如下其中一种方式获取: @@ -159,7 +156,6 @@ OpenHarmony是由开放原子开源基金会(OpenAtom Foundation)孵化及 ![](figure/zh-cn_image_0000001119915556.png) - 2. 了解发行版详情。 1. 仔细阅读发行版的说明信息,以了解使用场景、特性、组件构成、使用方法以及如何进行定制化,如下图所示。 @@ -182,7 +178,6 @@ OpenHarmony是由开放原子开源基金会(OpenAtom Foundation)孵化及 ![](figure/zh-cn_image_0000001166715379.png) - 4. 下载安装组件。 1. 解压下载的压缩文件,用命令行工具CMD(Linux下的Shell终端) 2. 在解压后的文件目录下执行hpm install指令 diff --git a/zh-cn/device-dev/glossary/glossary.md b/zh-cn/device-dev/glossary/glossary.md old mode 100755 new mode 100644 diff --git a/zh-cn/device-dev/guide/Readme-CN.md b/zh-cn/device-dev/guide/Readme-CN.md index aa2470b29a038a4c9b924c787a6cb564b5c97abb..ce9d01e0c1e707e51ead27f2c25026118818f59e 100755 --- a/zh-cn/device-dev/guide/Readme-CN.md +++ b/zh-cn/device-dev/guide/Readme-CN.md @@ -1,39 +1,34 @@ # 设备开发指南 -- [WLAN连接类产品](device-wifi.md) - - [LED外设控制](device-wifi-led-outcontrol.md) - - [集成三方SDK](device-wifi-sdk.md) - -- [无屏摄像头类产品](device-iotcamera.md) - - [概述](device-iotcamera-control-overview.md) - - [示例开发](device-iotcamera-control-demo.md) - - [拍照开发指导](device-iotcamera-control-demo-photodevguide.md) - - [录像开发指导](device-iotcamera-control-demo-videodevguide.md) - - - [应用实例](device-iotcamera-control-example.md) - -- [带屏摄像头类产品](device-camera.md) - - [屏幕和摄像头控制](device-camera-control.md) - - [概述](device-camera-control-overview.md) - - [示例开发](device-camera-control-demo.md) - - [拍照开发指导](device-camera-control-demo-photoguide.md) - - [录像开发指导](device-camera-control-demo-videoguide.md) - - [预览开发指导](device-camera-control-demo-previewguide.md) - - - [应用实例](device-camera-control-example.md) - - - [视觉应用开发](device-camera-visual.md) - - [概述](device-camera-visual-overview.md) - - [开发准备](device-camera-visual-prepare.md) - - [添加页面](device-camera-visual-addpage.md) - - [开发首页](device-camera-visual-first-page.md) - - [开发详情页](device-camera-visual-details.md) - - [调试打包](device-camera-visual-debug.md) - - [真机运行](device-camera-visual-run.md) - - [常见问题](device-camera-visual-faqs.md) - -- [时钟应用开发指导](device-clock-guide.md) -- [平台驱动开发示例](device-driver-demo.md) -- [外设驱动开发示例](device-outerdriver-demo.md) - - +- [轻量和小型系统设备](device-lite.md) + - [WLAN连接类产品](device-wlan.md) + - [LED外设控制](oem_wifi_sdk_des.md) + - [集成三方SDK](device-wlan-sdk.md) + - [无屏摄像头类产品](device-iotcamera.md) + - [摄像头控制](device-iotcamera-control.md) + - [概述](device-iotcamera-control-overview.md) + - [示例开发](device-iotcamera-control-demo.md) + - [拍照开发指导](device-iotcamera-control-demo-photodevguide.md) + - [录像开发指导](device-iotcamera-control-demo-videodevguide.md) + - [应用实例](device-iotcamera-control-example.md) + - [带屏摄像头类产品](device-camera.md) + - [屏幕和摄像头控制](device-camera-control.md) + - [概述](device-camera-control-overview.md) + - [示例开发](device-camera-control-demo.md) + - [拍照开发指导](device-camera-control-demo-photoguide.md) + - [录像开发指导](device-camera-control-demo-videoguide.md) + - [预览开发指导](device-camera-control-demo-previewguide.md) + - [应用实例](device-camera-control-example.md) + - [视觉应用开发](device-camera-visual.md) + - [概述](device-camera-visual-overview.md) + - [开发准备](device-camera-visual-prepare.md) + - [添加页面](device-camera-visual-addpage.md) + - [开发首页](device-camera-visual-firstpage.md) + - [开发详情页](device-camera-visual-details.md) + - [调试打包](device-camera-visual-debug.md) + - [真机运行](device-camera-visual-run.md) + - [常见问题](device-camera-visual-faqs.md) +- [标准系统设备](device-standard.md) + - [时钟应用开发指导](device-clock-guide.md) + - [平台驱动开发示例](device-driver-demo.md) + - [外设驱动开发示例](device-outerdriver-demo.md) \ No newline at end of file diff --git a/zh-cn/device-dev/guide/device-camera-control-example.md b/zh-cn/device-dev/guide/device-camera-control-example.md index a092908acd9e92234b09634c4cdef1cf1a3d3c94..b6d605b04e649928de22fc84d90d947128c5dd2e 100644 --- a/zh-cn/device-dev/guide/device-camera-control-example.md +++ b/zh-cn/device-dev/guide/device-camera-control-example.md @@ -3,7 +3,7 @@ 本示例将运行源码中的camera示例代码,通过本示例可以实现对开发板拍照、录像及预览功能的控制。 - 本示例源码路径为“applications/sample/camera/media/camera\_sample.cpp”。 -- 在运行本示例前需先完成编译烧录、运行镜像等步骤,相关操作请参考[Hi3516快速入门](../quick-start/quickstart-lite-introduction-hi3516.md#section26131214194212)。 +- 在运行本示例前需先完成编译烧录、运行镜像等步骤,相关操作请参考[Hi3516快速入门](../quick-start/oem_minitinier_des_3516.md#section26131214194212)。 >![](../public_sys-resources/icon-note.gif) **说明:** >开发板启动后默认会加载launcher应用,应用的图形界面默认显示在媒体图层上方,会影响camera\_sample的演示结果,因此需要在编译或是打包时去掉launcher应用。 diff --git a/zh-cn/device-dev/guide/device-camera-visual-first-page.md b/zh-cn/device-dev/guide/device-camera-visual-firstpage.md similarity index 99% rename from zh-cn/device-dev/guide/device-camera-visual-first-page.md rename to zh-cn/device-dev/guide/device-camera-visual-firstpage.md index 354097ab25c36055562f5c6469393e8f73fba01d..bbfa60c30d6d6a901aa1e190145711955b69af50 100644 --- a/zh-cn/device-dev/guide/device-camera-visual-first-page.md +++ b/zh-cn/device-dev/guide/device-camera-visual-firstpage.md @@ -111,7 +111,6 @@ } ``` - - index="\{\{swiperPage\}\}" duration="500" onchange="swiperChange" 这些代码用来设置组件的属性和事件。其中,duration="500" 表示设置swiper的页面滑动的动画时长为500ms。 - index="\{\{swiperPage\}\}"设置了swiper子组件索引值,\{\{swiperPage\}\}这种写法表示index的值是和js代码中的swiperPage变量动态绑定的,index的值会随着swiperPage变动而改变。 - onchange="swiperChange" 设置了swiper组件的change事件和函数swiperChange绑定,对应的js代码如下: @@ -141,7 +140,6 @@ } ``` - 4. 设置一个城市的空气质量信息为一屏,在一屏内,要展示多种信息,分别使用不同的控件进行展示。 在swiper中添加两个子组件stack(绝对布局),每个stack组件内分别添加text、image、progress等组件来显示对应的信息 ,页面结构如下: diff --git a/zh-cn/device-dev/guide/device-camera-visual-run.md b/zh-cn/device-dev/guide/device-camera-visual-run.md index 3e7c3f1d165781cccae6694ca9327357317a6e40..59cea7e09931c4aff998255917c9ec2804d5eb3a 100644 --- a/zh-cn/device-dev/guide/device-camera-visual-run.md +++ b/zh-cn/device-dev/guide/device-camera-visual-run.md @@ -1,6 +1,6 @@ # 真机运行 -应用编译打包后即可安装到开发板。安装应用前需要先完成[DevEco Device Tool的安装配置](https://device.harmonyos.com/cn/docs/ide/user-guides/service_introduction-0000001050166905),然后将OpenHarmony烧录到开发板并运行。编译烧录、运行镜像的基本操作请参考快速入门手册:[Hi3516快速入门](../quick-start/quickstart-lite-introduction-hi3516.md#section26131214194212)。完成镜像运行,系统正常启动后,执行如下步骤安装或卸载三方应用。 +应用编译打包后即可安装到开发板。安装应用前需要先完成[DevEco Device Tool的安装配置](https://device.harmonyos.com/cn/docs/ide/user-guides/service_introduction-0000001050166905),然后将OpenHarmony烧录到开发板并运行。编译烧录、运行镜像的基本操作请参考快速入门手册:[Hi3516快速入门](../quick-start/oem_minitinier_des_3516.md#section26131214194212)。完成镜像运行,系统正常启动后,执行如下步骤安装或卸载三方应用。 1. 将IDE编译的未签名应用安装包和安装工具(镜像文件生成目录中的dev\_tools)放在sdcard中,将sdcard插入开发板卡槽。 2. 应用安装默认要校验签名,需要执行以下命令,关闭签名校验。 diff --git a/zh-cn/device-dev/guide/device-camera-visual.md b/zh-cn/device-dev/guide/device-camera-visual.md index ca4e46538b7894fdc3ce840b2b67f185d6e47d29..a0b185fbb0dbe44407302c27b9876869b7d1b723 100644 --- a/zh-cn/device-dev/guide/device-camera-visual.md +++ b/zh-cn/device-dev/guide/device-camera-visual.md @@ -6,7 +6,7 @@ - **[添加页面](device-camera-visual-addpage.md)** -- **[开发首页](device-camera-visual-first-page.md)** +- **[开发首页](device-camera-visual-firstpage.md)** - **[开发详情页](device-camera-visual-details.md)** diff --git a/zh-cn/device-dev/guide/device-clock-guide.md b/zh-cn/device-dev/guide/device-clock-guide.md index a615280a6e27bcf8c37efb75c72ac494e638ad11..4905dd828652d844a1f3670a8a6f66600ed2d79a 100644 --- a/zh-cn/device-dev/guide/device-clock-guide.md +++ b/zh-cn/device-dev/guide/device-clock-guide.md @@ -177,7 +177,6 @@ ``` - - **index.css文件** ``` @@ -217,7 +216,6 @@ } ``` - - **index.js:** js文件主要用于实现App应用的逻辑交互。在本页面js文件中,需要实现如下功能:定时获取系统时间。 @@ -263,7 +261,7 @@ ## 真机运行 -应用签名打包后即可安装到开发板。安装应用前需要先完成[DevEco Device Tool的安装配置](https://device.harmonyos.com/cn/docs/ide/user-guides/service_introduction-0000001050166905),然后将OpenHarmony系统烧录到开发板并运行。编译烧录、运行镜像的基本操作请参考快速入门手册:[标准系统Hi3516快速入门](../quick-start/quickstart-standard.md)。完成镜像运行,系统正常启动后,执行如下步骤安装或卸载应用。 +应用签名打包后即可安装到开发板。安装应用前需要先完成[DevEco Device Tool的安装配置](https://device.harmonyos.com/cn/docs/ide/user-guides/service_introduction-0000001050166905),然后将OpenHarmony系统烧录到开发板并运行。编译烧录、运行镜像的基本操作请参考快速入门手册:[标准系统Hi3516快速入门](../quick-start/quickstart-standard-overview.md)。完成镜像运行,系统正常启动后,执行如下步骤安装或卸载应用。 1. 从开发者工具代码仓路径中获取hdc客户端。 diff --git a/zh-cn/device-dev/guide/device-driver-demo.md b/zh-cn/device-dev/guide/device-driver-demo.md index 73e75ffda88df9a190e7e818a90852cb29c26734..1220e92265d08302120f54b3173db207529d966f 100644 --- a/zh-cn/device-dev/guide/device-driver-demo.md +++ b/zh-cn/device-dev/guide/device-driver-demo.md @@ -34,7 +34,7 @@ HDF驱动框架为常用外围设备提供了标准的驱动框架,驱动开 ## 环境准备 -环境准备具体操作请参考[标准系统基础环境搭建](../quick-start/quickstart-standard.md)。 +环境准备具体操作请参考[标准系统基础环境搭建](../quick-start/quickstart-standard-overview.md)。 >![](../public_sys-resources/icon-notice.gif) **须知:** >本示例针对OpenHarmony轻量系统、小型系统、标准系统都适用,本文以标准系统为例。其他系统的开发者可参考对应系统的指导文档进行环境搭建。 diff --git a/zh-cn/device-dev/guide/device-iotcamera-control-example.md b/zh-cn/device-dev/guide/device-iotcamera-control-example.md index 8f7e480ded6a00d4f830b0bde6413d9412cf7e2d..56bd5df7ff309943182b86a5da61732f251f9fdd 100644 --- a/zh-cn/device-dev/guide/device-iotcamera-control-example.md +++ b/zh-cn/device-dev/guide/device-iotcamera-control-example.md @@ -1,6 +1,6 @@ # 应用实例 -- 开发板介绍、编译烧录、运行镜像等操作请参考[Hi3518快速入门](../quick-start/quickstart-lite-introduction-hi3518.md#section14815247616),编译结果包含示例,结果文件为out/ipcamera\_hi3518ev300/dev\_tools/bin/camera\_sample,可将文件通过读卡器复制至TF卡中,或者修改camera\_sample的编译脚本将结果文件复制至rootfs.img中。 +- 开发板介绍、编译烧录、运行镜像等操作请参考[Hi3518快速入门](../quick-start/oem_minitinier_des_3518.md#section14815247616),编译结果包含示例,结果文件为out/ipcamera\_hi3518ev300/dev\_tools/bin/camera\_sample,可将文件通过读卡器复制至TF卡中,或者修改camera\_sample的编译脚本将结果文件复制至rootfs.img中。 修改applications/sample/camera/media/BUILD.gn中的output\_dir。 diff --git a/zh-cn/device-dev/guide/device-lite.md b/zh-cn/device-dev/guide/device-lite.md new file mode 100644 index 0000000000000000000000000000000000000000..5e2ac4c8748d7eb7572c07e2b886b3fd3d6ad344 --- /dev/null +++ b/zh-cn/device-dev/guide/device-lite.md @@ -0,0 +1,9 @@ +# 轻量和小型系统设备 + +- **[WLAN连接类产品](device-wlan.md)** + +- **[无屏摄像头类产品](device-iotcamera.md)** + +- **[带屏摄像头类产品](device-camera.md)** + + diff --git a/zh-cn/device-dev/guide/device-outerdriver-demo.md b/zh-cn/device-dev/guide/device-outerdriver-demo.md index 9526546a58e1da063e682b36e30a6a5f887ea6e7..523d084d55a16489d99fe4c2816d9beb13e77433 100644 --- a/zh-cn/device-dev/guide/device-outerdriver-demo.md +++ b/zh-cn/device-dev/guide/device-outerdriver-demo.md @@ -22,7 +22,7 @@ ## 概述 -本文档将介绍如何基于Hi3516DV300开发板完成基于HDF\_Input模型的触摸屏器件驱动开发,从而使开发者快速入门,进行基于的外设驱动开发。 +本文档将介绍如何基于Hi3516DV300开发板完成基于HDF\_Input模型的触摸屏器件驱动开发,从而使开发者快速入门,进行基于OpenHarmony的外设驱动开发。 ### 硬件资源简介 @@ -44,7 +44,7 @@ Input驱动模型核心部分由设备管理层、公共驱动层、器件驱动 ## 环境搭建 -环境准备具体操作请参考[标准系统基础环境搭建](../quick-start/quickstart-standard.md)。 +环境准备具体操作请参考[标准系统基础环境搭建](../quick-start/quickstart-standard-overview.md)。 >![](../public_sys-resources/icon-notice.gif) **须知:** >本示例针对OpenHarmony轻量系统、小型系统、标准系统都适用,本文以标准系统为例。其他系统的开发者可参考对应系统的指导文档进行环境搭建。 @@ -335,7 +335,7 @@ Input模型由三层驱动组成,开发者适配一款全新触摸屏驱动只 其中touch\_gt911.o为本示例中追加的内容。 -2. 具体编译及烧录操作请参考[标准系统快速入门编译及烧录章节](../nottoctopics/zh-cn_topic_0000001135402541.md#section375234715135)。 +2. 具体编译及烧录操作请参考[标准系统快速入门编译及烧录章节](../quick-start/quickstart-standard-burn.md)。 ## 调试验证 diff --git a/zh-cn/device-dev/guide/device-standard.md b/zh-cn/device-dev/guide/device-standard.md new file mode 100644 index 0000000000000000000000000000000000000000..15aec1754a40139d57b8b98058b5a4d5037e231a --- /dev/null +++ b/zh-cn/device-dev/guide/device-standard.md @@ -0,0 +1,9 @@ +# 标准系统设备 + +- **[时钟应用开发指导](device-clock-guide.md)** + +- **[平台驱动开发示例](device-driver-demo.md)** + +- **[外设驱动开发示例](device-outerdriver-demo.md)** + + diff --git a/zh-cn/device-dev/guide/device-wifi.md b/zh-cn/device-dev/guide/device-wifi.md deleted file mode 100644 index 3f85bc6f6c8626e1314093b28146dc989ee55167..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/guide/device-wifi.md +++ /dev/null @@ -1,7 +0,0 @@ -# WLAN连接类产品 - -- **[LED外设控制](device-wifi-led-outcontrol.md)** - -- **[集成三方SDK](device-wifi-sdk.md)** - - diff --git a/zh-cn/device-dev/guide/device-wifi-sdk.md b/zh-cn/device-dev/guide/device-wlan-sdk.md similarity index 100% rename from zh-cn/device-dev/guide/device-wifi-sdk.md rename to zh-cn/device-dev/guide/device-wlan-sdk.md diff --git a/zh-cn/device-dev/guide/device-wlan.md b/zh-cn/device-dev/guide/device-wlan.md new file mode 100644 index 0000000000000000000000000000000000000000..ece3a35d670fe43de2892f4eae35b6d8f25a4e29 --- /dev/null +++ b/zh-cn/device-dev/guide/device-wlan.md @@ -0,0 +1,7 @@ +# WLAN连接类产品 + +- **[LED外设控制](oem_wifi_sdk_des.md)** + +- **[集成三方SDK](device-wlan-sdk.md)** + + diff --git a/zh-cn/device-dev/guide/device.md b/zh-cn/device-dev/guide/device.md index 1cb2d60315d1a1a78b6b1452c4a4167bbc48ab8a..f524abc29dce1400b1767ae97a67f28383768d9c 100644 --- a/zh-cn/device-dev/guide/device.md +++ b/zh-cn/device-dev/guide/device.md @@ -1,15 +1,7 @@ -# 设备开发指南 +# 设备 -- **[WLAN连接类产品](device-wifi.md)** +- **[轻量和小型系统设备](device-lite.md)** -- **[无屏摄像头类产品](device-iotcamera.md)** - -- **[带屏摄像头类产品](device-camera.md)** - -- **[时钟应用开发指导](device-clock-guide.md)** - -- **[平台驱动开发示例](device-driver-demo.md)** - -- **[外设驱动开发示例](device-outerdriver-demo.md)** +- **[标准系统设备](device-standard.md)** diff --git a/zh-cn/device-dev/guide/device-wifi-led-outcontrol.md b/zh-cn/device-dev/guide/oem_wifi_sdk_des.md similarity index 91% rename from zh-cn/device-dev/guide/device-wifi-led-outcontrol.md rename to zh-cn/device-dev/guide/oem_wifi_sdk_des.md index 2d4970fa19c09b4fc4140751446e32bbed4e7ee3..678a8f2f287387542b48e814888d8676bac99f81 100644 --- a/zh-cn/device-dev/guide/device-wifi-led-outcontrol.md +++ b/zh-cn/device-dev/guide/oem_wifi_sdk_des.md @@ -10,7 +10,7 @@ OpenHarmony WLAN模组基于Hi3861平台提供了丰富的外设操作能力, ## 开发 -1. 请先完成[《Hi3861快速入门》](../quick-start/quickstart-lite-introduction-hi3861.md#section19352114194115)。 +1. 请先完成[《Hi3861快速入门》](../quick-start/oem_minitinier_des_3861.md#section19352114194115)。 LED控制参考示例存放于applications/sample/wifi-iot/app/iothardware/led\_example.c文件中。 @@ -101,7 +101,7 @@ OpenHarmony WLAN模组基于Hi3861平台提供了丰富的外设操作能力, ## 验证 -编译过程请参考《[Hi3861快速入门-源码编译](../quick-start/quickstart-lite-steps-board3861-connection.md#section191121332125319)》,烧录过程请参考《[Hi3861快速入门-镜像烧录](../quick-start/quickstart-lite-steps-board3861-connection.md#section19458165166)》。 +编译过程请参考《[Hi3861快速入门-源码编译](../quick-start/quickstart-lite-steps-hi3861-connection.md#section191121332125319)》,烧录过程请参考《[Hi3861快速入门-镜像烧录](../quick-start/quickstart-lite-steps-hi3861-connection.md#section19458165166)》。 完成以上两步后,按下RST键复位模组,可发现LED在周期性闪烁,与预期相符,验证完毕。 diff --git a/zh-cn/device-dev/kernel/Readme-CN.md b/zh-cn/device-dev/kernel/Readme-CN.md index 622c047a249a5efe407e282d2c1b448237a2fb0b..8322ca1667314d6016f60fbcd026a53d14c60b0e 100755 --- a/zh-cn/device-dev/kernel/Readme-CN.md +++ b/zh-cn/device-dev/kernel/Readme-CN.md @@ -4,22 +4,46 @@ - [内核概述](kernel-mini-overview.md) - [基础内核](kernel-mini-basic.md) - [中断管理](kernel-mini-basic-interrupt.md) + - [基本概念](kernel-mini-basic-interrupt-concept.md) + - [开发指导](kernel-mini-basic-interrupt-guide.md) - [任务管理](kernel-mini-basic-task.md) + - [基本概念](kernel-mini-basic-task-basic.md) + - [开发指导](kernel-mini-basic-task-guide.md) - [内存管理](kernel-mini-basic-memory.md) + - [基本概念](kernel-mini-basic-memory-basic.md) + - [静态内存](kernel-mini-basic-memory-static.md) + - [动态内存](kernel-mini-basic-memory-dynamic.md) - [内核通信机制](kernel-mini-basic-ipc.md) - [事件](kernel-mini-basic-ipc-event.md) + - [基本概念](kernel-mini-basic-ipc-event-basic.md) + - [开发指导](kernel-mini-basic-ipc-event-guide.md) - [互斥锁](kernel-mini-basic-ipc-mutex.md) + - [基本概念](kernel-mini-basic-ipc-mutex-basic.md) + - [开发指导](kernel-mini-basic-ipc-mutex-guide.md) - [消息队列](kernel-mini-basic-ipc-queue.md) + - [基本概念](kernel-mini-basic-ipc-queue-basic.md) + - [开发指导](kernel-mini-basic-ipc-queue-guide.md) - [信号量](kernel-mini-basic-ipc-sem.md) + - [基本概念](kernel-mini-basic-ipc-sem-basic.md) + - [开发指导](kernel-mini-basic-ipc-sem-guide.md) - [时间管理](kernel-basic-mini-time.md) + - [基本概念](kernel-mini-basic-time-basic.md) + - [开发指导](kernel-mini-basic-time-guide.md) - [软件定时器](kernel-mini-basic-soft.md) + - [基本概念](kernel-mini-basic-soft-basic.md) + - [开发指导](kernel-mini-basic-soft-guide.md) - [扩展组件](kernel-mini-extend.md) - [C++支持](kernel-mini-extend-support.md) - [CPU占用率](kernel-mini-extend-cpup.md) - - [动态加载](kernel-mini-extend-dynamic-loading.md) + - [基本概念](kernel-mini-extend-cpup-basic.md) + - [开发指导](kernel-mini-extend-cpup-guide.md) + - [基本概念](kernel-mini-extend-dynamic-loading-basic.md) + - [开发指导](kernel-mini-extend-dynamic-loading-guide.md) - [文件系统](kernel-mini-extend-file.md) - [FAT](kernel-mini-extend-file-fat.md) - [LittleFS](kernel-mini-extend-file-lit.md) + - [基本概念](kernel-mini-extend-file-littlefs-basic.md) + - [开发指导](kernel-mini-extend-file-littlefs-guide.md) - [内核调测](kernel-memory-inner.md) - [内存调测](kernel-mini-memory-debug.md) - [内存信息统计](kernel-mini-memory-debug-mes.md) @@ -69,6 +93,11 @@ - [文件系统](kernel-small-bundles-fs.md) - [虚拟文件系统](kernel-small-bundles-fs-virtual.md) - [支持的文件系统](kernel-small-bundles-fs-support.md) + - [FAT](kernel-small-bundles-fs-support-fat.md) + - [JFFS2](kernel-small-bundles-fs-support-jffs2.md) + - [NFS](kernel-small-bundles-fs-support-nfs.md) + - [Ramfs](kernel-small-bundles-fs-support-ramfs.md) + - [Procfs](kernel-small-bundles-fs-support-procfs.md) - [适配新的文件系统](kernel-small-bundles-fs-new.md) - [调测与工具](kernel-small-debug.md) - [Shell](kernel-small-debug-shell.md) @@ -77,8 +106,62 @@ - [Shell命令编程实例](kernel-small-debug-shell-build.md) - [Shell命令使用详解](kernel-small-debug-shell-details.md) - [系统命令](kernel-small-debug-shell-cmd.md) + - [cpup](kernel-small-debug-shell-cmd-cpup.md) + - [date](kernel-small-debug-shell-cmd-date.md) + - [dmesg](kernel-small-debug-shell-cmd-dmesg.md) + - [exec](kernel-small-debug-shell-cmd-exec.md) + - [free](kernel-small-debug-shell-cmd-free.md) + - [help](kernel-small-debug-shell-cmd-help.md) + - [hwi](kernel-small-debug-shell-cmd-hwi.md) + - [kill](kernel-small-debug-shell-cmd-kill.md) + - [log](kernel-small-debug-shell-cmd-log.md) + - [memcheck](kernel-small-debug-shell-cmd-memcheck.md) + - [oom](kernel-small-debug-shell-cmd-oom.md) + - [pmm](kernel-small-debug-shell-cmd-pmm.md) + - [reset](kernel-small-debug-shell-cmd-reset.md) + - [sem](kernel-small-debug-shell-cmd-sem.md) + - [stack](kernel-small-debug-shell-cmd-stack.md) + - [su](kernel-small-debug-shell-cmd-su.md) + - [swtmr](kernel-small-debug-shell-cmd-swtmr.md) + - [systeminfo](kernel-small-debug-shell-cmd-sysinfo.md) + - [task](kernel-small-debug-shell-cmd-task.md) + - [uname](kernel-small-debug-shell-cmd-uname.md) + - [vmm](kernel-small-debug-shell-cmd-vmm.md) + - [watch](kernel-small-debug-shell-cmd-watch.md) - [文件命令](kernel-small-debug-shell-file.md) + - [cat](kernel-small-debug-shell-file-cat.md) + - [cd](kernel-small-debug-shell-file-cd.md) + - [chgrp](kernel-small-debug-shell-file-chgrp.md) + - [chmod](kernel-small-debug-shell-file-chmod.md) + - [chown](kernel-small-debug-shell-file-chown.md) + - [cp](kernel-small-debug-shell-file-cp.md) + - [format](kernel-small-debug-shell-file-format.md) + - [ls](kernel-small-debug-shell-file-ls.md) + - [lsfd](kernel-small-debug-shell-file-lsfd.md) + - [mkdir](kernel-small-debug-shell-file-mkdir.md) + - [mount](kernel-small-debug-shell-file-mount.md) + - [partinfo](kernel-small-debug-shell-file-partinfo.md) + - [partition](kernel-small-debug-shell-file-partition.md) + - [pwd](kernel-small-debug-shell-file-pwd.md) + - [rm](kernel-small-debug-shell-file-rm.md) + - [rmdir](kernel-small-debug-shell-file-rmdir.md) + - [statfs](kernel-small-debug-shell-file-statfs.md) + - [sync](kernel-small-debug-shell-file-sync.md) + - [touch](kernel-small-debug-shell-file-touch.md) + - [writeproc](kernel-small-debug-shell-file-write.md) + - [umount](kernel-small-debug-shell-file-umount.md) - [网络命令](kernel-small-debug-shell-net.md) + - [arp](kernel-small-debug-shell-net-arp.md) + - [dhclient](kernel-small-debug-shell-net-dhclient.md) + - [dns](kernel-small-debug-shell-net-dns.md) + - [ifconfig](kernel-small-debug-shell-net-ifconfig.md) + - [ipdebug](kernel-small-debug-shell-net-ipdebug.md) + - [netstat](kernel-small-debug-shell-net-netstat.md) + - [ntpdate](kernel-small-debug-shell-net-ntpdate.md) + - [ping](kernel-small-debug-shell-net-ping.md) + - [ping6](kernel-small-debug-shell-net-ping6.md) + - [telnet](kernel-small-debug-shell-net-telnet.md) + - [tftp](kernel-small-debug-shell-net-tftp.md) - [魔法键使用方法](kernel-small-debug-shell-magickey.md) - [用户态异常信息说明](kernel-small-debug-shell-error.md) - [Trace](kernel-small-debug-trace.md) diff --git a/zh-cn/device-dev/kernel/figure/zh-cn_image_0000001179063579.png b/zh-cn/device-dev/kernel/figure/zh-cn_image_0000001179063579.png deleted file mode 100644 index 6fa3ffa48167681f4b3385278bb8d75fc251a050..0000000000000000000000000000000000000000 Binary files a/zh-cn/device-dev/kernel/figure/zh-cn_image_0000001179063579.png and /dev/null differ diff --git a/zh-cn/device-dev/kernel/figure/zh-cn_image_0000001191018697.png b/zh-cn/device-dev/kernel/figure/zh-cn_image_0000001191018697.png new file mode 100644 index 0000000000000000000000000000000000000000..9330ebba7e4fd0de3f88a0abda65beceb65a18ac Binary files /dev/null and b/zh-cn/device-dev/kernel/figure/zh-cn_image_0000001191018697.png differ diff --git "a/zh-cn/device-dev/kernel/figure/\345\206\205\345\255\230\347\224\263\350\257\267\347\244\272\346\204\217\345\233\276.png" "b/zh-cn/device-dev/kernel/figure/\345\206\205\345\255\230\347\224\263\350\257\267\347\244\272\346\204\217\345\233\276.png" index 38c338c52e40023604e58e5908a78c375038036a..9d502df58aeb0e4f01c83628c82a6a9d974765ab 100644 Binary files "a/zh-cn/device-dev/kernel/figure/\345\206\205\345\255\230\347\224\263\350\257\267\347\244\272\346\204\217\345\233\276.png" and "b/zh-cn/device-dev/kernel/figure/\345\206\205\345\255\230\347\224\263\350\257\267\347\244\272\346\204\217\345\233\276.png" differ diff --git "a/zh-cn/device-dev/kernel/figure/\345\206\205\345\255\230\351\207\212\346\224\276\347\244\272\346\204\217\345\233\276.png" "b/zh-cn/device-dev/kernel/figure/\345\206\205\345\255\230\351\207\212\346\224\276\347\244\272\346\204\217\345\233\276.png" index af94ee390dbd056ca7c44f524853bfbf89228f88..c4f9ba8dba9112333f43dfe8db6d3f046bb29631 100644 Binary files "a/zh-cn/device-dev/kernel/figure/\345\206\205\345\255\230\351\207\212\346\224\276\347\244\272\346\204\217\345\233\276.png" and "b/zh-cn/device-dev/kernel/figure/\345\206\205\345\255\230\351\207\212\346\224\276\347\244\272\346\204\217\345\233\276.png" differ diff --git "a/zh-cn/device-dev/kernel/figure/\345\212\250\346\200\201\345\206\205\345\255\230\346\240\270\345\277\203\347\256\227\346\263\225-19.png" "b/zh-cn/device-dev/kernel/figure/\345\212\250\346\200\201\345\206\205\345\255\230\346\240\270\345\277\203\347\256\227\346\263\225-19.png" index 1614d4992a7179c2606e2dc0324d9dd6a9411e3c..8fa49b71f46505f335a5e782cbef362f7336fdaa 100644 Binary files "a/zh-cn/device-dev/kernel/figure/\345\212\250\346\200\201\345\206\205\345\255\230\346\240\270\345\277\203\347\256\227\346\263\225-19.png" and "b/zh-cn/device-dev/kernel/figure/\345\212\250\346\200\201\345\206\205\345\255\230\346\240\270\345\277\203\347\256\227\346\263\225-19.png" differ diff --git a/zh-cn/device-dev/kernel/figure/zh-cn_image_0000001125101908.png "b/zh-cn/device-dev/kernel/figure/\346\226\207\344\273\266\347\263\273\347\273\237\347\232\204\346\200\273\344\275\223\347\273\223\346\236\204.png" similarity index 100% rename from zh-cn/device-dev/kernel/figure/zh-cn_image_0000001125101908.png rename to "zh-cn/device-dev/kernel/figure/\346\226\207\344\273\266\347\263\273\347\273\237\347\232\204\346\200\273\344\275\223\347\273\223\346\236\204.png" diff --git a/zh-cn/device-dev/kernel/figure/zh-cn_image_0000001132875772.png "b/zh-cn/device-dev/kernel/figure/\351\230\237\345\210\227\350\257\273\345\206\231\346\225\260\346\215\256\346\223\215\344\275\234\347\244\272\346\204\217\345\233\276.png" similarity index 100% rename from zh-cn/device-dev/kernel/figure/zh-cn_image_0000001132875772.png rename to "zh-cn/device-dev/kernel/figure/\351\230\237\345\210\227\350\257\273\345\206\231\346\225\260\346\215\256\346\223\215\344\275\234\347\244\272\346\204\217\345\233\276.png" diff --git a/zh-cn/device-dev/kernel/kernel-mini-extend-dynamic-loading.md b/zh-cn/device-dev/kernel/kernel-mini-extend-dynamic-loading.md index 809498749c51a43008ed83ed19083665dadc6037..22214ff3fb19311ebc343aeed02653310923bc5d 100644 --- a/zh-cn/device-dev/kernel/kernel-mini-extend-dynamic-loading.md +++ b/zh-cn/device-dev/kernel/kernel-mini-extend-dynamic-loading.md @@ -1,4 +1,4 @@ -# 动态加载 +# - **[基本概念](kernel-mini-extend-dynamic-loading-basic.md)** diff --git a/zh-cn/device-dev/kernel/kernel-mini-extend.md b/zh-cn/device-dev/kernel/kernel-mini-extend.md index 2c171e7ce636249dda71961412c9f4862046effb..f257a85a1cb30a1c691bf86cba024d1d8c483106 100644 --- a/zh-cn/device-dev/kernel/kernel-mini-extend.md +++ b/zh-cn/device-dev/kernel/kernel-mini-extend.md @@ -4,7 +4,7 @@ - **[CPU占用率](kernel-mini-extend-cpup.md)** -- **[动态加载](kernel-mini-extend-dynamic-loading.md)** +- **[](kernel-mini-extend-dynamic-loading.md)** - **[文件系统](kernel-mini-extend-file.md)** diff --git a/zh-cn/device-dev/kernel/kernel-small-basic-inner-reflect.md b/zh-cn/device-dev/kernel/kernel-small-basic-inner-reflect.md index 25229b427b8590d66a4dafd4321935607019c441..4eac07d96034017246b0fb4d80719d539918839e 100644 --- a/zh-cn/device-dev/kernel/kernel-small-basic-inner-reflect.md +++ b/zh-cn/device-dev/kernel/kernel-small-basic-inner-reflect.md @@ -18,7 +18,7 @@ 虚实映射其实就是一个建立页表的过程。MMU有多级页表,LiteOS-A内核采用二级页表描述进程空间。每个一级页表条目描述符占用4个字节,可表示1MiB的内存空间的映射关系,即1GiB用户空间(LiteOS-A内核中用户空间占用1GiB)的虚拟内存空间需要1024个。系统创建用户进程时,在内存中申请一块4KiB大小的内存块作为一级页表的存储区域,二级页表根据当前进程的需要做动态的内存申请。 -- 用户程序加载启动时,会将代码段、数据段映射进虚拟内存空间(详细可参考动态加载与链接一节),此时并没有物理页做实际的映射; +- 用户程序加载启动时,会将代码段、数据段映射进虚拟内存空间(详细可参考[动态加载与链接](kernel-small-bundles-linking.md)),此时并没有物理页做实际的映射; - 程序执行时,如下图粗箭头所示,CPU访问虚拟地址,通过MMU查找是否有对应的物理内存,若该虚拟地址无对应的物理地址则触发缺页异常,内核申请物理内存并将虚实映射关系及对应的属性配置信息写进页表,并把页表条目缓存至TLB,接着CPU可直接通过转换关系访问实际的物理内存; - 若CPU访问已缓存至TLB的页表条目,无需再访问保存在内存中的页表,可加快查找速度。 diff --git a/zh-cn/device-dev/kernel/kernel-small-basic-memory-physical.md b/zh-cn/device-dev/kernel/kernel-small-basic-memory-physical.md index 382bddc08c60020e1550985236ab841edd46a12c..ac56ca9cbaafc88a71d208d9d9ab2b6e74876404 100644 --- a/zh-cn/device-dev/kernel/kernel-small-basic-memory-physical.md +++ b/zh-cn/device-dev/kernel/kernel-small-basic-memory-physical.md @@ -11,7 +11,7 @@ ## 基本概念 -物理内存是计算机上最重要的资源之一,指的是实际的内存设备提供的、可以通过CPU总线直接进行寻址的内存空间,其主要作用是为操作系统及程序提供临时存储空间。LiteOS-A内核管理物理内存是通过分页实现的,除了内核堆占用的一部分内存外,其余可用内存均以4k为单位划分成页帧,内存分配和内存回收便是以页帧为单位进行操作。内核采用伙伴算法管理空闲页面,可以降低一定的内存碎片率,提高内存分配和释放的效率,但是一个很小的块往往也会阻塞一个大块的合并,导致不能分配较大的内存块。 +物理内存是计算机上最重要的资源之一,指的是实际的内存设备提供的、可以通过CPU总线直接进行寻址的内存空间,其主要作用是为操作系统及程序提供临时存储空间。LiteOS-A内核管理物理内存是通过分页实现的,除了内核堆占用的一部分内存外,其余可用内存均以4KiB为单位划分成页帧,内存分配和内存回收便是以页帧为单位进行操作。内核采用伙伴算法管理空闲页面,可以降低一定的内存碎片率,提高内存分配和释放的效率,但是一个很小的块往往也会阻塞一个大块的合并,导致不能分配较大的内存块。 ## 运行机制 @@ -24,7 +24,7 @@ - 申请内存 - 系统申请12k内存,即3个页帧时,9个内存块组中索引为3的链表挂着一块大小为8个页帧的内存块满足要求,分配出12k内存后还剩余20k内存,即5个页帧,将5个页帧分成2的幂次方之和,即4跟1,尝试查找伙伴进行合并。4个页帧的内存块没有伙伴则直接插到索引为2的链表上,继续查找1个页帧的内存块是否有伙伴,索引为0的链表上此时有1个,如果两个内存块地址连续则进行合并,并将内存块挂到索引为1的链表上,否则不做处理。 + 系统申请12KiB内存,即3个页帧时,9个内存块组中索引为3的链表挂着一块大小为8个页帧的内存块满足要求,分配出12KiB内存后还剩余20KiB内存,即5个页帧,将5个页帧分成2的幂次方之和,即4跟1,尝试查找伙伴进行合并。4个页帧的内存块没有伙伴则直接插到索引为2的链表上,继续查找1个页帧的内存块是否有伙伴,索引为0的链表上此时有1个,如果两个内存块地址连续则进行合并,并将内存块挂到索引为1的链表上,否则不做处理。 **图 2** 内存申请示意图 ![](figure/内存申请示意图.png "内存申请示意图") @@ -32,7 +32,7 @@ - 释放内存 - 系统释放12k内存,即3个页帧,将3个页帧分成2的幂次方之和,即2跟1,尝试查找伙伴进行合并,索引为1的链表上有1个内存块,若地址连续则合并,并将合并后的内存块挂到索引为2的链表上,索引为0的链表上此时也有1个,如果地址连续则进行合并,并将合并后的内存块挂到索引为1的链表上,此时继续判断是否有伙伴,重复上述操作。 + 系统释放12KiB内存,即3个页帧,将3个页帧分成2的幂次方之和,即2跟1,尝试查找伙伴进行合并,索引为1的链表上有1个内存块,若地址连续则合并,并将合并后的内存块挂到索引为2的链表上,索引为0的链表上此时也有1个,如果地址连续则进行合并,并将合并后的内存块挂到索引为1的链表上,此时继续判断是否有伙伴,重复上述操作。 **图 3** 内存释放示意图 ![](figure/内存释放示意图.png "内存释放示意图") @@ -104,11 +104,11 @@ ### 开发流程 -内存申请时根据需要调用相关接口,小内存申请建议使用堆内存申请相关接口,4k及以上内存申请可以使用上述物理内存相关接口。 +内存申请时根据需要调用相关接口,小内存申请建议使用堆内存申请相关接口,4KiB及以上内存申请可以使用上述物理内存相关接口。 >![](../public_sys-resources/icon-note.gif) **说明:** >- 物理内存申请相关接口需要在OsSysMemInit接口完成初始化之后再使用; ->- 内存申请的基本单位是页帧,即4k; +>- 内存申请的基本单位是页帧,即4KiB; >- 物理内存申请时,有地址连续要求的使用LOS\_PhysPagesAllocContiguous接口,无地址连续的要求尽量使用LOS\_PhysPagesAlloc接口,将连续的大块内存留给有需要的模块使用。 ### 编程实例 diff --git a/zh-cn/device-dev/kernel/kernel-small-basic-memory-virtual.md b/zh-cn/device-dev/kernel/kernel-small-basic-memory-virtual.md index 8d2281f3972b2aec9b266f3ba94fff3f62a89c83..dd1b7d412e6cb67a33e2f64582efd39e454d380a 100644 --- a/zh-cn/device-dev/kernel/kernel-small-basic-memory-virtual.md +++ b/zh-cn/device-dev/kernel/kernel-small-basic-memory-virtual.md @@ -9,56 +9,40 @@ ## 基本概念 -虚拟内存管理是计算机系统管理内存的一种技术。每个进程都有连续的虚拟地址空间,虚拟地址空间的大小由CPU的位数决定,32位的硬件平台可以提供的最大的寻址空间为0-4G。整个4G空间分成两部分,LiteOS-A内核占据3G的高地址空间,1G的低地址空间留给进程使用。各个进程空间的虚拟地址空间是独立的,代码、数据互不影响。 +虚拟内存管理是计算机系统管理内存的一种技术。每个进程都有连续的虚拟地址空间,虚拟地址空间的大小由CPU的位数决定,32位的硬件平台可以提供的最大的寻址空间为0-4GiB。整个4GiB空间分成两部分,LiteOS-A内核占据3GiB的高地址空间,1GiB的低地址空间留给进程使用。各个进程空间的虚拟地址空间是独立的,代码、数据互不影响。 -系统将虚拟内存分割为称为虚拟页的内存块,大小一般为4k或64k,LiteOS-A内核默认的页的大小是4k,根据需要可以对MMU(Memory Management Units)进行配置。虚拟内存管理操作的最小单位就是一个页,LiteOS-A内核中一个虚拟地址区间region包含地址连续的多个虚拟页,也可只有一个页。同样,物理内存也会按照页大小进行分割,分割后的每个内存块称为页帧。虚拟地址空间划分:内核态占高地址3G\(0x40000000 \~ 0xFFFFFFFF\),用户态占低地址1G\(0x01000000 \~ 0x3F000000\),具体见下表,详细可以查看或配置los\_vm\_zone.h。 +系统将虚拟内存分割为称为虚拟页的内存块,大小一般为4KiB或64KiB,LiteOS-A内核默认的页的大小是4KiB,根据需要可以对MMU(Memory Management Units)进行配置。虚拟内存管理操作的最小单位就是一个页,LiteOS-A内核中一个虚拟地址区间region包含地址连续的多个虚拟页,也可只有一个页。同样,物理内存也会按照页大小进行分割,分割后的每个内存块称为页帧。虚拟地址空间划分:内核态占高地址3GiB\(0x40000000 \~ 0xFFFFFFFF\),用户态占低地址1GiB\(0x01000000 \~ 0x3F000000\),具体见下表,详细可以查看或配置los\_vm\_zone.h。 **表 1** 内核态地址规划: -

Zone名称

+ - - - - - - - - - - - - - - - - - - - @@ -67,60 +51,40 @@ **表 2** 用户态虚地址规划: -

Zone名称

起始地址

+

描述

结束地址

-

用途

-

属性

+

属性

DMA zone

-

0x40000000

+

DMA zone

0x43FFFFFF

+

供IO设备的DMA使用。

USB、网络等dma内存访问

-

Uncache

+

Uncache

Normal zone

-

0x80000000

+

Normal zone

0x83FFFFFF

+

加载内核代码段、数据段、堆和栈的地址区间。

内核代码、数据段和堆内存和栈

-

Cache

+

Cache

high mem zone

-

0x84000000

+

high mem zone

0x8BFFFFFF

+

可以分配连续的虚拟内存,但其所映射的物理内存不一定连续。

连续虚拟内存分配,物理内存不连续

-

Cache

+

Cache

-

Zone名称

-

起始地址

+ - - - - - - - - - - - - - - - - - - - - - - - @@ -130,7 +94,7 @@ 虚拟内存管理中,虚拟地址空间是连续的,但是其映射的物理内存并不一定是连续的,如下图所示。可执行程序加载运行,CPU访问虚拟地址空间的代码或数据时存在两种情况: -- CPU访问的虚拟地址所在的页,如V0,已经与具体的物理页P0做映射,CPU通过找到进程对应的页表条目(详见虚实映射一节),根据页表条目中的物理地址信息访问物理内存中的内容并返回。 +- CPU访问的虚拟地址所在的页,如V0,已经与具体的物理页P0做映射,CPU通过找到进程对应的页表条目(详见[虚实映射](kernel-small-basic-inner-reflect.md)),根据页表条目中的物理地址信息访问物理内存中的内容并返回。 - CPU访问的虚拟地址所在的页,如V2,没有与具体的物理页做映射,系统会触发缺页异常,系统申请一个物理页,并把相应的信息拷贝到物理页中,并且把物理页的起始地址更新到页表条目中。此时CPU重新执行访问虚拟内存的指令便能够访问到具体的代码或数据。 **图 1** 内存映射示意图 @@ -303,12 +267,12 @@ - - - - - - - - - - - - - diff --git a/zh-cn/device-dev/kernel/kernel-small-debug-trace-other-faqs.md b/zh-cn/device-dev/kernel/kernel-small-debug-trace-other-faqs.md index 8f1ead1f8b506304b8572a09fd7b3f407c0593ed..bc36a03cff4f75cd039045efd99aff454cc625fc 100644 --- a/zh-cn/device-dev/kernel/kernel-small-debug-trace-other-faqs.md +++ b/zh-cn/device-dev/kernel/kernel-small-debug-trace-other-faqs.md @@ -1,7 +1,7 @@ # 常见问题定位方法 - [通过异常信息定位问题](#section695838161711) -- [内存池节点完整性验证](#section362917569179) +- [内存池完整性验证](#section362917569179) - [全局变量踩内存定位方法](#section18971311121816) ## 通过异常信息定位问题 @@ -24,7 +24,7 @@ 对于内核异常打印信息,确定PC和LR的具体位置的指令需要结合out目录下OHOS\_Image.asm(跟烧写的系统镜像OHOS\_Image.bin对应的汇编文件)查看,根据指令所在的位置可确认使用该指令的函数,依次确定LR位置所在的函数,即得到异常发生时的函数调用关系。 -## 内存池节点完整性验证 +## 内存池完整性验证 仅凭上节异常信息定位的基本方法,常常无法直接定位问题所在。并且常常会因为异常的寄存器值而无法对问题进行定位。若怀疑是堆内存越界导致的问题,可以调用内存池完整性检测函数LOS\_MemIntegrityCheck进行检查。函数LOS\_MemIntegrityCheck将会对系统动态内存池所有的节点进行遍历,如果所有节点正常则函数返回0,不会有任何打印,否则将打印相关的错误信息。该函数的入参使用\(VOID \*\)OS\_SYS\_MEM\_ADDR。 diff --git a/zh-cn/device-dev/kernel/kernel-small-debug-trace.md b/zh-cn/device-dev/kernel/kernel-small-debug-trace.md index bc83604a8bdc7246917a3e9666d57d55bd1c89f5..0d1b3b0684b86180d484c8f2f076bcaa0dc78c99 100644 --- a/zh-cn/device-dev/kernel/kernel-small-debug-trace.md +++ b/zh-cn/device-dev/kernel/kernel-small-debug-trace.md @@ -83,7 +83,7 @@ OpenHarmony LiteOS-A内核的Trace框架提供下面几种功能,接口详细 - -

Zone名称

结束地址

+

描述

用途

-

属性

+

属性

代码段

-

0x0200000

-

0x09FFFFFF

+

代码段

用户态代码段地址空间

+

用户态代码段地址区间。

Cache

+

Cache

-

0x0FC00000(起始地址随机)

-

0x17BFFFFF

+

用户态堆地址空间

+

用户态堆地址区间。

Cache

+

Cache

+

0x37000000

+

用户态栈地址区间。

0x3EFFFFFF(起始地址随机)

-

用户态栈空间地址

-

Cache

+

Cache

共享库

-

0x1F800000(起始地址随机)

-

0x277FFFFF

+

共享库

用户态共享库加载地址空间,包括mmap

+

用于加载用户态共享库的地址区间,包括mmap所映射的区间。

Cache

+

Cache

LOS_KernelMalloc

申请小于16k的内存则通过堆内存池获取,否则申请多个连续物理页

+

申请小于16KiB的内存则通过堆内存池获取,否则申请多个连续物理页

LOS_KernelMallocAlign

申请具有对齐属性的内存,申请规则:申请小于16k的内存则通过堆内存池获取,否则申请多个连续物理页

+

申请具有对齐属性的内存,申请规则:申请小于16KiB的内存则通过堆内存池获取,否则申请多个连续物理页

LOS_KernelFree

diff --git a/zh-cn/device-dev/kernel/kernel-small-basic-process-process.md b/zh-cn/device-dev/kernel/kernel-small-basic-process-process.md index c2e4e581a4abdf327805cb6a93bb24c4006448f7..b9ee70a61879b85c57783855e7c6c7f8d23817ae 100644 --- a/zh-cn/device-dev/kernel/kernel-small-basic-process-process.md +++ b/zh-cn/device-dev/kernel/kernel-small-basic-process-process.md @@ -25,7 +25,7 @@ - 就绪(Ready):进程在就绪列表中,等待CPU调度。 - 运行(Running):进程正在运行。 - 阻塞(Pending):进程被阻塞挂起。本进程内所有的线程均被阻塞时,进程被阻塞挂起。 -- 僵尸态(Zombies):进程运行结束,等待父进程回收其控制块资源。 +- 僵尸(Zombies):进程运行结束,等待父进程回收其控制块资源。 **图 1** 进程状态迁移示意图 ![](figure/进程状态迁移示意图.png "进程状态迁移示意图") diff --git a/zh-cn/device-dev/kernel/kernel-small-basic-trans-mutex.md b/zh-cn/device-dev/kernel/kernel-small-basic-trans-mutex.md index 6be13dd888747f43e2fd434f66e29ad313040124..cf974087d3df17063b9f8ff789d8c6988a456cdd 100644 --- a/zh-cn/device-dev/kernel/kernel-small-basic-trans-mutex.md +++ b/zh-cn/device-dev/kernel/kernel-small-basic-trans-mutex.md @@ -12,7 +12,7 @@ 互斥锁又称互斥型信号量,用于实现对共享资源的独占式处理。当有任务持有时,这个任务获得该互斥锁的所有权。当该任务释放它时,任务失去该互斥锁的所有权。当一个任务持有互斥锁时,其他任务将不能再持有该互斥锁。多任务环境下往往存在多个任务竞争同一共享资源的应用场景,互斥锁可被用于对共享资源的保护从而实现独占式访问。 -互斥量属性包含3个属性:协议属性、优先级上限属性和类型属性。协议属性用于处理不同优先级的任务申请互斥锁,协议属性包含如下三种: +互斥锁属性包含3个属性:协议属性、优先级上限属性和类型属性。协议属性用于处理不同优先级的任务申请互斥锁,协议属性包含如下三种: - LOS\_MUX\_PRIO\_NONE @@ -118,32 +118,32 @@

LOS_MuxAttrGetType

获取互斥锁类型属性

+

获取指定互斥锁属性的类型属性

LOS_MuxAttrSetType

设置互斥锁类型属性

+

设置指定互斥锁属性的类型属性

LOS_MuxAttrGetProtocol

获取互斥锁协议属性

+

获取指定互斥锁属性的协议属性

LOS_MuxAttrSetProtocol

设置互斥锁协议属性

+

设置指定互斥锁属性的协议属性

LOS_MuxAttrGetPrioceiling

获取互斥锁优先级上限属性

+

获取指定互斥锁属性的优先级上限属性

LOS_MuxAttrSetPrioceiling

设置互斥锁优先级上限属性

+

设置指定互斥锁属性的优先级上限属性

LOS_MuxGetPrioceiling

diff --git a/zh-cn/device-dev/kernel/kernel-small-basic-trans-queue.md b/zh-cn/device-dev/kernel/kernel-small-basic-trans-queue.md index 0acd40ee2bbed38995357739133962969416d070..af2bec2777b65bd57c5881bfb92fa9a544ed967d 100644 --- a/zh-cn/device-dev/kernel/kernel-small-basic-trans-queue.md +++ b/zh-cn/device-dev/kernel/kernel-small-basic-trans-queue.md @@ -68,9 +68,8 @@ typedef struct { - 读队列时,根据readWriteableCnt\[0\]判断队列是否有消息需要读取,对全部空闲(readWriteableCnt\[0\]为0)队列进行读操作会引起任务挂起。如果队列可以读取消息,则根据Head找到最先写入队列的消息节点进行读取。如果Head已经指向队列尾部则采用回卷方式。 - 删除队列时,根据队列ID找到对应队列,把队列状态置为未使用,把队列控制块置为初始状态,并释放队列所占内存。 -图 1 队列读写数据操作示意图 - -![](figure/zh-cn_image_0000001132875772.png) +**图 1** 队列读写数据操作示意图 +![](figure/队列读写数据操作示意图.png "队列读写数据操作示意图") 上图对读写队列做了示意,图中只画了尾节点写入方式,没有画头节点写入,但是两者是类似的。 diff --git a/zh-cn/device-dev/kernel/kernel-small-basic-trans-semaphore.md b/zh-cn/device-dev/kernel/kernel-small-basic-trans-semaphore.md index 6905259f4638b9859bfafce14136c5bd65a2baa3..69f8fae25af53ce693b815557a4d17194051f71d 100644 --- a/zh-cn/device-dev/kernel/kernel-small-basic-trans-semaphore.md +++ b/zh-cn/device-dev/kernel/kernel-small-basic-trans-semaphore.md @@ -136,10 +136,10 @@ typedef struct { 本实例实现如下功能: 1. 测试任务ExampleSem创建一个信号量,锁任务调度,创建两个任务ExampleSemTask1、ExampleSemTask2, ExampleSemTask2优先级高于ExampleSemTask1,两个任务中申请同一信号量,解锁任务调度后两任务阻塞,测试任务ExampleSem释放信号量。 -2. ExampleSemTask2得到信号量,被调度,然后任务休眠20Tick,ExampleSemTask2延迟,ExampleSemTask1被唤醒。 -3. ExampleSemTask1定时阻塞模式申请信号量,等待时间为10Tick,因信号量仍被ExampleSemTask2持有,ExampleSemTask1挂起,10Tick后仍未得到信号量,ExampleSemTask1被唤醒,试图以永久阻塞模式申请信号量,ExampleSemTask1挂起。 +2. ExampleSemTask2得到信号量,被调度,然后任务休眠20Ticks,ExampleSemTask2延迟,ExampleSemTask1被唤醒。 +3. ExampleSemTask1定时阻塞模式申请信号量,等待时间为10Ticks,因信号量仍被ExampleSemTask2持有,ExampleSemTask1挂起,10Ticks后仍未得到信号量,ExampleSemTask1被唤醒,试图以永久阻塞模式申请信号量,ExampleSemTask1挂起。 4. 20Tick后ExampleSemTask2唤醒, 释放信号量后,ExampleSemTask1得到信号量被调度运行,最后释放信号量。 -5. ExampleSemTask1执行完,40Tick后任务ExampleSem被唤醒,执行删除信号量。 +5. ExampleSemTask1执行完,400Ticks后任务ExampleSem被唤醒,执行删除信号量。 ### 编程示例 diff --git a/zh-cn/device-dev/kernel/kernel-small-basic-trans-user-signal.md b/zh-cn/device-dev/kernel/kernel-small-basic-trans-user-signal.md index d49376ae2983ecdeb477c57a4358fa79042eecff..e99e4abe9aba506ab4df9bc687ef7e1b43eff1cc 100644 --- a/zh-cn/device-dev/kernel/kernel-small-basic-trans-user-signal.md +++ b/zh-cn/device-dev/kernel/kernel-small-basic-trans-user-signal.md @@ -26,12 +26,12 @@

signal

注册系统总入口及注册和去注册某信号的回调函数。

+

注册信号总入口及注册和去注册某信号的回调函数。

sigaction

仅支持SIGINFO的选项。

+

功能同signal,但增加了信号发送相关的配置选项,目前仅支持SIGINFO结构体中的部分参数。

发送信号

@@ -69,17 +69,18 @@ >``` >void *signal(int sig, void (*func)(int))(int); >``` ->a. 31 号信号,会注册该进程的回调函数处理入口,不可重入。 ->b. 0-30 号信号,判断注册回调函数,注册与去注册回调函数。 +>a. 31 号信号,该信号用来注册该进程的回调函数处理入口,不可重复注册。 +>b. 0-30 号信号,该信号段用来注册与去注册回调函数。 +>注册回调函数: >``` >int sigaction(int, const struct sigaction *__restrict, struct sigaction *__restrict); >``` ->仅支持SIGINFO的选项,SIGINFO内容见sigtimedwait接口内描述。 +>支持信号注册的配置修改和配置获取,目前仅支持SIGINFO的选项,SIGINFO内容见sigtimedwait接口内描述。 >发送信号: ->a. 信号的默认行为不支持STOP及COTINUE,无COREDUMP功能。 ->b. 不能屏蔽SIGSTOP、SIGKILL、SIGCONT。 ->c. 杀死进程后,若父进程不回收,会产生僵尸进程。 ->d. 异步信号,发送信号给某进程后,直到该进程被调度后才会执行信号回调(为安全起见,杀死进程的动作是进程自己执行的,内核不能通过信号强制杀死对方)。 ->e. 进程消亡会发送SIGCHLD给父进程,发送动作无法取消。 ->f. 无法通过信号唤醒正在DELAY状态的进程。触发调度需要usleep\(10000\)即10ms才能完成进程调度转让。 +>a. 进程接收信号存在默认行为,单不支持POSIX标准所给出的STOP及COTINUE、COREDUMP功能。 +>b. 进程无法屏蔽SIGSTOP、SIGKILL、SIGCONT信号。 +>c. 某进程后被杀死后,若其父进程不回收该进程,其转为僵尸进程。 +>d. 进程接收到某信号后,直到该进程被调度后才会执行信号回调。 +>e. 进程结束后会发送SIGCHLD信号给父进程,该发送动作无法取消。 +>f. 无法通过信号唤醒处于DELAY状态的进程。 diff --git a/zh-cn/device-dev/kernel/kernel-small-bundles-fs-new.md b/zh-cn/device-dev/kernel/kernel-small-bundles-fs-new.md index ab54b352edf91fb5287598072375905dfcc99932..0f50e073d96d4adcab67d681b50f9402df9ac71c 100644 --- a/zh-cn/device-dev/kernel/kernel-small-bundles-fs-new.md +++ b/zh-cn/device-dev/kernel/kernel-small-bundles-fs-new.md @@ -155,7 +155,7 @@ int VfsJffs2Lookup(struct Vnode *parentVnode, const char *path, int len, struct /* 首先从private data中提取父节点的信息 */ parentNode = (struct jffs2_inode *)parentVnode->data; - /* 然后查询得到目标节点的信息,注意这里调用的jffs2_lookup是jffs2本身的查询函数,每个文件系统都有自己的查询函数,通过父节点的信息和VFS的查询函数对接起来 */ + /* 然后查询得到目标节点的信息,注意这里调用的jffs2_lookup是jffs2本身的查询函数 */ node = jffs2_lookup(parentNode, (const unsigned char *)path, len); if (!node) { LOS_MuxUnlock(&g_jffs2FsLock); @@ -216,7 +216,7 @@ int VfsJffs2Lookup(struct Vnode *parentVnode, const char *path, int len, struct 核心的逻辑其实在使用私有数据完成接口的功能,这些接口都是些文件系统的通用功能,文件系统在移植前本身应该都有相应实现,所以关键是归纳总结出文件系统所需的私有数据是什么,将其存储在vnode中,供之后使用。一般情况下,私有数据的内容是可以唯一定位到文件在存储介质上位置的信息,大部分文件系统本身都会有类似数据结构可以直接使用,比如JFFS2的inode数据结构。 >![](../public_sys-resources/icon-caution.gif) **注意:** ->1. 文件系统中的Lookup接口不是访问文件必经的路径,仅在上层路径缓存失效时才会调用到。 +>1. 访问文件时,不一定会调用文件系统中的Lookup接口,仅在上层的路径缓存失效时才会调用到。 >2. 通过VfsHashGet找到了已经存在的Vnode,不要直接将其作为结果返回,其储存的信息可能已经失效,请更新相应字段后再返回。 >3. Vnode会根据内存占用在后台自动释放,需要持久保存的信息,不要只保存在Vnode中。 >4. Reclaim接口在Vnode释放时会自动调用,请在这个接口中释放私有数据中的资源。 diff --git a/zh-cn/device-dev/kernel/kernel-small-bundles-fs-support-jffs2.md b/zh-cn/device-dev/kernel/kernel-small-bundles-fs-support-jffs2.md index 439c2cdeaeacfa959ecec65fa30f3c07fc683e67..8992d47a2ffe77a0dca52e3ff6fe63ad86270138 100644 --- a/zh-cn/device-dev/kernel/kernel-small-bundles-fs-support-jffs2.md +++ b/zh-cn/device-dev/kernel/kernel-small-bundles-fs-support-jffs2.md @@ -30,7 +30,7 @@ OpenHarmony内核的JFFS2主要应用于NOR FLASH闪存,其特点是:可读 **制作JFFS2文件系统镜像** -使用mkfs.jffs2工具,制作镜像默认命令见下。页大小默认为4KiB,eraseblock大小默认64KiB,镜像大小适应源目录并以0xFF填充为eraseblock大小的整数倍。若实际参数与下面不同时,修改相应参数。 +使用mkfs.jffs2工具,制作镜像默认命令如下。页大小默认为4KiB,eraseblock大小默认64KiB。若实际参数与下面不同时,修改相应参数。 ``` ./mkfs.jffs2 -d rootfs/ -o rootfs.jffs2 @@ -57,7 +57,7 @@ OpenHarmony内核的JFFS2主要应用于NOR FLASH闪存,其特点是:可读

-p

镜像大小,不指定默认适应源目录并以0xFF填充为eraseblock大小的整数倍

+

镜像大小。在镜像文件后面,用0xFF填充至指定大小,不指定则用0xFF填充至eraseblock对齐。

-d

diff --git a/zh-cn/device-dev/kernel/kernel-small-bundles-fs-virtual.md b/zh-cn/device-dev/kernel/kernel-small-bundles-fs-virtual.md index 33e469244ad48444fa1527055b6d7d98fb196e9e..f9eb12494b2561f694ece461030751a088ed2457 100644 --- a/zh-cn/device-dev/kernel/kernel-small-bundles-fs-virtual.md +++ b/zh-cn/device-dev/kernel/kernel-small-bundles-fs-virtual.md @@ -34,14 +34,14 @@ OpenHarmony内核中,VFS框架是通过在内存中的树结构来实现的, ![](figure/Vnode创建流程.png "Vnode创建流程") -1. PathCache:PathCache是路径缓存,与Vnode对应。PathCache同样通过哈希链表存储,通过父Vnode中缓存的PathCache可以快速获取子Vnode,加速路径查找。下图展示了文件/目录的查找流程。 +1. PathCache:PathCache是路径缓存,它通过哈希表存储,利用父节点Vnode的地址和子节点的文件名,可以从PathCache中快速查找到子节点对应的Vnode。下图展示了文件/目录的查找流程。 **图 2** 文件查找流程 ![](figure/文件查找流程.png "文件查找流程") -1. PageCache:PageCache是文件级别的内核缓存。当前PageCache仅支持对二进制文件操作,在初次访问该文件时通过mmap映射到内存中,减少内核内存的占用,也大大提升了对同一个文件的读写操作速度。另外基于PageCache可实现以文件为基底的进程间通信。 -2. fd管理:Fd(File Description)是描述一个打开的文件/目录的描述符。当前OpenHarmony内核中,fd总规格为896,分为三种类型: +1. PageCache:PageCache是内核中文件的缓存。当前PageCache仅支持缓存二进制文件,在初次访问文件时通过mmap映射到内存中,下次再访问时,直接从PageCache中读取,可以提升对同一个文件的读写速度。另外基于PageCache可实现以文件为基底的进程间通信。 +2. fd管理:Fd(File Descriptor)是描述一个打开的文件/目录的描述符。当前OpenHarmony内核中,fd总规格为896,分为三种类型: - 普通文件描述符,系统总规格为512。 - Socket描述符,系统总规格为128。 diff --git a/zh-cn/device-dev/kernel/kernel-small-bundles-fs.md b/zh-cn/device-dev/kernel/kernel-small-bundles-fs.md index da3ede163c2b39d6d4260ca370de6fb7b6d9126c..17837bc1ed82fc6678b1e36f63600e7e7012b39e 100644 --- a/zh-cn/device-dev/kernel/kernel-small-bundles-fs.md +++ b/zh-cn/device-dev/kernel/kernel-small-bundles-fs.md @@ -4,9 +4,8 @@ 文件系统对上通过C库提供的POSIX标准的操作接口,具体可以参考C库的API文档说明。对下,通过内核态的VFS虚拟层,屏蔽了各个具体文件系统的差异。基本架构如下: -**图 1** 文件系统的总体结构 - -![](figure/zh-cn_image_0000001125101908.png) +**图 1** 文件系统的总体结构 +![](figure/文件系统的总体结构.png "文件系统的总体结构") - **[虚拟文件系统](kernel-small-bundles-fs-virtual.md)** diff --git a/zh-cn/device-dev/kernel/kernel-small-bundles-linking.md b/zh-cn/device-dev/kernel/kernel-small-bundles-linking.md index d18d59b436d7d4a5d183a745a1ad51a9a8d5aaf1..6b3b154819c91ba60b683685840ccfebe90a692a 100644 --- a/zh-cn/device-dev/kernel/kernel-small-bundles-linking.md +++ b/zh-cn/device-dev/kernel/kernel-small-bundles-linking.md @@ -22,7 +22,7 @@ OpenHarmony系统的动态加载与链接机制主要是由内核加载器以及 **图 1** 动态加载流程 ![](figure/动态加载流程.png "动态加载流程") -1. 内核根据应用程序ELF文件的PT\_LOAD段信息映射至进程空间。对于ET\_EXEC类型的文件,根据PT\_LOAD段中p\_vaddr进行固定地址映射;对于ET\_DYN类型(位置无关的可执行程序,通过编译选项“-fPIE”得到)的文件,内核通过mmap接口选择base基址进行映射(load\_addr = base + p\_vaddr)。 +1. 内核将应用程序ELF文件的PT\_LOAD段信息映射至进程空间。对于ET\_EXEC类型的文件,根据PT\_LOAD段中p\_vaddr进行固定地址映射;对于ET\_DYN类型(位置无关的可执行程序,通过编译选项“-fPIE”得到)的文件,内核通过mmap接口选择base基址进行映射(load\_addr = base + p\_vaddr)。 2. 若应用程序是静态链接的(静态链接不支持编译选项“-fPIE”),设置堆栈信息后跳转至应用程序ELF文件中e\_entry指定的地址并运行;若程序是动态链接的,应用程序ELF文件中会有PT\_INTERP段,保存动态链接器的路径信息(ET\_DYN类型)。musl的动态链接器是libc-musl.so的一部分,libc-musl.so的入口即动态链接器的入口。内核通过mmap接口选择base基址进行映射,设置堆栈信息后跳转至base + e\_entry(该e\_entry为动态链接器的入口)地址并运行动态链接器。 3. 动态链接器自举并查找应用程序依赖的所有共享库并对导入符号进行重定位,最后跳转至应用程序的e\_entry(或base + e\_entry),开始运行应用程序。 @@ -32,7 +32,7 @@ OpenHarmony系统的动态加载与链接机制主要是由内核加载器以及 1. 加载器与链接器调用mmap映射PT\_LOAD段; 2. 内核调用map\_pages接口查找并映射pagecache已有的缓存; 3. 程序执行时,内存若无所需代码或数据时触发缺页中断,将elf文件内容读入内存,并将该内存块加入pagecache; -4. 映射步骤3已读入文件内容的内存块; +4. 将已读入文件内容的内存块与虚拟地址区间做映射; 5. 程序继续执行; 至此,程序将在不断地缺页中断中执行。 diff --git a/zh-cn/device-dev/kernel/kernel-small-debug-shell-cmd-free.md b/zh-cn/device-dev/kernel/kernel-small-debug-shell-cmd-free.md index 5470f71225fa8388944780a83da7809a4a8a77e1..7530dfc1fc39729c4519002995fef25e3c929610 100644 --- a/zh-cn/device-dev/kernel/kernel-small-debug-shell-cmd-free.md +++ b/zh-cn/device-dev/kernel/kernel-small-debug-shell-cmd-free.md @@ -37,14 +37,14 @@ free \[_-k | -m_\]

-k

以KB为单位显示。

+

以KiB为单位显示。

N/A

-m

以MB为单位显示。

+

以MiB为单位显示。

N/A

LOS_TraceBufDataGet

Trace数据获取到堆缓存(缓存空间内部申请,使用完需显示释放)

+

Trace数据获取到堆缓存(缓存空间内部申请,使用完需显式释放)

LOS_Trace2File

diff --git a/zh-cn/device-dev/kernel/kernel-small-overview.md b/zh-cn/device-dev/kernel/kernel-small-overview.md index 85151373f45051fbc9813d33976e1459e8abe05a..703cf6241c3aa10ad15908cb30bdb5085595ad84 100644 --- a/zh-cn/device-dev/kernel/kernel-small-overview.md +++ b/zh-cn/device-dev/kernel/kernel-small-overview.md @@ -33,7 +33,7 @@ OpenHarmony 轻量级内核是基于IoT领域轻量级物联网操作系统Huawe **图 1** OpenHarmony LiteOS-A内核架构图 -![](figure/zh-cn_image_0000001179063579.png) +![](figure/zh-cn_image_0000001191018697.png) - 基础内核主要包括内核的基础机制,如调度、内存管理、中断异常等 - 扩展组件主要包括文件系统、网络协议和安全等扩展功能 diff --git a/zh-cn/device-dev/kernel/kernel-small-start-user.md b/zh-cn/device-dev/kernel/kernel-small-start-user.md index e5f2ad5e8dd9bd91cdd96b3b9c61f2603d658ddd..d8feb2a066db4796bc2fb9705422a9644b54ad6c 100644 --- a/zh-cn/device-dev/kernel/kernel-small-start-user.md +++ b/zh-cn/device-dev/kernel/kernel-small-start-user.md @@ -39,7 +39,7 @@ LITE_USER_SEC_ENTRY VOID OsUserInit(VOID *args) - 启动关键系统程序或服务,如交互进程shell。 >![](../public_sys-resources/icon-note.gif) **说明:** - >在OpenHarmony 中**init**进程通过读取/etc/init.cfg,根据配置执行指定命令,或启动指定进程(详见:[init启动引导](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/init%E5%90%AF%E5%8A%A8%E5%BC%95%E5%AF%BC%E7%BB%84%E4%BB%B6.md))。 + >在OpenHarmony 中**init**进程通过读取/etc/init.cfg,根据配置执行指定命令,或启动指定进程(详见:[init启动引导](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-boot-init.md))。 - 监控回收孤儿进程,清理子进程中的僵尸进程。 @@ -48,7 +48,7 @@ LITE_USER_SEC_ENTRY VOID OsUserInit(VOID *args) 用户态程序常见编译方式有如下两种: -1. [利用框架编译用户态进程](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/quick-start/%E8%BF%90%E8%A1%8CHello-OHOS.md)。 +1. [利用框架编译用户态进程](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/quick-start/quickstart-lite-steps-hi3516-running.md)。 2. 手动编译 实例: @@ -57,7 +57,7 @@ LITE_USER_SEC_ENTRY VOID OsUserInit(VOID *args) clang --target=arm-liteos --sysroot=prebuilts/lite/sysroot -o helloworld helloworld.c ``` - **clang**:编译器下载:[llvm安装指导](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/quick-start/Ubuntu%E7%BC%96%E8%AF%91%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87.md#section12202192215415)。 + **clang**:参考[LLVM安装指导](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/quick-start/quickstart-lite-env-setup-linux.md)安装LLVM编译器。 **--target**:--target=arm-liteos,指定编译平台为arm-liteos。 diff --git a/zh-cn/device-dev/porting/Readme-CN.md b/zh-cn/device-dev/porting/Readme-CN.md index 32f2176a2d3ee35afe7adbb8fc516b9e83afc278..71d0fcb98f2c03934f85f9a727a0f39e5d7dfbc6 100755 --- a/zh-cn/device-dev/porting/Readme-CN.md +++ b/zh-cn/device-dev/porting/Readme-CN.md @@ -21,12 +21,37 @@ repo init -u https://gitee.com/openharmony-sig/manifest.git -b master -m devboar ## 开始移植你的开发板 -- [轻量级系统](transplant-minichip.md) -- [小型系统](transplant-smallchip.md) -- [标准系统](standard-system-porting-guide.md) +- [轻量系统芯片移植指导](porting-minichip.md) + - [移植准备](porting-chip-prepare.md) + - [移植须知](oem_transplant_chip_prepare_knows.md) + - [编译构建适配流程](porting-chip-prepare-process.md) + - [内核移植](porting-chip-kernel.md) + - [移植概述](porting-chip-kernel-overview.md) + - [内核基础适配](porting-chip-kernel-adjustment.md) + - [内核移植验证](porting-chip-kernel-verify.md) + - [板级系统移植](porting-chip-board.md) + - [移植概述](porting-chip-board-overview.md) + - [板级驱动适配](porting-chip-board-driver.md) + - [HAL层实现](porting-chip-board-hal.md) + - [系统组件调用](porting-chip-board-component.md) + - [三方组件适配](porting-chip-board-bundle.md) + - [XTS认证](porting-chip-board-xts.md) + - [常见问题](porting-chip-faqs.md) +- [小型系统芯片移植指导](porting-smallchip.md) + - [移植准备](porting-smallchip-prepare.md) + - [移植须知](porting-smallchip-prepare-needs.md) + - [编译构建](porting-smallchip-prepare-building.md) + - [移植内核](porting-smallchip-kernel.md) + - [LiteOS-A内核](porting-smallchip-kernel-a.md) + - [Linux内核](porting-smallchip-kernel-linux.md) + - [驱动移植](porting-smallchip-driver.md) + - [移植概述](porting-smallchip-driver-overview.md) + - [平台驱动移植](porting-smallchip-driver-plat.md) + - [器件驱动移植](porting-smallchip-driver-oom.md) +- [标准系统移植指南](standard-system-porting-guide.md) # 三方库移植 -- [三方库移植指导](transplant-thirdparty.md) - - +- [概述](porting-thirdparty-overview.md) +- [CMake方式组织编译的库移植](porting-thirdparty-cmake.md) +- [Makefile方式组织编译的库移植](porting-thirdparty-makefile.md) \ No newline at end of file diff --git a/zh-cn/device-dev/porting/figure/HDF_WIFI.png b/zh-cn/device-dev/porting/figure/HDF_WIFI.png index c325922a5ee67edb81aa526de1547716fae1a04b..56e6ab3aee9a539c76afd3edac98f21bff0766d5 100644 Binary files a/zh-cn/device-dev/porting/figure/HDF_WIFI.png and b/zh-cn/device-dev/porting/figure/HDF_WIFI.png differ diff --git "a/zh-cn/device-dev/porting/figure/WLAN\350\212\257\347\211\207.png" "b/zh-cn/device-dev/porting/figure/WLAN\350\212\257\347\211\207.png" new file mode 100644 index 0000000000000000000000000000000000000000..c325922a5ee67edb81aa526de1547716fae1a04b Binary files /dev/null and "b/zh-cn/device-dev/porting/figure/WLAN\350\212\257\347\211\207.png" differ diff --git a/zh-cn/device-dev/porting/transplant-chip-prepare-knows.md b/zh-cn/device-dev/porting/oem_transplant_chip_prepare_knows.md similarity index 94% rename from zh-cn/device-dev/porting/transplant-chip-prepare-knows.md rename to zh-cn/device-dev/porting/oem_transplant_chip_prepare_knows.md index 6c0282c492baf353133e15ad5fb6c24da7a2e8d9..4de0e275eef061e53fa143d15c56cd7a61862ec4 100644 --- a/zh-cn/device-dev/porting/transplant-chip-prepare-knows.md +++ b/zh-cn/device-dev/porting/oem_transplant_chip_prepare_knows.md @@ -33,7 +33,7 @@ OpenHarmony整体工程较为复杂,目录及实现为系统本身功能,如

/device

板级相关实现,各个三方厂商按照OpenHarmony规范适配实现,device下具体目录结构及移植过程参见板级系统移植

+

板级相关实现,各个三方厂商按照OpenHarmony规范适配实现,device下具体目录结构及移植过程参见板级系统移植

/vendor

@@ -80,5 +80,5 @@ OpenHarmony的device目录是基础芯片的适配目录,如果在三方芯片 ## 移植规范 - 满足OpenHarmony[开源贡献基本规范和准则](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E5%8F%82%E4%B8%8E%E8%B4%A1%E7%8C%AE.md)。 -- 三方芯片适配所需要贡献的代码主要在device、vendor和arch三个目录,参照[内核目录规范](transplant-chip-kernel-overview.md)和[板级目录规范](transplant-chip-board-overview.md#section6204129143013)满足基本目录命名和使用规范。 +- 三方芯片适配所需要贡献的代码主要在device、vendor和arch三个目录,参照[内核目录规范](porting-chip-kernel-overview.md)和[板级目录规范](porting-chip-board-overview.md#section6204129143013)满足基本目录命名和使用规范。 diff --git a/zh-cn/device-dev/porting/transplant-chip-board-bundle.md b/zh-cn/device-dev/porting/porting-chip-board-bundle.md similarity index 99% rename from zh-cn/device-dev/porting/transplant-chip-board-bundle.md rename to zh-cn/device-dev/porting/porting-chip-board-bundle.md index 8e235f7c54dd67da05510aa4f0e80a4e71e2c183..d29e4480efa8927c6f4d797e3b0cbd8a2af05f9e 100644 --- a/zh-cn/device-dev/porting/transplant-chip-board-bundle.md +++ b/zh-cn/device-dev/porting/porting-chip-board-bundle.md @@ -19,7 +19,6 @@ } ``` - 注意,上面的修改最好都新建一个config或者新建一个xxx\_alt.c文件来修改,不要直接在原先的代码中修改,侵入式的修改会导致后续版本升级出现大量零散冲突,增加升级维护成本。 2. 制作patch diff --git a/zh-cn/device-dev/porting/transplant-chip-board-component.md b/zh-cn/device-dev/porting/porting-chip-board-component.md similarity index 100% rename from zh-cn/device-dev/porting/transplant-chip-board-component.md rename to zh-cn/device-dev/porting/porting-chip-board-component.md diff --git a/zh-cn/device-dev/porting/transplant-chip-board-drive.md b/zh-cn/device-dev/porting/porting-chip-board-driver.md old mode 100755 new mode 100644 similarity index 100% rename from zh-cn/device-dev/porting/transplant-chip-board-drive.md rename to zh-cn/device-dev/porting/porting-chip-board-driver.md diff --git a/zh-cn/device-dev/porting/transplant-chip-board-hal.md b/zh-cn/device-dev/porting/porting-chip-board-hal.md old mode 100755 new mode 100644 similarity index 100% rename from zh-cn/device-dev/porting/transplant-chip-board-hal.md rename to zh-cn/device-dev/porting/porting-chip-board-hal.md diff --git a/zh-cn/device-dev/porting/transplant-chip-board-overview.md b/zh-cn/device-dev/porting/porting-chip-board-overview.md similarity index 94% rename from zh-cn/device-dev/porting/transplant-chip-board-overview.md rename to zh-cn/device-dev/porting/porting-chip-board-overview.md index 732872af5b5e2558bf8b298f918872b2eec030b5..eada2b43da18f4f8371ab449a0b3570d27ce30c1 100644 --- a/zh-cn/device-dev/porting/transplant-chip-board-overview.md +++ b/zh-cn/device-dev/porting/porting-chip-board-overview.md @@ -17,7 +17,7 @@ ## 板级目录规范 -板级系统编译适配参考[编译系统介绍](transplant-chip-prepare-process.md),板级相关的驱动、SDK、目录、HAL实现存放在device目录,目录结构和具体描述如下: +板级系统编译适配参考[编译系统介绍](porting-chip-prepare-process.md),板级相关的驱动、SDK、目录、HAL实现存放在device目录,目录结构和具体描述如下: ``` . diff --git a/zh-cn/device-dev/porting/transplant-chip-board-xts.md b/zh-cn/device-dev/porting/porting-chip-board-xts.md similarity index 100% rename from zh-cn/device-dev/porting/transplant-chip-board-xts.md rename to zh-cn/device-dev/porting/porting-chip-board-xts.md diff --git a/zh-cn/device-dev/porting/porting-chip-board.md b/zh-cn/device-dev/porting/porting-chip-board.md new file mode 100644 index 0000000000000000000000000000000000000000..2a5223401bcba6e6b8f28aee176d36289a362970 --- /dev/null +++ b/zh-cn/device-dev/porting/porting-chip-board.md @@ -0,0 +1,15 @@ +# 板级系统移植 + +- **[移植概述](porting-chip-board-overview.md)** + +- **[板级驱动适配](porting-chip-board-driver.md)** + +- **[HAL层实现](porting-chip-board-hal.md)** + +- **[系统组件调用](porting-chip-board-component.md)** + +- **[三方组件适配](porting-chip-board-bundle.md)** + +- **[XTS认证](porting-chip-board-xts.md)** + + diff --git a/zh-cn/device-dev/porting/transplant-chip-faqs.md b/zh-cn/device-dev/porting/porting-chip-faqs.md old mode 100755 new mode 100644 similarity index 100% rename from zh-cn/device-dev/porting/transplant-chip-faqs.md rename to zh-cn/device-dev/porting/porting-chip-faqs.md diff --git a/zh-cn/device-dev/porting/transplant-chip-kernel-adjustment.md b/zh-cn/device-dev/porting/porting-chip-kernel-adjustment.md similarity index 100% rename from zh-cn/device-dev/porting/transplant-chip-kernel-adjustment.md rename to zh-cn/device-dev/porting/porting-chip-kernel-adjustment.md diff --git a/zh-cn/device-dev/porting/transplant-chip-kernel-overview.md b/zh-cn/device-dev/porting/porting-chip-kernel-overview.md similarity index 100% rename from zh-cn/device-dev/porting/transplant-chip-kernel-overview.md rename to zh-cn/device-dev/porting/porting-chip-kernel-overview.md diff --git a/zh-cn/device-dev/porting/transplant-chip-kernel-verify.md b/zh-cn/device-dev/porting/porting-chip-kernel-verify.md similarity index 95% rename from zh-cn/device-dev/porting/transplant-chip-kernel-verify.md rename to zh-cn/device-dev/porting/porting-chip-kernel-verify.md index fc16eeb224f18814ed2c114a8fe3f4a07fea59b3..1df4bdd6f7b3edf8737962336b39e9bf78c4d22b 100644 --- a/zh-cn/device-dev/porting/transplant-chip-kernel-verify.md +++ b/zh-cn/device-dev/porting/porting-chip-kernel-verify.md @@ -55,5 +55,5 @@ LITE_OS_SEC_TEXT_INIT int main(void) } ``` -第一个任务运行正常后,说明最小系统的核心流程基本OK;由于xts用例框架对外依赖较多,主要是utils、bootstrap的链接脚本和编译框架,暂时无法支撑内核单独跑xts;此处略过内核测试套的测试,可以通过[XTS测试套](transplant-chip-board-xts.md)来覆盖最小系统是否完整移植成功。 +第一个任务运行正常后,说明最小系统的核心流程基本OK;由于xts用例框架对外依赖较多,主要是utils、bootstrap的链接脚本和编译框架,暂时无法支撑内核单独跑xts;此处略过内核测试套的测试,可以通过[XTS测试套](porting-chip-board-xts.md)来覆盖最小系统是否完整移植成功。 diff --git a/zh-cn/device-dev/porting/porting-chip-kernel.md b/zh-cn/device-dev/porting/porting-chip-kernel.md new file mode 100644 index 0000000000000000000000000000000000000000..b488ca9132ba1421d84a15ee0a28182b3e431052 --- /dev/null +++ b/zh-cn/device-dev/porting/porting-chip-kernel.md @@ -0,0 +1,9 @@ +# 内核移植 + +- **[移植概述](porting-chip-kernel-overview.md)** + +- **[内核基础适配](porting-chip-kernel-adjustment.md)** + +- **[内核移植验证](porting-chip-kernel-verify.md)** + + diff --git a/zh-cn/device-dev/porting/transplant-chip-prepare-process.md b/zh-cn/device-dev/porting/porting-chip-prepare-process.md similarity index 99% rename from zh-cn/device-dev/porting/transplant-chip-prepare-process.md rename to zh-cn/device-dev/porting/porting-chip-prepare-process.md index f8128b4735c30e9c4d669c3cb8f302a3caf435ef..c9fe780d754e5142e3259f245f8f7d4bf14c18d6 100644 --- a/zh-cn/device-dev/porting/transplant-chip-prepare-process.md +++ b/zh-cn/device-dev/porting/porting-chip-prepare-process.md @@ -25,7 +25,6 @@ 编译构建会按产品的选择的开发板,加载对应的config.gni,该文件中变量对系统组件全局可见。 - 以芯片解决方案厂商realtek的“rtl8720“开发板为例,device/realtek/rtl8720/liteos\_m/config.gni的内容如下: ``` diff --git a/zh-cn/device-dev/porting/porting-chip-prepare.md b/zh-cn/device-dev/porting/porting-chip-prepare.md new file mode 100644 index 0000000000000000000000000000000000000000..64ee48b8940843e378cc2fd767f0206ae6a5d444 --- /dev/null +++ b/zh-cn/device-dev/porting/porting-chip-prepare.md @@ -0,0 +1,7 @@ +# 移植准备 + +- **[移植须知](oem_transplant_chip_prepare_knows.md)** + +- **[编译构建适配流程](porting-chip-prepare-process.md)** + + diff --git a/zh-cn/device-dev/porting/porting-minichip.md b/zh-cn/device-dev/porting/porting-minichip.md new file mode 100644 index 0000000000000000000000000000000000000000..cbd7bbcbda08bc96e2a9b18a8d628426544e38d9 --- /dev/null +++ b/zh-cn/device-dev/porting/porting-minichip.md @@ -0,0 +1,11 @@ +# 轻量系统芯片移植指导 + +- **[移植准备](porting-chip-prepare.md)** + +- **[内核移植](porting-chip-kernel.md)** + +- **[板级系统移植](porting-chip-board.md)** + +- **[常见问题](porting-chip-faqs.md)** + + diff --git a/zh-cn/device-dev/porting/transplant-smallchip-drive-oom.md b/zh-cn/device-dev/porting/porting-smallchip-driver-oom.md similarity index 100% rename from zh-cn/device-dev/porting/transplant-smallchip-drive-oom.md rename to zh-cn/device-dev/porting/porting-smallchip-driver-oom.md diff --git a/zh-cn/device-dev/porting/transplant-smallchip-drive-des.md b/zh-cn/device-dev/porting/porting-smallchip-driver-overview.md similarity index 100% rename from zh-cn/device-dev/porting/transplant-smallchip-drive-des.md rename to zh-cn/device-dev/porting/porting-smallchip-driver-overview.md diff --git a/zh-cn/device-dev/porting/transplant-smallchip-drive-plat.md b/zh-cn/device-dev/porting/porting-smallchip-driver-plat.md similarity index 100% rename from zh-cn/device-dev/porting/transplant-smallchip-drive-plat.md rename to zh-cn/device-dev/porting/porting-smallchip-driver-plat.md diff --git a/zh-cn/device-dev/porting/porting-smallchip-driver.md b/zh-cn/device-dev/porting/porting-smallchip-driver.md new file mode 100644 index 0000000000000000000000000000000000000000..5b2a0921c904135c90d0decda6f55b96a8737b81 --- /dev/null +++ b/zh-cn/device-dev/porting/porting-smallchip-driver.md @@ -0,0 +1,9 @@ +# 驱动移植 + +- **[移植概述](porting-smallchip-driver-overview.md)** + +- **[平台驱动移植](porting-smallchip-driver-plat.md)** + +- **[器件驱动移植](porting-smallchip-driver-oom.md)** + + diff --git a/zh-cn/device-dev/porting/transplant-smallchip-kernel-a.md b/zh-cn/device-dev/porting/porting-smallchip-kernel-a.md similarity index 96% rename from zh-cn/device-dev/porting/transplant-smallchip-kernel-a.md rename to zh-cn/device-dev/porting/porting-smallchip-kernel-a.md index f4de2f397dbc53de27f711e7bfa1e909a35b222c..1588a5c84a8d3e16051e2760f33e30be12875a0d 100644 --- a/zh-cn/device-dev/porting/transplant-smallchip-kernel-a.md +++ b/zh-cn/device-dev/porting/porting-smallchip-kernel-a.md @@ -26,10 +26,12 @@ LiteOS-A提供系统运行所需的系统初始化流程和定制化配置选项 如下图所示,LiteOS-A的初始化流程主要包含以下五步: 1. 新增target\_config.h文件,并且编写单板内存相关的配置宏DDR\_MEM\_ADDR和DDR\_MEM\_SIZE,分别表示内存起始地址和内存的长度,预链接脚本board.ld.S会根据这两个宏进行展开生成链接脚本board.ld。 -2. 链接阶段根据链接脚本board.ld生成内核镜像。 -3. 单核CPU镜像运行入口为汇编文件reset\_vector\_up.S,多核CPU的入口为reset\_vector\_mp.S,在汇编文件中进行中断向量表初始化、MMU页表初始化等操作。 -4. reset\_vector.S汇编代码最终会跳转到C语言的main函数,进行硬件时钟、软件定时器、内存和任务等初始化,这个过程会依赖target\_config.h的特性宏配置,最后会创建SystemInit任务,并且开启任务调度OsSchedStart\(\)。 -5. SystemInit任务在单板代码中实现,其中调用DeviceManagerStart函数进行HDF驱动初始化,这个过程会调用单板代码中的驱动配置文件hdf.hcs以及drivers源码实现。 +2. 新增定义MMU映射全局数组\(g\_archMmuInitMapping\),指定各个内存段属性及虚实映射关系,内核启动阶段根据该表建立内存映射关系。 +3. 如果是多核,需要新增定义从核操作函数句柄\(struct SmpOps\),其中SmpOps-\>SmpCpuOn函数需要实现唤醒从核的功能;接着定义SmpRegFunc函数,调用LOS\_SmpOpsSet接口进行句柄注册;最后通过启动框架完成注册过程,即LOS\_MODULE\_INIT\(SmpRegFunc, LOS\_INIT\_LEVEL\_EARLIEST\)。 +4. 链接阶段根据链接脚本board.ld生成内核镜像。 +5. 单核CPU镜像运行入口为汇编文件reset\_vector\_up.S,多核CPU的入口为reset\_vector\_mp.S,在汇编文件中进行中断向量表初始化、MMU页表初始化等操作。 +6. reset\_vector.S汇编代码最终会跳转到C语言的main函数,进行硬件时钟、软件定时器、内存和任务等初始化,这个过程会依赖target\_config.h的特性宏配置,最后会创建SystemInit任务,并且开启任务调度OsSchedStart\(\)。 +7. SystemInit任务在单板代码中实现,其中调用DeviceManagerStart函数进行HDF驱动初始化,这个过程会调用单板代码中的驱动配置文件hdf.hcs以及drivers源码实现 整体启动流程如下图所示: diff --git a/zh-cn/device-dev/porting/transplant-smallchip-kernel-linux.md b/zh-cn/device-dev/porting/porting-smallchip-kernel-linux.md similarity index 99% rename from zh-cn/device-dev/porting/transplant-smallchip-kernel-linux.md rename to zh-cn/device-dev/porting/porting-smallchip-kernel-linux.md index 911329dbd1b9971e422b9242171c031102a137b0..a467d3cdf26edadcd26a6f25da304bb265e852d7 100644 --- a/zh-cn/device-dev/porting/transplant-smallchip-kernel-linux.md +++ b/zh-cn/device-dev/porting/porting-smallchip-kernel-linux.md @@ -87,7 +87,6 @@ Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后 启动配置在vendor/\{company\}/\{product\}/init\_configs/etc目录下,包括fstab、rsS和Sxxx文件,请按开发板实际情况配置。 - 编译完成后,可通过检查产品编译输出目录下的rootfs内容,确认rootfs.img文件生成是否符合预期。 2. 调试init进程和shell。 diff --git a/zh-cn/device-dev/porting/porting-smallchip-kernel.md b/zh-cn/device-dev/porting/porting-smallchip-kernel.md new file mode 100644 index 0000000000000000000000000000000000000000..2d13c4839377e4a433c3efb6cd1a446e3f780074 --- /dev/null +++ b/zh-cn/device-dev/porting/porting-smallchip-kernel.md @@ -0,0 +1,7 @@ +# 移植内核 + +- **[LiteOS-A内核](porting-smallchip-kernel-a.md)** + +- **[Linux内核](porting-smallchip-kernel-linux.md)** + + diff --git a/zh-cn/device-dev/porting/transplant-smallchip-prepare-building.md b/zh-cn/device-dev/porting/porting-smallchip-prepare-building.md similarity index 100% rename from zh-cn/device-dev/porting/transplant-smallchip-prepare-building.md rename to zh-cn/device-dev/porting/porting-smallchip-prepare-building.md diff --git a/zh-cn/device-dev/porting/transplant-smallchip-prepare-needs.md b/zh-cn/device-dev/porting/porting-smallchip-prepare-needs.md similarity index 100% rename from zh-cn/device-dev/porting/transplant-smallchip-prepare-needs.md rename to zh-cn/device-dev/porting/porting-smallchip-prepare-needs.md diff --git a/zh-cn/device-dev/porting/porting-smallchip-prepare.md b/zh-cn/device-dev/porting/porting-smallchip-prepare.md new file mode 100644 index 0000000000000000000000000000000000000000..b76d5afe44d24f5c0294e9d5f0a8c5c944e0b72c --- /dev/null +++ b/zh-cn/device-dev/porting/porting-smallchip-prepare.md @@ -0,0 +1,7 @@ +# 移植准备 + +- **[移植须知](porting-smallchip-prepare-needs.md)** + +- **[编译构建](porting-smallchip-prepare-building.md)** + + diff --git a/zh-cn/device-dev/porting/porting-smallchip.md b/zh-cn/device-dev/porting/porting-smallchip.md new file mode 100644 index 0000000000000000000000000000000000000000..df2ce355915f58107c9f9e431a25d69a86d83351 --- /dev/null +++ b/zh-cn/device-dev/porting/porting-smallchip.md @@ -0,0 +1,9 @@ +# 小型系统芯片移植指导 + +- **[移植准备](porting-smallchip-prepare.md)** + +- **[移植内核](porting-smallchip-kernel.md)** + +- **[驱动移植](porting-smallchip-driver.md)** + + diff --git a/zh-cn/device-dev/porting/transplant-thirdparty-cmake.md b/zh-cn/device-dev/porting/porting-thirdparty-cmake.md similarity index 97% rename from zh-cn/device-dev/porting/transplant-thirdparty-cmake.md rename to zh-cn/device-dev/porting/porting-thirdparty-cmake.md index 670acc13ba9d4cbd6884beb806e069d7705ba545..6800ba882e2a34476c4aeafa6e4f107af8cb0a9b 100644 --- a/zh-cn/device-dev/porting/transplant-thirdparty-cmake.md +++ b/zh-cn/device-dev/porting/porting-thirdparty-cmake.md @@ -136,10 +136,10 @@ CMake方式可通过指定工具链进行交叉编译,修改并编译该库, set(CMAKE_LINKER clang) set(CMAKE_CXX_LINKER clang++) set(CMAKE_C_LINKER clang) - set(CMAKE_C_LINK_EXECUTABLE "${CMAKE_C_LINKER} - ${MY_LINK_FLAGS} -o ") - set(CMAKE_CXX_LINK_EXECUTABLE "${CMAKE_CXX_LINKER} - ${MY_LINK_FLAGS} -o ") + set(CMAKE_C_LINK_EXECUTABLE + "${CMAKE_C_LINKER} ${MY_LINK_FLAGS} -o ") + set(CMAKE_CXX_LINK_EXECUTABLE + "${CMAKE_CXX_LINKER} ${MY_LINK_FLAGS} -o ") #指定链接库的查找路径。 set(CMAKE_SYSROOT ${OHOS_SYSROOT_PATH}) ``` @@ -154,7 +154,7 @@ CMake方式可通过指定工具链进行交叉编译,修改并编译该库, make -j ``` - 其中OHOS\_SYSROOT\_PATH需用绝对路径指定出sysroot目录的位置,以OpenHarmony为例即目录openHarmony/prebuilts/lite/sysroot的绝对路径。 + 其中OHOS\_SYSROOT\_PATH需用绝对路径指定出sysroot目录的位置,以OpenHarmony为例即目录out/hispark\_xxx/ipcamera\_hispark\_xxx/sysroot的绝对路径。上述目录会在全量编译后生成,因此移植前先完成一次全量编译。 3. 查看结果 diff --git a/zh-cn/device-dev/porting/transplant-thirdparty-makefile.md b/zh-cn/device-dev/porting/porting-thirdparty-makefile.md similarity index 96% rename from zh-cn/device-dev/porting/transplant-thirdparty-makefile.md rename to zh-cn/device-dev/porting/porting-thirdparty-makefile.md index ddabc1ef30ae29930bea14394ced65ec43e227a2..51627f2fcbf895aa960948877f5eac60f0eec35a 100644 --- a/zh-cn/device-dev/porting/transplant-thirdparty-makefile.md +++ b/zh-cn/device-dev/porting/porting-thirdparty-makefile.md @@ -98,7 +98,7 @@ CC:=clang AR:=llvm-ar #cflags中必须要添加--target及--sysroot选项 - CFLAGS:=-Wall -Wextra -Wno-unused-parameter -O2 -g --target=arm-liteos -march=armv7-a --sysroot=$(OHOS_ROOT_PATH)prebuilts/lite/sysroot + CFLAGS:=-Wall -Wextra -Wno-unused-parameter -O2 -g --target=arm-liteos -march=armv7-a --sysroot=$(OHOS_SYSROOT_PATH) ``` 原有配置 @@ -117,7 +117,7 @@ make test OHOS_SYSROOT_PATH=... ``` - 其中OHOS\_SYSROOT\_PATH需用绝对路径指定出sysroot所在目录,以OpenHarmony为例即源码根目录prebuilts/lite/sysroot/所在的绝对路径。 + 其中OHOS\_SYSROOT\_PATH需用绝对路径指定出sysroot所在目录,以OpenHarmony为例即源码根目录下out/hispark\_xxx/ipcamera\_hispark\_xxx/sysroot目录的绝对路径。上述目录会在全量编译后生成,因此移植前先完成一次全量编译。 3. 查看结果 @@ -148,7 +148,7 @@ ## 测试 -yxml库测试步骤与double-conversion库基本一致,可参考[CMake方式组织编译的库移植](transplant-thirdparty-cmake.md#section6686144293611)的测试过程,以下内容介绍yxml库测试用例的使用方法: +yxml库测试步骤与double-conversion库基本一致,可参考[CMake方式组织编译的库移植](porting-thirdparty-cmake.md#section6686144293611)的测试过程,以下内容介绍yxml库测试用例的使用方法: **表 3** 生成的test目录结构示意 @@ -236,7 +236,7 @@ echo "All tests completed successfully." ## 将该库编译添加到OpenHarmony工程中 -yxml库添加的过程除了适配文件build.gn和config.gni有些许变化外,其他和double-conversion库完全一致,参考[CMake方式组织编译的库移植](transplant-thirdparty-cmake.md#section1651053153715)的配置过程。要修改的适配文件及添加后的目录结构如下: +yxml库添加的过程除了适配文件build.gn和config.gni有些许变化外,其他和double-conversion库完全一致,参考[CMake方式组织编译的库移植](porting-thirdparty-cmake.md#section1651053153715)的配置过程。要修改的适配文件及添加后的目录结构如下: - yxml库新增的BUILD.gn实现如下: diff --git a/zh-cn/device-dev/porting/transplant-thirdparty-overview.md b/zh-cn/device-dev/porting/porting-thirdparty-overview.md old mode 100755 new mode 100644 similarity index 100% rename from zh-cn/device-dev/porting/transplant-thirdparty-overview.md rename to zh-cn/device-dev/porting/porting-thirdparty-overview.md diff --git a/zh-cn/device-dev/porting/porting-thirdparty.md b/zh-cn/device-dev/porting/porting-thirdparty.md new file mode 100644 index 0000000000000000000000000000000000000000..306476fd681c9d20af7a121166156e27402696be --- /dev/null +++ b/zh-cn/device-dev/porting/porting-thirdparty.md @@ -0,0 +1,9 @@ +# 三方库移植指导 + +- **[概述](porting-thirdparty-overview.md)** + +- **[CMake方式组织编译的库移植](porting-thirdparty-cmake.md)** + +- **[Makefile方式组织编译的库移植](porting-thirdparty-makefile.md)** + + diff --git a/zh-cn/device-dev/porting/porting.md b/zh-cn/device-dev/porting/porting.md new file mode 100644 index 0000000000000000000000000000000000000000..735393aaf20573cd471bd71ca0cbef732244b68b --- /dev/null +++ b/zh-cn/device-dev/porting/porting.md @@ -0,0 +1,11 @@ +# 移植 + +- **[三方库移植指导](porting-thirdparty.md)** + +- **[轻量系统芯片移植指导](porting-minichip.md)** + +- **[小型系统芯片移植指导](porting-smallchip.md)** + +- **[标准系统移植指南](standard-system-porting-guide.md)** + + diff --git a/zh-cn/device-dev/porting/standard-system-porting-guide.md b/zh-cn/device-dev/porting/standard-system-porting-guide.md index ad6d4c683add5ea523b6289109e879909cea12a5..b0013ba943a68b299159983804af5bc7cd5ee3cc 100644 --- a/zh-cn/device-dev/porting/standard-system-porting-guide.md +++ b/zh-cn/device-dev/porting/standard-system-porting-guide.md @@ -1,377 +1,510 @@ -# 标准系统移植指南 - - - - - -- [定义开发板](#定义开发板) - - [1. 定义SOC](#1-定义soc) - - [2. 定义产品](#2-定义产品) - - [3. 移植验证](#3-移植验证) -- [内核移植](#内核移植) - - [1. 为SOC添加内核构建的子系统](#1-为soc添加内核构建的子系统) - - [2. 编译内核](#2-编译内核) - - [3. 移植验证](#3-移植验证-1) -- [HDF驱动移植](#hdf驱动移植) - - [1. LCD](#1-lcd) - - [2. 触摸屏](#2-触摸屏) - - [3. WLAN](#3-wlan) - - - -本文描述了移植一块开发板的通用步骤,和具体芯片相关的详细移植过程无法在此一一列举。后续社区还会陆续发布开发板移植的实例供开发者参考。 - -## 定义开发板 - -本文以移植名为MyProduct的开发板为例讲解移植过程,假定MyProduct是MyProductVendor公司的开发板,使用MySoCVendor公司生产的MySOC芯片作为处理器。 - -### 1. 定义SOC - -在`//productdefine/common/device`目录下创建以SOC名字命名的json文件,并指定CPU的架构。 - -如要移植一个叫MySOC的SOC,这个SOC采用32位ARM内核。配置如下: - -`//productdefine/common/device/MySOC.json` -```json -{ - "target_os": "ohos", - "target_cpu": "arm" -} -``` -根据实际情况,这里的target_cpu也可能是arm64 、riscv、 x86等。当前仅支持arm作为target_cpu。 - -### 2. 定义产品 - -在`//productdefine/common/products`目录下创建以产品名命名的json文件。该文件用于描述产品所使用的SOC 以及 所需的子系统。 -配置如下 -`//productdefine/common/products/MyProduct.json` -```json -{ - "product_name": "MyProduct", - "product_company" : "MyProductVendor", - "product_device": "MySOC", - "version": "2.0", - "type": "standard", - "parts":{ - "ace:ace_engine_standard":{}, - "ace:napi":{}, - ... - "xts:phone_tests":{} - } -} - -``` -主要的配置内容包括: - -1. `product_device`:配置所使用的SOC -2. `type`: 配置系统的级别, 这里直接standard即可 -3. `parts`: 系统需要启用的子系统。子系统可以简单理解位一块独立构建的功能块。 - -已定义的子系统可以在`//build/subsystem_config.json`中找到。当然你也可以定制子系统。 - -这里建议先拷贝Hi3516DV300 开发板的配置文件,删除掉 hisilicon_products 这个子系统。这个子系统为Hi3516DV300 SOC编译内核,显然不适合MySOC。 - -### 3. 移植验证 - -至此,你可以使用如下命令,启动你产品的构建了: - -`./build.sh --product-name MyProduct ` - -构建完成后,可以在如下目录看到构建出来的OpenHarmony镜像文件: - -`//out/ohos-arm-release/packages/phone/images` - -## 内核移植 - -这一步需要移植Linux内核,让Linux内核可以成功运行起来。 - -### 1. 为SOC添加内核构建的子系统 - -修改文件 `//build/subsystem_config.json` 增加一个子系统. 配置如下: - -```json - "MySOCVendor_products": { - "project": "hmf/MySOCVendor_products", - "path": "device/MySOCVendor/MySOC/build", - "name": "MySOCVendor_products", - "dir": "device/MySOCVendor" - }, -``` - -接着需要修改定义产品的配置文件`//productdefine/common/products/MyProduct.json`。将刚刚定义的子系统加入到产品中。 - -### 2. 编译内核 - -OpenHarmony源码中提供了Linux 4.19的内核,归档在`//kernel/linux-4.19`。本节以该内核版本为例,讲解如何编译内核。 - -在子系统的定义中,描述了子系统构建的路径path,即`//device/MySOCVendor/MySOC/build`。这一节会在这个目录创建构建脚本,告诉构建系统如何构建内核。 - -建议的目录结构如下: -``` -├── build -│   ├── kernel -│   │ ├── linux -│   │ ├──standard_patch_for_4_19.patch // 基于4.19版本内核的补丁 -│   ├── BUILD.gn -│   ├── ohos.build -``` -BUILD.gn是subsystem构建的唯一入口。 - -期望的构建结果 - -| 文件 | 文件说明| -|------|------| -|$root_build_dir/packages/phone/images/uImage| 内核镜像| -|$root_build_dir/packages/phone/images/uboot | bootloader镜像| - -### 3. 移植验证 - -启动编译,验证预期的kernel镜像是否成功生成。 - -## HDF驱动移植 - -### 1. LCD -HDF为LCD设计了驱动模型。支持一块新的LCD,需要编写一个驱动,在驱动中生成模型的实例,并完成注册。 - -这些LCD的驱动被放置在`//drivers/framework/model/display/driver/panel`目录中。 - -- 创建Panel驱动 - -在驱动的Init方法中,需要调用RegisterPanel接口注册模型实例。如: -```C -int32_t XXXInit(struct HdfDeviceObject *object) -{ - struct PanelData *panel = CreateYourPanel(); - - // 注册 - if (RegisterPanel(panel) != HDF_SUCCESS) { - HDF_LOGE("%s: RegisterPanel failed", __func__); - return HDF_FAILURE; - } - return HDF_SUCCESS; -} - -struct HdfDriverEntry g_xxxxDevEntry = { - .moduleVersion = 1, - .moduleName = "LCD_XXXX", - .Init = XXXInit, -}; - -HDF_INIT(g_xxxxDevEntry); -``` - -- 配置加载panel驱动 -产品的所有设备信息被定义在文件`//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs`中。修改该文件,在display的host中,名为device_lcd的device中增加配置。 -注意:moduleName 要与panel驱动中的moduleName相同。 - -```hcs -root { - ... - display :: host { - device_lcd :: device { - deviceN :: deviceNode { - policy = 0; - priority = 100; - preload = 2; - moduleName = "LCD_XXXX"; - } - } - } -} -``` - -更详细的驱动开发指导,请参考 [LCD](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/LCD.md)。 - -### 2. 触摸屏 -本节描述如何移植触摸屏驱动。触摸屏的驱动被放置在`//drivers/framework/model/input/driver/touchscreen`目录中。移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。 - -- 创建触摸屏器件驱动 - -在目录中创建名为`touch_ic_name.c`的文件。代码模板如下: -注意:请替换ic_name为你所适配芯片的名称。 - -```C -#include "hdf_touch.h" - -static int32_t HdfXXXXChipInit(struct HdfDeviceObject *device) -{ - ChipDevice *tpImpl = CreateXXXXTpImpl(); - if(RegisterChipDevice(tpImpl) != HDF_SUCCESS) { - ReleaseXXXXTpImpl(tpImpl); - return HDF_FAILURE; - } - return HDF_SUCCESS; -} - -struct HdfDriverEntry g_touchXXXXChipEntry = { - .moduleVersion = 1, - .moduleName = "HDF_TOUCH_XXXX", - .Init = HdfXXXXChipInit, -}; - -HDF_INIT(g_touchXXXXChipEntry); -``` - -其中ChipDevice中要提供若干方法: -| 方法| 实现说明| -|------|------| -|int32_t (*Init)(ChipDevice *device)| 器件初始化| -|int32_t (*Detect)(ChipDevice *device)| 器件探测| -|int32_t (*Suspend)(ChipDevice *device)| 器件休眠| -|int32_t (*Resume)(ChipDevice *device)| 器件唤醒| -|int32_t (*DataHandle)(ChipDevice *device)| 从器件读取数据,将触摸点数据填写入device->driver->frameData中| -|int32_t (*UpdateFirmware)(ChipDevice *device)| 固件升级| - -- 配置产品,加载器件驱动 - -产品的所有设备信息被定义在文件`//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs`中。修改该文件,在名为input的host中,名为device_touch_chip的device中增加配置。 -注意:moduleName 要与触摸屏驱动中的moduleName相同。 - -```hcs - deviceN :: deviceNode { - policy = 0; - priority = 130; - preload = 0; - permission = 0660; - moduleName = "HDF_TOUCH_XXXX"; - deviceMatchAttr = "touch_XXXX_configs"; - } -``` - -更详细的驱动开发指导,请参考 [TOUCHSCREEN](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/TOUCHSCREEN.md)。 - - -### 3. WLAN - -Wi-Fi驱动分为两部分,一部分负责管理WLAN设备,另一个部分负责处理WLAN流量。`HDF WLAN`分别为这两部分做了抽象。目前支持SDIO接口的WLAN芯片。 - -Wi-Fi结构图 - -支持一款芯片的主要工作是实现一个ChipDriver驱动。实现HDF_WLAN_CORE和NetDevice提供的接口。主要需要实现的接口有: - -| 接口| 定义头文件| 说明| -|------|------|------| -| HdfChipDriverFactory| `//drivers/framework/include/wifi/hdf_wlan_chipdriver_manager.h`| ChipDriver的Factory,用于支持一个芯片多个Wi-Fi端口| -| HdfChipDriver | `//drivers/framework/include/wifi/wifi_module.h`| 每个WLAN端口对应一个HdfChipDriver,用来管理一个特定的WLAN端口| -|NetDeviceInterFace| `//drivers/framework/include/wifi/net_device.h`| 与协议栈之间的接口,如发送数据、设置网络接口状态等| - -建议适配按如下步骤操作: - -1. 创建HDF驱动 - -建议将代码放置在`//device/MySoCVendor/peripheral/wifi/chip_name/`。 -文件模板如下: - -```C -static int32_t HdfWlanHisiChipDriverInit(struct HdfDeviceObject *device) { - static struct HdfChipDriverFactory factory = CreateChipDriverFactory(); - struct HdfChipDriverManager *driverMgr = HdfWlanGetChipDriverMgr(); - if (driverMgr->RegChipDriver(&factory) != HDF_SUCCESS) { - HDF_LOGE("%s fail: driverMgr is NULL!", __func__); - return HDF_FAILURE; - } - return HDF_SUCCESS; -} - -struct HdfDriverEntry g_hdfXXXChipEntry = { - .moduleVersion = 1, - .Init = HdfWlanXXXChipDriverInit, - .Release = HdfWlanXXXChipRelease, - .moduleName = "HDF_WIFI_CHIP_XXX" -}; - -HDF_INIT(g_hdfXXXChipEntry); -``` - -在CreateChipDriverFactory中需要创建一个HdfChipDriverFactory,接口如下: -| 接口| 说明| -|------|------| -|const char *driverName| 当前driverName | -|int32_t (*InitChip)(struct HdfWlanDevice *device)| 初始化芯片| -|int32_t (*DeinitChip)(struct HdfWlanDevice *device)| 去初始化芯片| -|void (*ReleaseFactory)(struct HdfChipDriverFactory *factory)| 释放HdfChipDriverFactory对象| -|struct HdfChipDriver *(*Build)(struct HdfWlanDevice *device, uint8_t ifIndex)|创建一个HdfChipDriver;输入参数中,device是设备信息,ifIndex是当前创建的接口在这个芯片中的序号| -|void (*Release)(struct HdfChipDriver *chipDriver)| 释放chipDriver -|uint8_t (*GetMaxIFCount)(struct HdfChipDriverFactory *factory)| 获取当前芯片支持的最大接口数| - -HdfChipDriver需要实现的接口有 - -|接口| 说明| -|------|------| -|int32_t (*init)(struct HdfChipDriver *chipDriver, NetDevice *netDev)| 初始化当前网络接口,这里需要向netDev提供接口NetDeviceInterFace| -|int32_t (*deinit)(struct HdfChipDriver *chipDriver, NetDevice *netDev)| 去初始化当前网络接口| -|struct HdfMac80211BaseOps *ops| WLAN基础能力接口集| -|struct HdfMac80211STAOps *staOps| 支持STA模式所需的接口集| -|struct HdfMac80211APOps *apOps| 支持AP模式所需要的接口集| - - - -2. 编写配置文件,描述驱动支持的设备 - -在产品配置目录下创建芯片的配置文件`//vendor/MyProductVendor/MyProduct/config/wifi/wlan_chip_chip_name.hcs`。 -注意: 路径中的vendor_name、product_name、chip_name请替换成实际名称。 -模板如下: -```hcs -root { - wlan_config { - chip_name :& chipList { - chip_name :: chipInst { - match_attr = "hdf_wlan_chips_chip_name"; /* 这是配置匹配属性,用于提供驱动的配置根 */ - driverName = "driverName"; /* 需要与HdfChipDriverFactory中的driverName相同*/ - sdio { - vendorId = 0x0296; - deviceId = [0x5347]; - } - } - } - } -} -``` - -3. 编写配置文件,加载驱动 - -产品的所有设备信息被定义在文件`//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs`中。修改该文件,在名为network的host中,名为device_wlan_chips的device中增加配置。 -注意:moduleName 要与触摸屏驱动中的moduleName相同。 -模板如下: - -```hcs - deviceN :: deviceNode { - policy = 0; - preload = 2; - moduleName = "HDF_WLAN_CHIPS"; - deviceMatchAttr = "hdf_wlan_chips_chip_name"; - serviceName = "driverName"; - } -``` - -4. 构建驱动 - -- 创建内核菜单 -在 `//device/MySoCVendor/peripheral` 目录中创建Kconfig文件,内容模板如下: -``` -config DRIVERS_WLAN_XXX - bool "Enable XXX WLAN Host driver" - default n - depends on DRIVERS_HDF_WIFI - help - Answer Y to enable XXX Host driver. Support chip xxx -``` - -接着修改文件 `//drivers/adapter/khdf/linux/model/network/wifi/Kconfig`,在文件末尾加入如下代码将配置菜单加入内核中。如: -``` -source "../../../../../device/MySoCVendor/peripheral/Kconfig" -``` - -- 创建构建脚本 - -在`//drivers/adapter/khdf/linux/model/network/wifi/Makefile` 文件末尾增加配置,模板如下: - -``` -HDF_DEVICE_ROOT := $(HDF_DIR_PREFIX)/../device -obj-$(CONFIG_DRIVERS_WLAN_XXX) += $(HDF_DEVICE_ROOT)/MySoCVendor/peripheral/build/standard/ -``` - -当在内核中开启`DRIVERS_WLAN_XXX`开关时,会调用`//device/MySoCVendor/peripheral/build/standard/`中的makefile。 - - -更多详细的开发手册,请参考[WLAN开发](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/WLAN.md)。 \ No newline at end of file +# 标准系统移植指南 + +- [定义开发板](#section132mcpsimp) + - [定义SOC](#section135mcpsimp) + - [定义产品](#section145mcpsimp) + - [移植验证](#section163mcpsimp) + +- [内核移植](#section171mcpsimp) + - [1.为SOC添加内核构建的子系统](#section174mcpsimp) + - [2. 编译内核](#section182mcpsimp) + - [3. 移植验证](#section207mcpsimp) + +- [HDF驱动移植](#section210mcpsimp) + - [1. LCD](#section212mcpsimp) + - [2. 触摸屏](#section229mcpsimp) + - [3. WLAN](#section274mcpsimp) + + +## 定义开发板 + +本文以移植名为MyProduct的开发板为例讲解移植过程,假定MyProduct是MyProductVendor公司的开发板,使用MySoCVendor公司生产的MySOC芯片作为处理器。 + +### 定义SOC + +在“//productdefine/common/device”目录下创建以SOC名字命名的json文件,并指定CPU的架构。 + +如要移植一个叫MySOC的SOC,这个SOC采用32位ARM内核。配置如下: + +//productdefine/common/device/MySOC.json + +``` +{ + "target_os": "ohos", + "target_cpu": "arm" +} +``` + +根据实际情况,这里的target\_cpu也可能是arm64 、riscv、 x86等。当前仅支持arm作为target\_cpu。 + +### 定义产品 + +在“//productdefine/common/products”目录下创建以产品名命名的json文件。该文件用于描述产品所使用的SOC 以及 所需的子系统。配置如下 + +//productdefine/common/products/MyProduct.json + +``` +{ + "product_name": "MyProduct", + "product_company" : "MyProductVendor", + "product_device": "MySOC", + "version": "2.0", + "type": "standard", + "parts":{ + "ace:ace_engine_standard":{}, + "ace:napi":{}, + ... + "xts:phone_tests":{} + } +} + +``` + +主要的配置内容包括: + +1. product\_device:配置所使用的SOC +2. type:配置系统的级别, 这里直接standard即可 +3. parts:系统需要启用的子系统。子系统可以简单理解位一块独立构建的功能块。 + +已定义的子系统可以在“//build/subsystem\_config.json”中找到。当然你也可以定制子系统。 + +这里建议先拷贝Hi3516DV300 开发板的配置文件,删除掉 hisilicon\_products 这个子系统。这个子系统为Hi3516DV300 SOC编译内核,显然不适合MySOC。 + +### 移植验证 + +至此,你可以使用如下命令,启动你产品的构建了: + +``` +./build.sh --product-name MyProduct +``` + +构建完成后,可以在“//out/ohos-arm-release/packages/phone/images”目录下看到构建出来的HarmonyOSOpenHarmony镜像文件。 + +## 内核移植 + +这一步需要移植Linux内核,让Linux内核可以成功运行起来。 + +### 1.为SOC添加内核构建的子系统 + +修改文件 //build/subsystem\_config.json增加一个子系统. 配置如下: + +``` + "MySOCVendor_products": { + "project": "hmf/MySOCVendor_products", + "path": "device/MySOCVendor/MySOC/build", + "name": "MySOCVendor_products", + "dir": "device/MySOCVendor" + }, +``` + +接着需要修改定义产品的配置文件//productdefine/common/products/MyProduct.json。将刚刚定义的子系统加入到产品中 + +### 2. 编译内核 + +在上一节定义subsystem的时候,定义了构建的路径path,即//device/MySOCVendor/MySOC/build。这一节会在这个目录创建构建脚本,告诉构建系统如何构建内核。 + +目前OpenHarmony源码中提供了Linux 4.19的内核,归档在//kernel/linux-4.19。请尽可能使用这个内核。每个SOC必然需要对内核做一些修改或扩展,建议采用补丁的方式。 + +建议的目录结构 + +``` +├── build +│   ├── kernel +│   │ ├── linux +│   │ ├──standard_patch_for_4_19.patch +│   ├── BUILD.gn +│   ├── ohos.build +``` + +BUILD.gn是subsystem构建的唯一入口。 + +期望的构建结果 + + + + + + + + + + + + +

文件

+

文件说明

+

$root_build_dir/packages/phone/images/uImage

+

内核镜像

+

$root_build_dir/packages/phone/images/uboot

+

bootloader镜像

+
+ +### 3. 移植验证 + +启动编译,验证预期的kernel镜像是否成功生成。 + +## HDF驱动移植 + +### 1. LCD + +HDF为LCD设计了驱动模型。支持一块新的LCD,需要编写一个驱动,在驱动中生成模型的实例,并完成注册。 + +这些LCD的驱动被放置在//drivers/framework/model/display/driver/panel目录中。 + +- 创建Panel驱动 + +在驱动的Init方法中,需要调用RegisterPanel接口注册模型实例。如: + +``` +int32_t XXXInit(struct HdfDeviceObject *object) +{ + struct PanelData *panel = CreateYourPanel(); + + // 注册 + if (RegisterPanel(panel) != HDF_SUCCESS) { + HDF_LOGE("%s: RegisterPanel failed", __func__); + return HDF_FAILURE; + } + return HDF_SUCCESS; +} + +struct HdfDriverEntry g_xxxxDevEntry = { + .moduleVersion = 1, + .moduleName = "LCD_XXXX", + .Init = XXXInit, +}; + +HDF_INIT(g_xxxxDevEntry); +``` + +- 配置加载panel驱动产品的所有设备信息被定义在文件//vendor/MyProductVendor/MyProduct/config/device\_info/device\_info.hcs中。修改该文件,在display的host中,名为device\_lcd的device中增加配置。注意:moduleName 要与panel驱动中的moduleName相同。 + +``` +root { + ... + display :: host { + device_lcd :: device { + deviceN :: deviceNode { + policy = 0; + priority = 100; + preload = 2; + moduleName = "LCD_XXXX"; + } + } + } +} +``` + +更详细的驱动开发指导,请参考 [LCD](../driver/driver-peripherals-lcd-des.md) + +### 2. 触摸屏 + +本节描述如何移植触摸屏驱动。触摸屏的驱动被放置在//drivers/framework/model/input/driver/touchscreen目录中。移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。 + +- 创建触摸屏器件驱动 + +在目录中创建名为 + +``` +touch_ic_name.c +``` + +的文件。代码模板如下:注意:请替换ic\_name为你所适配芯片的名称 + +``` +#include "hdf_touch.h" + +static int32_t HdfXXXXChipInit(struct HdfDeviceObject *device) +{ + ChipDevice *tpImpl = CreateXXXXTpImpl(); + if(RegisterChipDevice(tpImpl) != HDF_SUCCESS) { + ReleaseXXXXTpImpl(tpImpl); + return HDF_FAILURE; + } + return HDF_SUCCESS; +} + +struct HdfDriverEntry g_touchXXXXChipEntry = { + .moduleVersion = 1, + .moduleName = "HDF_TOUCH_XXXX", + .Init = HdfXXXXChipInit, +}; + +HDF_INIT(g_touchXXXXChipEntry); +``` + +其中ChipDevice中要提供若干方法 + + + + + + + + + + + + + + + + + + + + + + + + +

方法

+

实现说明

+

int32_t (*Init)(ChipDevice *device)

+

器件初始化

+

int32_t (*Detect)(ChipDevice *device)

+

器件探测

+

int32_t (*Suspend)(ChipDevice *device)

+

器件休眠

+

int32_t (*Resume)(ChipDevice *device)

+

器件唤醒

+

int32_t (*DataHandle)(ChipDevice *device)

+

从器件读取数据,将触摸点数据填写入device->driver->frameData中

+

int32_t (*UpdateFirmware)(ChipDevice *device)

+

固件升级

+
+ +- 配置产品,加载器件驱动 + + 产品的所有设备信息被定义在文件//vendor/MyProductVendor/MyProduct/config/device\_info/device\_info.hcs中。修改该文件,在名为input的host中,名为device\_touch\_chip的device中增加配置。注意:moduleName 要与触摸屏驱动中的moduleName相同。 + + +``` + deviceN :: deviceNode { + policy = 0; + priority = 130; + preload = 0; + permission = 0660; + moduleName = "HDF_TOUCH_XXXX"; + deviceMatchAttr = "touch_XXXX_configs"; + } +``` + +更详细的驱动开发指导,请参考 [TOUCHSCREEN](../driver/driver-peripherals-touch-des.md) + +### 3. WLAN + +Wi-Fi驱动分为两部分,一部分负责管理WLAN设备,另一个部分负责处理WLAN流量。HDF WLAN分别为这两部分做了抽象。目前支持SDIO接口的WLAN芯片。 + +**图 1** WLAN芯片 +![](figure/WLAN芯片.png "WLAN芯片") + +支持一款芯片的主要工作是实现一个ChipDriver驱动。实现HDF\_WLAN\_CORE和NetDevice提供的接口。主要需要实现的接口有: + + + + + + + + + + + + + + + + + + + +

接口

+

定义头文件

+

说明

+

HdfChipDriverFactory

+
//drivers/framework/include/wifi/hdf_wlan_chipdriver_manager.h
+

ChipDriver的Factory,用于支持一个芯片多个Wi-Fi端口

+

HdfChipDriver

+
//drivers/framework/include/wifi/wifi_module.h
+

每个WLAN端口对应一个HdfChipDriver,用来管理一个特定的WLAN端口

+

NetDeviceInterFace

+
//drivers/framework/include/wifi/net_device.h
+

与协议栈之间的接口,如发送数据、设置网络接口状态等

+
+ +建议适配按如下步骤操作: + +1.创建HDF驱动建议将代码放置在//device/MySoCVendor/peripheral/wifi/chip\_name/ + +``` +static int32_t HdfWlanHisiChipDriverInit(struct HdfDeviceObject *device) { + static struct HdfChipDriverFactory factory = CreateChipDriverFactory(); + struct HdfChipDriverManager *driverMgr = HdfWlanGetChipDriverMgr(); + if (driverMgr->RegChipDriver(&factory) != HDF_SUCCESS) { + HDF_LOGE("%s fail: driverMgr is NULL!", __func__); + return HDF_FAILURE; + } + return HDF_SUCCESS; +} + +struct HdfDriverEntry g_hdfXXXChipEntry = { + .moduleVersion = 1, + .Init = HdfWlanXXXChipDriverInit, + .Release = HdfWlanXXXChipRelease, + .moduleName = "HDF_WIFI_CHIP_XXX" +}; + +HDF_INIT(g_hdfXXXChipEntry); +``` + +在CreateChipDriverFactory中,需要创建一个HdfChipDriverFactory + + + + + + + + + + + + + + + + + + + + + + + + + + + +

接口

+

说明

+

const char *driverName

+

当前driverName

+

int32_t (*InitChip)(struct HdfWlanDevice *device)

+

初始化芯片

+

int32_t (*DeinitChip)(struct HdfWlanDevice *device)

+

去初始化芯片

+

void (_ReleaseFactory)(struct HdfChipDriverFactory _factory)

+

释放HdfChipDriverFactory对象

+

struct HdfChipDriver _(_Build)(struct HdfWlanDevice *device, uint8_t ifIndex)

+

创建一个HdfChipDriver;输入参数中,device是设备信息,ifIndex是当前创建的接口在这个芯片中的序号

+

void (_Release)(struct HdfChipDriver _chipDriver)

+

释放chipDriver

+

uint8_t (*GetMaxIFCount)(struct HdfChipDriverFactory *factory)

+

获取当前芯片支持的最大接口数

+
+ +HdfChipDriver需要实现的接口有 + + + + + + + + + + + + + + + + + + + + + +

接口

+

说明

+

int32_t (*init)(struct HdfChipDriver *chipDriver, NetDevice *netDev)

+

初始化当前网络接口,这里需要向netDev提供接口NetDeviceInterFace

+

int32_t (*deinit)(struct HdfChipDriver *chipDriver, NetDevice *netDev)

+

去初始化当前网络接口

+

struct HdfMac80211BaseOps *ops

+

WLAN基础能力接口集

+

struct HdfMac80211STAOps *staOps

+

支持STA模式所需的接口集

+

struct HdfMac80211APOps *apOps

+

支持AP模式所需要的接口集

+
+ +2.编写配置文件,描述驱动支持的设备 + +在产品配置目录下创建芯片的配置文件//vendor/MyProductVendor/MyProduct/config/wifi/wlan\_chip\_chip\_name.hcs + +注意: 路径中的vendor\_name、product\_name、chip\_name请替换成实际名称 + +``` +root { + wlan_config { + chip_name :& chipList { + chip_name :: chipInst { + match_attr = "hdf_wlan_chips_chip_name"; /* 这是配置匹配属性,用于提供驱动的配置根 */ + driverName = "driverName"; /* 需要与HdfChipDriverFactory中的driverName相同*/ + sdio { + vendorId = 0x0296; + deviceId = [0x5347]; + } + } + } + } +} +``` + +3.编写配置文件,加载驱动 + +产品的所有设备信息被定义在文件//vendor/MyProductVendor/MyProduct/config/device\_info/device\_info.hcs中。修改该文件,在名为network的host中,名为device\_wlan\_chips的device中增加配置。注意:moduleName 要与触摸屏驱动中的moduleName相同。 + +``` + deviceN :: deviceNode { + policy = 0; + preload = 2; + moduleName = "HDF_WLAN_CHIPS"; + deviceMatchAttr = "hdf_wlan_chips_chip_name"; + serviceName = "driverName"; + } +``` + +4.构建驱动 + +- 创建内核菜单在//device/MySoCVendor/peripheral目录中创建Kconfig文件,内容模板如下: + +``` +config DRIVERS_WLAN_XXX + bool "Enable XXX WLAN Host driver" + default n + depends on DRIVERS_HDF_WIFI + help + Answer Y to enable XXX Host driver. Support chip xxx +``` + +接着修改文件//drivers/adapter/khdf/linux/model/network/wifi/Kconfig,在文件末尾加入如下代码将配置菜单加入内核中。 + +``` +source "../../../../../device/MySoCVendor/peripheral/Kconfig" +``` + +- 创建构建脚本 + + 在//drivers/adapter/khdf/linux/model/network/wifi/Makefile文件末尾增加配置,模板如下 + + +``` +HDF_DEVICE_ROOT := $(HDF_DIR_PREFIX)/../device +obj-$(CONFIG_DRIVERS_WLAN_XXX) += $(HDF_DEVICE_ROOT)/MySoCVendor/peripheral/build/standard/ +``` + +当在内核中开启DRIVERS\_WLAN\_XXX开关时,会调用//device/MySoCVendor/peripheral/build/standard/中的makefile更多详细的开发手册,请参考[WLAN开发](../guide/oem_wifi_sdk_des.md)。 + diff --git a/zh-cn/device-dev/porting/transplant-chip-board.md b/zh-cn/device-dev/porting/transplant-chip-board.md deleted file mode 100644 index f5d7b754b53786192eec6ce7572833fa12329c8e..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-chip-board.md +++ /dev/null @@ -1,15 +0,0 @@ -# 板级系统移植 - -- **[移植概述](transplant-chip-board-overview.md)** - -- **[板级驱动适配](transplant-chip-board-drive.md)** - -- **[HAL层实现](transplant-chip-board-hal.md)** - -- **[系统组件调用](transplant-chip-board-component.md)** - -- **[三方组件适配](transplant-chip-board-bundle.md)** - -- **[XTS认证](transplant-chip-board-xts.md)** - - diff --git a/zh-cn/device-dev/porting/transplant-chip-kernel.md b/zh-cn/device-dev/porting/transplant-chip-kernel.md deleted file mode 100644 index e27fea3d596d06af478a4b24eb46ddc8a6b81187..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-chip-kernel.md +++ /dev/null @@ -1,9 +0,0 @@ -# 内核移植 - -- **[移植概述](transplant-chip-kernel-overview.md)** - -- **[内核基础适配](transplant-chip-kernel-adjustment.md)** - -- **[内核移植验证](transplant-chip-kernel-verify.md)** - - diff --git a/zh-cn/device-dev/porting/transplant-chip-prepare.md b/zh-cn/device-dev/porting/transplant-chip-prepare.md deleted file mode 100644 index 358da845b74ef9ce278a3bff22ee09be59501cb2..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-chip-prepare.md +++ /dev/null @@ -1,7 +0,0 @@ -# 移植准备 - -- **[移植须知](transplant-chip-prepare-knows.md)** - -- **[编译构建适配流程](transplant-chip-prepare-process.md)** - - diff --git a/zh-cn/device-dev/porting/transplant-chip.md b/zh-cn/device-dev/porting/transplant-chip.md deleted file mode 100644 index d0fbee119dd00fe8fb475196714a9a253e676f2b..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-chip.md +++ /dev/null @@ -1,11 +0,0 @@ -# 三方芯片移植指导 - -- **[移植准备](transplant-chip-prepare.md)** - -- **[内核移植](transplant-chip-kernel.md)** - -- **[板级系统移植](transplant-chip-board.md)** - -- **[常见问题](transplant-chip-faqs.md)** - - diff --git a/zh-cn/device-dev/porting/transplant-minichip.md b/zh-cn/device-dev/porting/transplant-minichip.md deleted file mode 100644 index 58bebe026e881c23d1d2aa1cd173cc6bc86ea777..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-minichip.md +++ /dev/null @@ -1,11 +0,0 @@ -# 轻量系统芯片移植指导 - -- **[移植准备](transplant-chip-prepare.md)** - -- **[内核移植](transplant-chip-kernel.md)** - -- **[板级系统移植](transplant-chip-board.md)** - -- **[常见问题](transplant-chip-faqs.md)** - - diff --git a/zh-cn/device-dev/porting/transplant-smallchip-drive.md b/zh-cn/device-dev/porting/transplant-smallchip-drive.md deleted file mode 100644 index 8d265ae4d089593010d0ddd7ef6bcbc0ab327f99..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-smallchip-drive.md +++ /dev/null @@ -1,9 +0,0 @@ -# 驱动移植 - -- **[移植概述](transplant-smallchip-drive-des.md)** - -- **[平台驱动移植](transplant-smallchip-drive-plat.md)** - -- **[器件驱动移植](transplant-smallchip-drive-oom.md)** - - diff --git a/zh-cn/device-dev/porting/transplant-smallchip-kernel.md b/zh-cn/device-dev/porting/transplant-smallchip-kernel.md deleted file mode 100644 index a1adc2dde7e4c576f8fc9137c42217474a15311e..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-smallchip-kernel.md +++ /dev/null @@ -1,7 +0,0 @@ -# 移植内核 - -- **[LiteOS-A内核](transplant-smallchip-kernel-a.md)** - -- **[Linux内核](transplant-smallchip-kernel-linux.md)** - - diff --git a/zh-cn/device-dev/porting/transplant-smallchip-prepare.md b/zh-cn/device-dev/porting/transplant-smallchip-prepare.md deleted file mode 100644 index 6ec4b45dff790140fe40830288b5c0bb961ceddb..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-smallchip-prepare.md +++ /dev/null @@ -1,7 +0,0 @@ -# 移植准备 - -- **[移植须知](transplant-smallchip-prepare-needs.md)** - -- **[编译构建](transplant-smallchip-prepare-building.md)** - - diff --git a/zh-cn/device-dev/porting/transplant-smallchip.md b/zh-cn/device-dev/porting/transplant-smallchip.md deleted file mode 100644 index 4ba38ff4484d56d07681a0dce923d1839b80df87..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-smallchip.md +++ /dev/null @@ -1,9 +0,0 @@ -# 小型系统芯片移植指导 - -- **[移植准备](../porting/transplant-smallchip-prepare.md)** - -- **[移植内核](../porting/transplant-smallchip-kernel.md)** - -- **[驱动移植](../porting/transplant-smallchip-drive.md)** - - diff --git a/zh-cn/device-dev/porting/transplant-thirdparty.md b/zh-cn/device-dev/porting/transplant-thirdparty.md deleted file mode 100644 index ca27b2d33989ef22f963d59881cc0d317a337b35..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant-thirdparty.md +++ /dev/null @@ -1,9 +0,0 @@ -# 三方库移植指导 - -- **[概述](transplant-thirdparty-overview.md)** - -- **[CMake方式组织编译的库移植](transplant-thirdparty-cmake.md)** - -- **[Makefile方式组织编译的库移植](transplant-thirdparty-makefile.md)** - - diff --git a/zh-cn/device-dev/porting/transplant.md b/zh-cn/device-dev/porting/transplant.md deleted file mode 100644 index bc8d8a3ad12bef77aaf9e3f74738efe311ecb464..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/porting/transplant.md +++ /dev/null @@ -1,9 +0,0 @@ -# 移植 - -- **[三方库移植指导](transplant-thirdparty.md)** - -- **[轻量系统芯片移植指导](transplant-minichip.md)** - -- **[小型系统芯片移植指导](transplant-smallchip.md)** - - diff --git a/zh-cn/device-dev/quick-start/quickstart-lite-steps-hi3861-running.md b/zh-cn/device-dev/quick-start/quickstart-lite-steps-hi3861-running.md index fbc4cb843294a4fef84eea40dc9774f16d910580..afb05fbff25c8ddb49473ae447e4e99a59bfe07c 100644 --- a/zh-cn/device-dev/quick-start/quickstart-lite-steps-hi3861-running.md +++ b/zh-cn/device-dev/quick-start/quickstart-lite-steps-hi3861-running.md @@ -155,5 +155,5 @@ wifi init success! ## 下一步学习 -恭喜,您已完成Hi3861 WLAN模组快速上手!建议您下一步进入[WLAN产品开发](../guide/device-wifi.md)的学习 。 +恭喜,您已完成Hi3861 WLAN模组快速上手!建议您下一步进入[WLAN产品开发](../guide/device-wlan.md)的学习 。 diff --git a/zh-cn/device-dev/security/Readme-CN.md b/zh-cn/device-dev/security/Readme-CN.md index 9a8e221f7fe6561d044900efa29dfec7d0d82af0..4c79f16371fde366048aa441e1b85e2325b523f5 100755 --- a/zh-cn/device-dev/security/Readme-CN.md +++ b/zh-cn/device-dev/security/Readme-CN.md @@ -1,5 +1,5 @@ # 隐私与安全 -- [隐私保护](safety-protection-privacyguide.md) -- [安全指南](safety-safeguide-security.md) +- [隐私保护](security-privacy-protection.md) +- [安全指南](security-guidelines-overall.md) diff --git a/zh-cn/device-dev/security/safety.md b/zh-cn/device-dev/security/safety.md deleted file mode 100644 index 72bbe83ac0cf5052a2b1b53ce27b380ef390b963..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/security/safety.md +++ /dev/null @@ -1,7 +0,0 @@ -# 隐私与安全 - -- **[隐私保护](safety-protection-privacyguide.md)** - -- **[安全指南](safety-safeguide-security.md)** - - diff --git a/zh-cn/device-dev/security/safety-safeguide-security.md b/zh-cn/device-dev/security/security-guidelines-overall.md similarity index 100% rename from zh-cn/device-dev/security/safety-safeguide-security.md rename to zh-cn/device-dev/security/security-guidelines-overall.md diff --git a/zh-cn/device-dev/security/safety-protection-privacyguide.md b/zh-cn/device-dev/security/security-privacy-protection.md similarity index 98% rename from zh-cn/device-dev/security/safety-protection-privacyguide.md rename to zh-cn/device-dev/security/security-privacy-protection.md index 95e5eccca8ac113c4ac92f908bb5701109b0e842..ae8f6bcae405462488b73f4bb68a746d391dd5ad 100644 --- a/zh-cn/device-dev/security/safety-protection-privacyguide.md +++ b/zh-cn/device-dev/security/security-privacy-protection.md @@ -195,9 +195,9 @@ 从技术上保证数据处理活动的安全性,包括个人数据的加密存储、安全传输等安全机制,系统应默认开启或采取安全保护措施。 -- 对于个人数据的访问需要有保护机制,主要包括身份认证和访问控制。身份认证(如用户名、密码)限定只有经过认证的用户才能访问数据,可应用于多用户场景;访问控制(如[权限控制](safety-safeguide-security.md#li201725506375))可应用于对应用程序的限制。 +- 对于个人数据的访问需要有保护机制,主要包括身份认证和访问控制。身份认证(如用户名、密码)限定只有经过认证的用户才能访问数据,可应用于多用户场景;访问控制(如[权限控制](security-guidelines-overall.md#li201725506375))可应用于对应用程序的限制。 - 分布式设备个人数据安全存储要满足密钥管理和存储服务(HUKS:Huawei Universal Keystore)的要求,包括:密钥安全存储、数据安全存储。 -- 个人数据在分布式设备间传输要满足设备间的信任绑定关系和数据传输通道的安全性要求。详细信息可以参考[设备互联安全](safety-safeguide-security.md#section26153183616)。 +- 个人数据在分布式设备间传输要满足设备间的信任绑定关系和数据传输通道的安全性要求。详细信息可以参考[设备互联安全](security-guidelines-overall.md#section26153183616)。 - 认证凭证数据(密码、口令、指纹等)须加密存储。 **本地化处理** diff --git a/zh-cn/device-dev/security/security.md b/zh-cn/device-dev/security/security.md new file mode 100644 index 0000000000000000000000000000000000000000..1d9db4c8610e88ab991a455bc8be6fc56db2e36c --- /dev/null +++ b/zh-cn/device-dev/security/security.md @@ -0,0 +1,7 @@ +# 隐私与安全 + +- **[隐私保护](security-privacy-protection.md)** + +- **[安全指南](security-guidelines-overall.md)** + + diff --git a/zh-cn/device-dev/subsystems/Readme-CN.md b/zh-cn/device-dev/subsystems/Readme-CN.md index 843563ec81e16ad3c87a21e020cc28bca5b3a5fb..fbecac938668c28197c9c762863df819974e4a98 100755 --- a/zh-cn/device-dev/subsystems/Readme-CN.md +++ b/zh-cn/device-dev/subsystems/Readme-CN.md @@ -1,78 +1,74 @@ # 子系统开发指南 -- [编译构建](subsys-build.md) - - [轻量和小型系统编译构建指导](subsys-build-mini-lite.md) - - [标准系统编译构建指导](subsys-build-standard-large.md) -- [分布式远程启动](subsys-remote-start.md) -- [图形图像](subsys-graphics.md) - - [图形图像概述](subsys-graphics-overview.md) - - [容器类组件开发指导](subsys-graphics-bundle-guide1.md) - - [布局容器类组件开发指导](subsys-graphics-bundle-guide2.md) - - [普通组件开发指导](subsys-graphics-bundle-guide3.md) - - [动画开发指导](subsys-graphics-animation-guide.md) -- [媒体](subsys-multimedia.md) - - [相机](subsys-multimedia-camera.md) - - [相机开发概述](subsys-multimedia-camera-overview.md) - - [拍照开发指导](subsys-multimedia-camera-photo-guide.md) - - [录像开发指导](subsys-multimedia-camera-record-guide.md) - - [预览开发指导](subsys-multimedia-camera-preview-guide.md) - - - [音视频](subsys-multimedia-video.md) - - [音视频开发概述](subsys-multimedia-video-overview.md) - - [音视频播放开发指导](subsys-multimedia-video-play-guide.md) - - [音视频录制开发指导](subsys-multimedia-video-record-guide.md) -- [公共基础](subsys-utils.md) - - [公共基础库概述](subsys-utils-overview.md) - - [公共基础库开发指导](subsys-utils-guide.md) - - [公共基础库常见问题](subsys-utils-faqs.md) -- [AI框架](subsys-aiframework.md) - - [AI引擎框架开发指南](subsys-aiframework-guide.md) - - [搭建环境](subsys-aiframework-envbuild.md) - - [技术规范](subsys-aiframework-tech.md) - - [代码管理规范](subsys-aiframework-tech-codemanage.md) - - [命名规范](subsys-aiframework-tech-name.md) - - [接口开发规范](subsys-aiframework-tech-interface.md) - - - [开发指导](subsys-aiframework-devguide.md) - - [SDK开发过程](subsys-aiframework-devguide-sdk.md) - - [插件的开发过程](subsys-aiframework-devguide-plugin.md) - - [配置文件的开发过程](subsys-aiframework-devguide-conf.md) - - - [开发示例](subsys-aiframework-demo.md) - - [唤醒词识别SDK的开发示例](subsys-aiframework-demo-sdk.md) - - [唤醒词识别插件的开发示例](subsys-aiframework-demo-plugin.md) - - [唤醒词识别配置文件的开发示例](subsys-aiframework-demo-conf.md) -- [Sensor服务](subsys-sensor.md) - - [Sensor服务子系概述](subsys-sensor-overview.md) - - [Sensor服务子系使用指导](subsys-sensor-guide.md) - - [Sensor服务子系使用实例](subsys-sensor-demo.md) -- [用户程序框架](subsys-application-framework.md) - - [概述](subsys-application-framework-overview.md) - - [搭建环境](subsys-application-framework-builden.md) - - [开发指导](subsys-application-framework-guide.md) - - [开发实例](subsys-application-framework-demo.md) -- [OTA升级](subsys-ota-guide.md) -- [安全](subsys-security.md) - - [概述](subsys-security-overview.md) - - [应用验签开发指导](subsys-security-sigverify.md) - - [应用权限管理开发指导](subsys-security-rightmanagement.md) - - [IPC通信鉴权开发指导](subsys-security-communicationverify.md) -- [启动恢复](subsys-boot.md) - - [启动恢复子系统概述](subsys-boot-overview.md) - - [init启动引导组件](subsys-boot-init.md) - - [appspawn应用孵化组件](subsys-boot-appspawn.md) - - [bootstrap服务启动组件](subsys-boot-bootstrap.md) - - [syspara系统属性组件](subsys-boot-syspara.md) - - [常见问题](subsys-boot-faqs.md) - - [参考](subsys-boot-ref.md) -- [测试](subsys-testguide-test.md) -- [DFX](subsys-dfx.md) - - [DFX概述](subsys-dfx-overview.md) - - [HiLog开发指导](subsys-dfx-hilog-rich.md) - - [HiLog\_Lite开发指导](subsys-dfx-hilog-lite.md) - - [HiSysEvent开发指导](subsys-dfx-hisysevent.md) -- [研发工具链](subsys-toolchain.md) - - [bytrace使用指导](subsys-toolchain-bytrace-guide.md) - - [hdc\_std 使用指导](subsys-toolchain-hdc-guide.md) -- [XTS认证子系统开发指南](subsys-xts-guide.md) - +- [编译构建](subsys-build.md) + - [轻量和小型系统编译构建指导](subsys-build-mini-lite.md) + - [标准系统编译构建指导](subsys-build-standard-large.md) +- [分布式远程启动](subsys-remote-start.md) +- [图形图像](subsys-graphics.md) + - [图形图像概述](subsys-graphics-overview.md) + - [容器类组件开发指导](subsys-graphics-container-guide.md) + - [布局容器类组件开发指导](subsys-graphics-layout-guide.md) + - [普通组件开发指导](subsys-graphics-common-guide.md) + - [动画开发指导](subsys-graphics-animation-guide.md) +- [媒体](subsys-multimedia.md) + - [相机](subsys-multimedia-camera.md) + - [相机开发概述](subsys-multimedia-camera-overview.md) + - [拍照开发指导](subsys-multimedia-camera-photo-guide.md) + - [录像开发指导](subsys-multimedia-camera-record-guide.md) + - [预览开发指导](subsys-multimedia-camera-preview-guide.md) + - [音视频](subsys-multimedia-video.md) + - [音视频开发概述](subsys-multimedia-video-overview.md) + - [音视频播放开发指导](subsys-multimedia-video-play-guide.md) + - [音视频录制开发指导](subsys-multimedia-video-record-guide.md) +- [公共基础](subsys-utils.md) + - [公共基础库概述](subsys-utils-overview.md) + - [公共基础库开发指导](subsys-utils-guide.md) + - [公共基础库常见问题](subsys-utils-faqs.md) +- [AI框架](subsys-aiframework.md) + - [AI引擎框架开发指南](subsys-aiframework-guide.md) + - [搭建环境](subsys-aiframework-envbuild.md) + - [技术规范](subsys-aiframework-tech.md) + - [代码管理规范](subsys-aiframework-tech-codemanage.md) + - [命名规范](subsys-aiframework-tech-name.md) + - [接口开发规范](subsys-aiframework-tech-interface.md) + - [开发指导](subsys-aiframework-devguide.md) + - [SDK开发过程](subsys-aiframework-devguide-sdk.md) + - [插件的开发过程](subsys-aiframework-devguide-plugin.md) + - [配置文件的开发过程](subsys-aiframework-devguide-conf.md) + - [开发示例](subsys-aiframework-demo.md) + - [唤醒词识别SDK的开发示例](subsys-aiframework-demo-sdk.md) + - [唤醒词识别插件的开发示例](subsys-aiframework-demo-plugin.md) + - [唤醒词识别配置文件的开发示例](subsys-aiframework-demo-conf.md) +- [Sensor服务](subsys-densor.md) + - [Sensor服务子系概述](subsys-densor-overview.md) + - [Sensor服务子系使用指导](subsys-densor-guide.md) + - [Sensor服务子系使用实例](subsys-densor-demo.md) +- [用户程序框架](subsys-application-framework.md) + - [概述](subsys-application-framework-overview.md) + - [搭建环境](subsys-application-framework-envbuild.md) + - [开发指导](subsys-application-framework-guide.md) + - [开发实例](subsys-application-framework-demo.md) +- [OTA升级](subsys-ota-guide.md) +- [安全](subsys-security.md) + - [概述](subsys-security-overview.md) + - [应用验签开发指导](subsys-security-sigverify.md) + - [应用权限管理开发指导](subsys-security-rightmanagement.md) + - [IPC通信鉴权开发指导](subsys-security-communicationverify.md) +- [启动恢复](subsys-boot.md) + - [启动恢复子系统概述](subsys-boot-overview.md) + - [init启动引导组件](subsys-boot-init.md) + - [appspawn应用孵化组件](subsys-boot-appspawn.md) + - [bootstrap服务启动组件](subsys-boot-bootstrap.md) + - [syspara系统属性组件](subsys-boot-syspara.md) + - [常见问题](subsys-boot-faqs.md) + - [参考](subsys-boot-ref.md) +- [测试用例开发指导](subsys-testguide-test.md) +- [DFX](subsys-dfx.md) + - [DFX概述](subsys-dfx-overview.md) + - [HiLog开发指导](subsys-dfx-hilog-rich.md) + - [HiLog\_Lite开发指导](subsys-dfx-hilog-lite.md) + - [HiSysEvent开发指导](subsys-dfx-hisysevent.md) +- [研发工具链](subsys-toolchain.md) + - [bytrace使用指导](subsys-toolchain-bytrace-guide.md) + - [hdc\_std 使用指导](subsys-toolchain-hdc-guide.md) +- [XTS认证用例开发指导](subsys-xts-guide.md) \ No newline at end of file diff --git a/zh-cn/device-dev/subsystems/figure/zh-cn_image_0000001181934155.png b/zh-cn/device-dev/subsystems/figure/zh-cn_image_0000001181934155.png new file mode 100644 index 0000000000000000000000000000000000000000..8a3b4daf5fdd4d78948488046bc404bc9ffedbbd Binary files /dev/null and b/zh-cn/device-dev/subsystems/figure/zh-cn_image_0000001181934155.png differ diff --git "a/zh-cn/device-dev/subsystems/figure/\345\256\211\345\205\250\345\255\220\347\263\273\347\273\237.png" "b/zh-cn/device-dev/subsystems/figure/\345\256\211\345\205\250\345\255\220\347\263\273\347\273\237.png" deleted file mode 100755 index 68b98482855637206e94bbd373623dc182a04474..0000000000000000000000000000000000000000 Binary files "a/zh-cn/device-dev/subsystems/figure/\345\256\211\345\205\250\345\255\220\347\263\273\347\273\237.png" and /dev/null differ diff --git a/zh-cn/device-dev/subsystems/subsys-application-framework-builden.md b/zh-cn/device-dev/subsystems/subsys-application-framework-envbuild.md similarity index 100% rename from zh-cn/device-dev/subsystems/subsys-application-framework-builden.md rename to zh-cn/device-dev/subsystems/subsys-application-framework-envbuild.md diff --git a/zh-cn/device-dev/subsystems/subsys-application-framework-guide.md b/zh-cn/device-dev/subsystems/subsys-application-framework-guide.md index b132c23b9381bc71ac04a83359bad84395061fc8..630bf13450e9532d0ef94901bf39539a09a983e6 100644 --- a/zh-cn/device-dev/subsystems/subsys-application-framework-guide.md +++ b/zh-cn/device-dev/subsystems/subsys-application-framework-guide.md @@ -334,7 +334,6 @@ 在Service销毁时调用。Service应通过实现此方法来清理任何资源,如关闭线程、注册的侦听器等。 - 4. 重写消息处理方法。 MsgHandle是Service用来处理客户端消息的方法。其中funcId是客户端传过来的消息类型,request是客户端传过来的序列化请求参数。如果用户在处理完成之后想要把结果传回去,需要把结果序列化后写入reply中。 @@ -392,7 +391,6 @@ Service一旦创建就会一直保持在后台运行,开发者可以通过调用StopAbility\(\)来停止Service。 - 7. 连接Service。 - 如果Service需要与Page Ability或其他应用组件中的Service进行交互,则应创建用于连接的Service。Service支持其他Ability通过ConnectAbility\(\)与其进行连接,ConnectAbility\(\)需要传入目标Service的Want,以及IAbilityConnection的实例来处理回调。IAbilityConnection提供了两个方法供用户实现,OnAbilityConnectDone\(\)用来处理连接的回调,OnAbilityDisconnectDone\(\)用来处理断开连接的回调。 diff --git a/zh-cn/device-dev/subsystems/subsys-application-framework-overview.md b/zh-cn/device-dev/subsystems/subsys-application-framework-overview.md index a0ab8c2d1bbeb2118c32fee4eda946747445c5eb..7809336cf531540a1d15a3bbccda105dfa58f2fc 100644 --- a/zh-cn/device-dev/subsystems/subsys-application-framework-overview.md +++ b/zh-cn/device-dev/subsystems/subsys-application-framework-overview.md @@ -129,7 +129,6 @@ Ability管理服务和包管理服务启动后,就可以安装OpenHarmony应 - ROM: \> 300K (包含JS应用开发框架,UIKit及引擎等强相关子系统) - - Cortex-A RAM/ROM: - RAM:建议大于2M diff --git a/zh-cn/device-dev/subsystems/subsys-application-framework.md b/zh-cn/device-dev/subsystems/subsys-application-framework.md index 99997047ffcf4648b1b4e7fe5eb8ce2db5c6d66c..178c2f17a9cae8229098822c0f98158a0dfeed9f 100644 --- a/zh-cn/device-dev/subsystems/subsys-application-framework.md +++ b/zh-cn/device-dev/subsystems/subsys-application-framework.md @@ -2,7 +2,7 @@ - **[概述](subsys-application-framework-overview.md)** -- **[搭建环境](subsys-application-framework-builden.md)** +- **[搭建环境](subsys-application-framework-envbuild.md)** - **[开发指导](subsys-application-framework-guide.md)** diff --git a/zh-cn/device-dev/subsystems/subsys-build-mini-lite.md b/zh-cn/device-dev/subsystems/subsys-build-mini-lite.md index dc07da91d5c8c7967965ba91ae1ed276279eb8f7..858b9424b862f5442361b9ef7c3dec524dccf02f 100644 --- a/zh-cn/device-dev/subsystems/subsys-build-mini-lite.md +++ b/zh-cn/device-dev/subsystems/subsys-build-mini-lite.md @@ -396,7 +396,6 @@ vendor - $\{root\_path\} - $\{fs\_dir\_name\} - >![](../public_sys-resources/icon-note.gif) **说明:** >fs.yml是可选的,对于没有文件系统的设备可不配置。 @@ -616,7 +615,7 @@ optional arguments: 1. 创建芯片解决方案目录。 - 按照[芯片解决方案配置规则](#section1625463413327)创建目录,以芯片厂商realtek的“rtl8720“开发板为例, 在代码根目录执行: + 按照[芯片解决方案配置规则](#section2345183962710)创建目录,以芯片厂商realtek的“rtl8720“开发板为例, 在代码根目录执行: ``` mkdir -p device/realtek/rtl8720 @@ -683,7 +682,7 @@ optional arguments: 1. 创建产品目录 - 按照[产品解决方案配置规则](#section1625463413327)创建产品目录,以基于“rtl8720“开发板的wifiiot模组为例,在代码根目录执行: + 按照[产品解决方案配置规则](#section2345183962710)创建产品目录,以基于“rtl8720“开发板的wifiiot模组为例,在代码根目录执行: ``` mkdir -p vendor/my_company/wifiiot diff --git a/zh-cn/device-dev/subsystems/subsys-build-mini.md b/zh-cn/device-dev/subsystems/subsys-build-mini.md deleted file mode 100644 index df6e2e0c54c21c72fbecedb3c1c6dbf7132c87ed..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/subsystems/subsys-build-mini.md +++ /dev/null @@ -1,5 +0,0 @@ -# 轻量和小型系统编译构建指导 - -- **[编译构建子系统—轻量和小型系统](subsys-build-mini-lite.md)** - - diff --git a/zh-cn/device-dev/subsystems/subsys-build-standard.md b/zh-cn/device-dev/subsystems/subsys-build-standard.md deleted file mode 100644 index d5d5ce6278bf65d44db5da6b8b7734e22463b486..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/subsystems/subsys-build-standard.md +++ /dev/null @@ -1,5 +0,0 @@ -# 标准系统编译构建指导 - -- **[编译构建子系统—标准系统](subsys-build-standard-large.md)** - - diff --git a/zh-cn/device-dev/subsystems/subsys-sensor-demo.md b/zh-cn/device-dev/subsystems/subsys-densor-demo.md old mode 100755 new mode 100644 similarity index 100% rename from zh-cn/device-dev/subsystems/subsys-sensor-demo.md rename to zh-cn/device-dev/subsystems/subsys-densor-demo.md diff --git a/zh-cn/device-dev/subsystems/subsys-sensor-guide.md b/zh-cn/device-dev/subsystems/subsys-densor-guide.md similarity index 100% rename from zh-cn/device-dev/subsystems/subsys-sensor-guide.md rename to zh-cn/device-dev/subsystems/subsys-densor-guide.md diff --git a/zh-cn/device-dev/subsystems/subsys-sensor-overview.md b/zh-cn/device-dev/subsystems/subsys-densor-overview.md similarity index 100% rename from zh-cn/device-dev/subsystems/subsys-sensor-overview.md rename to zh-cn/device-dev/subsystems/subsys-densor-overview.md diff --git a/zh-cn/device-dev/subsystems/subsys-densor.md b/zh-cn/device-dev/subsystems/subsys-densor.md new file mode 100644 index 0000000000000000000000000000000000000000..2c5ea0dbbeeab7689d3120089e1f91e994cac8bb --- /dev/null +++ b/zh-cn/device-dev/subsystems/subsys-densor.md @@ -0,0 +1,9 @@ +# Sensor服务 + +- **[Sensor服务子系概述](subsys-densor-overview.md)** + +- **[Sensor服务子系使用指导](subsys-densor-guide.md)** + +- **[Sensor服务子系使用实例](subsys-densor-demo.md)** + + diff --git a/zh-cn/device-dev/subsystems/subsys-dfx-hisyseventread.md b/zh-cn/device-dev/subsystems/subsys-dfx-hisyseventread.md deleted file mode 100644 index 333dd112b45fe83e91673798d6fd125db71747e3..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/subsystems/subsys-dfx-hisyseventread.md +++ /dev/null @@ -1,103 +0,0 @@ -# HiSysEvent订阅指导 - -- [概述](#section315316685112) -- [接口说明](#section0342191810519) -- [开发实例](#section123181432175110) - -## 概述 - -HiSysEvent提供了跨进程订阅机制,用户可以通过注册订阅接口。 - -## 接口说明 - -**表 1** HiSysEvent订阅接口 - - - - - - - - - - - - - -

接口名

-

描述

-

int ISysEventService::AddListener(in SysEventRule[] rules, in ISysEventCallback callback)

-

接口功能:订阅HiSysEvent事件。

-

输入参数:

-
  • rules:事件订阅规则
  • callback:订阅回调对象
-

返回值:

-
  • 0:订阅成功,重复订阅
  • 1:订阅成功,初次订阅
  • 其他返回值:订阅失败
-

void ISysEventCallback::Handle(in String domain, in String eventName, in int eventType, in String eventDetail)

-

接口功能:订阅事件的回调接口。

-

输入参数:

-
  • domain:事件所属领域
  • eventName:事件的名称
  • eventType:事件类型
  • eventDetail:包含事件相关信息的字符串,以json的形式体现
-

返回值:无。

-
- -**表 2** SysEventRule订阅规则对象 - - - - - - - - - - - - - - - - -

属性名称

-

描述

-

uint32_t ruleType

-

规则类型(匹配范围包括domain以及eventName):

-
  • 1:全字符匹配
  • 2:前缀匹配
  • 3:正则表达式匹配
  • 其他值:无效的匹配方式
-

std::string domain;

-
  • domain:事件所属领域,如果传入的是空字符串,则默认事件领域字段匹配成功
-

std::string eventName

-
  • eventName:事件的名称,如果传入的是空字符串,则默认事件名称字段匹配成功
-
- -## 开发实例 - -1. 源代码开发: - - 引入对应的aidl文件,包括:ISysEventService.aidl、SysEventRule.aidl、ISysEventCallback.aidl。 - - 在相应的业务逻辑里面调用ISysEventService::AddListener\(in SysEventRule\[\] rules, in ISysEventCallback callback\)接口。 - - 实现对应的回调对象: - - ISysEventCallback::Handle\(in String domain, in String eventName, in int eventType, in String eventDetail\) - - -1. 源代码开发: - - 引入对应的aidl文件,包括:ISysEventService.aidl、SysEventRule.aidl、ISysEventCallback.aidl。 - - 在相应的业务逻辑里面调用ISysEventService::AddListener\(in SysEventRule\[\] rules, in ISysEventCallback callback\)接口。 - - 实现对应的回调对象: - - ISysEventCallback::Handle\(in String domain, in String eventName, in int eventType, in String eventDetail\) - -2. 编译设置: - -在编译子系统里面,需要依赖libbinder模块 - -aosp\_deps = \[ "shared\_library:libbinder", \] - -- **[bytrace使用指导](subsys-toolchain-bytrace-guide.md)** - -- **[hdc\_std 使用指导](subsys-toolchain-hdc-guide.md)** - - diff --git a/zh-cn/device-dev/subsystems/subsys-graphics-bundle-guide3.md b/zh-cn/device-dev/subsystems/subsys-graphics-common-guide.md similarity index 100% rename from zh-cn/device-dev/subsystems/subsys-graphics-bundle-guide3.md rename to zh-cn/device-dev/subsystems/subsys-graphics-common-guide.md diff --git a/zh-cn/device-dev/subsystems/subsys-graphics-bundle-guide1.md b/zh-cn/device-dev/subsystems/subsys-graphics-container-guide.md similarity index 100% rename from zh-cn/device-dev/subsystems/subsys-graphics-bundle-guide1.md rename to zh-cn/device-dev/subsystems/subsys-graphics-container-guide.md diff --git a/zh-cn/device-dev/subsystems/subsys-graphics-bundle-guide2.md b/zh-cn/device-dev/subsystems/subsys-graphics-layout-guide.md similarity index 100% rename from zh-cn/device-dev/subsystems/subsys-graphics-bundle-guide2.md rename to zh-cn/device-dev/subsystems/subsys-graphics-layout-guide.md diff --git a/zh-cn/device-dev/subsystems/subsys-graphics.md b/zh-cn/device-dev/subsystems/subsys-graphics.md index bb255fa159a9823a6ddbfc724ba7b9ba4c5ac9cd..27feed54e9015bfebd8d33c9bbe1c90176937c85 100644 --- a/zh-cn/device-dev/subsystems/subsys-graphics.md +++ b/zh-cn/device-dev/subsystems/subsys-graphics.md @@ -2,11 +2,11 @@ - **[图形图像概述](subsys-graphics-overview.md)** -- **[容器类组件开发指导](subsys-graphics-bundle-guide1.md)** +- **[容器类组件开发指导](subsys-graphics-container-guide.md)** -- **[布局容器类组件开发指导](subsys-graphics-bundle-guide2.md)** +- **[布局容器类组件开发指导](subsys-graphics-layout-guide.md)** -- **[普通组件开发指导](subsys-graphics-bundle-guide3.md)** +- **[普通组件开发指导](subsys-graphics-common-guide.md)** - **[动画开发指导](subsys-graphics-animation-guide.md)** diff --git a/zh-cn/device-dev/subsystems/subsys-multimedia-camera-overview.md b/zh-cn/device-dev/subsystems/subsys-multimedia-camera-overview.md index 75b2033e9c72cb5541ed32a6d7a8e098e748a526..824d3461ea0f803b8e568fedc442c45c86592eee 100644 --- a/zh-cn/device-dev/subsystems/subsys-multimedia-camera-overview.md +++ b/zh-cn/device-dev/subsystems/subsys-multimedia-camera-overview.md @@ -102,7 +102,6 @@ ![](figure/zh-cn_image_0000001054101094.png) - 1. Camera录像/预览流程 开发者首先通过CameraKit创建Camera,然后FrameConfig类对录像或者预览帧属性进行配置。录像/预览时序如下: diff --git a/zh-cn/device-dev/subsystems/subsys-security-communicationverify.md b/zh-cn/device-dev/subsystems/subsys-security-communicationverify.md index a0c52fc9c75746a7a9da6e4d5d862354f94f30dd..7b6da780217233b210aec73f2f177e3eddf7c795 100755 --- a/zh-cn/device-dev/subsystems/subsys-security-communicationverify.md +++ b/zh-cn/device-dev/subsystems/subsys-security-communicationverify.md @@ -41,7 +41,7 @@ IPC通信鉴权提供的API,仅供Samgr调用,开发者在开发服务时需 本部分以BMS服务通过IPC通信方式对外开放接口为例,讲解如何通过IPC通信鉴权组件配置对应接口的访问策略。这里BMS在Samgr中注册的service为bundlems,为开放的接口注册的Feature为BmsFeature。 -1. 在源码路径下的头文件base/security/permission/services/permission\_lite/ipc\_auth/include/policy\_preset.h中配置相应的访问策略,访问策略主要有三种类型: +1. 鸿蒙侧在源码路径下的头文件base/security/permission/services/permission\_lite/ipc\_auth/include/policy\_preset.h中配置相应的访问策略,产品侧独有的在vendor/hisilicon/产品名称/hals/security/permission\_lite/ipc\_auth/include/policy\_preset\_product.h中配置相应的访问策略,配置策略后将头文件中的宏POLICY\_PRODUCT 配置为1;访问策略主要有三种类型: (1)type为RANGE类型:允许某个特定范围UID的进程访问,需要指定uidMin和uidMax; diff --git a/zh-cn/device-dev/subsystems/subsys-security-overview.md b/zh-cn/device-dev/subsystems/subsys-security-overview.md index 5c47b308081819cc88c581f359cca3b4dc8cdd8f..5ce4e86cbcb0fe8b2a4ffb6a0018735372eb309d 100644 --- a/zh-cn/device-dev/subsystems/subsys-security-overview.md +++ b/zh-cn/device-dev/subsystems/subsys-security-overview.md @@ -13,10 +13,6 @@ OpenHarmony安全子系统目前提供给开发者的安全能力主要包含应 应用权限是管理应用访问系统资源和使用系统能力的一种通用方式,应用在开发阶段需要在profile.json中指明此应用在运行过程中可能会调用哪些权限,其中静态权限表示只需要在安装阶段注册就可以,而动态权限一般表示涉及到敏感信息,所以需要用户进行动态授权。 -- IPC通信鉴权 - - 系统服务通过IPC暴露接口给其他进程访问,这些接口需要配置相应的访问策略,当其他进程访问这些接口时,将会触发IPC通信鉴权机制校验访问进程是否拥有权限访问该接口,若无权限,则拒绝访问该接口。 - - 可信设备群组管理 提供基于群组概念的同华为账号群组、点对点群组(如二维码、碰一碰等)的设备安全可信关系的创建和查询,分布式应用可基于该能力进行设备间的可信认证,然后向分布式软总线请求设备间安全会话。 @@ -36,41 +32,28 @@ OpenHarmony安全子系统目前提供给开发者的安全能力主要包含应 BMS\(Bundle Manager Service\)包管理管理,在OpenHarmony上主要负责应用的安装、卸载和数据管理。 -- 描述文件 - - 本文中的描述文件,指HarmonyAppProvision,简称profile。HarmonyAppProvision采用json文件格式进行描述。 - +- 授权文件 -- 叶子证书 - - 最终用于为整包或profile签名的证书称为叶子证书,位于数字证书链的最末端。 + 本文中的授权文件,指HarmonyAppProvision,简称profile。HarmonyAppProvision采用json文件格式进行描述。 - 调试应用 - 指开发者从应用市场申请调试证书与调试描述文件,并以此签名的hap包。 - - -- 待上架应用 - - 指开发者从应用市场申请发布证书与发布描述文件,以此签名,未通过应用市场正式发布的hap包。 + 指开发者从应用市场申请调试证书与调试授权文件,并以此签名的hap包。 - 发布应用 - 指开发者从应用市场申请发布证书与发布描述文件,以此签名的hap包,上传至应用市场,并由应用市场正式发布的hap包。 + 指开发者从应用市场申请发布证书与发布授权文件,以此签名的hap包,上传至应用市场,并由应用市场正式发布的hap包。 -- OpenHarmony自签名应用 +- OpenHarmony签名应用 - 当开发者自行编译OpenHarmony系统应用后,采用原应用描述文件,以及公开的OpenHarmony公私钥对和证书进行自签名产生的hap包。 + OpenHarmony开源了一个根CA的证书和密钥,以此根CA签发的签名证书和授权文件签名的应用。 ## 约束与限制 -- 仅支持以下三类应用的验签:应用市场调试应用、应用市场发布应用、OpenHarmony自签名应用的验签。 -- 若对应用市场调试应用验签,则本机UDID需要在描述文件包含的UDID列表中。 -- 待上架应用无法验签通过。 -- 验签组件提供的接口都位于security\_interfaces\_innerkits\_app\_verify仓[app\_verify\_pub.h](https://gitee.com/fork_ohos_wj/security_interfaces_innerkits_app_verify/blob/master/app_verify_pub.h)中,仅支持系统应用开发者调用。 -- 可信设备群组管理接口,目前只对系统签名权限才可以使用。 +- 仅支持以下三类应用的验签:应用市场调试应用、应用市场发布应用、OpenHarmony签名应用。 +- 若对应用市场调试应用验签,则本机UDID需要在授权文件授权调试的UDID列表中。 diff --git a/zh-cn/device-dev/subsystems/subsys-security-sigverify.md b/zh-cn/device-dev/subsystems/subsys-security-sigverify.md index a7e2f85b64ec50c09ad516a117b157d71907c11f..7c46ac23f5d5892104ed36a6b7b357fb5b3d8f8d 100644 --- a/zh-cn/device-dev/subsystems/subsys-security-sigverify.md +++ b/zh-cn/device-dev/subsystems/subsys-security-sigverify.md @@ -3,57 +3,47 @@ - [场景介绍](#section18502174174019) - [验签流程](#section554632717226) - [接口说明](#section1633115419401) -- [开发步骤(场景一)](#section4207112818418) - - [验签指导](#section11470123816297) - - [生成OpenHarmony自签名应用](#section167151429133312) - - [开发示例](#section174318361353) +- [开发步骤](#section4207112818418) + - [生成OpenHarmony签名应用](#section167151429133312) -- [开发步骤(场景二)](#section81272563427) - - [验签指导](#section07028210442) - - [开发示例](#section1930711345445) - -- [调测验证](#section427316292411) ## 场景介绍 -当需要验证调试应用、发布应用,OpenHarmony自签名应用的完整性是否被破坏时,可以调用验签组件的接口进行验证。如有需要还可通过验签接口获取部分描述文件信息,如appid。对于调试应用,还可通过验签接口验证应用和设备的UDID是否匹配,确保应用安装在了正确的设备上。 +为了确保应用的完整性和来源可靠,OpenHarmony需要对应用进行签名和验签。 + +- 应用开发阶段:开发者完成开发并生成安装包后,需要开发者对安装包进行签名,以证明安装包发布到设备的过程中没有被篡改。OpenHarmony的应用完整性校验模块提供了签名工具、签名证书生成规范,以及签名所需的公钥证书等完整的机制,支撑开发者对应用安装包签名。为了方便开源社区开发者,版本中预置了公钥证书和对应的私钥,为开源社区提供离线签名和校验能力;在OpenHarmony商用版本中应替换此公钥证书和对应的私钥。 +- 应用安装阶段:OpenHarmony用户程序框架子系统负责应用的安装。在接收到应用安装包之后,应用程序框架子系统需要解析安装包的签名数据,然后使用应用完整性校验模块的API对签名进行验证,只有校验成功之后才允许安装此应用. 应用完整性校验模块在校验安装包签名数据时,会使用系统预置的公钥证书进行验签。 ## 验签流程 未经签名的Hap包的压缩方式是ZIP格式,简单分为文件块,中心目录(Central directory)块,中心目录结尾(EOCD,End of central directory record)块。 -经过签名的Hap包,在文件块,和中心目录块之间,插入了签名块。签名块由文件签名数据块(data sign block)、描述文件签名数据块(profile sign block)和签名头(sign head)组成,如下图所示。 +经过签名的Hap包,在文件块,和中心目录块之间,插入了签名块。签名块由整包签名数据块(data sign block)、授权文件签名数据块(profile sign block)和签名头(sign head)组成,如下图所示。 **图 1** 经过签名的Hap包结构 -![](figure/安全子系统.png) +![](figure/zh-cn_image_0000001181934155.png) -整个验签流程,主要分为三部分:整包验签、描述文件签名块验签,以及描述文件内容校验。 +整个验签流程,主要分为三部分:整包验签、授权文件验签,以及授权文件内容校验。 **整包验签** -用设备的预置根证书,通过证书链来证明叶子证书本身是可信的,然后用叶子证书的公钥解密出的摘要证明整包是未篡改的。 - -具体操作步骤如下: - -1. 对文件签名数据块中的证书链进行校验,确定其叶子证书是可信的。 -2. 用叶子证书中的公钥对文件签名块进行验签,证明其未被篡改。 -3. 计算并合并文件块,中心目录块和中心目录结尾块的摘要。然后将计算结果,再与签名块中的描述文件签名块的摘要合并,将最终合并的摘要与文件签名块中包含的摘要对比,如果两者相等,则整包验签通过。 +整包签名数据块是一个PKCS7格式的签名块(signed data),验签过程包括PKSC7签名验证、哈希比较、证书链验证以及证书链与设备预置根证书的匹配校验。 -**描述文件签名块验签** +**授权文件验签** -首先判断文件签名的签发单位,如果是应用市场签发的发布应用,则无需对描述文件进行验签,直接信任,否则要对其验签。先取出整个描述文件签名块,然后验证证书链,最后用叶子证书对描述文件数据块验签,证明其未被篡改。 +授权文件数据块是一个PKCS7格式的签名块(signed data),其中PKCS7签名块的内容信息\(contentinfo\)是授权文件的内容。验签过程包括:PKCS7签名验证、哈希比较、证书链验证以及签发授权文件证书的合法性校验。 -**描述文件内容校验** +**授权文件内容校验** -取出描述文件,并对其内容进行合法性检查。其中若hap包为调试应用,则会比对本机UDID与描述文件中包含的UDID列表,如果本机UDID在描述文件的UDID列表中包含,则验证通过。比较描述文件中包含的证书(如果是应用市场发布应用或OpenHarmony自签名则无需比较),和整包校验时使用的叶子证书,如果相同,认为整个验签流程完成。 +验签模块将对授权文件内容进行合法性检查。如果授权文件是调试类型,则会比对本机UDID是否在授权文件授权调试的UDID列表中,如果本机UDID在授权文件授权调试的UDID列表中,则会进一步比较授权文件中的调试证书和整包签名使用的证书是否相同,如果相同,则验证通过。 ## 接口说明 验签组件当前提供innerkits接口,仅供系统应用调用,相关接口及功能描述如下: -**表 1** 验签组件API接口功能介绍 +**表 1** 轻量级系统验签组件API接口功能介绍

接口名

@@ -81,192 +71,26 @@
-## 开发步骤(场景一) - -### 验签指导 - -对应用市场发布应用、基于应用市场调试证书签发的调试应用、OpenHarmony自签名应用的校验。 - -1. 定义出参结构体变量VerifyResult; - - ``` - VerifyResult verifyResult = {0}; - ``` - -2. 以文件路径及VerifyResult为入参,调用APPVERI\_AppVerify进行文件校验; - - ``` - int32_t ret = APPVERI_AppVerify(hapFilepath.c_str(), &verifyResult); - ``` - -3. 判断返回结果,如果校验通过的话,获取VerifyResult中的数据,进行业务处理; - - ``` - signatureInfo.appId = verifyResult.profile.appid; - signatureInfo.provisionBundleName = verifyResult.profile.bundleInfo.bundleName; - ``` - -4. 调用APPVERI\_FreeVerifyRst,释放VerifyResult中申请的内存。 - - ``` - APPVERI_FreeVerifyRst(&verifyResult); - ``` - - -### 生成OpenHarmony自签名应用 - -如果是OpenHarmony自签名应用的校验,开发者可通过以下方式生成OpenHarmony自签名应用。 - -1. 材料备齐。 - - 生成自签名应用需要的材料有:签名工具、系统应用hap包、系统应用profile文件\(\*.p7b\)、签名证书\(\*.cer\)、签名公私钥对\(\*.jks\)。 - -2. 将所有材料放在同一个目录下,打开shell。 -3. 根据应用、描述文件的实际名称修改指令,并在shell中输入,完成签名。 - - ``` - java -jar hapsigntoolv2.jar sign -mode localjks -privatekey "OpenHarmony Software Signature" -inputFile camera.hap -outputFile signed_camera.hap -signAlg SHA256withECDSA -keystore OpenHarmony.jks -keystorepasswd 123456 -keyaliaspasswd 123456 -profile camera_release.p7b -certpath OpenHarmony.cer -profileSigned 1 - ``` - - 关键字段说明: - - -jar:签名工具,[hapsigntool](https://repo.huaweicloud.com/harmonyos/develop_tools/hapsigntoolv2.jar) - - -mode:本地签名标记位,固定为localjks - - -privatekey:密钥对别名,签名公私钥对的别名为OpenHarmony Software Signature - - -inputFile:待签名应用,通过编译产生 - - -outputFile:签名后应用,最终输出 - - -signAlg:签名算法,当前固定为SHA256withECDSA +**表 2** 标准系统验签组件API接口功能介绍 - -keystore:公私钥对,使用签名公私钥对,位于开源库security\_services\_app\_verify仓中OpenHarmonyCer目录下,[OpenHarmony.jks](https://gitee.com/openharmony/security_appverify/blob/master/interfaces/innerkits/appverify_lite/OpenHarmonyCer/OpenHarmony.jks)。默认密码为123456 ,用户可采用工具\(例如keytool\)更改默认密码 - - -keystorepasswd:公私钥对密码,默认签名公私钥对密码为123456 - - -keyaliaspasswd:公私钥对别名密码,默认签名公私钥对别名密码为123456 - - -profile:描述文件,应用的描述文件位于对应源代码目录中 - - -certpath:使用签名证书,位于开源库security\_services\_app\_verify仓中OpenHarmonyCer目录下,[OpenHarmony.cer](https://gitee.com/openharmony/security_appverify/blob/master/interfaces/innerkits/appverify_lite/OpenHarmonyCer/OpenHarmony.cer) - - -profileSigned:签名块中是否包含描述文件\(profile\)。固定为1(包含) - - -### 开发示例 - -以应用管理框架组件在应用安装时进行验签的实际调用为例: - -``` -uint8_t HapSignVerify::VerifySignature(const std::string &hapFilepath, SignatureInfo &signatureInfo) -{ - bool mode = ManagerService::GetInstance().IsDebugMode(); - HILOG_INFO(HILOG_MODULE_APP, "current mode is %d!", mode); - // 定义结果结构体 - VerifyResult verifyResult = {0}; - // 输入待验签文件路径进行验签 - int32_t ret = APPVERI_AppVerify(hapFilepath.c_str(), &verifyResult); - uint8_t errorCode = SwitchErrorCode(ret); - if (errorCode != ERR_OK) { - return errorCode; - } - // 从结果结构体中获取appid - signatureInfo.appId = verifyResult.profile.appid; - // 从结果结构体中获取描述文件中书写的应用名 - signatureInfo.provisionBundleName = verifyResult.profile.bundleInfo.bundleName; - int32_t restricNum = verifyResult.profile.permission.restricNum; - for (int32_t i = 0; i < restricNum; i++) { - signatureInfo.restrictedPermissions.emplace_back((verifyResult.profile.permission.restricPermission)[i]); - } - // 释放结果结构体中申请的内存 - APPVERI_FreeVerifyRst(&verifyResult); - return ERR_OK; -} -``` - -## 开发步骤(场景二) - -### 验签指导 - -对采用基于测试根密钥证书签名的应用的校验。 - -1. 调用APPVERI\_SetDebugMode\(true\)开启测试模式; - - ``` - ManagerService::SetDebugMode(true); - ... - uint8_t ManagerService::SetDebugMode(bool enable) - { - int32_t ret = APPVERI_SetDebugMode(enable); - if (ret < 0) { - HILOG_ERROR(HILOG_MODULE_APP, "set signature debug mode failed"); - return ERR_APPEXECFWK_SET_DEBUG_MODE_ERROR; - } - isDebugMode_ = enable; - HILOG_INFO(HILOG_MODULE_APP, "current sign debug mode is %d", isDebugMode_); - return ERR_OK; - } - ``` - -2. 同场景一中步骤一至四,定义结构体,校验、释放结构体; -3. 调用APPVERI\_SetDebugMode\(false\)关闭测试模式。 - - ``` - ManagerService::SetDebugMode(false); - ``` - - -### 开发示例 - -完整开发示例如下(在场景一代码示例的基础上进行补充): + + + + + + + + + +

接口名

+

描述

+

nt HapVerify(const std::string& filePath, HapVerifyResult& hapVerifyResult)

+

校验应用完整性,识别应用来源。

+
-``` -uint8_t ManagerService::SetDebugMode(bool enable) -{ - int32_t ret = APPVERI_SetDebugMode(enable); - if (ret < 0) { - HILOG_ERROR(HILOG_MODULE_APP, "set signature debug mode failed"); - return ERR_APPEXECFWK_SET_DEBUG_MODE_ERROR; - } - isDebugMode_ = enable; - HILOG_INFO(HILOG_MODULE_APP, "current sign debug mode is %d", isDebugMode_); - return ERR_OK; -} -uint8_t HapSignVerify::VerifySignature(const std::string &hapFilepath, SignatureInfo &signatureInfo) -{ - // 开启支持测试服务器签名应用验证 - ManagerService::SetDebugMode(true); - bool mode = ManagerService::GetInstance().IsDebugMode(); - HILOG_INFO(HILOG_MODULE_APP, "current mode is %d!", mode); - // 定义结果结构体 - VerifyResult verifyResult = {0}; - // 输入待验签文件路径进行验签 - int32_t ret = APPVERI_AppVerify(hapFilepath.c_str(), &verifyResult); - uint8_t errorCode = SwitchErrorCode(ret); - if (errorCode != ERR_OK) { - return errorCode; - } - // 从结果结构体中获取appid - signatureInfo.appId = verifyResult.profile.appid; - // 从结果结构体中获取描述文件中书写的应用名 - signatureInfo.provisionBundleName = verifyResult.profile.bundleInfo.bundleName; - int32_t restricNum = verifyResult.profile.permission.restricNum; - for (int32_t i = 0; i < restricNum; i++) { - signatureInfo.restrictedPermissions.emplace_back((verifyResult.profile.permission.restricPermission)[i]); - } - // 释放结果结构体中申请的内存 - APPVERI_FreeVerifyRst(&verifyResult); - // 关闭支持测试服务器签名应用验证 - ManagerService::SetDebugMode(false); - return ERR_OK; -} -``` +## 开发步骤 -## 调测验证 +### 生成OpenHarmony签名应用 -1. 选取一个在OpenHarmony上能够正常安装的应用A。 -2. 根据开发指导开发。 -3. 对应用A,采用自开发程序进行验签,验签通过,能获取到appid。即为开发成功。 +参考文档:https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/quick-start/%E9%85%8D%E7%BD%AEOpenHarmony%E5%BA%94%E7%94%A8%E7%AD%BE%E5%90%8D%E4%BF%A1%E6%81%AF.md diff --git a/zh-cn/device-dev/subsystems/subsys-sensor.md b/zh-cn/device-dev/subsystems/subsys-sensor.md deleted file mode 100644 index 415eec2bde7a96ccb8ee88e7c27d41872654b843..0000000000000000000000000000000000000000 --- a/zh-cn/device-dev/subsystems/subsys-sensor.md +++ /dev/null @@ -1,9 +0,0 @@ -# Sensor服务 - -- **[Sensor服务子系概述](subsys-sensor-overview.md)** - -- **[Sensor服务子系使用指导](subsys-sensor-guide.md)** - -- **[Sensor服务子系使用实例](subsys-sensor-demo.md)** - - diff --git a/zh-cn/device-dev/subsystems/subsys-testguide-test.md b/zh-cn/device-dev/subsystems/subsys-testguide-test.md index 2403929934b2c2860c3e2dd2200e9a9046930e64..1797e29f6a3ef77e96481d8b862f553815555593 100644 --- a/zh-cn/device-dev/subsystems/subsys-testguide-test.md +++ b/zh-cn/device-dev/subsystems/subsys-testguide-test.md @@ -1,4 +1,4 @@ -# 测试 +# 测试用例开发指导 - [概述](#section12403172115920) - [基本概念](#section53632272090) @@ -237,7 +237,7 @@ ### 场景介绍 -针对对开发的业务代码进行白盒测试验证。 +针对开发的业务代码进行白盒测试验证。 ### 接口说明 @@ -466,7 +466,6 @@ } ``` - 6. 编写测试用例资源配置,当测试用例需要使用静态测试资源文件时使用该配置。 1. 在部件或者模块的test目录下创建resource目录。 2. 在resource目录下创建形态目录,如phone。 @@ -620,7 +619,6 @@ ``` - 3. (可选)修改developertest组件配置。如果测试用例已完成编译,可以直接指定测试用例的编译输出路径,测试平台执行用例时即不会重新编译测试用例。 配置文件:config/user\_config.xml @@ -642,7 +640,6 @@ ``` - 4. (可选)测试环境准备。当被测设备仅支持串口时,需要检查。 - 系统镜像与文件系统已烧录进开发板,开发板上系统正常运行,在系统模式下,如使用shell登录时,设备提示符是“OHOS\#”。 - 开发主机和开发板串口连接正常,网口连接正常。 @@ -663,7 +660,6 @@ ./start.sh ``` - - 设备形态选择。 根据实际的开发板选择,设备形态配置:developertest/config/framework\_config.xml。 @@ -704,7 +700,6 @@ -tl TESTLEVEL, --testlevel TESTLEVEL Specify test level ``` - - 测试框架帮助。 帮助指令,用于查询测试平台支持哪些测试指令,如下: @@ -721,7 +716,6 @@ quit ``` - 6. (必选)查看测试结果与日志,通过在测试平台中执行测试指令,即可在developertest/reports目录下生成测试日志和测试报告。 - 测试用例的结果会直接显示在控制台上,执行一次的测试结果根路径如下: @@ -753,7 +747,6 @@ details_report.html ``` - - 测试平台日志目录如下: ``` diff --git a/zh-cn/device-dev/subsystems/subsys-toolchain-hdc-guide.md b/zh-cn/device-dev/subsystems/subsys-toolchain-hdc-guide.md index 93b765389398c04173ff43ab84aa32cf4eff038c..1f57ac737f3ce1e4cf6eea3f49aaf7e27147a529 100644 --- a/zh-cn/device-dev/subsystems/subsys-toolchain-hdc-guide.md +++ b/zh-cn/device-dev/subsystems/subsys-toolchain-hdc-guide.md @@ -22,7 +22,7 @@ hdc\_std(OpenHarmony Device Connector)是OpenHarmony为开发人员提供的 **hdc\_std 工具获取方式:** -从开源仓developtools\_hdc\_standard中获取,具体位置在该开源仓的prebuilt目录。 +从开源仓developtools\_hdc\_standard中获取,具体位置在该开源仓的prebuilt目录,开源仓链接如下:https://gitee.com/openharmony/developtools\_hdc\_standard **使用举例:** diff --git a/zh-cn/device-dev/subsystems/subsys-toolchain.md b/zh-cn/device-dev/subsystems/subsys-toolchain.md index fcf4e3ed14c0ce6975b04b70d0e9a0bd9c21f06e..9f71a36d323e436abf32db47ac858973a0ef3c8b 100644 --- a/zh-cn/device-dev/subsystems/subsys-toolchain.md +++ b/zh-cn/device-dev/subsystems/subsys-toolchain.md @@ -1,6 +1,7 @@ -# 研发工具链 +# 研发工具链 -- [bytrace使用指导](subsys-toolchain-bytrace-guide.md) -- [hdc\_std 使用指导](subsys-toolchain-hdc-guide.md) +- **[bytrace使用指导](subsys-toolchain-bytrace-guide.md)** + +- **[hdc\_std 使用指导](subsys-toolchain-hdc-guide.md)** diff --git a/zh-cn/device-dev/subsystems/subsys-utils-guide.md b/zh-cn/device-dev/subsystems/subsys-utils-guide.md index 1cabae57341e29c31a2ebf0b47e670e438f27444..98866eec08eed9f7693172402a20e0ae81e6e557 100644 --- a/zh-cn/device-dev/subsystems/subsys-utils-guide.md +++ b/zh-cn/device-dev/subsystems/subsys-utils-guide.md @@ -237,7 +237,6 @@ printf("UtilsDeleteValue delete ret = %d\n", ret); } ``` - - 生成hap包。 - 按照如下目录结构存放文件,res/drawable下面放置资源文件: @@ -246,7 +245,6 @@ printf("UtilsDeleteValue delete ret = %d\n", ret); - 将上述文件打包生成zip包,修改后缀为.hap,例如Launcher.hap - 2. 连接单板,通过串口向单板发送安装KV存储native应用的命令。 ``` diff --git a/zh-cn/device-dev/subsystems/subsys-xts-guide.md b/zh-cn/device-dev/subsystems/subsys-xts-guide.md index 1240c60b9d64b230d4415ddf74c37477f57b27ed..896f7db9e7df9e927330e8e7e94c2e1946c378ae 100644 --- a/zh-cn/device-dev/subsystems/subsys-xts-guide.md +++ b/zh-cn/device-dev/subsystems/subsys-xts-guide.md @@ -1,4 +1,4 @@ -# XTS认证子系统开发指南 +# XTS认证用例开发指导 - [简介](#section465982318513) - [系统类型](#section125090457443) @@ -12,7 +12,6 @@ - [C++语言用例执行指导(适用于小型系统、标准系统用例开发)](#section128222336544) - [JS语言用例开发指导(适用于标准系统)](#section159801435165220) - [JS语言用例编译打包指导(适用于标准系统)](#section445519106559) - - [\#ZH-CN\_TOPIC\_0000001126156429/section191521423950](#section191521423950) - [全量编译指导(适用于标准系统)](#section1519992743415) - [全量用例执行指导(适用于小型系统、标准系统)](#section118149111426) @@ -695,7 +694,6 @@ Windows工作台下安装python3.7及以上版本,确保工作台和测试设 ![](figure/zh-cn_image_0000001119924146.gif) - - 模块执行\(具体模块可以查看\\acts\\testcases\\\) ``` @@ -704,7 +702,6 @@ Windows工作台下安装python3.7及以上版本,确保工作台和测试设 ![](figure/zh-cn_image_0000001166643927.jpg) - 等待执行完成。 diff --git a/zh-cn/device-dev/subsystems/subsys.md b/zh-cn/device-dev/subsystems/subsys.md index b301414e122da41764db79ca418a5d7a84c838a8..b36d4325c6d4389ad8fe7e5c3168fec7f323292f 100644 --- a/zh-cn/device-dev/subsystems/subsys.md +++ b/zh-cn/device-dev/subsystems/subsys.md @@ -1,4 +1,4 @@ -# 子系统开发指南 +# 子系统 - **[编译构建](subsys-build.md)** @@ -12,7 +12,7 @@ - **[AI框架](subsys-aiframework.md)** -- **[Sensor服务](subsys-sensor.md)** +- **[Sensor服务](subsys-densor.md)** - **[用户程序框架](subsys-application-framework.md)** @@ -22,12 +22,12 @@ - **[启动恢复](subsys-boot.md)** -- **[测试](subsys-testguide-test.md)** +- **[测试用例开发指导](subsys-testguide-test.md)** - **[DFX](subsys-dfx.md)** -- **[HiSysEvent订阅指导](subsys-dfx-hisyseventread.md)** +- **[研发工具链](subsys-toolchain.md)** -- **[XTS认证子系统开发指南](subsys-xts-guide.md)** +- **[XTS认证用例开发指导](subsys-xts-guide.md)** diff --git a/zh-cn/readme.md b/zh-cn/readme.md index e2e5a096466e209c5e220c61fd2a0f1c88c4c2c6..b06bd9e00c6c412a40e11c24f87c43d2cb7c3130 100644 --- a/zh-cn/readme.md +++ b/zh-cn/readme.md @@ -17,14 +17,14 @@ - Security:[隐私与安全](device-dev/security/Readme-CN.md) - guide:开发示例 - - [WLAN连接类产品](device-dev/guide/device-wifi.md)(LED外设控制、集成三方SDK) + - [WLAN连接类产品](device-dev/guide/device-wlan.md)(LED外设控制、集成三方SDK) - [无屏摄像头类产品](device-dev/guide/device-iotcamera-control.md)(摄像头控制) - [带屏摄像头类产品](device-dev/guide/device-camera.md)(屏幕和摄像头控制、视觉应用开发) - porting:移植适配 - - [三方库移植指导](device-dev/porting/transplant-thirdparty.md) - - [轻量系统芯片移植指导](device-dev/porting/transplant-minichip.md) - - [小型系统芯片移植指导](device-dev/porting/transplant-smallchip.md) + - [三方库移植指导](device-dev/porting/porting-thirdparty.md) + - [轻量系统芯片移植指导](device-dev/porting/porting-minichip.md) + - [小型系统芯片移植指导](device-dev/porting/porting-smallchip.md) - bundles:Bundle开发 - [Bundle开发规范](device-dev/bundles/oem_bundle_standard_des.md) @@ -47,7 +47,7 @@ - [外设驱动](device-dev/guide/device-outerdriver-demo.md) - porting:移植适配 - - [三方库移植指导](device-dev/porting/transplant-thirdparty.md) + - [三方库移植指导](device-dev/porting/porting-thirdparty.md) - [标准系统芯片移植指导](device-dev/porting/standard-system-porting-guide.md) - bundles:Bundle开发