diff --git a/en/device-dev/bundles/Readme-EN.md b/en/device-dev/bundles/Readme-EN.md
index 2ae8dc847c778c4cef4a191f56f5d3e107a2d1c7..b95e0adea8e0b365a0c1a7736a77c8a8a1643ac2 100644
--- a/en/device-dev/bundles/Readme-EN.md
+++ b/en/device-dev/bundles/Readme-EN.md
@@ -1,20 +1,11 @@
-# Bundle Development
-
-- [Development Specifications](development-specifications.md)
- - [Overview](overview.md)
- - [Bundle Composition](bundle-composition.md)
- - [Bundle Management](bundle-management.md)
- - [Bundle Version](bundle-version.md)
- - [Distribution](distribution.md)
- - [Environment Variables](environment-variables.md)
-
-- [Development Guidelines](development-guidelines.md)
- - [Overview](overview-0.md)
- - [Preparations](preparations.md)
- - [Bundle Development](bundle-development.md)
-
-- [HPM User Guide](hpm-user-guide.md)
- - [Introduction](introduction.md)
- - [Preparations](preparations-1.md)
- - [Development Example](development-example.md)
-
+# Bundle Development
+
+- [Development Specifications](bundles-standard-rules.md)
+- [Development Guidelines](bundles-guide.md)
+ - [Bundle Development](bundles-guide-overview.md)
+ - [Preparations](bundles-guide-prepare.md)
+ - [Bundle Development](bundles-guide-develop.md)
+- [HPM User Guide](bundles-demo.md)
+ - [Introduction](bundles-demo-hpmdescription.md)
+ - [Preparations](bundles-demo-environment.md)
+ - [Development Example](bundles-demo-devsample.md)
\ No newline at end of file
diff --git a/en/device-dev/bundles/bundle-composition.md b/en/device-dev/bundles/bundle-composition.md
deleted file mode 100644
index 754f38a7c428547cacc97f55d0042e6eae62bb75..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/bundle-composition.md
+++ /dev/null
@@ -1,99 +0,0 @@
-# Bundle Composition
-
-- [Code files](#section101483489110)
-- [README File](#section10519101221211)
-- [Metadata Description File](#section45511827111211)
-
-A bundle contains the following contents:
-
-- **src** directory for storing code files or code library
-- **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
-- **LICENSE** file for open-source code
-
- ```
- my-bundle
- |_ohos_bundles
- |_src
- |_bundle.json
- |_README.md
- |_LICENSE
- ```
-
-
-## Code files
-
-Bundle code files are the same as those in a common code directory. The only difference lies in the open APIs \(declared in header files\) of a bundle, which are likely to be referenced by other bundles and need to be declared in the **dirs** of **bundle.json**.
-
-## README File
-
-**README.md** is a bundle self-description file using the markdown syntax. For details, see [Syntax Reference](https://www.markdownguide.org/getting-started/).
-
-To help you easily find and use the desired bundle on the HarmonyOS Package Manager \(HPM\) platform, a **README** file is provided in the root directory of each bundle.
-
-The **README** file may include instructions on how to install, configure, and use the instance code in the bundle, as well as any other information helpful to you.
-
-The **README** file is available in the bundle details page of the HPM platform.
-
-## Metadata Description File
-
-A **bundle.json** file describes the metadata of a bundle. Each bundle has its own **bundle.json** file.
-
-```
-{
- "name": "@myorg/demo-bundle",
- "version": "1.0.0",
- "license": "MIT",
- "description": "bundle description",
- "keywords": ["hos"],
- "tags": ["applications", "drivers"],
- "author": {"name":"","email":"","url":""},
- "contributors":[{"name":"","email":"","url":""},{"name":"","email":"","url":""}],
- "homepage": "http://www.foo.bar.com",
- "repository": "https://git@gitee.com:foo/bar.git",
- "publishAs": "source",
- "dirs": {
- "src": ["src/**/*.c"],
- "headers": ["headers/**/*.h"],
- "bin": ["bin/**/*.o"]
- },
- "scripts": {
- "build": "make"
- },
- "envs": {},
- "ohos": {
- "os": "2.0.0",
- "board": "hi3516",
- "kernel": "liteos-a"
- },
- "rom": "10240",
- "ram": "1024",
- "dependencies": {
- "@myorg/net":"1.0.0"
- }
-}
-```
-
-Each **bundle.json** file has the following fields:
-
-- **name**: a bundle name, which starts with @ and is separated by /, for example, **@myorg/mybundle**
-
-- **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
-
-- **envs**: parameters required for bundle compilation, including global parameters and dependency parameters.
-
-- **scripts**: commands executable to a bundle, such as those for compiling, building, testing, and burning
-
-- **publishAs**: bundle publishing type, which can be **source**, **binary**, **distribution**, or **code-segment**
-
-- **dirs**: directory structure \(such as the header file\) generated for publishing
-
-- **ram&rom**: statistical information about the estimated read-only memory \(ROM\) and random access memory \(RAM\) usage
-- **ohos**: mappings among OpenHarmony versions, development boards, and kernels, separated by commas \(,\).
-- Extended information: author, home page, code repository, license, tags, and keywords
-- **base** \(only for a distribution\): a base distribution which others inherit from.
-
diff --git a/en/device-dev/bundles/bundle-development.md b/en/device-dev/bundles/bundle-development.md
deleted file mode 100644
index 09330f69915d1cc850b0125a3e198e4f1c8c163f..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/bundle-development.md
+++ /dev/null
@@ -1,241 +0,0 @@
-# Bundle Development
-
-- [Developing a OpenHarmony Bundle](#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 a Distribution](#section413216495619)
-- [Defining Scripts](#section11503171219190)
-- [Distributing](#section4694125521912)
-- [Burning](#section1746331545413)
-- [Debugging](#section6742131615549)
-
-## Developing a OpenHarmony Bundle
-
-You have an option to use any of the following methods to develop an OpenHarmony bundle:
-
-- 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.
-
-## 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.
-
-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:
-
-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:
-
-```
-hpm init -t default -d demo my-bundle
-```
-
-The following files are generated in the **source** directory:
-
-```
-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
-```
-
-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.
-
-## Modifying 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:
-
-```
-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.
-
- ```
- $ hpm init
- Your bundle will be created in dirname E:\demo\mybundle2
- ? bundle name mybundel2
- ? version 1.0.0
- Init finished!
- ```
-
-
-1. Modify other information \(such as the author, code repository, code directory, command script, and dependent bundles\) in **bundle.json**.
-
- ```
- {
- "name": "mybundle2",
- "version": "1.0.0",
- "publishAs": "source",
- "dirs":{
- ".":[
- "README.md"
- ],
- "src":[
- "test.c"
- ],
- "header":[
- "header/test.h"
- ],
- "src/common":[
- "src/common/foobar.txt"
- ]
- },
- "scripts": {
- "build": "make -${args}"
- },
- "dependencies": {
- "@ohos/cjson": "^1.0.0",
- "@ohos/": "^1.2.0"
- }
- }
- ```
-
-
-## Using HPM-provided Template to Create a Bundle
-
-The HPM provides **default** and **simple** templates as well as other templates that are stored on the server.
-
-You can run the **hpm search -t template** command to search for a template stored on the server.
-
-
-
-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:
-
-```
-hpm init -t {templatename} -d dir name
-```
-
-- **\{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.
-
-## Building a Bundle
-
-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.
-
-## Defining the Building Script
-
-This section uses how to build an executable file **helloworld** in the **app** directory as an example.
-
-```
-app
-├── BUILD.gn
-├── include
-│ └── helloworld.h
-└── src
- └── helloworld.c
-```
-
-Create a **BUILD.gn** file in the same directory as **helloworld.c**.
-
-```
-touch BUILD.gn
-vim BUILD.gn
-```
-
-The following is an example of **BUILD.gn** for your reference:
-
-```
-executable("hello_world") {
- sources = [
- "src/helloworld.c"
- ]
-
- include_dirs = [
- "include"
- ]
-}
-```
-
-> **NOTE:**
->- **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
-
-Run the following command:
-
-```
-hpm build
-```
-
-After all building operations are complete, the message "build succeed" is displayed. You need to check the building result.
-
-
-
-## 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.
-
-## Defining Scripts
-
-Define scripts in **bundle.json** as follows:
-
-```
-{
-"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
-
-Run the following command in the current distribution directory:
-
-```
-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:
-
-```
-out
-|-xxdist.img
-|-xx.file
-```
-
-## 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.
-
-```
-"scripts": {
-"flash": "{$DEP_HIBURN}/hiburn"
-},
-```
-
-You should set burning parameters by referring to the specific guide on the burning tool you use.
-
-```
-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.
-
diff --git a/en/device-dev/bundles/bundle-management.md b/en/device-dev/bundles/bundle-management.md
deleted file mode 100644
index 4511f3427ca7e4ba140bc844e3c4450fd545daf8..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/bundle-management.md
+++ /dev/null
@@ -1,232 +0,0 @@
-# Bundle Management
-
-- [Dependency](#section12657593129)
-- [HPM Command Reference](#section1258849181312)
-
-## Dependency
-
-A basic **bundle.json** file needs to be enriched by bundle dependencies to implement more complex features. Bundle names and version numbers should be defined in the **dependencies** field of **bundle.json**.
-
-```
-{
- "name": "my-bundle",
- "version": "1.0.0",
- "dependencies": {
- "net": "1.0.0"
- }
-}
-```
-
-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:
-
-```
-hpm install
-```
-
-Bundle dependencies are then stored in the **ohos\_bundles** folder in the root directory of the current bundle. A tree structure illustrating the bundle and its dependencies will be generated. You need to run the following command in the root directory of the bundle:
-
-```
-username@server MINGW64 /f/showcase/demo/demo
-$ hpm list
-+--demo@1.0.0
-| +--@huawei/media@1.0.2
-| +--@demo/sport_hi3518ev300_liteos_a@1.0.0
-| | +--@demo/app@4.0.1
-| | | +--@demo/build@4.0.1
-| | | +--@demo/arm_harmonyeabi_gcc@4.0.0
-| | +--@demo/liteos_a@4.0.0
-| | | +--@demo/third_party_fatfs@4.0.0
-| | | +--@demo/arm_harmonyeabi_gcc@4.0.0
-| | +--@demo/init@4.0.0
-| | +--@demo/dist_tools@4.0.0
-```
-
-Alternatively, you can view the dependencies of the current bundle in a graph by running the following command:
-
-```
-hpm dependencies
-```
-
-A **deps\_visual** folder is generated in the current directory. The folder contains the **deps.html** and **deps-data.js** files. After you open the **deps.html** file via a browser, you can view bundle dependencies illustrated by a graph, as shown in the following figure.
-
-Each dependency type is indicated by a different color at the corresponding node. You can move the mouse pointer to a node to view the implied information.
-
-**Figure 1** Bundle dependencies
-
-
-## HPM Command Reference
-
-You can use the hpm-cli tool to manage the lifecycle of a bundle. The following table describes available HPM commands. \(You can run the **hpm -h** command to get the command details\).
-
-**Table 1** HPM commands
-
-
-
Function
-
-
Command
-
-
Description
-
-
-
-
Querying version information
-
-
hpm -V or hpm --version
-
-
Queries the hpm-cli version number.
-
-
-
Querying help information
-
-
hpm -h or hpm --version
-
-
Queries the command list and help information.
-
-
-
hpm -h
-
-
Queries command reference.
-
-
-
Creating a project
-
-
-
hpm init bundle
-
-
Creates a bundle project.
-
-
-
hpm init -t template
-
-
Creates a scaffolding project based on the template.
-
-
-
Installing bundles
-
-
-
hpm install or hpm i
-
-
Installs dependent bundles in the bundle.json file.
-
-
-
hpm install bundle@version
-
-
Installs bundles of a specified version.
-
-
-
Uninstalling bundles
-
-
-
hpm uninstall bundle
-
-
Removes dependent bundles.
-
-
-
hpm remove or hpm rm bundlename
-
-
Removes dependent bundles.
-
-
-
Viewing information
-
-
-
hpm list or hpm ls
-
-
Displays the bundle tree of available bundles and distributions.
-
-
-
hpm dependencies
-
-
Generates the dependency diagram (in HTML format) of available bundles and distributions.
-
-
-
Searching for bundles
-
-
hpm search name
-
-
Searches for bundles. --json is used to specify the search result in JSON format, and -type is used to set the target type, which can be bundle, distribution, or code-segment.
-
-
-
Setting HPM configuration items
-
-
hpm config set key value
-
-
Sets configuration items, such as the server address and network proxy.
-
-
-
hpm config delete key
-
-
Deletes configurations.
-
-
-
Updating bundle versions
-
-
-
hpm update
-
-
Updates the versions of dependent bundles.
-
-
-
hpm check-update
-
-
Checks whether version updates are available to dependent bundles.
-
-
-
Building
-
-
-
hpm build
-
-
Builds a bundle or distribution.
-
-
-
hpm dist
-
-
Packs a distribution, depending on the dist script in scripts of bundle.json.
-
-
-
Packing
-
-
hpm pack
-
-
Packs dependencies of local bundles.
-
-
-
Burning
-
-
hpm run flash
-
-
Burns the firmware, depending on the flash script in scripts of bundle.json.
-
-
-
Publishing
-
-
hpm publish
-
-
Publishes a bundle, which must be unique in the repository and has a unique version. (An account is required for login.)
-
-
-
Running extended commands
-
-
hpm run
-
-
Runs the commands in scripts defined in bundle.json. Multiple commands can be executed in batches by using &&.
-
-
-
Generating a key
-
-
hpm gen-keys
-
-
Generates a public-private key pair and configures the public key on the HPM server, achieving password-free hpm-cli login for bundle publishing.
-
-
-
Generating third-party open source notice
-
-
hpm gen-notice
-
-
Generates a joint file describing the notice on third-party open source based on the description of each bundle.
-
-
-
-
-
diff --git a/en/device-dev/bundles/bundle-version.md b/en/device-dev/bundles/bundle-version.md
deleted file mode 100644
index d07118d86a36d626e1ba8a04112560d4fb25d4ad..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/bundle-version.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Bundle Version
-
-- [Version Number Naming Specifications](#section16893854141310)
-- [Version Publishing](#section43401320171420)
-
-## Version Number Naming Specifications
-
-Each version name allows only lowercase letters, which can be separated by hyphens \(-\) or underscores \(\_\). For example, **bundle** and **my\_bundle** are allowed.
-
-A bundle version number is in the format of _major version number_._minor version number_._revision version number_ or _major version number_._minor version number_._revision version number_-_pre-release version number_, for example, **1.0.0** and **1.0.0-beta**. For details, see [https://semver.org](https://semver.org/).
-
-## Version Publishing
-
-You should upload bundles to the remote repository so that your peers have an option to use them. You can run the following command to upload the bundles:
-
-```
-hpm publish
-```
-
-After this command is executed, the system checks the bundle dependencies and downloads the missing dependencies. If the bundles you uploaded are in binary, the system compiles the entire bundle, generates a binary file, packs the file, and uploads it. If the bundles you uploaded are in another format, the system packs the bundle file in compliance with the defined packing rules and then uploads the file.
-
-Note: To publish a bundle, you need an HPM account for login. After logging in to the HPM platform, register with an organization and apply for authentication. After successful authentication, you will have the permission to publish the bundle.
-
diff --git a/en/device-dev/bundles/bundles-demo-devsample.md b/en/device-dev/bundles/bundles-demo-devsample.md
new file mode 100644
index 0000000000000000000000000000000000000000..4b896d4811456deb410fab4abbab7baac6e2493c
--- /dev/null
+++ b/en/device-dev/bundles/bundles-demo-devsample.md
@@ -0,0 +1,54 @@
+# Development Example
+
+This following uses the Hi3861 platform as an example to describe how to install, compile, and package components by using HPM.
+
+1. Run the following commands to initialize the installation directory \(whose name can be customized\):
+
+ ```
+ mkdir test3861
+ cd test3861
+ hpm init -t dist
+ ```
+
+ If the following information is displayed, the initialization is successful:
+
+ ```
+ Initialization finished.
+ ```
+
+2. Run the following command to install the **wifi\_iot** distribution:
+
+ ```
+ hpm install @ohos/wifi_iot
+ ```
+
+ If the following information is displayed, the installation is successful:
+
+ ```
+ Installed.
+ ```
+
+ > **NOTE:**
+ >Run the following command for the Hi3516 platform:
+ >```
+ >hpm install @ohos/ip_camera_hi3516dv300
+ >```
+ >Run the following command for the Hi3518 platform:
+ >```
+ >hpm install @ohos/ip_camera_hi3518ev300
+ >```
+
+3. Run the following command to build and package components:
+
+ ```
+ hpm dist
+ ```
+
+ If the building is successful, the following information is displayed:
+
+ ```
+ {{name}}: distribution building completed.
+ ```
+
+4. Check the result in the **./out** directory. You can burn the distribution into the corresponding development board for testing.
+
diff --git a/en/device-dev/bundles/bundles-demo-environment.md b/en/device-dev/bundles/bundles-demo-environment.md
new file mode 100644
index 0000000000000000000000000000000000000000..6780aa705ee1b918dd9f6d748c286b0deae34476
--- /dev/null
+++ b/en/device-dev/bundles/bundles-demo-environment.md
@@ -0,0 +1,139 @@
+# Preparations
+
+- [Linux Server](#section20979554791)
+- [Node.js](#section9954105413153)
+- [HPM](#section15937194904819)
+- [Python Environment](#section1621819180417)
+- [File Packaging Tool](#section77617165913)
+- [SCons](#section20558439191516)
+
+## 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.
+
+Configure Ubuntu to use bash as the Linux system shell, by performing the following:
+
+```
+ls -l $(which sh)
+# If the file does not point to bash, modify the file using either of the provided methods.
+# Method 1: Run the following command and select no:
+dpkg-reconfigure dash
+# Method 2: Run the following commands to delete /bin/sh and then create a new symbolic link to bash:
+rm -f /bin/sh
+ln -s bash /bin/sh
+```
+
+## Node.js
+
+> **NOTE:**
+>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
+>```
+
+You are advised to install Node.js 12.x \(including npm 6.14.4\) or a later version \(12.13.0 or later is recommended\).
+
+```
+sudo apt-get install nodejs
+sudo apt-get install npm
+```
+
+Run the following commands to view Node.js and NPM versions:
+
+```
+node --version # Check the Node.js version.
+npm --version # Check the NPM version.
+```
+
+## HPM
+
+Install the **hpm-cli** command line tool by using the NPM \(default source: https://registry.npmjs.org/\) provided by the Node.js.
+
+```
+npm install -g @ohos/hpm-cli
+```
+
+After **hpm-cli** is installed, run the following command to view default HPM configurations:
+
+```
+hpm config
+```
+
+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.
+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.
+```
+
+For details about **hpm-cli** commands, see [HPM Commands](bundles-standard-rules.md).
+
+## Python Environment
+
+Run the following commands to install Python later than 3.7:
+
+```
+sudo apt-get install python3.8
+sudo apt-get install python3-pip
+sudo pip3 install setuptools
+sudo pip3 install kconfiglib # Install kconfiglib 13.2.0 or later.
+```
+
+> **NOTE:**
+>The preceding method is applicable to Hi3518 and Hi3516 platforms. For Hi3861, run the following commands to install the Python environment:
+>```
+>sudo apt-get install python3.8
+>sudo apt-get install python3-pip
+>sudo pip3 install setuptools
+>sudo pip3 install kconfiglib # Install kconfiglib 13.2.0 or later.
+>sudo pip3 install pycryptodome
+>sudo pip3 install six --upgrade --ignore-installed six
+>sudo pip3 install ecdsa
+>```
+
+If both Python2 and Python3 have been installed in the current system, run the following commands to set the default Python to Python3:
+
+```
+ll `which python`
+rm /usr/bin/python
+ln -s python3.8 /usr/bin/python
+```
+
+## File Packaging Tool
+
+Run the following commands to install the tool:
+
+```
+which mkfs.vfat # If mkfs.vfat is not found, run the following command:
+sudo apt-get install dosfstools
+which mcopy # If mcopy is not found, run the following command:
+sudo apt-get install mtools
+```
+
+> **NOTE:**
+>Both Hi3518 and Hi3516 platforms require the file packaging tool. For Hi3861, the tool is not required.
+
+## SCons
+
+1. Start a Linux server.
+2. Run the following command to install the SCons installation package:
+
+ ```
+ 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.
+
+ ```
+ scons -v
+ ```
+
+ **Figure 1** Successful installation \(SCons version requirement: 3.0.4 or later\)
+ -25.png "successful-installation-(scons-version-requirement-3-0-4-or-later)-25")
+
+
+> **NOTE:**
+>SCons is required for the Hi3861 platform, but not for the Hi3518 or Hi3516 platform.
+
diff --git a/en/device-dev/bundles/introduction.md b/en/device-dev/bundles/bundles-demo-hpmdescription.md
similarity index 100%
rename from en/device-dev/bundles/introduction.md
rename to en/device-dev/bundles/bundles-demo-hpmdescription.md
diff --git a/en/device-dev/bundles/bundles-demo.md b/en/device-dev/bundles/bundles-demo.md
new file mode 100644
index 0000000000000000000000000000000000000000..846d6b1bde058051ef3212edb3596a2d7ec22396
--- /dev/null
+++ b/en/device-dev/bundles/bundles-demo.md
@@ -0,0 +1,9 @@
+# HPM User Guide
+
+- **[Introduction](bundles-demo-hpmdescription.md)**
+
+- **[Preparations](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
new file mode 100644
index 0000000000000000000000000000000000000000..d7f0fdad1f664ab9f46ffbee7f40e07ae024dffb
--- /dev/null
+++ b/en/device-dev/bundles/bundles-guide-develop.md
@@ -0,0 +1,240 @@
+# Bundle Development
+
+- [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 a Distribution](#section413216495619)
+- [Defining Scripts](#section11503171219190)
+- [Distributing](#section4694125521912)
+- [Burning](#section1746331545413)
+- [Debugging](#section6742131615549)
+
+## Developing 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.
+
+## 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.
+
+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:
+
+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:
+
+```
+hpm init -t default -d demo my-bundle
+```
+
+The following files are generated in the **source** directory:
+
+```
+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
+```
+
+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.
+
+## Modifying 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:
+
+```
+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.
+
+ ```
+ $ hpm init
+ Your bundle will be created in dirname E:\demo\mybundle2
+ ? bundle name mybundel2
+ ? version 1.0.0
+ Init finished!
+ ```
+
+
+1. Modify other information \(such as the author, code repository, code directory, command script, and dependent bundles\) in **bundle.json**.
+
+ ```
+ {
+ "name": "mybundle2",
+ "version": "1.0.0",
+ "publishAs": "source",
+ "dirs":{
+ ".":[
+ "README.md"
+ ],
+ "src":[
+ "test.c"
+ ],
+ "header":[
+ "header/test.h"
+ ],
+ "src/common":[
+ "src/common/foobar.txt"
+ ]
+ },
+ "scripts": {
+ "build": "make -${args}"
+ },
+ "dependencies": {
+ "@ohos/cjson": "^1.0.0",
+ "@ohos/": "^1.2.0"
+ }
+ }
+ ```
+
+
+## Using HPM-provided Template to Create a Bundle
+
+The HPM provides **default** and **simple** templates as well as other templates that are stored on the server.
+
+You can run the **hpm search -t template** command to search for a template stored on the server.
+
+
+
+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:
+
+```
+hpm init -t {templatename} -d dir name
+```
+
+- **\{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.
+
+## Building a Bundle
+
+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.
+
+## Defining the Building Script
+
+This section uses how to build an executable file **helloworld** in the **app** directory as an example.
+
+```
+app
+├── BUILD.gn
+├── include
+│ └── helloworld.h
+└── src
+ └── helloworld.c
+```
+
+Create a **BUILD.gn** file in the same directory as **helloworld.c**.
+
+```
+touch BUILD.gn
+vim BUILD.gn
+```
+
+The following is an example of **BUILD.gn** for your reference:
+
+```
+executable("hello_world") {
+ sources = [
+ "src/helloworld.c"
+ ]
+
+ include_dirs = [
+ "include"
+ ]
+}
+```
+
+> **NOTE:**
+>- **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
+
+Run the following command:
+
+```
+hpm build
+```
+
+After all building operations are complete, the message "build succeed" is displayed. You need to check the building result.
+
+
+
+## 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.
+
+## Defining Scripts
+
+Define scripts in **bundle.json** as follows:
+
+```
+{
+"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
+
+Run the following command in the current distribution directory:
+
+```
+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:
+
+```
+out
+|-xxdist.img
+|-xx.file
+```
+
+## 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.
+
+```
+"scripts": {
+"flash": "{$DEP_HIBURN}/hiburn"
+},
+```
+
+You should set burning parameters by referring to the specific guide on the burning tool you use.
+
+```
+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.
+
diff --git a/en/device-dev/bundles/bundles-guide-overview.md b/en/device-dev/bundles/bundles-guide-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..a6d16e00da5e950294612bc72454fe531fa3bbdf
--- /dev/null
+++ b/en/device-dev/bundles/bundles-guide-overview.md
@@ -0,0 +1,146 @@
+# 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)
+
+- [Bundle Development](#section15640113715318)
+
+## Overview
+
+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.
+
+- 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.
+
+**Table 1** Differences between a bundle and a distribution
+
+
+
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
+
+
+
+
+## Preparations
+
+### Hardware Requirements
+
+- Development boards \(examples: Hi3861, Hi3516D V300, and Hi3518E V300\)
+- Host computer \(Windows workstation\)
+- Linux server
+
+**Figure 2** Hardware connections
+
+
+### 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
+
diff --git a/en/device-dev/bundles/bundles-guide-prepare.md b/en/device-dev/bundles/bundles-guide-prepare.md
new file mode 100644
index 0000000000000000000000000000000000000000..f706e2c2f8ebf2c8307e60a5595d53eb9799d1c1
--- /dev/null
+++ b/en/device-dev/bundles/bundles-guide-prepare.md
@@ -0,0 +1,84 @@
+# Preparations
+
+- [Hardware Requirements](#section98535485518)
+- [Installing Node.js and the hpm-cli Tool](#section106591616205311)
+- [\(Optional\) Modifying HPM Configurations](#section71821165412)
+- [Downloading OpenHarmony Code](#section102338221707)
+- [Installing Dependent Bundles](#section19233183315020)
+
+## Hardware Requirements
+
+- Development boards \(examples: Hi3861, Hi3516D V300, and Hi3518E V300\)
+- Host computer \(Windows workstation\)
+- Linux server
+
+**Figure 1** Hardware connections
+
+
+## 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.
+
diff --git a/en/device-dev/bundles/bundles-guide.md b/en/device-dev/bundles/bundles-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..162b7be93ab12c2b1da404fd0fca89f6a3b6e4d4
--- /dev/null
+++ b/en/device-dev/bundles/bundles-guide.md
@@ -0,0 +1,9 @@
+# Development Guidelines
+
+- **[Bundle Development](bundles-guide-overview.md)**
+
+- **[Preparations](bundles-guide-prepare.md)**
+
+- **[Bundle Development](bundles-guide-develop.md)**
+
+
diff --git a/en/device-dev/bundles/bundles-standard-rules.md b/en/device-dev/bundles/bundles-standard-rules.md
new file mode 100644
index 0000000000000000000000000000000000000000..8adaac0e618ca9b141d52d7a4683a8ba3fa086ae
--- /dev/null
+++ b/en/device-dev/bundles/bundles-standard-rules.md
@@ -0,0 +1,549 @@
+# Development Specifications
+
+- [Overview](#section1725818533344)
+ - [Definition](#section4821219183514)
+ - [Bundle Division Principles](#section1089794263513)
+ - [Bundle Dependency](#section25701647163710)
+
+- [Bundle Composition](#section185538333914)
+ - [Code Files](#section8431268393)
+ - [README File](#section168121548173914)
+ - [Metadata Description File](#section7107181819406)
+
+- [Bundle Management](#section32061634104110)
+ - [Dependency](#section791115242423)
+ - [HPM Command Reference](#section1183205411429)
+
+- [Bundle Version](#section12612142864316)
+ - [Version Number Naming Specifications](#section1487612416432)
+ - [Version Publishing](#section1548171014440)
+
+- [Distribution](#section1264139114413)
+- [Environment Variables](#section15352105174512)
+
+## Overview
+
+This document describes the basic concepts of a bundle and how to define it in compliance with specifications.
+
+### Definition
+
+OpenHarmony software is developed on a per-bundle basis. In terms of the operating system, all software running on OpenHarmony are bundles. Generally, bundles are classified into the following types based on their application scopes:
+
+- Board-level bundles: device hardware-specific bundles, such as **board**, **arch**, and **mcu**
+- System-level bundles: a set of bundles with independent features, such as the kernel, file system, and framework
+- Application-level bundles: applications that provide services to users, such as **wifi\_iot** and **ip\_camera**
+
+Bundles are designed for reuse purposes. Any reusable modules can be defined as bundles. They are classified into the following types based on their forms:
+
+- Source code
+- Binary system
+- Code snippet
+- Distribution
+
+### Bundle Division Principles
+
+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:
+
+- Independence: Bundles provide relatively independent features and can be independently built. Each bundle is capable of providing its own APIs and services for external systems.
+- Coupling: If a bundle must depend on another bundle to provide services, they can be coupled to one bundle.
+- Correlation: If a group of bundles jointly implement a feature, and if other bundles never depend on them, the group of bundles can be combined into one bundle.
+
+### Bundle Dependency
+
+A bundle dependency can be mandatory or optional.
+
+- Mandatory dependency: If bundle A must depend on bundle B to implement a feature \(the APIs or services specific to bundle B must be invoked\), bundle B is a mandatory dependency of bundle A.
+- Optional dependency: If bundle C or bundle D is required for bundle A to implement a feature and bundle C and bundle D are interchangeable, bundle C and bundle D are optional dependencies of bundle A.
+
+## Bundle Composition
+
+A bundle contains the following:
+
+- **src** directory for storing code files or code library
+- **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
+- **LICENSE** file for open-source code
+
+ ```
+ my-bundle
+ |_ohos_bundles
+ |_src
+ |_bundle.json
+ |_README.md
+ |_LICENSE
+ ```
+
+
+### Code Files
+
+Bundle code files are the same as those in a common code directory. The only difference lies in the open APIs \(declared in header files\) of a bundle, which are likely to be referenced by other bundles and need to be declared in **dirs** of **bundle.json**.
+
+### README File
+
+**README.md** is a bundle self-description file using the markdown syntax. For details, see [Syntax Reference](https://www.markdownguide.org/getting-started/).
+
+To help you easily find and use the desired bundle on the HarmonyOS Package Manager \(HPM\) platform, a **README** file is provided in the root directory of each bundle.
+
+The **README** file may include instructions on how to install, configure, and use the instance code in the bundle, as well as any other information helpful to you.
+
+The **README** file is available in the bundle details page of the HPM platform.
+
+### Metadata Description File
+
+The **bundle.json** file describes the metadata of a bundle. Each bundle has its own **bundle.json** file.
+
+```
+{
+ "name": "@myorg/demo-bundle",
+ "version": "1.0.0",
+ "license": "MIT",
+ "description": "bundle description",
+ "keywords": ["hos"],
+ "tags": ["applications", "drivers"],
+ "author": {"name":"","email":"","url":""},
+ "contributors":[{"name":"","email":"","url":""},{"name":"","email":"","url":""}],
+ "homepage": "http://www.foo.bar.com",
+ "repository": "https://git@gitee.com:foo/bar.git",
+ "publishAs": "code-segment",
+ "segment":{
+ "destPath":"/the/dest/path"
+ },
+ "dirs": {
+ "src": ["src/**/*.c"],
+ "headers": ["headers/**/*.h"],
+ "bin": ["bin/**/*.o"]
+ },
+ "scripts": {
+ "build": "make"
+ },
+ "envs": {},
+ "ohos": {
+ "os": "2.0.0",
+ "board": "hi3516",
+ "kernel": "liteos-a"
+ },
+ "rom": "10240",
+ "ram": "1024",
+ "dependencies": {
+ "@myorg/net":"1.0.0"
+ }
+}
+```
+
+Each **bundle.json** file has the following fields:
+
+- **name**: a bundle name, which starts with @ and is separated by /, for example, **@myorg/mybundle**
+
+- **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
+
+- **envs**: parameters required for bundle compilation, including global parameters and dependency parameters.
+
+- **scripts**: commands executable to a bundle, such as commands for compiling, building, testing, and burning
+
+- **publishAs**: bundle publishing type, which can be **source**, **binary**, **distribution**, or **code-segment**
+
+- **segment**: destination path of the code-segment bundle. That is, the destination path of the files contained in the bundle package after the bundle is installed.
+- **dirs**: directory structure \(such as the header file\) generated for publishing
+
+- **ram&rom**: statistical information about the estimated read-only memory \(ROM\) and random access memory \(RAM\) usage
+- **ohos**: mappings among OpenHarmony versions, development boards, and kernels, separated by commas \(,\).
+- Extended information: author, home page, code repository, license, tags, and keywords
+- **base** \(only for a distribution\): a base distribution which others inherit from.
+
+## Bundle Management
+
+### Dependency
+
+A basic **bundle.json** file needs to be enriched by bundle dependencies to implement more complex features. Bundle names and version numbers should be defined in the **dependencies** field of **bundle.json**.
+
+```
+{
+ "name": "my-bundle",
+ "version": "1.0.0",
+ "dependencies": {
+ "net": "1.0.0"
+ }
+}
+```
+
+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:
+
+```
+hpm install
+```
+
+Bundle dependencies are then stored in the **ohos\_bundles** folder in the root directory of the current bundle. A tree structure illustrating the bundle and its dependencies will be generated. You need to run the following command in the root directory of the bundle:
+
+```
+username@server MINGW64 /f/showcase/demo/demo
+$ hpm list
++--demo@1.0.0
+| +--@huawei/media@1.0.2
+| +--@demo/sport_hi3518ev300_liteos_a@1.0.0
+| | +--@demo/app@4.0.1
+| | | +--@demo/build@4.0.1
+| | | +--@demo/arm_harmonyeabi_gcc@4.0.0
+| | +--@demo/liteos_a@4.0.0
+| | | +--@demo/third_party_fatfs@4.0.0
+| | | +--@demo/arm_harmonyeabi_gcc@4.0.0
+| | +--@demo/init@4.0.0
+| | +--@demo/dist_tools@4.0.0
+```
+
+Alternatively, you can run the following command to view the dependencies of the current bundle in a visualized way:
+
+```
+hpm ui
+```
+
+A web service is started on the local host \(by default, the browser is open and the project page is displayed\). Click the project dependency icon on the sidebar. The list of dependent bundles is displayed. Click the button on the right to switch to the tree view. The bundle dependencies are displayed as shown in the following figure.
+
+**Figure 1** Bundle dependencies
+
+
+
+
+### HPM Command Reference
+
+You can use the hpm-cli tool to manage the lifecycle of a bundle. The following table describes available HPM commands. \(You can run the **hpm -h** command to get the command details\).
+
+**Table 1** HPM commands
+
+
+
Function
+
+
Command Line
+
+
Description
+
+
+
+
Querying version information
+
+
hpm -V or hpm --version
+
+
Displays the hpm-cli version number.
+
+
+
Querying help information
+
+
hpm -h or hpm --version
+
+
Displays the command list and help information.
+
+
+
hpm -h
+
+
Displays command help information.
+
+
+
Creating a project
+
+
+
hpm init bundle
+
+
Creates a bundle project.
+
+
+
hpm init -t template
+
+
Creates a scaffolding project from a template.
+
+
+
Installing bundles
+
+
+
hpm install or hpm i
+
+
Installs dependent bundles in the bundle.json file.
+
+
+
hpm install bundle@version
+
+
Installs bundles of a specified version.
+
+
+
Uninstalling bundles
+
+
+
hpm uninstall bundle
+
+
Uninstalls dependent bundles.
+
+
+
hpm remove or hpm rm bundlename
+
+
Removes dependent bundles.
+
+
+
Viewing information
+
+
+
hpm list or hpm ls
+
+
Displays the bundle tree of available bundles and distributions.
+
+
+
hpm dependencies
+
+
Generates the dependency relationship data of a bundle or distribution. (This command is also integrated in the HPM UI to display the bundle dependencies intuitively.)
+
+
+
Searching for bundles
+
+
hpm search name
+
+
Searches for bundles. --json is used to specify the search result in JSON format, and -type is used to set the target type, which can be bundle, distribution, or code-segment.
+
+
+
Setting HPM configuration items
+
+
hpm config set key value
+
+
Sets configuration items, such as the server address and network proxy.
+
+
+
hpm config delete key
+
+
Deletes configurations.
+
+
+
Updating bundle versions
+
+
+
hpm update
+
+
Updates the versions of dependent bundles.
+
+
+
hpm check-update
+
+
Checks whether version updates are available to dependent bundles.
+
+
+
Building
+
+
+
hpm build
+
+
Builds a bundle or distribution.
+
+
+
hpm dist
+
+
Builds a distribution. The build depends on the dist script in scripts of bundle.json.
+
+
+
Packing
+
+
hpm pack
+
+
Packs dependencies of local bundles.
+
+
+
Burning
+
+
hpm run flash
+
+
Burns the firmware. The firmware burning depends on the flash script in scripts of bundle.json.
+
+
+
Publishing
+
+
hpm publish
+
+
Publishes a bundle, which must be unique in the repository and has a unique version. (An account is required for login.)
+
+
+
Running extended commands
+
+
hpm run
+
+
Runs the commands in scripts defined in bundle.json. Multiple commands can be executed at a time by using &&.
+
+
+
Decompressing
+
+
hpm extract
+
+
Decompresses files in zip, tar, tgz, or .tar.gz format.
+
+
+
Restarting GUI
+
+
hpm ui
+
+
Starts the HPM UI locally. You can use the -p parameter to specify a port. On the Windows platform, the default browser is used to open the HPM UI.
+
+
+
Changing language
+
+
hpm lang
+
+
Alternates between Chinese and English on the CLI and UI.
+
+
+
Converting to HPM format
+
+
hpm x2h
+
+
Converts a Maven or NPM package to an HPM package and publishes it to the HPM.
+
+
+
Code segment restoration or cleanup
+
+
hpm code clean|restore
+
+
Clears or restores the dependent code segment (code-segment). That is, copy or delete the code segment based on segment.destPath.
+
+
+
Generating a key
+
+
hpm gen-keys
+
+
Generates a public-private key pair and configures the public key on the HPM server, which enables password-free hpm-cli login for bundle publishing.
+
+
+
Generating third-party open source notice
+
+
hpm gen-notice
+
+
Generates a file providing the notice on third-party open source by combining the description of each bundle.
+
+
+
+
+
+## Bundle Version
+
+### Version Number Naming Specifications
+
+Each version name allows only lowercase letters, which can be separated by hyphens \(-\) or underscores \(\_\). For example, **bundle** and **my\_bundle** are allowed.
+
+A bundle version number is in the format of _major version number_._minor version number_._revision version number_ or _major version number_._minor version number_._revision version number_-_pre-release version number_, for example, **1.0.0** and **1.0.0-beta**. For details, see [https://semver.org](https://semver.org/).
+
+### Version Publishing
+
+You should upload bundles to the remote repository so that your peers have an option to use them. You can run the following command to upload the bundles:
+
+```
+hpm publish
+```
+
+After this command is executed, the system checks the bundle dependencies and downloads the missing dependencies. If the bundles you uploaded are in binary, the system compiles the entire bundle, generates a binary file, packs the file, and uploads it. If the bundles you uploaded are in another format, the system packs the bundle file in compliance with the defined packing rules and then uploads the file.
+
+Note: To publish a bundle, you need an HPM account for login. After logging in to the HPM platform, register with an organization and apply for authentication. After successful authentication, you will have the permission to publish the bundle.
+
+## 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.
+
+Generally, a distribution does not require code but contains only the **bundle.json** description \(**publishAs** set to **distribution**\) and some compilation scripts.
+
+As system-provided environment variables are required during distribution compiling, run the **dist** command in **scripts**.
+
+```
+{
+ "publishAs":"distribution",
+ "scripts": {
+ "dist": "script compile command"
+ }
+}
+```
+
+Run the following command:
+
+```
+hpm dist
+```
+
+As it is rather complex to redefine the functionality of a distribution, OpenHarmony allows inheritance from a distribution so that you can make a tailored distribution based on the existing functionality. To inherit from a distribution, you need to define the **base** field in **bundle.json**.
+
+```
+{
+ "base": {
+ "name": "dist_wifi_iot",
+ "version": "1.0.0"
+ }
+}
+```
+
+In this example, the current bundle inherits from the **dist-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.
+
+```
+{
+ "dependencies": {
+ "?my_bundle": "1.0.0"
+ }
+}
+```
+
+In this example, **my\_bundle** is an optional dependent bundle that can be removed by using the keyword **excludes**.
+
+```
+{
+ "excludes": [ "my_bundle" ]
+}
+```
+
+The removed **my-bundle** will not be involved in the build process. If you forcibly remove mandatory dependent bundles, an error message will be displayed.
+
+## Environment Variables
+
+During bundle compilation, system-provided environment variables are required to define the output and link the required binary files. These variables are injected into the context for executing scripts based on service requirements. Therefore, their values can be directly obtained from the scripts. The following environment variables are available:
+
+Global variables are defined by the **envs** attribute in **bundle.json**. All dependent bundles can obtain the values of global variables.
+
+```
+{
+ "envs": {
+ "compileEnv": "arm"
+ }
+}
+```
+
+Different parameters can be passed to bundles when introducing dependencies so that the compilation of dependent bundles can meet the requirements of the current bundle. The parameters defined in the dependencies can be obtained from the context for executing the corresponding scripts.
+
+```
+{
+ "dependencies": {
+ "my-bundle": {
+ "version": "1.0.0",
+ "mode": "debug"
+ }
+ }
+}
+```
+
+When linking to a binary file, the bundle needs to know the file path regarding the dependencies. Therefore, the path \(as an environment variable\) is passed to the bundle for compiling.
+
+The passed environment variable is in **DEP\__BundleName_** format, where **BundleName** indicates the name of the dependent bundle, for example, **DEP\_first\_bundle**.
+
+Tags can be defined to group dependent bundles. You can obtain the path of a group of dependent bundles based on their tag. A tag starts with a number sign \(\#\) and is defined as follows:
+
+```
+{
+ "dependencies": {
+ "#tool": {
+ "first-bundle": "1.0.0",
+ "second-bundle": "1.0.0"
+ },
+ "#drivers": {
+ "xx-bundle": "1.0.0",
+ "yy-bundle": "1.0.0"
+ }
+ }
+}
+```
+
+There are two fixed environment variables:
+
+- **DEP\_OHOS\_BUNDLES**: path of the **ohos\_bundles** folder
+- **DEP\_BUNDLE\_BASE**: path of the outermost bundle
+
diff --git a/en/device-dev/bundles/bundles.md b/en/device-dev/bundles/bundles.md
new file mode 100644
index 0000000000000000000000000000000000000000..21586387bbddd35439986cadb9c812a6d0c58bc3
--- /dev/null
+++ b/en/device-dev/bundles/bundles.md
@@ -0,0 +1,9 @@
+# Bundle Development
+
+- **[Development Specifications](bundles-standard-rules.md)**
+
+- **[Development Guidelines](bundles-guide.md)**
+
+- **[HPM User Guide](bundles-demo.md)**
+
+
diff --git a/en/device-dev/bundles/development-example.md b/en/device-dev/bundles/development-example.md
deleted file mode 100644
index 159de560311c2fe03fd03c947fbfa669c060f3fa..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/development-example.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Development Example
-
-This following uses the Hi3861 platform as an example to describe how to install, compile, and package components by using HPM.
-
-1. Run the following commands to initialize the installation directory \(whose name can be customized\):
-
- ```
- mkdir test3861
- cd test3861
- hpm init -t dist
- ```
-
- If the following information is displayed, the initialization is successful:
-
- ```
- Initialization finished.
- ```
-
-2. Run the following command to install the **wifi\_iot** distribution:
-
- ```
- hpm install @ohos/wifi_iot
- ```
-
- If the following information is displayed, the installation is successful:
-
- ```
- Installed.
- ```
-
- > **NOTE:**
- >Run the following command for the Hi3516 platform:
- >```
- >hpm install @ohos/ip_camera_hi3516dv300
- >```
- >Run the following command for the Hi3518 platform:
- >```
- >hpm install @ohos/ip_camera_hi3518ev300
- >```
-
-3. Run the following command to build and package components:
-
- ```
- hpm dist
- ```
-
- If the building is successful, the following information is displayed:
-
- ```
- {{name}}: distribution building completed.
- ```
-
-4. Check the result in the **./out** directory. You can burn the distribution into the corresponding development board for testing.
-
diff --git a/en/device-dev/bundles/development-guidelines.md b/en/device-dev/bundles/development-guidelines.md
deleted file mode 100644
index 6ae82a8f668402df6a4b967fad4fb85af5f59eef..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/development-guidelines.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Development Guidelines
-
-- **[Overview](overview-0.md)**
-
-- **[Preparations](preparations.md)**
-
-- **[Bundle Development](bundle-development.md)**
-
-
diff --git a/en/device-dev/bundles/development-specifications.md b/en/device-dev/bundles/development-specifications.md
deleted file mode 100644
index 6f583016abacb71b7bee2f3d550924cac1025286..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/development-specifications.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Development Specifications
-
-- **[Overview](overview.md)**
-
-- **[Bundle Composition](bundle-composition.md)**
-
-- **[Bundle Management](bundle-management.md)**
-
-- **[Bundle Version](bundle-version.md)**
-
-- **[Distribution](distribution.md)**
-
-- **[Environment Variables](environment-variables.md)**
-
-
diff --git a/en/device-dev/bundles/distribution.md b/en/device-dev/bundles/distribution.md
deleted file mode 100644
index 426905862509138efe9d65a22ddd1c5bc5b3d3f7..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/distribution.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# 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.
-
-Generally, a distribution does not require code but contains only the **bundle.json** description \(**publishAs** set to **distribution**\) and some compilation scripts.
-
-As system-provided environment variables are required during distribution compiling, run the **dist** command in **scripts**.
-
-```
-{
- "publishAs":"distribution",
- "scripts": {
- "dist": "script compile command"
- }
-}
-```
-
-Run the following command:
-
-```
-hpm dist
-```
-
-As it is rather complex to redefine the functionality of a distribution, OpenHarmony allows inheritance from a distribution so that you can make a tailored distribution based on the existing functionality. To inherit from a distribution, you need to define the **base** field in **bundle.json**.
-
-```
-{
- "base": {
- "name": "dist_wifi_iot",
- "version": "1.0.0"
- }
-}
-```
-
-In this example, the current bundle inherits from the **dist-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.
-
-```
-{
- "dependencies": {
- "?my_bundle": "1.0.0"
- }
-}
-```
-
-In this example, **my\_bundle** is an optional dependent bundle that can be removed by using the keyword "excludes".
-
-```
-{
- "excludes": [ "my_bundle" ]
-}
-```
-
-After **my-bundle** is removed, it will not be involved in the building process. If you forcibly remove mandatory dependent bundles, an error message will be displayed.
-
diff --git a/en/device-dev/bundles/environment-variables.md b/en/device-dev/bundles/environment-variables.md
deleted file mode 100644
index 933994a6818205f1a7958390a67876048369f67e..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/environment-variables.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# Environment Variables
-
-During bundle compilation, system-provided environment variables are required to define the output and link the required binary files. These variables are injected into the context for executing scripts based on service requirements. Therefore, their values can be directly obtained from the scripts. Currently, there are global and fixed environment variables in the system.
-
-Global variables are defined by the **envs** attribute in **bundle.json**. All dependent bundles can obtain the values of global variables.
-
-```
-{
- "envs": {
- "compileEnv": "arm"
- }
-}
-```
-
-Different parameters can be passed to bundles when introducing dependencies so that the compilation of dependent bundles can meet the requirements of the current bundle. The parameters defined in the dependencies can be obtained from the context for executing the corresponding scripts.
-
-```
-{
- "dependencies": {
- "my-bundle": {
- "version": "1.0.0",
- "mode": "debug"
- }
- }
-}
-```
-
-When linking to a binary file, the bundle needs to know the file path regarding the dependencies. Therefore, the path \(as an environment variable\) is passed to the bundle for compiling.
-
-The passed environment variable is in **DEP\__BundleName_** format, where **BundleName** indicates the name of the dependent bundle, for example, **DEP\_first-bundle**.
-
-Tags can be defined to group dependent bundles. You can obtain the path of a group of dependent bundles based on their tag. A tag starts with a number sign \(\#\) and is defined as follows:
-
-```
-{
- "dependencies": {
- "#tool": {
- "first-bundle": "1.0.0",
- "second-bundle": "1.0.0"
- },
- "#drivers": {
- "xx-bundle": "1.0.0",
- "yy-bundle": "1.0.0"
- }
- }
-}
-```
-
-There are two fixed environment variables:
-
-- **DEP\_OHOS\_BUNDLES**: path of the **ohos\_bundles** folder
-- **DEP\_BUNDLE\_BASE**: path of the outermost bundle
-
diff --git a/en/device-dev/bundles/figures/en-us_image_0000001051452177.png b/en/device-dev/bundles/figure/en-us_image_0000001051452177.png
similarity index 100%
rename from en/device-dev/bundles/figures/en-us_image_0000001051452177.png
rename to en/device-dev/bundles/figure/en-us_image_0000001051452177.png
diff --git a/en/device-dev/bundles/figures/en-us_image_0000001051770876.png b/en/device-dev/bundles/figure/en-us_image_0000001051770876.png
similarity index 100%
rename from en/device-dev/bundles/figures/en-us_image_0000001051770876.png
rename to en/device-dev/bundles/figure/en-us_image_0000001051770876.png
diff --git a/en/device-dev/bundles/figure/en-us_image_0000001173313501.png b/en/device-dev/bundles/figure/en-us_image_0000001173313501.png
new file mode 100644
index 0000000000000000000000000000000000000000..52f943be7f91caa887bff689f6c37040858fa8ce
Binary files /dev/null and b/en/device-dev/bundles/figure/en-us_image_0000001173313501.png differ
diff --git a/en/device-dev/bundles/figures/hardware-connections.png b/en/device-dev/bundles/figure/hardware-connections-23.png
similarity index 100%
rename from en/device-dev/bundles/figures/hardware-connections.png
rename to en/device-dev/bundles/figure/hardware-connections-23.png
diff --git a/en/device-dev/bundles/figure/hardware-connections-24.png b/en/device-dev/bundles/figure/hardware-connections-24.png
new file mode 100644
index 0000000000000000000000000000000000000000..c4636401a20e37794d8ec28dc173e9308b2b72db
Binary files /dev/null and b/en/device-dev/bundles/figure/hardware-connections-24.png differ
diff --git a/en/device-dev/bundles/figures/successful-installation-(scons-version-requirement-3-0-4-or-later).png b/en/device-dev/bundles/figure/successful-installation-(scons-version-requirement-3-0-4-or-later)-25.png
similarity index 100%
rename from en/device-dev/bundles/figures/successful-installation-(scons-version-requirement-3-0-4-or-later).png
rename to en/device-dev/bundles/figure/successful-installation-(scons-version-requirement-3-0-4-or-later)-25.png
diff --git "a/en/device-dev/bundles/figures/\347\273\204\344\273\2660924.png" "b/en/device-dev/bundles/figure/\347\273\204\344\273\2660924.png"
similarity index 100%
rename from "en/device-dev/bundles/figures/\347\273\204\344\273\2660924.png"
rename to "en/device-dev/bundles/figure/\347\273\204\344\273\2660924.png"
diff --git a/en/device-dev/bundles/figures/bundle-dependencies.png b/en/device-dev/bundles/figures/bundle-dependencies.png
deleted file mode 100644
index 1b936a2cbc95d3f9d7ddab0187305c3d0c486b0a..0000000000000000000000000000000000000000
Binary files a/en/device-dev/bundles/figures/bundle-dependencies.png and /dev/null differ
diff --git a/en/device-dev/bundles/hpm-user-guide.md b/en/device-dev/bundles/hpm-user-guide.md
deleted file mode 100644
index daaf5734779208bf468d896807d4ecdb3dfc6f6f..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/hpm-user-guide.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# HPM User Guide
-
-- **[Introduction](introduction.md)**
-
-- **[Preparations](preparations-1.md)**
-
-- **[Development Example](development-example.md)**
-
-
diff --git a/en/device-dev/bundles/overview-0.md b/en/device-dev/bundles/overview-0.md
deleted file mode 100644
index 44fc41de4b49eaf811cc9b139d6751613452c21d..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/overview-0.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Overview
-
-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.
-
-- 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.
-
-**Table 1** Differences between a bundle and a distribution
-
-
-
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
-
-
-
-
diff --git a/en/device-dev/bundles/overview.md b/en/device-dev/bundles/overview.md
deleted file mode 100644
index 3490dd84640d272e6c707c96d35fbee2c71b8da0..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/overview.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Overview
-
-- [Definition](#section177563344911)
-- [Bundle Division Principles](#section2487162541016)
-- [Bundle Dependency](#section185955409107)
-
-This document describes the basic concepts of a bundle and how to define it in compliance with specifications.
-
-## Definition
-
-OpenHarmony software is developed on a per-bundle basis. In terms of the operating system, all software running on OpenHarmony are bundles. Generally, bundles are classified into the following types based on their application scopes:
-
-- Board-level bundles: device hardware-specific bundles, such as **board**, **arch**, and **mcu**
-- System-level bundles: a set of bundles with independent features, such as the kernel, file system, and framework
-- Application-level bundles: applications that provide services to users, such as **wifi\_iot** and **ip\_camera**
-
-Bundles are designed for the reuse purpose. Any reusable modules can be defined as bundles. They are classified into the following types based on their forms:
-
-- Source code
-- Binary system
-- Code snippet
-- Distribution
-
-## Bundle Division Principles
-
-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:
-
-- Independence: Bundles provide relatively independent features and can be independently compiled. Each of them is capable of providing its own APIs and services for external systems.
-- Coupling: If a bundle must depend on another bundle to provide services, they can be coupled to one bundle.
-- Correlation: If a group of bundles jointly implement a feature, and if other bundles never depend on them, the group of bundles can be combined into one bundle.
-
-## Bundle Dependency
-
-A bundle dependency can be mandatory or optional.
-
-- Mandatory dependency: If bundle A must depend on bundle B to implement a feature, that is, the APIs or services specific to bundle B must be invoked, then bundle B is defined as the mandatory dependency of bundle A.
-- Optional dependency: If either bundle C or bundle D is required for bundle A to implement a feature, and if bundle C and bundle D are interchangeable, then bundle C and bundle D are defined as optional dependencies of bundle A.
-
diff --git a/en/device-dev/bundles/preparations-1.md b/en/device-dev/bundles/preparations-1.md
deleted file mode 100644
index 6a0981f81bc1c1562946a9f1987eaabc30b50439..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/preparations-1.md
+++ /dev/null
@@ -1,139 +0,0 @@
-# Preparations
-
-- [Linux Server](#section20979554791)
-- [Node.js](#section9954105413153)
-- [HPM](#section15937194904819)
-- [Python Environment](#section1621819180417)
-- [File Packaging Tool](#section77617165913)
-- [SCons](#section20558439191516)
-
-## 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.
-
-Configure Ubuntu to use bash as the Linux system shell, by performing the following:
-
-```
-ls -l $(which sh)
-# If the file does not point to bash, modify the file using either of the provided methods.
-# Method 1: Run the following command and select no:
-dpkg-reconfigure dash
-# Method 2: Run the following commands to delete /bin/sh and then create a new symbolic link to bash:
-rm -f /bin/sh
-ln -s bash /bin/sh
-```
-
-## Node.js
-
-> **NOTE:**
->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
->```
-
-You are advised to install Node.js 12.x \(including npm 6.14.4\) or a later version \(12.13.0 or later is recommended\).
-
-```
-sudo apt-get install nodejs
-sudo apt-get install npm
-```
-
-Run the following commands to view Node.js and NPM versions:
-
-```
-node --version # Check the Node.js version.
-npm --version # Check the NPM version.
-```
-
-## HPM
-
-Install the **hpm-cli** command line tool by using the NPM \(default source: https://registry.npmjs.org/\) provided by the Node.js.
-
-```
-npm install -g @ohos/hpm-cli
-```
-
-After **hpm-cli** is installed, run the following command to view default HPM configurations:
-
-```
-hpm config
-```
-
-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.
-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.
-```
-
-For details about **hpm-cli** commands, see [HPM Commands](bundle-management.md).
-
-## Python Environment
-
-Run the following commands to install Python later than 3.7:
-
-```
-sudo apt-get install python3.8
-sudo apt-get install python3-pip
-sudo pip3 install setuptools
-sudo pip3 install kconfiglib # Install kconfiglib 13.2.0 or later.
-```
-
-> **NOTE:**
->The preceding method is applicable to Hi3518 and Hi3516 platforms. For Hi3861, run the following commands to install the Python environment:
->```
->sudo apt-get install python3.8
->sudo apt-get install python3-pip
->sudo pip3 install setuptools
->sudo pip3 install kconfiglib # Install kconfiglib 13.2.0 or later.
->sudo pip3 install pycryptodome
->sudo pip3 install six --upgrade --ignore-installed six
->sudo pip3 install ecdsa
->```
-
-If both Python2 and Python3 have been installed in the current system, run the following commands to set the default Python to Python3:
-
-```
-ll `which python`
-rm /usr/bin/python
-ln -s python3.8 /usr/bin/python
-```
-
-## File Packaging Tool
-
-Run the following commands to install the tool:
-
-```
-which mkfs.vfat # If mkfs.vfat is not found, run the following command:
-sudo apt-get install dosfstools
-which mcopy # If mcopy is not found, run the following command:
-sudo apt-get install mtools
-```
-
-> **NOTE:**
->Both Hi3518 and Hi3516 platforms require the file packaging tool. For Hi3861, the tool is not required.
-
-## SCons
-
-1. Start a Linux server.
-2. Run the following command to install the SCons installation package:
-
- ```
- 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.
-
- ```
- scons -v
- ```
-
- **Figure 1** Successful installation \(SCons version requirement: 3.0.4 or later\)
- .png "successful-installation-(scons-version-requirement-3-0-4-or-later)")
-
-
-> **NOTE:**
->SCons is required for the Hi3861 platform, but not for the Hi3518 or Hi3516 platform.
-
diff --git a/en/device-dev/bundles/preparations.md b/en/device-dev/bundles/preparations.md
deleted file mode 100644
index dedd9b41f76f016fd1a33e1a407113feadabff7f..0000000000000000000000000000000000000000
--- a/en/device-dev/bundles/preparations.md
+++ /dev/null
@@ -1,84 +0,0 @@
-# Preparations
-
-- [Hardware Requirements](#section98535485518)
-- [Installing Node.js and the hpm-cli Tool](#section106591616205311)
-- [\(Optional\) Modifying HPM Configurations](#section71821165412)
-- [Downloading OpenHarmony Code](#section102338221707)
-- [Installing Dependent Bundles](#section19233183315020)
-
-## Hardware Requirements
-
-- Development boards \(examples: Hi3861, Hi3516DV300, and Hi3518EV300\)
-- Host computer \(Windows workstation\)
-- Linux server
-
-**Figure 1** Hardware connections
-
-
-## 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](bundle-management.md).
-
-## Downloading OpenHarmony Code
-
-For details, see [Source Code Acquisition](../get-code/source-code-acquisition.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/driver/Readme-EN.md b/en/device-dev/driver/Readme-EN.md
index 18678440ad06c989d251367330af5c65e8d93a59..bbcc73ae3c78709e739d443be1eb9f41329d4390 100644
--- a/en/device-dev/driver/Readme-EN.md
+++ b/en/device-dev/driver/Readme-EN.md
@@ -1,73 +1,23 @@
# Drivers
-- [HDF](hdf.md)
- - [HDF Overview](hdfoverview.md)
- - [Driver Development](driver-development.md)
- - [Driver Service Management](driver-service-management.md)
- - [Driver Message Mechanism Management](driver-message-mechanism-management.md)
- - [Driver Configuration Management](driver-configuration-management.md)
- - [HDF Development Example](hdfdevelopment-example.md)
-
-- [Driver Platform](driver-platform.md)
- - [GPIO](gpio.md)
- - [GPIO Overview](gpiooverview.md)
- - [GPIO Usage Guidelines](gpiousage-guidelines.md)
- - [GPIO Usage Example](gpiousage-example.md)
-
- - [I2C](i2c.md)
- - [I2C Overview](i2c-overview.md)
- - [I2C Usage Guidelines](i2c-usage-guidelines.md)
- - [I2C Usage Example](i2c-usage-example.md)
-
- - [RTC](rtc.md)
- - [RTC Overview](rtc-overview.md)
- - [RTC Usage Guidelines](rtc-usage-guidelines.md)
- - [RTC Usage Example](rtc-usage-example.md)
-
- - [SDIO](sdio.md)
- - [SDIO Overview](sdiooverview.md)
- - [SDIO Usage Guidelines](sdiousage-guidelines.md)
- - [SDIO Usage Example](sdiousage-example.md)
-
- - [SPI](spi.md)
- - [SPI Overview](spioverview.md)
- - [SPI Usage Guidelines](spiusage-guidelines.md)
- - [SPI Usage Example](spiusage-example.md)
-
- - [UART](uart.md)
- - [UART Overview](uartoverview.md)
- - [UART Usage Guidelines](uartusage-guidelines.md)
- - [UART Usage Example](uartusage-example.md)
-
- - [WATCHDOG](watchdog.md)
- - [Watchdog Overview](watchdogoverview.md)
- - [Watchdog Usage Guidelines](watchdogusage-guidelines.md)
- - [Watchdog Usage Example](watchdogusage-example.md)
-
- - [MIPI DSI](mipi-dsi.md)
- - [MIPI DSI Overview](mipi-dsi-overview.md)
- - [Usage Guidelines](usage-guidelines.md)
- - [Usage Example](usage-example.md)
-
-- [Peripherals](peripherals.md)
- - [LCD](lcd.md)
- - [LCD Overview](lcdoverview.md)
- - [LCD Development Guidelines](lcddevelopment-guidelines.md)
- - [LCD Development Example](lcddevelopment-example.md)
-
- - [TOUCHSCREEN](touchscreen.md)
- - [Touchscreen Overview](touchscreenoverview.md)
- - [Touchscreen Development Guidelines](touchscreendevelopment-guidelines.md)
- - [Touchscreen Development Example](touchscreendevelopment-example.md)
-
- - [SENSOR](sensor.md)
- - [Sensor Driver Overview](sensor-driver-overview.md)
- - [Sensor Driver Development Guidelines](sensor-driver-development-guidelines.md)
- - [Sensor Driver Development Example](sensor-driver-development-example.md)
- - [Sensor Driver Test Guidelines](sensor-driver-test-guidelines.md)
-
- - [WLAN](wlan.md)
- - [WLAN Overview](wlanoverview.md)
- - [WLAN Development Guidelines](wlandevelopment-guidelines.md)
- - [WLAN Development Example](wlandevelopment-example.md)
-
+- [HDF](drive-hdf.md)
+ - [HDF Overview](drive-hdf-overview.md)
+ - [Driver Development](drive-hdf-development.md)
+ - [Driver Service Management](drive-hdf-servicemanage.md)
+ - [Driver Message Mechanism Management](drive-hdf-news.md)
+ - [Driver Configuration Management](drive-hdf-manage.md)
+ - [HDF Development Example](drive-hdf-sample.md)
+- [Platform Drivers](drive-platform.md)
+ - [GPIO](drive-platform-gpio-des.md)
+ - [I2C](drive-platform-i2c-des.md)
+ - [RTC](drive-platform-rtc-des.md)
+ - [SDIO](drive-platform-sdio-des.md)
+ - [SPI](drive-platform-spi-des.md)
+ - [UART](drive-platform-uart-des.md)
+ - [Watchdog](drive-platform-watchdog-des.md)
+ - [MIPI DSI](drive-platform-mipidsi-des.md)
+- [Peripherals](drive-peripherals.md)
+ - [LCD](drive-peripherals-lcd-des.md)
+ - [TOUCHSCREEN](drive-peripherals-touch-des.md)
+ - [Sensor](drive-peripherals-sensor-des.md)
+ - [WLAN](drive-peripherals-external-des.md)
\ No newline at end of file
diff --git a/en/device-dev/driver/drive-hdf-development.md b/en/device-dev/driver/drive-hdf-development.md
new file mode 100644
index 0000000000000000000000000000000000000000..3bff3b0910ee0c9506999c6362818cc630423183
--- /dev/null
+++ b/en/device-dev/driver/drive-hdf-development.md
@@ -0,0 +1,175 @@
+# Driver Development
+
+- [Introduction](#section157425168112)
+- [How to Develop](#section1969312275533)
+
+## Introduction
+
+The HDF is designed based on the component-based driver model. It provides more refined driver management to make driver development and deployment more standard. Device drivers of the same type are placed in the same host. You can develop and deploy the drivers separately. One driver can have multiple nodes. [Figure 1](#fig5487113011526) shows the HDF driver model.
+
+**Figure 1** HDF driver model
+
+
+
+
+## How to Develop
+
+Driver development based on the HDF consists of two parts: driver implementation and driver configuration. The details are as follows:
+
+1. Implement driver.
+
+ To implement a driver, compile driver service code and register a driver entry.
+
+ - Driver service code
+
+ ```
+ #include "hdf_device_desc.h" // Header file that describes the APIs provided by the HDF to the driver.
+ #include "hdf_log.h" // Header file that describes the log APIs provided by the HDF.
+
+ #define HDF_LOG_TAG "sample_driver" // Tag contained in logs. If no tag is not specified, the default HDF_TAG is used.
+
+ // The driver service interface must be bound to the HDF for you to use the service capability.
+ int32_t HdfSampleDriverBind(struct HdfDeviceObject *deviceObject)
+ {
+ HDF_LOGD("Sample driver bind success");
+ return 0;
+ }
+
+ // Initialize the driver service.
+ int32_t HdfSampleDriverInit(struct HdfDeviceObject *deviceObject)
+ {
+ HDF_LOGD("Sample driver Init success");
+ return 0;
+ }
+
+ // Release the driver resources.
+ void HdfSampleDriverRelease(struct HdfDeviceObject *deviceObject)
+ {
+ HDF_LOGD("Sample driver release success");
+ return;
+ }
+ ```
+
+ - Registering the driver entry with the HDF
+
+ ```
+ // Define the object of the driver entry. The object must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h).
+ struct HdfDriverEntry g_sampleDriverEntry = {
+ .moduleVersion = 1,
+ .moduleName = "sample_driver",
+ .Bind = HdfSampleDriverBind,
+ .Init = HdfSampleDriverInit,
+ .Release = HdfSampleDriverRelease,
+ };
+
+ // Call HDF_INIT to register the driver entry with the HDF framework. When loading the driver, call the Bind function and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit.
+ HDF_INIT(g_sampleDriverEntry);
+ ```
+
+
+2. Compile the driver code.
+ - Use the **Makefile** template provided by the HDF to compile the driver code.
+
+ ```
+ include $(LITEOSTOPDIR)/../../drivers/adapter/lite/khdf/lite.mk # (Mandatory) Import the predefined content of the HDF.
+ MODULE_NAME := # Generated result file
+ LOCAL_INCLUDE: = # Header file directory of the driver
+ LOCAL_SRCS : = # Source code file of the driver
+ LOCAL_CFLAGS : = # Custom compilation options
+ include $(HDF_DRIVER) # Import the template Makefile to complete compilation.
+ ```
+
+ - Link the compilation result file to the kernel image by adding the result file to **hdf\_vendor.mk** in the **vendor** directory. The following is an example:
+
+ ```
+ LITEOS_BASELIB += -lxxx # Static library generated through linking
+ 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](drive-hdf-manage.md).
+
+ The driver configuration consists of the driver device description defined by the HDF and private driver configuration information.
+
+ - \(Mandatory\) Driver device description
+
+ The information required for the HDF to load drivers comes from the driver device description defined by the HDF. Therefore, the device description must be added to the configuration file **device\_info.hcs** defined by the HDF for drivers developed based on the HDF. The following is an example:
+
+ ```
+ root {
+ device_info {
+ match_attr = "hdf_manager";
+ template host { // Host template. If the node (for example, sample_host) that inherits the template uses default values in the template, the values of the node fields can be omitted.
+ hostName = "";
+ priority = 100;
+ template device {
+ template deviceNode {
+ policy = 0;
+ priority = 100;
+ preload = 0;
+ permission = 0664;
+ moduleName = "";
+ serviceName = "";
+ deviceMatchAttr = "";
+ }
+ }
+ }
+ sample_host :: host{
+ hostName = "host0"; // Host name. The host node is used to store a certain type of drivers.
+ priority = 100; // Host startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the host loading sequence is random.
+ device_sample :: device { // Device node of sample
+ device0 :: deviceNode { // DeviceNode of the sample driver
+ policy = 1; // Driver service release policy. For details, see section Driver Service Management.
+ priority = 100; // Driver startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the device loading sequence is random.
+ preload = 0; // On-demand loading of the driver. For details, see "NOTE" at the end of this section.
+ permission = 0664; // Permission for the driver to create device nodes.
+ moduleName = "sample_driver"; // Driver name. The value of this field must be the same as the value of moduleName in the driver entry structure.
+ serviceName = "sample_service"; // Name of the service released by the driver. The name must be unique.
+ deviceMatchAttr = "sample_config"; // Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver.
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ - \(Optional\) Private configuration information of the driver
+
+ If the driver has private configurations, you can add a driver configuration file to fill in the default configuration information of the driver. When loading the driver, the HDF obtains the information and saves it in the **property** of **HdfDeviceObject**, and transfers it to the driver using **Bind** and **Init** \(see [1](#li35182436435)\). The following is an example of the driver configuration information:
+
+ ```
+ root {
+ SampleDriverConfig {
+ sample_version = 1;
+ sample_bus = "I2C_0";
+ match_attr = "sample_config"; // The value of this field must be the same as that of deviceMatchAttr in device_info.hcs.
+ }
+ }
+ ```
+
+ After the configuration information is defined, you need to add the configuration file to the board-level configuration entry file **hdf.hcs**. \(You can use the DevEco to perform on-click configuration. For details, see the description about the driver development suite.\) The following is an example:
+
+ ```
+ #include "device_info/device_info.hcs"
+ #include "sample/sample_config.hcs"
+ ```
+
+
+
+> **NOTE:**
+>On-demand loading and sequential loading are supported. The detailed usage is as follows:
+>- On-demand loading
+> ```
+> typedef enum {
+> DEVICE_PRELOAD_ENABLE = 0,
+> DEVICE_PRELOAD_ENABLE_STEP2,
+> DEVICE_PRELOAD_DISABLE,
+> 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.
+>- 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/drive-hdf-manage.md b/en/device-dev/driver/drive-hdf-manage.md
new file mode 100644
index 0000000000000000000000000000000000000000..08a88cae19f8c85942cfbe4fe6a6bf73585fda77
--- /dev/null
+++ b/en/device-dev/driver/drive-hdf-manage.md
@@ -0,0 +1,437 @@
+# Driver Configuration Management
+
+- [HDF Configuration Overview](#section59914284576)
+- [Configuration Syntax](#section533713333580)
+- [Keywords](#section1316625413586)
+- [Basic Syntax](#section173481622115918)
+- [Data Types](#section96521601302)
+- [Pre-processing](#section8164295515)
+- [Commenting](#section0338205819610)
+- [Modifying a Reference](#section179799204716)
+- [Replicating Node Configuration](#section382424014712)
+- [Deleting a Node or Attribute](#section165211112586)
+- [Referencing an Attribute](#section192841514490)
+- [Keyword Template](#section520134294)
+- [Configuration Generation](#section106152531919)
+- [Introduction to HC-GEN](#section8260625101012)
+
+## HDF Configuration Overview
+
+HCS is the source code that describes the configuration of the HDF using key-value pairs. It decouples the configuration code from driver code, thereby facilitating configuration management.
+
+HDF Configuration Generator \(HC-GEN\) is a tool for converting a configuration file into a file that can be read by the target software.
+
+- In a low-performance system on a chip \(SoC\), this tool can convert a configuration file into the source code of the configuration tree so that the driver can obtain the configuration by directly calling the C library code.
+- In a high-performance SoC, this tool can convert an HCS configuration file into the HDF Configuration Binary \(HCB\) file, allowing the driver to obtain the configuration through the APIs provided by the HDF.
+
+The following figure shows the typical application scenario of the HCB mode.
+
+**Figure 1** Process of using HCS
+
+
+
+
+The HCS is compiled using the HC-GEN tool to generate an HCB file. The HCS Parser module in the HDF recreates a configuration tree using the HCB file. Then, the HDF driver modules obtain the configurations using the API provided by the HCS Paser.
+
+## Configuration Syntax
+
+The HCS syntax is described as follows:
+
+## Keywords
+
+The keywords listed in the following table below are reserved for HCS configuration files.
+
+**Table 1** Reserved keywords for HCS configuration files
+
+
+
Keywords
+
+
Description
+
+
Remarks
+
+
+
+
root
+
+
Configures the root node.
+
+
-
+
+
+
include
+
+
References other HCS configuration files.
+
+
-
+
+
+
delete
+
+
Deletes a node or an attribute.
+
+
This keyword applies only to the configuration tree imported using the include keyword.
+
+
+
template
+
+
Defines a template node.
+
+
-
+
+
+
match_attr
+
+
Marks the node attribute for matching.
+
+
During configuration parsing, the keyword value can be used to find the corresponding node.
+
+
+
+
+
+## Basic Syntax
+
+The HCS configuration file consists of configurations of attributes and nodes.
+
+**Attributes**
+
+An attribute, as the minimum configuration unit, is an independent configuration item. Its syntax is as follows:
+
+```
+ attribute_name = value;
+```
+
+- The value of **attribute\_name** is a case-sensitive string of characters starting with a letter and consisting of letters, digits, and underscores \(\_\).
+
+- Available formats of **value** are as follows:
+
+ - A binary, octal, decimal, or hexadecimal integer. For details, see [Data Types](#section96521601302).
+
+ - A character string. The content should be enclosed in double quotation marks \(" "\).
+
+ - A node reference
+
+
+- An attribute key-value pair must end with a semicolon \(;\) and belong to a node.
+
+
+**Nodes**
+
+A node is a set of attributes. Its syntax is as follows:
+
+```
+ node_name {
+ module = "sample";
+ ...
+ }
+```
+
+- The value of **node\_name** is a case-sensitive string of characters starting with a letter and consisting of letters, digits, and underscores \(\_\).
+
+- A semicolon \(;\) is not required after the curly brace \(\}\).
+
+- The reserved keyword **root** is used to declare the root node of a configuration table.
+
+- The root node must contain a **module** attribute that uses a string to represent the module to which the configuration belongs.
+
+- The **match\_attr** attribute can be added to a node. Its value is a globally unique character string. During configuration parsing, the query interface can be invoked to query the nodes with the attribute based on the attribute value.
+
+## Data Types
+
+Attributes automatically use built-in data types, including integers, strings, arrays, and booleans. You do not need to explicitly specify the data type for the attribute values.
+
+**Integer**
+
+An integer can be binary, octal, decimal, or hexadecimal. The minimum space is automatically allocated to the integer based on the actual data length.
+
+- Binary: prefixed with 0b, for example, 0b1010
+
+- Octal: prefixed with 0, for example, 0664
+- Decimal: either signed or unsigned, without a prefix, for example, 1024 or +1024. Negative integers can be read only via signed interfaces.
+
+- Hexadecimal: prefixed with 0x, for example, 0xff00 and 0xFF
+
+
+**String**
+
+A string is enclosed by double quotation marks \(" "\).
+
+**Array**
+
+The elements in an array can be integers or strings, but cannot be a combination of both. The combination of **uint32\_t** and **uint64\_t** in an integer array will enable up-casting to **uint64**. The following is an example of an integer array and a string array:
+
+```
+attr_foo = [0x01, 0x02, 0x03, 0x04];
+attr_bar = ["hello", "world"];
+```
+
+**Boolean**
+
+A Boolean data type has two possible values: **true** and **false**.
+
+## Pre-processing
+
+**include**
+
+The **include** keyword is used to import other HCS files. The syntax is as follows:
+
+```
+#include "foo.hcs"
+#include "../bar.hcs"
+```
+
+- The file names must be enclosed by double quotation marks \(" "\). Files in different directories can be referenced using relative paths. The file included must be a valid HCS file.
+- In the scenario that multiple HCS files are imported using **include**, if the same nodes exist, the latter node will override the former one, and other nodes are listed in sequence.
+
+## Commenting
+
+Comments can be formatted as follows:
+
+- Single-line comment
+
+ ```
+ // comment
+ ```
+
+- Multi-line comment
+
+ ```
+ /*
+ comment
+ */
+ ```
+
+ > **NOTE:**
+ >Multi-line comments cannot be nested.
+
+
+## Modifying a Reference
+
+You can use the following syntax to modify the content of any other node:
+
+```
+ node :& source_node
+```
+
+This syntax indicates that the node value is a modification of the source\_node value. Example:
+
+```
+root {
+ module = "sample";
+ foo {
+ foo_ :& root.bar{
+ attr = "foo";
+ }
+ foo1 :& foo2 {
+ attr = 0x2;
+ }
+ foo2 {
+ attr = 0x1;
+ }
+ }
+
+ bar {
+ attr = "bar";
+ }
+}
+```
+
+The following configuration tree is generated:
+
+```
+root {
+ module = "sample";
+ foo {
+ foo2 {
+ attr = 0x2;
+ }
+ }
+ bar {
+ attr = "foo";
+ }
+}
+```
+
+In the preceding example, the **foo.foo\_** node changes the value of the referenced **bar.attr** to "**foo**", and the **foo.foo1** node changes the value of the referenced **foo.foo2.attr** to **0x2**. In the generated configuration tree, **foo.foo\_** and **foo.foo1** are not displayed, but their configuration modifications are presented by their referenced nodes.
+
+- A node of the same level can be referenced simply using the node name. A node of a different level must be referenced by the absolute path, and node names are separated using a period \(.\). **root** indicates the root node. The path format is the node path sequence starting with root. For example, **root.foo.bar** is a valid absolute path.
+- If multiple modifications are made to the same attribute, only one uncertain modification can take effect, and a warning will be displayed.
+
+## Replicating Node Configuration
+
+The content of a node can be replicated to another node to define the node with similar content. The syntax is as follows:
+
+```
+ node : source_node
+```
+
+The preceding statement indicates that the attributes of **source\_node** are replicated to **node**. Example:
+
+```
+root {
+ module = "sample";
+ foo {
+ attr_0 = 0x0;
+ }
+ bar:foo {
+ attr_1 = 0x1;
+ }
+}
+```
+
+The following configuration tree is generated:
+
+```
+root {
+ module = "sample";
+ foo {
+ attr_0 = 0x0;
+ }
+ bar {
+ attr_1 = 0x1;
+ attr_0 = 0x0;
+ }
+}
+```
+
+In the preceding example, the **bar** node configuration includes both the **attr\_0** and **attr\_1** values. The modification to **attr\_0** in the **bar** node does not affect the **foo** node.
+
+The path of the **foo** node is not required if the **foo** node and the **bar** node are of the same level. Otherwise, the absolute path must be used. For details, see [Modifying a Reference](#section179799204716).
+
+## Deleting a Node or Attribute
+
+You can use the keyword **delete** to delete unnecessary nodes or attributes in the base configuration tree imported by the **include** keyword. In the following example, **sample1.hcs** imports the configuration of **sample2.hcs** using **include**, and deletes the **attribute2** attribute and the **foo\_2** node using the **delete** keyword.
+
+```
+// sample2.hcs
+root {
+ attr_1 = 0x1;
+ attr_2 = 0x2;
+ foo_2 {
+ t = 0x1;
+ }
+}
+
+// sample1.hcs
+#include "sample2.hcs"
+root {
+ attr_2 = delete;
+ foo_2 : delete {
+ }
+}
+```
+
+The following configuration tree is generated:
+
+```
+root {
+ attr_1 = 0x1;
+}
+```
+
+> **NOTE:**
+>The **delete** keyword cannot be used in the same HCS file. It is recommended that you delete unnecessary attributes directly from the configuration source code.
+
+## Referencing an Attribute
+
+To quickly locate the associated node during configuration parsing, you can use the node as the value of the attribute and read the attribute to find the corresponding node. The syntax is as follows:
+
+```
+ attribute = &node;
+```
+
+This syntax indicates that the **attribute** value is a reference to **node**. During code parsing, you can quickly locate the node using this attribute. Example:
+
+```
+node1 {
+ attributes;
+}
+
+node2 {
+ attr_1 = &node1;
+}
+```
+
+## Keyword Template
+
+The **template** keyword is used to generate nodes with strictly consistent syntax, thereby facilitating the traverse and management of nodes of the same type.
+
+If a node is defined using the keyword **template**, its child nodes inherit the node configuration through the double colon operator \(::\). The child nodes can modify but cannot add or delete attributes in **template**. The attributes not defined in the child nodes will use the attributes defined in **template** as the default values. Example:
+
+```
+root {
+ module = "sample";
+ template foo {
+ attr_1 = 0x1;
+ attr_2 = 0x2;
+ }
+
+ bar :: foo {
+ }
+
+ bar_1 :: foo {
+ attr_1 = 0x2;
+ }
+}
+```
+
+The following configuration tree is generated:
+
+```
+root {
+ module = "sample";
+ bar {
+ attr_1 = 0x1;
+ attr_2 = 0x2;
+ }
+ bar_1 {
+ attr_1 = 0x2;
+ attr_2 = 0x2;
+ }
+}
+```
+
+In the preceding example, the **bar** and **bar\_1** nodes inherit the **foo** node. The structures of the generated configuration tree nodes are the same as that of the **foo** node, but the attribute values are different.
+
+## Configuration Generation
+
+The HC-GEN tool is used to generate configurations. It checks the HCS configuration syntax and converts HCS source files into HCB files.
+
+## Introduction to HC-GEN
+
+Parameter description:
+
+```
+Usage: hc-gen [Options] [File]
+options:
+ -o output file name, default same as input
+ -a hcb align with four bytes
+ -b output binary output, default enable
+ -t output config in C language source file style
+ -i output binary hex dump in C language source file style
+ -p prefix of generated symbol name
+ -d decompile hcb to hcs
+ -V show verbose info
+ -v show version
+ -h show this help message
+```
+
+Generate a **.c** or **.h** configuration file.
+
+```
+hc-gen -o [OutputCFileName] -t [SourceHcsFileName]
+```
+
+Generate an HCB file.
+
+```
+hc-gen -o [OutputHcbFileName] -b [SourceHcsFileName]
+```
+
+Compile an **HCB** file to an **HCS** file:
+
+```
+hc-gen -o [OutputHcsFileName] -d [SourceHcbFileName]
+```
+
diff --git a/en/device-dev/driver/drive-hdf-news.md b/en/device-dev/driver/drive-hdf-news.md
new file mode 100644
index 0000000000000000000000000000000000000000..90f70d1aa93f3c0964e923e24b16c9b42c16171a
--- /dev/null
+++ b/en/device-dev/driver/drive-hdf-news.md
@@ -0,0 +1,193 @@
+# Driver Message Mechanism Management
+
+- [When to Use](#section33014541954)
+- [Available APIs](#section538852311616)
+- [How to Develop](#section946912121153)
+
+## When to Use
+
+When user-level applications need to interact with kernel-level drivers, the driver message mechanism of the HDF can be used.
+
+## Available APIs
+
+The message mechanism provides the following features:
+
+1. User-level applications send messages to drivers.
+2. User-level applications receive events sent by the drivers.
+
+**Table 1** APIs for the driver message mechanism
+
+
+
+
+The WLAN driver module provides APIs for driver developers, such as initializing/deregistering, opening/stopping a **NetDevice**, and obtaining the state of a **NetDevice**. [Table 2](#table74613501475) describes some APIs.
+
+**Table 2** APIs for driver developers of WLAN vendors to implement
+
+
+
+
+The WLAN driver provides the HDI layer with the APIs for creating and destroying an **IWiFi** object and setting the MAC address. [Table 3](#table141076311618) describes some APIs.
+
+**Table 3** APIs provided by the WLAN HAL module
+
+
+
Obtains information about all sensors in the system. The information about a sensor generally includes the sensor name, sensor vendor, firmware version, hardware version, sensor type ID, sensor ID, maximum measurement range, accuracy, and power.
+
+
+
Setting
+
+
int32_t Enable(int32_t sensorId)
+
+
Enables the sensor that has been subscribed to. The subscriber can obtain the sensor data only after the sensor is enabled.
+
+The following table lists the APIs provided by the sensor driver model for driver developers. You can directly call these APIs without any implementations.
+
+**Table 2** APIs provided by the sensor driver model for driver developers
+
+
+
Obtains basic configuration information such as sensor, bus, and attribute configurations based on the HCS resource configuration of the sensor device, and initializes the basic configuration data structure.
+
+The following table lists the APIs that need to be implemented by driver developers.
+
+**Table 3** APIs that need to be implemented by driver developers
+
+
+
Category
+
+
API
+
+
Description
+
+
+
+
Basic functions
+
+
int32_t init(void)
+
+
Initializes the configuration of a sensor device after it is detected.
+
+
+
int32_t GetInfo(struct SensorBasicInfo *info)
+
+
Obtains the basic information about the current sensor device from the HCS of sensor devices.
+
+
+
int32_t Enable(void)
+
+
Enables the current sensor device by delivering the register configuration in the operation group based on the HCS of the current sensor device.
+
+
+
int32_t Disable(void)
+
+
Disables the current sensor device by delivering the register configuration in the operation group based on the HCS of the current sensor device.
Sets the processing time of the data reporting thread for the current sensor device based on the data sampling interval and data reporting interval.
+
+
+
int32_t SetMode(int32_t mode)
+
+
Sets the data reporting mode of the current sensor device.
+
+
+
int32_t SetOption(uint32_t option)
+
+
Sets the register configuration such as the measurement range and accuracy based on sensor options.
+
+
+
void ReadSensorData(void)
+
+
Reads sensor data.
+
+
+
+
+
+For details about the API implementation, see [Development Example](#section257750691).
+
+## Development Guidelines
+
+Regardless of the OS and system on a chip \(SoC\), the sensor driver is developed based on the HDF, platform, and OSAL APIs to provide a unified driver model for sensor devices. This section uses the acceleration sensor as an example to describe how to develop a sensor driver.
+
+### How to Develop
+
+1. Register the acceleration sensor driver. The HDF provides a unified driver management model. The HDF identifies and loads the target module driver based on the configuration of the acceleration sensor module.
+2. Initialize and deinitialize the acceleration sensor driver. Using the **init** function, the HDF starts loading the sensor device driver and allocating configuration resources for sensor device data, respectively. Using the **release** function, the HDF releases the resources and configurations loaded by the driver.
+3. Parse the configurations of the acceleration sensor register group. For different types of sensors, you must configure their respective HCS configuration files in the HCS, check whether the sensor device is in position during the device driver startup, and then load the corresponding configuration file to generate the configuration structure object.
+4. Implement APIs for acceleration sensor driver operations. The driver APIs for various types of sensors, such as **init**, **GetInfo**, **Enable**, **Disable**, **SetBatch**, **SetMode**, **SetOption**, and **ReadSensorData**, are normalized to deliver sensor driver configurations and report sensor data.
+
+> **NOTE:**
+>The sensor driver model provides a collection of APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, general configuration, and configuration parsing capabilities. For details about the APIs, see [Table 2](#table1156812588320). You need to implement the following APIs: some operations to perform on sensors \([Table 3](#table1083014911336)\), differentiated data configuration of the sensor HCS, and verification of basic driver functions.
+
+## Development Example
+
+This section uses a code example to demonstrate how to load and start the acceleration sensor driver based on the HDF driver model. For details about the mechanism, see [Driver Development](drive-hdf-development.md). This example uses the Bosch BMI160 acceleration sensor that communicates over I2C.
+
+1. Register the driver entry of the acceleration sensor.
+
+- Implementation of the entry function
+
+```
+/* Register the entry structure object of the acceleration sensor. */
+struct HdfDriverEntry g_sensorAccelDevEntry = {
+ .moduleVersion = 1, /* Version of the acceleration sensor module */
+ .moduleName = "HDF_SENSOR_ACCEL", /* Name of the acceleration sensor module. The value must be the same as that of moduleName in the device_info.hcs file. */
+ .Bind = BindAccelDriver, /* Binding function of the acceleration sensor */
+ .Init = InitAccelDriver, /* Initialization function of the acceleration sensor */
+ .Release = ReleaseAccelDriver, /* Resource release function of the acceleration sensor */
+};
+
+/* Call HDF_INIT to register the driver entry with the HDF. When loading the driver, the HDF calls the Bind function first and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit.
+HDF_INIT(g_sensorAccelDevEntry);
+```
+
+- Acceleration sensor configuration
+
+The acceleration sensor model uses the HCS as the configuration source code. For details about the HCS configuration fields, see [Driver Configuration Management](drive-hdf-manage.md).
+
+```
+/* HCS configuration of the acceleration sensor device */
+device_sensor_accel :: device {
+ device0 :: deviceNode {
+ policy = 1; /* Policy for providing the driver service */
+ priority = 105; /* Driver startup priority (0–200). A larger value indicates a lower priority. The default value 100 is recommended. The sequence for loading devices with the same priority is random. */
+ preload = 2; /* Field for specifying whether to load the driver. The value 0 means to load the driver, and 2 means the opposite. */
+ permission = 0664; /* Permission for the driver to create device nodes */
+ moduleName = "HDF_SENSOR_ACCEL"; /* Driver name. The value must be the same as that of moduleName in the driver entry structure. */
+ serviceName = "sensor_accel"; /* Name of the service provided by the driver. The name must be unique. */
+ deviceMatchAttr = "hdf_sensor_accel_driver"; /* Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver. */
+ }
+}
+```
+
+1. Initialize and deinitialize the acceleration sensor driver.
+
+- Initialization entry function **init**
+
+```
+/* Bind the service provided by the acceleration sensor driver to the HDF. */
+int32_t BindAccelDriver(struct HdfDeviceObject *device)
+{
+ CHECK_NULL_PTR_RETURN_VALUE(device, HDF_ERR_INVALID_PARAM);
+
+ static struct IDeviceIoService service = {
+ .object = {0},
+ .Dispatch = DispatchAccel,
+ };
+ device->service = &service;
+
+ return HDF_SUCCESS;
+}
+/* After detecting that the device is in position, call RegisterAccelChipOps to register the differentiation adaptation function. */
+int32_t RegisterAccelChipOps(struct AccelOpsCall *ops)
+{
+ struct AccelDrvData *drvData = NULL;
+
+ CHECK_NULL_PTR_RETURN_VALUE(ops, HDF_ERR_INVALID_PARAM);
+
+ drvData = AccelGetDrvData();
+ drvData->ops.Init = ops->Init;
+ drvData->ops.ReadData = ops->ReadData;
+ return HDF_SUCCESS;
+}
+/* Hook the acceleration sensor driver normalization function. */
+static int32_t InitAccelOps(struct SensorDeviceInfo *deviceInfo)
+{
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ (void)memset_s((void *)deviceInfo, sizeof(*deviceInfo), 0, sizeof(*deviceInfo));
+ deviceInfo->ops.GetInfo = SetAccelInfo;
+ deviceInfo->ops.Enable = SetAccelEnable;
+ deviceInfo->ops.Disable = SetAccelDisable;
+ deviceInfo->ops.SetBatch = SetAccelBatch;
+ deviceInfo->ops.SetMode = SetAccelMode;
+ deviceInfo->ops.SetOption = SetAccelOption;
+
+ if (memcpy_s(&deviceInfo->sensorInfo, sizeof(deviceInfo->sensorInfo),
+ &drvData->accelCfg->sensorInfo, sizeof(drvData->accelCfg->sensorInfo)) != EOK) {
+ HDF_LOGE("%s: copy sensor info failed", __func__);
+ return HDF_FAILURE;
+ }
+ /* The sensor type ID can be configured in the HCS configuration file or here. */
+ drvData->accelCfg->sensorInfo.sensorTypeId = SENSOR_TAG_ACCELEROMETER;
+ drvData->accelCfg->sensorInfo.sensorId = SENSOR_TAG_ACCELEROMETER;
+
+ return HDF_SUCCESS;
+}
+/* Initialize the sensor register. */
+static int32_t InitAccelAfterConfig(void)
+{
+ struct SensorDeviceInfo deviceInfo;
+
+ if (InitAccelConfig() != HDF_SUCCESS) {
+ HDF_LOGE("%s: init accel config failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ if (InitAccelOps(&deviceInfo) != HDF_SUCCESS) {
+ HDF_LOGE("%s: init accel ops failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ if (AddSensorDevice(&deviceInfo) != HDF_SUCCESS) {
+ HDF_LOGE("%s: add accel device failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ return HDF_SUCCESS;
+}
+/* Call the device detection function to hook the differentiated device function. */
+static int32_t DetectAccelChip(void)
+{
+ int32_t num;
+ int32_t ret;
+ int32_t loop;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+ CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
+
+ num = sizeof(g_accelDetectIfList) / sizeof(g_accelDetectIfList[0]);
+ for (loop = 0; loop < num; ++loop) {
+ if (g_accelDetectIfList[loop].DetectChip != NULL) {
+ ret = g_accelDetectIfList[loop].DetectChip(drvData->accelCfg);
+ if (ret == HDF_SUCCESS) {
+ drvData->detectFlag = true;
+ break;
+ }
+ }
+ }
+
+ if (loop == num) {
+ HDF_LOGE("%s: detect accel device failed", __func__);
+ drvData->detectFlag = false;
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+}
+/* The entry function of the acceleration sensor driver is used to initialize the structure object of the sensor private data, allocate space for the HCS data configuration object of the sensor, invoke the entry function for initializing the sensor HCS data configuration, detect whether the sensor device is in position, create the sensor data reporting timer, implement the sensor normalization API, and register the sensor device. */
+int32_t InitAccelDriver(struct HdfDeviceObject *device)
+{
+ /* Obtain the private data structure object of the sensor. */
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ /* When detecting sensors of the same type from different vendors, the function checks whether this type of sensors is in position. If yes, it no longer detects the other sensors of this type and directly returns the result. */
+ if (drvData->detectFlag) {
+ HDF_LOGE("%s: accel sensor have detected", __func__);
+ return HDF_SUCCESS;
+ }
+
+ CHECK_NULL_PTR_RETURN_VALUE(device, HDF_ERR_INVALID_PARAM);
+ /* Allocate space for the private data structure objects for storing sensor data configurations. The allocated space needs to be released when the driver is released. */
+ drvData->accelCfg = (struct SensorCfgData *)OsalMemCalloc(sizeof(*cfg));
+ if (drvData->accelCfg == NULL) {
+ HDF_LOGE("%s: malloc sensor config data failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ drvData->accelCfg->regCfgGroup = &g_regCfgGroup[0];
+ /* Initializing the sensor configuration data aims to parse the configuration information of the sensor communication bus, basic sensor information, sensor attributes, whether the sensor is in position, and register group information. */
+ if (GetSensorBaseConfigData(device->property, drvData->accelCfg) != HDF_SUCCESS) {
+ HDF_LOGE("%s: get sensor base config failed", __func__);
+ goto Base_CONFIG_EXIT;
+ }
+
+ if (DetectAccelChip() != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel sensor detect device no exist", __func__);
+ goto DETECT_CHIP_EXIT;
+ }
+ drvData->detectFlag = true;
+ if (ParseSensorRegConfig(drvData->accelCfg) != HDF_SUCCESS) {
+ HDF_LOGE("%s: detect sensor device failed", __func__);
+ goto REG_CONFIG_EXIT;
+ }
+
+ if (InitAccelAfterConfig() != HDF_SUCCESS) {
+ HDF_LOGE("%s: init accel after config failed", __func__);
+ goto INIT_EXIT;
+ }
+
+ HDF_LOGI("%s: init accel driver success", __func__);
+ return HDF_SUCCESS;
+
+INIT_EXIT:
+ DestroySensorThread(&drvData->thread, &drvData->threadStatus);
+ (void)DeleteSensorDevice(SENSOR_TAG_ACCELEROMETER);
+REG_CONFIG_EXIT:
+ ReleaseSensorAllRegConfig(drvData->accelCfg);
+ (void)ReleaseSensorBusHandle(&drvData->accelCfg->busCfg);
+DETECT_CHIP_EXIT:
+ drvData->detectFlag = false;
+BASE_CONFIG_EXIT:
+ drvData->accelCfg->root = NULL;
+ drvData->accelCfg->regCfgGroup = NULL;
+ OsalMemFree(drvData->accelCfg);
+ drvData->accelCfg = NULL;
+ return HDF_FAILURE;
+}
+
+/* Release the resources allocated during driver initialization. */
+void ReleaseAccelDriver(struct HdfDeviceObject *device)
+{
+ (void)device;
+ struct AccelDrvData *drvData = NULL;
+
+ drvData = AccelGetDrvData();
+ (void)DestroySensorThread(&drvData->thread, &drvData->threadStatus);
+ (void)DeleteSensorDevice(SENSOR_TAG_ACCELEROMETER);
+ drvData->detectFlag = false;
+
+ if (drvData->accelCfg != NULL) {
+ drvData->accelCfg->root = NULL;
+ drvData->accelCfg->regCfgGroup = NULL;
+ ReleaseSensorAllRegConfig(drvData->accelCfg);
+ (void)ReleaseSensorBusHandle(&drvData->accelCfg->busCfg);
+ OsalMemFree(drvData->accelCfg);
+ drvData->accelCfg = NULL;
+ }
+
+ drvData->initStatus = false;
+}
+```
+
+1. Configure the acceleration sensor register group.
+
+You only need to configure the acceleration sensor data according to the template. Template configuration parsing has been implemented via the **InitSensorConfigData** function and only needs to be called during initialization. If new configuration items are added, you need to modify this function accordingly.
+
+```
+Acceleration sensor data configuration template (accel_config.hcs)
+root {
+ sensorAccelConfig {
+ accelChipConfig {
+ /* Sensor information template */
+ template sensorInfo {
+ sensorName = "accelerometer"; /* Acceleration sensor name. The value contains a maximum of 16 bytes. */
+ vendorName = "borsh_bmi160"; /* Sensor vendor name. The value contains a maximum of 16 bytes. */
+ firmwareVersion = "1.0"; /* Sensor firmware version. The default value is 1.0. The value contains a maximum of 16 bytes. */
+ hardwareVersion = "1.0"; /* Sensor hardware version. The default value is 1.0. The value contains a maximum of 16 bytes. */
+ sensorTypeId = 1; /* Sensor type ID. For details, see SensorTypeTag. */
+ sensorId = 1; /* Sensor ID, which is defined by the sensor driver developer. The SensorTypeTag enums are recommended. */
+ maxRange = 8; /* Maximum measurement range of the sensor. Set this parameter based on your business requirements. */
+ precision = 0; /* Sensor accuracy, which is used together with sensor data reporting. For details, see SensorEvents. */
+ power = 230; /* Power consumption of the sensor */
+ }
+ /* Template of the bus type and configuration information used by the sensor */
+ template sensorBusConfig {
+ busType = 0; /* 0:i2c 1:spi */
+ busNum = 6; /* Device ID allocated to the sensor on the chip */
+ busAddr = 0; /* Address allocated to the sensor on the chip */
+ regWidth = 1; /* Width of the sensor register address */
+ regBigEndian = 0; /* Endian mode of the sensor register */
+ }
+ /* Sensor attribute template */
+ template sensorAttr {
+ chipName = ""; /* Sensor chip name */
+ chipIdRegister = 0xf; /* Address of the register detecting whether the sensor is in position */
+ chipIdValue = 0xd1; /* Value of the register detecting whether the sensor is in position */
+ }
+ }
+ }
+}
+
+/* You can modify the template configuration based on the differences of sensor devices. If no modification is made, the default template configuration is used. */
+root {
+ sensorAccelConfig {
+ accel_bmi160_chip_config : accelChipConfig {
+ match_attr = "hdf_sensor_accel_driver"; /* The value must be the same as the match_attr field configured for the acceleration sensor. */
+ accelInfo :: sensorInfo {
+ vendorName = "borsh_bmi160";
+ sensorTypeId = 1;
+ sensorId = 1;
+ }
+ accelBusConfig :: sensorBusConfig {
+ busType = 0; /* I2C communication mode */
+ busNum = 6;
+ busAddr = 0x68;
+ regWidth = 1; /* 1-byte bit width */
+ }
+ accelAttr :: sensorAttr {
+ chipName = "bmi160";
+ chipIdRegister = 0x00;
+ chipIdValue = 0xd1;
+ }
+ accelRegConfig {
+ /* regAddr: Register address
+ value: Register value
+ mask: Mask of the register value
+ len: Length (in bytes) of the register value
+ delay: Register delay (in milliseconds)
+ opsType: Operation type. The options can be 0 (no operation), 1 (read), 2 (write), 3 (read and check), and 4 (bit update).
+ calType: Calculation type. The options can be 0 (none), 1 (write), 2 (negate), 3 (XOR) 4, (left shift), and 5 (right shift).
+ shiftNum: Number of shifts
+ debug: Debugging switch. The value can be 0 (disabled) or 1 (enabled).
+ save: Data saving switch. The value can be 0 (not save data) or 1 (save data).
+ */
+ /* Groups of sensor register operations. Registers can be configured in sequence based on the groups. */
+ /* Register address, register value, mask of the register value, data length of the register value, register delay, operation type, calculation type, number of shifts, debugging switch, data saving switch */
+ /* Initialize the register groups. */
+ initSeqConfig = [
+ 0x7e, 0xb6, 0xff, 1, 5, 2, 0, 0, 0, 0,
+ 0x7e, 0x10, 0xff, 1, 5, 2, 0, 0, 0, 0
+ ];
+ /* Enable the register groups. */
+ enableSeqConfig = [
+ 0x7e, 0x11, 0xff, 1, 5, 2, 0, 0, 0, 0,
+ 0x41, 0x03, 0xff, 1, 0, 2, 0, 0, 0, 0,
+ 0x40, 0x08, 0xff, 1, 0, 2, 0, 0, 0, 0
+ ];
+ /* Disable the register groups. */
+ disableSeqConfig = [
+ 0x7e, 0x10, 0xff, 1, 5, 2, 0, 0, 0, 0
+ ];
+ }
+ }
+ }
+}
+```
+
+1. Implement APIs for acceleration sensor driver operations.
+
+You need to implement normalized APIs based on sensor types.
+
+```
+/* Leave a function empty if it is not used. */
+static int32_t SetAccelInfo(struct SensorBasicInfo *info)
+{
+ (void)info;
+
+ return HDF_ERR_NOT_SUPPORT;
+}
+/* Deliver the configuration of enabling the register groups. */
+static int32_t SetAccelEnable(void)
+{
+ int32_t ret;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
+ ret = SetSensorRegCfgArray(&drvData->accelCfg->busCfg, drvData->accelCfg->regCfgGroup[SENSOR_ENABLE_GROUP]);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel sensor disable config failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ drvData->threadStatus = SENSOR_THREAD_RUNNING;
+
+ return HDF_SUCCESS;
+}
+/* Deliver the configuration of disabling the register groups. */
+static int32_t SetAccelDisable(void)
+{
+ int32_t ret;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
+
+ ret = SetSensorRegCfgArray(&drvData->accelCfg->busCfg, drvData->accelCfg->regCfgGroup[SENSOR_DISABLE_GROUP]);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel sensor disable config failed", __func__);
+ return HDF_FAILURE;
+ }
+
+ drvData->threadStatus = SENSOR_THREAD_STOPPED;
+
+ return HDF_SUCCESS;
+}
+/* Set the sampling interval and data reporting interval of the sensor. */
+static int32_t SetAccelBatch(int64_t samplingInterval, int64_t interval)
+{
+ (void)interval;
+
+ struct AccelDrvData *drvData = AccelGetDrvData();
+ drvData->interval = samplingInterval;
+
+ return HDF_SUCCESS;
+}
+/* Set the data reporting mode of the sensor. Currently, the real-time mode is supported. */
+static int32_t SetAccelMode(int32_t mode)
+{
+ return (mode == SENSOR_WORK_MODE_REALTIME) ? HDF_SUCCESS : HDF_FAILURE;
+}
+/* Set the sensor options. */
+static int32_t SetAccelOption(uint32_t option)
+{
+ (void)option;
+ return HDF_ERR_NOT_SUPPORT;
+}
+```
+
+- Differentiated processing APIs
+
+ ```
+ /* If a device is detected, register the differentiated processing function to the accel driver model. */
+ int32_t DetectAccelBim160Chip(struct SensorCfgData *data)
+ {
+ int32_t ret;
+ struct AccelOpsCall ops;
+ CHECK_NULL_PTR_RETURN_VALUE(data, HDF_ERR_INVALID_PARAM);
+
+ if (strcmp(ACCEL_CHIP_NAME_BMI160, data->sensorAttr.chipName) != 0) {
+ return HDF_SUCCESS;
+ }
+ ret = InitAccelPreConfig();
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: init BMI160 bus mux config", __func__);
+ return HDF_FAILURE;
+ }
+ if (DetectSensorDevice(data) != HDF_SUCCESS) {
+ return HDF_FAILURE;
+ }
+
+ /* Differentiated processing function */
+ ops.Init = InitBmi160;
+ ops.ReadData = ReadBmi160Data;
+ ret = RegisterAccelChipOps(&ops);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: register BMI160 accel failed", __func__);
+ (void)ReleaseSensorBusHandle(&data->busCfg);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+ }
+ /* Initialization processing function */
+ static int32_t InitBmi160(struct SensorCfgData *data)
+ {
+ int32_t ret;
+
+ CHECK_NULL_PTR_RETURN_VALUE(data, HDF_ERR_INVALID_PARAM);
+ ret = SetSensorRegCfgArray(&data->busCfg, data->regCfgGroup[SENSOR_INIT_GROUP]);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: bmi160 sensor init config failed", __func__);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+ }
+ /* Data processing function */
+ int32_t ReadBmi160Data(struct SensorCfgData *data)
+ {
+ int32_t ret;
+ struct AccelData rawData = { 0, 0, 0 };
+ int32_t tmp[ACCEL_AXIS_NUM];
+ struct SensorReportEvent event;
+
+ (void)memset_s(&event, sizeof(event), 0, sizeof(event));
+
+ ret = ReadBmi160RawData(data, &rawData, &event.timestamp);
+ if (ret != HDF_SUCCESS) {
+ return HDF_FAILURE;
+ }
+
+ event.sensorId = SENSOR_TAG_ACCELEROMETER;
+ event.option = 0;
+ event.mode = SENSOR_WORK_MODE_REALTIME;
+
+ rawData.x = rawData.x * BMI160_ACC_SENSITIVITY_2G;
+ rawData.y = rawData.y * BMI160_ACC_SENSITIVITY_2G;
+ rawData.z = rawData.z * BMI160_ACC_SENSITIVITY_2G;
+
+ tmp[ACCEL_X_AXIS] = (rawData.x * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
+ tmp[ACCEL_Y_AXIS] = (rawData.y * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
+ tmp[ACCEL_Z_AXIS] = (rawData.z * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
+
+ event.dataLen = sizeof(tmp);
+ event.data = (uint8_t *)&tmp;
+ ret = ReportSensorEvent(&event);
+ return ret;
+ }
+ ```
+
+- Data processing function
+
+Create a sensor timer to periodically sample data based on the configured sampling interval and report the data to the data subscriber.
+
+```
+/* Scheduled working thread of the sensor */
+static int32_t ReadAccelDataThreadWorker(void *arg)
+{
+ (void)arg;
+ int64_t interval;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ drvData->threadStatus = SENSOR_THREAD_START;
+ while (true) {
+ if (drvData->threadStatus == SENSOR_THREAD_RUNNING) {
+ if (drvData->ops.ReadData != NULL) {
+ (void)drvData->ops.ReadData(drvData->accelCfg);
+ }
+ interval = OsalDivS64(drvData->interval, (SENSOR_CONVERT_UNIT * SENSOR_CONVERT_UNIT));
+ OsalMSleep(interval);
+ } else if (drvData->threadStatus == SENSOR_THREAD_DESTROY) {
+ break;
+ } else {
+ OsalMSleep(ACC_DEFAULT_SAMPLING_200_MS / SENSOR_CONVERT_UNIT / SENSOR_CONVERT_UNIT);
+ }
+
+ if ((!drvData->initStatus) || (drvData->interval < 0) || drvData->threadStatus != SENSOR_THREAD_RUNNING) {
+ continue;
+ }
+ }
+
+ return HDF_SUCCESS;
+}
+/* Create a sensor timer and initialize the sensor device. */
+static int32_t InitAccelConfig(void)
+{
+ int32_t ret;
+ struct AccelDrvData *drvData = AccelGetDrvData();
+
+ if (drvData->threadStatus != SENSOR_THREAD_NONE && drvData->threadStatus != SENSOR_THREAD_DESTROY) {
+ HDF_LOGE("%s: accel thread have created", __func__);
+ return HDF_SUCCESS;
+ }
+
+ ret = CreateSensorThread(&drvData->thread, ReadAccelDataThreadWorker, "hdf_sensor_accel", drvData);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel create thread failed", __func__);
+ drvData->threadStatus = SENSOR_THREAD_NONE;
+ return HDF_FAILURE;
+ }
+
+ CHECK_NULL_PTR_RETURN_VALUE(drvData->ops.Init, HDF_ERR_INVALID_PARAM);
+
+ ret = drvData->ops.Init(drvData->accelCfg);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: accel create thread failed", __func__);
+ drvData->threadStatus = SENSOR_THREAD_NONE;
+ return HDF_FAILURE;
+ }
+ drvData->initStatus = true;
+ return HDF_SUCCESS;
+}
+```
+
+- Major data structures
+
+```
+/* Sensor conversion units */
+#define SENSOR_CONVERT_UNIT 1000
+#define SENSOR_1K_UNIT 1024
+/* Sensitivity conversion value of the sensor with a 2g measurement range */
+#define BMI160_ACC_SENSITIVITY_2G 61
+/* Address of the sensor data sampling register */
+#define BMI160_ACCEL_X_LSB_ADDR 0X12
+#define BMI160_ACCEL_X_MSB_ADDR 0X13
+#define BMI160_ACCEL_Y_LSB_ADDR 0X14
+#define BMI160_ACCEL_Y_MSB_ADDR 0X15
+#define BMI160_ACCEL_Z_LSB_ADDR 0X16
+#define BMI160_ACCEL_Z_MSB_ADDR 0X17
+/* Data dimension of the sensor */
+enum AccelAxisNum {
+ ACCEL_X_AXIS = 0,
+ ACCEL_Y_AXIS = 1,
+ ACCEL_Z_AXIS = 2,
+ ACCEL_AXIS_NUM = 3,
+};
+/* Each dimension of the sensor */
+struct AccelData {
+ int32_t x;
+ int32_t y;
+ int32_t z;
+};
+/* Private data structure of the sensor */
+struct AccelDrvData {
+ bool detectFlag;
+ uint8_t threadStatus;
+ uint8_t initStatus;
+ int64_t interval;
+ struct SensorCfgData *accelCfg;
+ struct OsalThread thread;
+ struct AccelOpsCall ops;
+};
+/* Differentiation adaptation function */
+struct AccelOpsCall {
+ int32_t (*Init)(struct SensorCfgData *data);
+ int32_t (*ReadData)(struct SensorCfgData *data);
+};
+```
+
+## Test Guidelines
+
+After the driver is developed, you can develop self-test cases in the sensor unit test to verify the basic functions of the driver. The developer self-test platform is used as the test environment.
+
+```
+/* Specify whether to report sensor data. */
+static int32_t g_sensorDataFlag = 0;
+/* Retain the address of the sensor interface instance. */
+static const struct SensorInterface *g_sensorDev = nullptr;
+
+/* Register the data reporting function. */
+static int SensorTestDataCallback(struct SensorEvents *event)
+{
+ if (event == nullptr) {
+ return -1;
+ }
+ float *data = (float*)event->data;
+ printf("time [%lld] sensor id [%d] x-[%f] y-[%f] z-[%f]\n\r", event->timestamp,
+ event->sensorId, (*data), *(data + 1), *(data + g_axisZ));
+ if (*data > 1e-5) {
+ g_sensorDataFlag = 1;
+ }
+ return 0;
+}
+/* Initialize the sensor interface instance before executing the test cases. */
+void HdfSensorTest::SetUpTestCase()
+{
+ g_sensorDev = NewSensorInterfaceInstance();
+ if (g_sensorDev == nullptr) {
+ printf("test sensorHdi get Module instace failed\n\r");
+ }
+}
+/* Release case resources. */
+void HdfSensorTest::TearDownTestCase()
+{
+ if (g_sensorDev != nullptr) {
+ FreeSensorInterfaceInstance();
+ g_sensorDev = nullptr;
+ }
+}
+/* Verify the sensor driver. */
+HWTEST_F(HdfSensorTest,TestAccelDriver_001, TestSize.Level0)
+{
+ int32_t sensorInterval = 1000000000; /* Data sampling interval, in nanoseconds */
+ int32_t pollTime = 5; /* Data sampling duration, in seconds */
+ int32_t accelSensorId = 1; /* Acceleration sensor type ID, which is 1 */
+ int32_t count = 0;
+ int ret;
+ struct SensorInformation *sensorInfo = nullptr;
+
+ ret = g_sensorDev->Register(SensorTestDataCallback)
+ EXPECT_EQ(SENSOR_NULL_PTR, ret);
+
+ ret = g_sensorDev->GetAllSensors(&sensorInfo, &count);
+ EXPECT_EQ(0, ret);
+ if (sensorInfo == nullptr) {
+ EXPECT_NE(nullptr, sensorInfo);
+ return;
+ }
+ /* Print the obtained sensor list. */
+ for (int i = 0; i < count; i++) {
+ printf("get sensoriId[%d], info name[%s]\n\r", sensorInfo[i]->sensorId, sensorInfo[i]->sensorName);
+ }
+ ret = g_sensorDev->Enable(accelSensorId);
+ EXPECT_EQ(0, ret);
+ g_sensorDataFlag = 0;
+
+ ret = g_sensorDev->SetBatch(accelSensorId, sensorInterval, pollTime);
+ EXPECT_EQ(0, ret);
+ /* Observe the printed data within the period specified by pollTime. */
+ OsalSleep(pollTime);
+ EXPECT_EQ(1, g_sensorDataFlag);
+
+ ret = g_sensorDev->Disable(accelSensorId);
+ g_sensorDataFlag = 0;
+ EXPECT_EQ(0, ret);
+
+ ret = g_sensorDev->Unregister();
+ EXPECT_EQ(0, ret);
+}
+```
+
diff --git a/en/device-dev/driver/drive-peripherals-touch-des.md b/en/device-dev/driver/drive-peripherals-touch-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..274355990ed1ba5a507fee12cb95c853d772dc60
--- /dev/null
+++ b/en/device-dev/driver/drive-peripherals-touch-des.md
@@ -0,0 +1,410 @@
+# TOUCHSCREEN
+
+- [Overview](#section175431838101617)
+ - [Available APIs](#section17667171301711)
+
+- [Development Guidelines](#section65745222184)
+ - [How to Develop](#section865734181916)
+
+- [Development Example](#section263714411191)
+ - [Add the touchscreen driver-related descriptions.](#section18249155619195)
+ - [Board-level Hardware Configuration and Private Data Configuration](#section3571192072014)
+ - [Adding the Touchscreen Driver](#section6356758162015)
+
+
+## Overview
+
+- **Functions of the Touchscreen driver**
+
+ The Touchscreen driver is used to power on its integrated circuit \(IC\), configure and initialize hardware pins, register interrupts, configure Inter-Integrated Circuit \(I2C\) or SPI APIs, set input-related configurations, and download and update firmware.
+
+
+- **Layers of the Touchscreen driver**
+
+ This section describes how to develop the touchscreen driver based on the input driver model. [Figure 1](#fig6251184817261) shows an overall architecture of the touchscreen driver.
+
+ The input driver is developed based on the hardware driver foundation \(HDF\), platform APIs, and operating system abstraction layer \(OSAL\) APIs. It provides hardware driver capabilities through the input Hardware Driver Interfaces \(HDIs\) for upper-layer input services to control the touchscreen.
+
+
+**Figure 1** Architecture of the input driver model
+
+
+- **Input driver model**
+
+ The input driver model mainly consists of the device manager, common drivers, and chip drivers. The platform data channel provides capabilities for sending data generated by the touchscreen from the kernel to the user space. The driver model adapts to different touchscreen devices and hardware platforms via the configuration file, improving the efficiency of the touchscreen development. The description for each part of the input driver model is as follows:
+
+ - Input device manager: provides input device drivers with the APIs for registering or unregistering input devices and manages the input device list.
+
+ - Input common driver: provides common abstract drivers \(such as the touchscreen common driver\) of various input devices for initializing the board-level hardware, processing hardware interrupts, and registering input devices with the input device manager.
+
+ - Input chip driver: provides different chip drivers of each vendor. You can minimize the workload for the input chip driver development by calling differentiated APIs reserved by the input platform driver.
+
+ - Event hub: provides a unified data reporting channel, which enables input devices to report input events.
+
+ - HDF input config: parses and manages the board-level configuration as well as the private configuration of input devices.
+
+
+- **Advantages of developing drivers based on the HDF**
+
+ The touchscreen driver is developed based on the [HDF](drive-hdf-development.md) and is implemented via calls to the OSAL and platform APIs, including bus APIs and OS native APIs \(such as memory, lock, thread, and timer\). The OSAL and platform APIs hide the differences of underlying hardware, so that the touchscreen driver can be migrated across platforms and OSs. In this regard, you can develop the touchscreen driver only once but deploy it on multiple devices.
+
+
+### Available APIs
+
+Based on the attributes of the pins, interfaces on the touchscreens can be classified into the following types:
+
+- Power interfaces
+- I/O control interfaces
+- Communications interfaces
+
+**Figure 2** Common pins of the touchscreen
+
+
+The interfaces shown in the figure are described as follows:
+
+1. **Power interfaces**
+ - LDO\_1P8: 1.8 V digital circuits
+ - LDO\_3P3: 3.3 V analog circuits
+
+ 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).
+
+
+## Development Guidelines
+
+Regardless of the OS and system on a chip \(SoC\), the input driver is developed based on the HDF, platform, and OSAL APIs to provide a unified driver model for touchscreen devices.
+
+- The following uses the touchscreen driver as an example to describe the loading process of the input driver model:
+
+ \(1\) Complete the device description configuration, such as the loading priority, board-level hardware information, and private data, by referring to the existing template.
+
+ \(2\) Load the input device management driver. The input management driver is loaded automatically by the HDF to create and initialize the device manager.
+
+ \(3\) Load the platform driver. The platform driver is loaded automatically by the HDF to parse the board-level configuration, initialize the hardware, and provide the API for registering the touchscreen.
+
+ \(4\) Load the touchscreen driver. The touchscreen driver is loaded automatically by the HDF to instantiate the touchscreen device, parse the private data, and implement differentiated APIs provided by the platform.
+
+ \(5\) Register the instantiated touchscreen device with the platform driver. Then bind this device to the platform driver, and complete touchscreen initialization such as interrupt registration and power-on and power-off.
+
+ \(6\) Instantiate the input device and register it with the input manager after the touchscreen is initialized.
+
+
+### How to Develop
+
+1. Add the touchscreen driver-related descriptions.
+
+ Currently, the input driver is developed based on the HDF and is loaded and started by the HDF. Register the driver information, such as whether to load the driver and the loading priority in the configuration file. Then, the HDF starts the registered driver modules one by one. For details about the driver configuration, see [Driver Development](drive-hdf-development.md#section1969312275533).
+
+2. Complete the board-level configuration and private data configuration of the touchscreen.
+
+ Configure the required I/O pins. For example, configure a register for the I2C pin reserved for the touchscreen to use I2C for transmitting data.
+
+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).
+
+
+## Development Example
+
+This example describes how to develop the touchscreen driver.
+
+### Add the touchscreen driver-related descriptions.
+
+The information about modules of the input driver model is shown as follows and enables the HDF to load the modules in sequence. For details, see [Driver Development](drive-hdf-development.md).
+
+```
+input :: host {
+ hostName = "input_host";
+ priority = 100;
+ device_input_manager :: device {
+ device0 :: deviceNode {
+ policy = 2; // Publish services externally.
+ priority = 100; // Loading priority. The input device manager in the input driver has the highest priority.
+ preload = 0; // Value 0 indicates that the driver is to be loaded, and value 1 indicates the opposite.
+ permission = 0660;
+ moduleName = "HDF_INPUT_MANAGER";
+ serviceName = "input_dev_manager";
+ deviceMatchAttr = "";
+ }
+ }
+ device_hdf_touch :: device {
+ device0 :: deviceNode {
+ policy = 2;
+ priority = 120;
+ preload = 0;
+ permission = 0660;
+ moduleName = "HDF_TOUCH";
+ serviceName = "event1";
+ deviceMatchAttr = "touch_device1";
+ }
+ }
+
+ device_touch_chip :: device {
+ device0 :: deviceNode {
+ policy = 0;
+ priority = 130;
+ preload = 0;
+ permission = 0660;
+ moduleName = "HDF_TOUCH_SAMPLE";
+ serviceName = "hdf_touch_sample_service";
+ deviceMatchAttr = "zsj_sample_5p5";
+ }
+ }
+}
+```
+
+### Board-level Hardware Configuration and Private Data Configuration
+
+The following describes the configuration of the board-level hardware and private data of the touchscreen. You can modify the configuration based on service requirements.
+
+```
+root {
+ input_config {
+ touchConfig {
+ touch0 {
+ boardConfig {
+ match_attr = "touch_device1";
+ inputAttr {
+ inputType = 0; // Value 0 indicates that the input device is a touchscreen.
+ solutionX = 480;
+ solutionY = 960;
+ devName = "main_touch"; // Device name
+ }
+ busConfig {
+ busType = 0; // Value 0 indicates the I2C bus.
+ busNum = 6;
+ clkGpio = 86;
+ dataGpio = 87;
+ i2cClkIomux = [0x114f0048, 0x403]; // Register configuration of the i2c_clk pin
+ i2cDataIomux = [0x114f004c, 0x403]; // Register configuration of the i2c_data pin
+ }
+ pinConfig {
+ rstGpio = 3;
+ intGpio = 4;
+ rstRegCfg = [0x112f0094, 0x400]; // Register configuration of the reset pin
+ intRegCfg = [0x112f0098, 0x400]; // Register configuration of the interrupt pin
+ }
+ powerConfig {
+ vccType = 2; // Values 1, 2, and 3 indicate the low-dropout regulator (LDO), GPIO, and PMIC, respectively.
+ vccNum = 20; // The GPIO number is 20.
+ vccValue = 1800; // The voltage amplitude is 1800 mV.
+ vciType = 1;
+ vciNum = 12;
+ vciValue = 3300;
+ }
+ featureConfig {
+ capacitanceTest = 0;
+ gestureMode = 0;
+ gloverMOde = 0;
+ coverMode = 0;
+ chargerMode = 0;
+ knuckleMode = 0;
+ }
+ }
+ chipConfig {
+ template touchChip {
+ match_attr = "";
+ chipName = "sample";
+ vendorName = "zsj";
+ chipInfo = "AAAA11222"; // The first four characters indicate the product name. The fifth and sixth characters indicate the IC model. The last three characters indicate the chip model.
+ busType = 0;
+ deviceAddr = 0x5D;
+ irqFlag = 2; // Values 1 and 2 indicate that the interrupt is triggered on the rising and falling edges, respectively. Values 4 and 8 indicate that the interrupt is triggered by the high and low levels, respectively.
+ maxSpeed = 400;
+ chipVersion = 0;
+ powerSequence {
+ /* Power-on sequence is described as follows:
+ [Type, status, direction, delay]
+ Value 0 indicates the power or pin is empty. Values 1 and 2 indicate the VCC (1.8 V) and VCI (3.3 V) power, respectively. Values 3 and 4 indicate the reset and interrupt pins, respectively.
+ Values 0 and 1 indicate the power-off or pull-down, and the power-on or pull-up, respectively. Value 2 indicates that no operation is performed.
+ Values 0 and 1 indicate the input and output directions, respectively. Value 2 indicates that no operation is performed.
+ Delay time, in milliseconds.
+ */
+ powerOnSeq = [4, 0, 1, 0,
+ 3, 0, 1, 10,
+ 3, 1, 2, 60,
+ 4, 2, 0, 0];
+ suspendSeq = [3, 0, 2, 10];
+ resumeSeq = [3, 1, 2, 10];
+ powerOffSeq = [3, 0, 2, 10,
+ 1, 0, 2, 20];
+ }
+ }
+ chip0 :: touchChip {
+ match_attr = "zsj_sample_5p5";
+ chipInfo = "ZIDN45100";
+ chipVersion = 0;
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+### Adding the Touchscreen Driver
+
+The following example shows how to implement the differentiated APIs provided by the platform driver to obtain and parse the touchscreen data. You can adjust the development process based on the board and touchscreen in use.
+
+```
+/* Parse the touch reporting data read from the touchscreen into coordinates. */
+static void ParsePointData(ChipDevice *device, FrameData *frame, uint8_t *buf, uint8_t pointNum)
+{
+ int32_t resX = device->driver->boardCfg->attr.resolutionX;
+ int32_t resY = device->driver->boardCfg->attr.resolutionY;
+
+ for (int32_t i = 0; i < pointNum; i++) {
+ frame->fingers[i].y = (buf[GT_POINT_SIZE * i + GT_X_LOW] & ONE_BYTE_MASK) |
+ ((buf[GT_POINT_SIZE * i + GT_X_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
+ frame->fingers[i].x = (buf[GT_POINT_SIZE * i + GT_Y_LOW] & ONE_BYTE_MASK) |
+ ((buf[GT_POINT_SIZE * i + GT_Y_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
+ frame->fingers[i].valid = true;
+ }
+}
+/* Obtain the touch reporting data from the chip. */
+static int32_t ChipDataHandle(ChipDevice *device)
+{
+ int32_t ret;
+ uint8_t touchStatus = 0;
+ uint8_t pointNum;
+ uint8_t buf[GT_POINT_SIZE * MAX_SUPPORT_POINT] = {0};
+ InputI2cClient *i2cClient = &device->driver->i2cClient;
+ uint8_t reg[GT_ADDR_LEN] = {0};
+ FrameData *frame = &device->driver->frameData;
+ reg[0] = (GT_BUF_STATE_ADDR >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
+ reg[1] = GT_BUF_STATE_ADDR & ONE_BYTE_MASK;
+ ret = InputI2cRead(i2cClient, reg, GT_ADDR_LEN, &touchStatus, 1);
+ if (ret < 0 || touchStatus == GT_EVENT_INVALID) {
+ return HDF_FAILURE;
+ }
+ OsalMutexLock(&device->driver->mutex);
+ (void)memset_s(frame, sizeof(FrameData), 0, sizeof(FrameData));
+ if (touchStatus == GT_EVENT_UP) {
+ frame->realPointNum = 0;
+ frame->definedEvent = TOUCH_UP;
+ goto exit;
+ }
+ reg[0] = (GT_X_LOW_BYTE_BASE >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
+ reg[1] = GT_X_LOW_BYTE_BASE & ONE_BYTE_MASK;
+ pointNum = touchStatus & GT_FINGER_NUM_MASK;
+ if (pointNum <= 0 || pointNum > MAX_SUPPORT_POINT) {
+ HDF_LOGE("%s: pointNum is invalid, %d", __func__, pointNum);
+ (void)ChipCleanBuffer(i2cClient);
+ OsalMutexUnlock(&device->driver->mutex);
+ return HDF_FAILURE;
+ }
+ frame->realPointNum = pointNum;
+ frame->definedEvent = TOUCH_DOWN;
+ /* Read the touch reporting data from the register. */
+ (void)InputI2cRead(i2cClient, reg, GT_ADDR_LEN, buf, GT_POINT_SIZE * pointNum);
+ /* Parse the touch reporting data. */
+ ParsePointData(device, frame, buf, pointNum);
+exit:
+ OsalMutexUnlock(&device->driver->mutex);
+ if (ChipCleanBuffer(i2cClient) != HDF_SUCCESS) {
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+}
+
+static struct TouchChipOps g_sampleChipOps = {
+ .Init = ChipInit,
+ .Detect = ChipDetect,
+ .Resume = ChipResume,
+ .Suspend = ChipSuspend,
+ .DataHandle = ChipDataHandle,
+};
+
+static TouchChipCfg *ChipConfigInstance(struct HdfDeviceObject *device)
+{
+ TouchChipCfg *chipCfg = (TouchChipCfg *)OsalMemAlloc(sizeof(TouchChipCfg));
+ if (chipCfg == NULL) {
+ HDF_LOGE("%s: instance chip config failed", __func__);
+ return NULL;
+ }
+ (void)memset_s(chipCfg, sizeof(TouchChipCfg), 0, sizeof(TouchChipCfg));
+ /* Parse the private configuration of the touchscreen. */
+ if (ParseTouchChipConfig(device->property, chipCfg) != HDF_SUCCESS) {
+ HDF_LOGE("%s: parse chip config failed", __func__);
+ OsalMemFree(chipCfg);
+ chipCfg = NULL;
+ }
+ return chipCfg;
+}
+
+static ChipDevice *ChipDeviceInstance(void)
+{
+ ChipDevice *chipDev = (ChipDevice *)OsalMemAlloc(sizeof(ChipDevice));
+ if (chipDev == NULL) {
+ HDF_LOGE("%s: instance chip device failed", __func__);
+ return NULL;
+ }
+ (void)memset_s(chipDev, sizeof(ChipDevice), 0, sizeof(ChipDevice));
+ return chipDev;
+}
+
+static void FreeChipConfig(TouchChipCfg *config)
+{
+ if (config->pwrSeq.pwrOn.buf != NULL) {
+ OsalMemFree(config->pwrSeq.pwrOn.buf);
+ }
+ if (config->pwrSeq.pwrOff.buf != NULL) {
+ OsalMemFree(config->pwrSeq.pwrOff.buf);
+ }
+ OsalMemFree(config);
+}
+
+static int32_t HdfSampleChipInit(struct HdfDeviceObject *device)
+{
+ TouchChipCfg *chipCfg = NULL;
+ ChipDevice *chipDev = NULL;
+ HDF_LOGE("%s: enter", __func__);
+ if (device == NULL) {
+ return HDF_ERR_INVALID_PARAM;
+ }
+ /* Parse the private configuration of the touchscreen. */
+ chipCfg = ChipConfigInstance(device);
+ if (chipCfg == NULL) {
+ return HDF_ERR_MALLOC_FAIL;
+ }
+ /* Instantiate the touchscreen device. */
+ chipDev = ChipDeviceInstance();
+ if (chipDev == NULL) {
+ goto freeCfg;
+ }
+ chipDev->chipCfg = chipCfg;
+ chipDev->ops = &g_sampleChipOps;
+ chipDev->chipName = chipCfg->chipName;
+ chipDev->vendorName = chipCfg->vendorName;
+
+ /* Register the touchscreen device with the platform driver. */
+ if (RegisterChipDevice(chipDev) != HDF_SUCCESS) {
+ goto freeDev;
+ }
+ HDF_LOGI("%s: exit succ, chipName = %s", __func__, chipCfg->chipName);
+ return HDF_SUCCESS;
+
+freeDev:
+ OsalMemFree(chipDev);
+freeCfg:
+ FreeChipConfig(chipCfg);
+ return HDF_FAILURE;
+}
+
+struct HdfDriverEntry g_touchSampleChipEntry = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_TOUCH_SAMPLE",
+ .Init = HdfSampleChipInit,
+};
+
+HDF_INIT(g_touchSampleChipEntry);
+```
+
diff --git a/en/device-dev/driver/drive-peripherals.md b/en/device-dev/driver/drive-peripherals.md
new file mode 100644
index 0000000000000000000000000000000000000000..074c08226b900cad58231e574606428049bd8224
--- /dev/null
+++ b/en/device-dev/driver/drive-peripherals.md
@@ -0,0 +1,11 @@
+# Peripherals
+
+- **[LCD](drive-peripherals-lcd-des.md)**
+
+- **[TOUCHSCREEN](drive-peripherals-touch-des.md)**
+
+- **[Sensor](drive-peripherals-sensor-des.md)**
+
+- **[WLAN](drive-peripherals-external-des.md)**
+
+
diff --git a/en/device-dev/driver/drive-platform-gpio-des.md b/en/device-dev/driver/drive-platform-gpio-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..045a23db3e998a174fd191525fd04742b9ca86a8
--- /dev/null
+++ b/en/device-dev/driver/drive-platform-gpio-des.md
@@ -0,0 +1,560 @@
+# GPIO
+
+- [Overview](#section1635911016188)
+ - [Available APIs](#section17715915181611)
+
+- [Usage Guidelines](#section259614242196)
+ - [How to Use](#section103477714216)
+ - [Determining a GPIO Pin Number](#section370083272117)
+ - [Using APIs to Operate GPIO Pins](#section13604050132118)
+
+- [Usage Example](#section25941262111)
+
+## Overview
+
+Generally, a general-purpose input/output \(GPIO\) controller manages all GPIO pins by group. Each group of GPIO pins is associated with one or more registers. The GPIO pins are operated by reading data from and writing data to the registers.
+
+The GPIO APIs define a set of standard functions for performing operations on GPIO pins, including:
+
+- Setting the pin direction, which can be input or output \(High impedance is not supported currently.\)
+
+- Reading and writing level values, which can be low or high
+- Setting an interrupt service routine \(ISR\) function and interrupt trigger mode for a pin
+- Enabling or disabling a pin interrupt
+
+### Available APIs
+
+**Table 1** APIs available for the GPIO driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
GPIO read/write
+
+
GpioRead
+
+
Reads the level value of a GPIO pin.
+
+
+
GpioWrite
+
+
Writes the level value of a GPIO pin.
+
+
+
GPIO settings
+
+
GpioSetDir
+
+
Sets the direction for a GPIO pin.
+
+
+
GpioGetDir
+
+
Obtains the direction for a GPIO pin.
+
+
+
GPIO interrupt settings
+
+
GpioSetIrq
+
+
Sets the ISR function for a GPIO pin.
+
+
+
GpioUnSetIrq
+
+
Cancels the setting of the ISR function for a GPIO pin.
+
+
+
GpioEnableIrq
+
+
Enables a GPIO interrupt.
+
+
+
GpioDisableIrq
+
+
Disables a GPIO interrupt.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### How to Use
+
+The GPIO APIs use the GPIO pin number to specify a pin. [Figure 1](#fig1399416053717) shows the general process of using a GPIO.
+
+**Figure 1** Process of using a GPIO
+
+
+
+
+### Determining a GPIO Pin Number
+
+The method for converting GPIO pin numbers varies according to the GPIO controller model, parameters, and controller driver of different system on chips \(SoCs\).
+
+- Hi3516DV300
+
+ 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
+
+ Example: GPIO number of GPIO10\_3 = 10 x 8 + 3 = 83
+
+- Hi3518EV300
+
+ A controller manages 10 groups of GPIO pins. Each group contains 10 GPIO pins.
+
+ GPIO pin number = GPIO group index \(0–9\) x Number of GPIO pins in each group \(10\) + Offset in the group
+
+ Example: GPIO pin number of GPIO7\_3 = 7 x 10 + 3 = 73
+
+
+### Using APIs to Operate GPIO Pins
+
+- Set the direction for a GPIO pin.
+
+ Before performing read/write operations on a GPIO pin, call the following function to set the direction:
+
+ int32\_t GpioSetDir\(uint16\_t gpio, uint16\_t dir\);
+
+ **Table 2** Description of GpioSetDir
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
dir
+
+
Direction to set.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the direction for a GPIO pin.
+
+
+
Negative value
+
+
Failed to set the direction for a GPIO pin.
+
+
+
+
+
+
+- Read or write the level value for a GPIO pin.
+
+ To read the level value of a GPIO pin, call the following function:
+
+ int32\_t GpioRead\(uint16\_t gpio, uint16\_t \*val\);
+
+ **Table 3** Description of GpioRead
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
val
+
+
Pointer to the level value.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in reading the level value.
+
+
+
Negative value
+
+
Failed to read the level value.
+
+
+
+
+
+ To write the level value for a GPIO pin, call the following function:
+
+ int32\_t GpioWrite\(uint16\_t gpio, uint16\_t val\);
+
+ **Table 4** Description of GpioWrite
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
val
+
+
Level value to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in writing the level value.
+
+
+
Negative value
+
+
Failed to write the level value.
+
+
+
+
+
+ Example:
+
+ ```
+ int32_t ret;
+ uint16_t val;
+ /* Set the output direction for GPIO3. */
+ ret = GpioSetDir(3, GPIO_DIR_OUT);
+ if (ret != 0) {
+ HDF_LOGE("GpioSerDir: failed, ret %d\n", ret);
+ return;
+ }
+ /* Write the low level GPIO_VAL_LOW for GPIO3. */
+ ret = GpioWrite(3, GPIO_VAL_LOW);
+ if (ret != 0) {
+ HDF_LOGE("GpioWrite: failed, ret %d\n", ret);
+ return;
+ }
+ /* Set the input direction for GPIO6. */
+ ret = GpioSetDir(6, GPIO_DIR_IN);
+ if (ret != 0) {
+ HDF_LOGE("GpioSetDir: failed, ret %d\n", ret);
+ return;
+ }
+ /* Read the level value of GPIO6. */
+ ret = GpioRead(6, &val);
+ ```
+
+
+- Set the ISR function for a GPIO pin.
+
+ To set the ISR function for a GPIO pin, call the following function:
+
+ int32\_t GpioSetIrq\(uint16\_t gpio, uint16\_t mode, GpioIrqFunc func, void \*arg\);
+
+ **Table 5** Description of GpioSetIrq
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
mode
+
+
Interrupt trigger mode.
+
+
+
func
+
+
ISR function to set.
+
+
+
arg
+
+
Pointer to the parameters passed to the ISR function.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the ISR function for a GPIO pin.
+
+
+
Negative value
+
+
Failed to set the ISR function for a GPIO pin.
+
+
+
+
+
+ > **CAUTION:**
+ >Only one ISR function can be set for a GPIO pin at a time. If **GpioSetIrq** is called repeatedly, the previous IRS function will be replaced.
+
+ If the ISR function is no longer required, call the following function to cancel the setting:
+
+ int32\_t GpioUnSetIrq\(uint16\_t gpio\);
+
+ **Table 6** Description of GpioUnSetIrq
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in canceling the ISR function.
+
+
+
Negative value
+
+
Failed to cancel the ISR function.
+
+
+
+
+
+ After the ISR function is set, call the following function to enable a GPIO interrupt:
+
+ int32\_t GpioEnableIrq\(uint16\_t gpio\);
+
+ **Table 7** Description of GpioEnableIrq
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in enabling a GPIO interrupt.
+
+
+
Negative value
+
+
Failed to enable a GPIO interrupt.
+
+
+
+
+
+ > **CAUTION:**
+ >The configured ISR function can be responded only after the GPIO interrupt is enabled.
+
+ Use the following function to disable the GPIO interrupt:
+
+ int32\_t GpioDisableIrq\(uint16\_t gpio\);
+
+ **Table 8** Description of GpioDisableIrq
+
+
+
Parameter
+
+
Description
+
+
+
gpio
+
+
GPIO pin number.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in disabling a GPIO interrupt.
+
+
+
Negative value
+
+
Failed to disable a GPIO interrupt.
+
+
+
+
+
+ Example:
+
+ ```
+ /* ISR function */
+ */
+ int32_t MyCallBackFunc(uint16_t gpio, void *data)
+ {
+ HDF_LOGI("%s: gpio:%u interrupt service in! data=%p\n", __func__, gpio, data);
+ return 0;
+ }
+
+ int32_t ret;
+ /* Set the ISR function to MyCallBackFunc, the parameter to NULL, and the interrupt trigger mode to rising edge. */
+ ret = GpioSetIrq(3, OSAL_IRQF_TRIGGER_RISING, MyCallBackFunc, NULL);
+ if (ret != 0) {
+ HDF_LOGE("GpioSetIrq: failed, ret %d\n", ret);
+ return;
+ }
+
+ /* Enable an interrupt for GPIO3. */
+ ret = GpioEnableIrq(3);
+ if (ret != 0) {
+ HDF_LOGE("GpioEnableIrq: failed, ret %d\n", ret);
+ return;
+ }
+
+ /* Disable the interrupt for GPIO3. */
+ ret = GpioDisableIrq(3);
+ if (ret != 0) {
+ HDF_LOGE("GpioDisableIrq: failed, ret %d\n", ret);
+ return;
+ }
+
+ /* Cancel the ISR function for GPIO3. */
+ ret = GpioUnSetIrq(3);
+ if (ret != 0) {
+ HDF_LOGE("GpioUnSetIrq: failed, ret %d\n", ret);
+ return;
+ }
+ ```
+
+
+## Usage Example
+
+In this example, we test the interrupt trigger of a GPIO pin as follows: Set the ISR function for the pin, set the trigger mode to rising edge and failing edge, write high and low levels to the pin alternately to generate level fluctuation, and observe the execution of the ISR function.
+
+Select an idle GPIO pin. This example uses a Hi3516D V300 development board and GPIO pin GPIO10\_3, which is numbered GPIO83.
+
+You can select an idle GPIO pin based on the development board and schematic diagram.
+
+```
+#include "gpio_if.h"
+#include "hdf_log.h"
+#include "osal_irq.h"
+#include "osal_time.h"
+
+static uint32_t g_irqCnt;
+
+/* ISR function */
+static int32_t TestCaseGpioIrqHandler(uint16_t gpio, void *data)
+{
+ HDF_LOGE("%s: irq triggered! on gpio:%u, data=%p", __func__, gpio, data);
+ g_irqCnt++; /* If the ISR function is triggered, the number of global interrupts is incremented by 1. */
+ return GpioDisableIrq(gpio);
+}
+
+/* Test case function */
+static int32_t TestCaseGpioIrqEdge(void)
+{
+ int32_t ret;
+ uint16_t valRead;
+ uint16_t mode;
+ uint16_t gpio = 83; /* Number of the GPIO pin to test */
+ uint32_t timeout;
+
+ /* Set the output direction for the pin. */
+ ret = GpioSetDir(gpio, GPIO_DIR_OUT);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set dir fail! ret:%d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Disable the interrupt of the pin. */
+ ret = GpioDisableIrq(gpio);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: disable irq fail! ret:%d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Set the ISR function for the pin. The trigger mode is both rising edge and falling edge. */
+ mode = OSAL_IRQF_TRIGGER_RISING | OSAL_IRQF_TRIGGER_FALLING;
+ HDF_LOGE("%s: mode:%0x\n", __func__, mode);
+ ret = GpioSetIrq(gpio, mode, TestCaseGpioIrqHandler, NULL);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set irq fail! ret:%d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Enable the interrupt for this pin. */
+ ret = GpioEnableIrq(gpio);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: enable irq fail! ret:%d\n", __func__, ret);
+ (void)GpioUnSetIrq(gpio);
+ return ret;
+ }
+
+ g_irqCnt = 0; /* Reset the global counter. */
+ timeout = 0; /* Reset the waiting time. */
+ /* Wait for the ISR function of this pin to trigger. The timeout duration is 1000 ms. */
+ while (g_irqCnt <= 0 && timeout < 1000) {
+ (void)GpioRead(gpio, &valRead);
+ (void)GpioWrite(gpio, (valRead == GPIO_VAL_LOW) ? GPIO_VAL_HIGH : GPIO_VAL_LOW);
+ HDF_LOGE("%s: wait irq timeout:%u\n", __func__, timeout);
+ OsalMDelay(200); /* wait for irq trigger */
+ timeout += 200;
+ }
+ (void)GpioUnSetIrq(gpio);
+ return (g_irqCnt > 0) ? HDF_SUCCESS : HDF_FAILURE;
+}
+```
+
diff --git a/en/device-dev/driver/drive-platform-i2c-des.md b/en/device-dev/driver/drive-platform-i2c-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..7b70a9fbd022795d0bdbfd142626fdeecf61346d
--- /dev/null
+++ b/en/device-dev/driver/drive-platform-i2c-des.md
@@ -0,0 +1,426 @@
+# I2C
+
+- [Overview](#section5361140416)
+ - [Available APIs](#section459052019177)
+
+- [Usage Guidelines](#section1695201514281)
+ - [How to Use](#section1338373417288)
+ - [Opening an I2C Controller](#section13751110132914)
+ - [Performing I2C Communication](#section9202183372916)
+ - [Closing an I2C Controller](#section19481164133018)
+
+- [Usage Example](#section5302202015300)
+
+## Overview
+
+- The Inter-Integrated Circuit \(I2C\) is a simple, bidirectional, and synchronous serial bus that uses merely two wires.
+- In an I2C communication, one controller communicates with one or more devices through the serial data line \(SDA\) and serial clock line \(SCL\), as shown in [Figure 1](#fig1135561232714).
+
+- I2C data transfer must begin with a **START** condition and end with a **STOP** condition. Data is transmitted byte-by-byte from the most significant bit to the least significant bit.
+- Each I2C node is recognized by a unique address and can serve as either a controller or a device. When the controller needs to communicate with a device, it writes the device address to the bus through broadcast. A device matching this address sends a response to set up a data transfer channel.
+
+- The I2C APIs define a set of common functions for I2C data transfer, including:
+
+ - I2C controller management: opening or closing an I2C controller
+ - I2C message transfer: custom transfer by using a message array
+
+ **Figure 1** Physical connection diagram for I2C
+ 
+
+
+### Available APIs
+
+**Table 1** APIs available for the I2C driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
I2C controller management
+
+
I2cOpen
+
+
Opens an I2C controller.
+
+
+
I2cClose
+
+
Closes an I2C controller.
+
+
+
I2C message transfer
+
+
I2cTransfer
+
+
Performs a custom transfer.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 2](#fig166181128151112) illustrates the process of an I2C device.
+
+**Figure 2** Process of using an I2C device
+
+
+
+
+### Opening an I2C Controller
+
+Call the following function to open an I2C controller:
+
+DevHandle I2cOpen\(int16\_t number\);
+
+**Table 2** Description of I2cOpen
+
+
+
Parameter
+
+
Description
+
+
+
+
number
+
+
I2C controller ID.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to open the I2C controller.
+
+
+
Device handle
+
+
Handle of the I2C controller.
+
+
+
+
+
+This example assumes that the system has eight I2C controllers \(numbered from 0 to 7\) and I2C controller 3 is to open.
+
+```
+DevHandle i2cHandle = NULL; /* I2C controller handle */
+
+/* Open an I2C controller. */
+i2cHandle = I2cOpen(3);
+if (i2cHandle == NULL) {
+ HDF_LOGE("I2cOpen: failed\n");
+ return;
+}
+```
+
+### Performing I2C Communication
+
+Use the following function for message transfer:
+
+int32\_t I2cTransfer\(DevHandle handle, struct I2cMsg \*msgs, int16\_t count\);
+
+**Table 3** Description of I2cTransfer
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Handle of an I2C controller.
+
+
+
msgs
+
+
Message array of the data to transfer.
+
+
+
count
+
+
Length of the message array.
+
+
+
Return Value
+
+
Description
+
+
+
Positive integer
+
+
Number of message structures that are successfully transmitted.
+
+
+
Negative value
+
+
Failed to perform the message transfer.
+
+
+
+
+
+The type of an I2C message transfer is defined by **I2cMsg**. Each message structure indicates a read or write operation. Multiple read or write operations can be performed by using a message array.
+
+```
+int32_t ret;
+uint8_t wbuff[2] = { 0x12, 0x13 };
+uint8_t rbuff[2] = { 0 };
+struct I2cMsg msgs[2]; /* Custom message array for transfer */
+msgs[0].buf = wbuff; /* Data to write */
+msgs[0].len = 2; /* The length of the data to write is 2. */
+msgs[0].addr = 0x5A; /* The address of the device to write the data is 0x5A. */
+msgs[0].flags = 0; /* The flag is 0, indicating the write operation. */
+msgs[1].buf = rbuff; /* Data to read */
+msgs[1].len = 2; /* The length of the data to read is 2. */
+msgs[1].addr = 0x5A; /* The address of the device to read is 0x5A. */
+msgs[1].flags = I2C_FLAG_READ /* I2C_FLAG_READ is configured, indicating the read operation. */
+/* Perform a custom transfer to transfer two messages. */
+ret = I2cTransfer(i2cHandle, msgs, 2);
+if (ret != 2) {
+ HDF_LOGE("I2cTransfer: failed, ret %d\n", ret);
+ return;
+}
+```
+
+> **CAUTION:**
+>- The device address in the **I2cMsg** structure does not contain the read/write flag bit. The read/write information is transferred by the read/write control bit in the member variable **flags**.
+>- The **I2cTransfer** function does not limit the number of message structures, which is determined by the I2C controller.
+>- The **I2cTransfer** function does not limit the data length of each message structure, which is determined by the I2C controller.
+>- The **I2cTransfer** function may cause the system to sleep and therefore cannot be called in the interrupt context.
+
+### Closing an I2C Controller
+
+Call the following function to close the I2C controller after the communication is complete:
+
+void I2cClose\(DevHandle \*handle\);
+
+**Table 4** Description of I2cClose
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Handle of an I2C controller.
+
+
+
+
+
+```
+I2cClose(i2cHandle); /* Close the I2C controller. */
+```
+
+## Usage Example
+
+This example describes how to use I2C APIs with an I2C device on a development board.
+
+This example shows a simple register read/write operation on TouchPad on a Hi3516D V300 development board. The basic hardware information is as follows:
+
+- SoC: hi3516dv300
+
+- Touch IC: The I2C address is 0x38, and the bit width of Touch IC's internal register is 1 byte.
+
+- Schematic diagram: TouchPad is mounted to I2C controller 3. The reset pin of Touch IC is GPIO3.
+
+In this example, first we reset Touch IC. \(The development board supplies power to Touch IC by default after being powered on, and this use case does not consider the power supply\). Then, we perform a read/write operation on an internal register to test whether the I2C channel is normal.
+
+> **NOTE:**
+>The example focuses on I2C device access and verifies the I2C channel. The read and write values of the device register are not concerned. The behavior caused by the read and write operations on the register is determined by the device itself.
+
+Example:
+
+```
+#include "i2c_if.h" /* Header file of I2C APIs */
+#include "gpio_if.h" /* Header file of GPIO APIs */
+#include "hdf_log.h" /* Header file for log APIs */
+#include "osal_io.h" /* Header file of I/O read and write APIs */
+#include "osal_time.h" /* Header file of delay and sleep APIs */
+
+/* Define a TP device structure to store I2C and GPIO hardware information. */
+struct TpI2cDevice {
+ uint16_t rstGpio; /* Reset pin */
+ uint16_t busId; /* I2C bus ID */
+ uint16_t addr; /* I2C device address */
+ uint16_t regLen; /* Register bit width */
+ DevHandle i2cHandle; /* I2C controller handle */
+};
+
+/* I2C pin I/O configuration. For details, see the SoC register manual. */
+#define I2C3_DATA_REG_ADDR 0x112f008c /* Address of the SDA pin configuration register of I2C controller 3
+#define I2C3_CLK_REG_ADDR 0x112f0090 /* Address of the SCL pin configuration register of I2C controller 3
+#define I2C_REG_CFG 0x5f1 /* Configuration values of SDA and SCL pins of I2C controller 3
+
+static void TpSocIoCfg(void)
+{
+ /* Set the I/O function of the two pins corresponding to I2C controller 3 to I2C. */
+ OSAL_WRITEL(I2C_REG_CFG, IO_DEVICE_ADDR(I2C3_DATA_REG_ADDR));
+ OSAL_WRITEL(I2C_REG_CFG, IO_DEVICE_ADDR(I2C3_CLK_REG_ADDR));
+}
+
+/* Initialize the reset pin of the TP. Pull up the pin for 20 ms, pull down the pin for 50 ms, and then pull up the pin for 20 ms to complete the resetting. */
+static int32_t TestCaseGpioInit(struct TpI2cDevice *tpDevice)
+{
+ int32_t ret;
+
+ /* Set the output direction for the reset pin. */
+ ret = GpioSetDir(tpDevice->rstGpio, GPIO_DIR_OUT);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set rst dir fail!:%d", __func__, ret);
+ return ret;
+ }
+
+ ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_HIGH);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set rst hight fail!:%d", __func__, ret);
+ return ret;
+ }
+ OsalMSleep(20);
+
+ ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_LOW);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set rst low fail!:%d", __func__, ret);
+ return ret;
+ }
+ OsalMSleep(50);
+
+ ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_HIGH);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set rst high fail!:%d", __func__, ret);
+ return ret;
+ }
+ OsalMSleep(20);
+
+ return HDF_SUCCESS;
+}
+
+/* Use I2cTransfer to encapsulate a register read/write auxiliary function. Use flag to indicate the read or write operation. */
+static int TpI2cReadWrite(struct TpI2cDevice *tpDevice, unsigned int regAddr,
+ unsigned char *regData, unsigned int dataLen, uint8_t flag)
+{
+ int index = 0;
+ unsigned char regBuf[4] = {0};
+ struct I2cMsg msgs[2] = {0};
+
+ /* Perform length adaptation for the single- or dual-byte register. */
+ if (tpDevice->regLen == 1) {
+ regBuf[index++] = regAddr & 0xFF;
+ } else {
+ regBuf[index++] = (regAddr >> 8) & 0xFF;
+ regBuf[index++] = regAddr & 0xFF;
+ }
+
+ /* Fill in the I2cMsg message structure. */
+ msgs[0].addr = tpDevice->addr;
+ msgs[0].flags = 0; /* The flag is 0, indicating the write operation. */
+ msgs[0].len = tpDevice->regLen;
+ msgs[0].buf = regBuf;
+
+ msgs[1].addr = tpDevice->addr;
+ msgs[1].flags = (flag == 1)? I2C_FLAG_READ: 0; /* Add the read flag. */
+ msgs[1].len = dataLen;
+ msgs[1].buf = regData;
+
+ if (I2cTransfer(tpDevice->i2cHandle, msgs, 2) != 2) {
+ HDF_LOGE("%s: i2c read err", __func__);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+}
+
+/* TP register read function */
+static inline int TpI2cReadReg(struct TpI2cDevice *tpDevice, unsigned int regAddr,
+ unsigned char *regData, unsigned int dataLen)
+{
+ return TpI2cReadWrite(tpDevice, regAddr, regData, dataLen, 1);
+}
+
+/* TP register write function */
+static inline int TpI2cWriteReg(struct TpI2cDevice *tpDevice, unsigned int regAddr,
+ unsigned char *regData, unsigned int dataLen)
+{
+ return TpI2cReadWrite(tpDevice, regAddr, regData, dataLen, 0);
+}
+
+/* Main entry of I2C */
+static int32_t TestCaseI2c(void)
+{
+ int32_t i;
+ int32_t ret;
+ unsigned char bufWrite[7] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xA, 0xB, 0xC };
+ unsigned char bufRead[7] = {0};
+ static struct TpI2cDevice tpDevice;
+
+ /* I/O pin function configuration */
+ TpSocIoCfg();
+
+ /* Initialize TP device information. */
+ tpDevice.rstGpio = 3;
+ tpDevice.busId = 3;
+ tpDevice.addr = 0x38;
+ tpDevice.regLen = 1;
+ tpDevice.i2cHandle = NULL;
+
+ /* Initialize the GPIO pin. */
+ ret = TestCaseGpioInit(&tpDevice);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: gpio init fail!:%d", __func__, ret);
+ return ret;
+ }
+
+ /* Open an I2C controller. */
+ tpDevice.i2cHandle = I2cOpen(tpDevice.busId);
+ if (tpDevice.i2cHandle == NULL) {
+ HDF_LOGE("%s: Open I2c:%u fail!", __func__, tpDevice.busId);
+ return -1;
+ }
+
+ /* Continuously write 7-byte data to register 0xD5 of TP-IC. */
+ ret = TpI2cWriteReg(&tpDevice, 0xD5, bufWrite, 7);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: tp i2c write reg fail!:%d", __func__, ret);
+ I2cClose(tpDevice.i2cHandle);
+ return -1;
+ }
+ OsalMSleep(10);
+
+ /* Continuously read 7-byte data from register 0xDO of TP-IC. */
+ ret = TpI2cReadReg(&tpDevice, 0xD5, bufRead, 7);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: tp i2c read reg fail!:%d", __func__, ret);
+ I2cClose(tpDevice.i2cHandle);
+ return -1;
+ }
+
+ HDF_LOGE("%s: tp i2c write&read reg success!", __func__);
+ for (i = 0; i < 7; i++) {
+ HDF_LOGE("%s: bufRead[%d] = 0x%x", __func__, i, bufRead[i]);
+ }
+
+ /* Close the I2C controller. */
+ I2cClose(tpDevice.i2cHandle);
+ return ret;
+}
+```
+
diff --git a/en/device-dev/driver/drive-platform-mipidsi-des.md b/en/device-dev/driver/drive-platform-mipidsi-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..250a419f0ee64f2364f03478a247bb11c0ff6d90
--- /dev/null
+++ b/en/device-dev/driver/drive-platform-mipidsi-des.md
@@ -0,0 +1,554 @@
+# MIPI DSI
+
+- [Overview](#section16806142183217)
+ - [Available APIs](#section129611916132011)
+
+- [Usage Guidelines](#section037231715335)
+ - [How to Use](#section49299119344)
+ - [Obtains a MIPI DSI device handle.](#section5126155683811)
+ - [Setting MIPI DSI Configuration Parameters](#section201164274344)
+ - [Sending/Receiving the Pointer to a Command](#section199401342173415)
+ - [Releasing the MIPI DSI Device Handle](#section161011610357)
+
+- [Usage Example](#section17470126123520)
+
+## Overview
+
+- The Display Serial Interface \(DSI\) is a specification stipulated by the Mobile Industry Processor Interface \(MIPI\) Alliance, aiming to reduce the cost of display controllers in a mobile device. It defines a serial bus and communication protocol among the host, the source of image data, and the target device. In this way, the DSI can send pixel data or commands to peripherals \(usually LCDs or similar display devices\) in serial mode, or reads information such as status and pixel from the peripherals.
+
+- MIPI DSI is capable of working in both high speed \(HS\) mode and low power \(LP\) mode. All data lanes can only travel from the DSI host to a peripheral in HS mode, except the first data lane, which can also receive data such as status information and pixels from the peripheral in LP mode. The clock lane is dedicated to transmitting synchronization clock signals in HS mode.
+- [Figure 1](#fig1122611461203) shows a simplified DSI interface. Conceptually, a DSI-compliant interface has the same features as interfaces complying with DBI-2 and DPI-2 standards. It sends pixels or commands to a peripheral and can read status or pixel information from the peripheral. The main difference is that the DSI serializes all pixel data, commands, and events that, in traditional interfaces, are conveyed to and from the peripheral on a parallel data bus with additional control signals.
+
+ **Figure 1** DSI transmitting and receiving interface
+ 
+
+
+### Available APIs
+
+**Table 1** APIs for MIPI DSI
+
+
+
Sets configuration parameters for a MIPI DSI device.
+
+
+
MipiDsiGetCfg
+
+
Obtains configuration parameters of a MIPI DSI device.
+
+
+
Obtaining /Releasing device handles
+
+
MipiDsiOpen
+
+
Obtains a MIPI DSI device handle.
+
+
+
MipiDsiClose
+
+
Releases a specified MIPI DSI device handle.
+
+
+
Setting the LP or HS mode
+
+
MipiDsiSetLpMode
+
+
Sets LP mode for a MIPI DSI device.
+
+
+
MipiDsiSetHsMode
+
+
Sets HS mode for a MIPI DSI device.
+
+
+
Reading/Sending commands
+
+
MipiDsiTx
+
+
Sends a display command set (DCS) command for sending data.
+
+
+
MipiDsiRx
+
+
Receives a DCS command for reading data with the specified length.
+
+
+
+
+
+> **NOTE:**
+>All functions described in this document can be called only in kernel space.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 2](#fig99821771782) shows the process of using a MIPI DSI device.
+
+**Figure 2** Process of using a MIPI DSI device
+
+
+
+
+### Obtains a MIPI DSI device handle.
+
+Before performing MIPI DSI communication, obtain a MIPI DSI device handle by calling **MipiDsiOpen**. This function returns a MIPI DSI device handle with a specified channel ID.
+
+DevHandle MipiDsiOpen\(uint8\_t id\);
+
+**Table 2** Description of **MipiDsiOpen**
+
+
+
Parameter
+
+
Description
+
+
+
+
id
+
+
MIPI DSI channel ID.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to receive the specified command.
+
+
+
Device handle
+
+
MIPI DSI device handle with a specified channel ID, whose data type is DevHandle.
+
+
+
+
+
+The following example shows how to obtain a MIPI DSI device handle with the channel ID **0**:
+
+```
+DevHandle mipiDsiHandle = NULL; /* Device handle */
+chnId = 0; /* MIPI DSI channel ID */
+
+/* Obtain the MIPI DSI device handle based on a specified channel ID. */
+mipiDsiHandle = MipiDsiOpen(chnId);
+if (mipiDsiHandle == NULL) {
+ HDF_LOGE("MipiDsiOpen: failed\n");
+ return;
+}
+```
+
+### Setting MIPI DSI Configuration Parameters
+
+- Set MIPI DSI configuration parameters by calling the following function:
+
+int32\_t MipiDsiSetCfg\(DevHandle handle, struct MipiCfg \*cfg\);
+
+**Table 3** Description of **MipiDsiSetCfg**
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
MIPI DSI device handle.
+
+
+
cfg
+
+
Pointer to MIPI DSI configuration parameters.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting MIPI DSI configuration parameters.
+
+```
+MipiDsiClose(mipiHandle); /* Release the MIPI DSI device handle */
+```
+
+## Usage Example
+
+The following is an example of using a MIPI DSI device:
+
+```
+#include "hdf.h"
+#include "mipi_dsi_if.h"
+
+void PalMipiDsiTestSample(void)
+{
+ uint8_t chnId;
+ int32_t ret;
+ DevHandle handle = NULL;
+
+ /* Device channel ID */
+ chnId = 0;
+ /* Obtain the MIPI DSI device handle based on a specified channel ID. */
+ handle = MipiDsiOpen(chnId);
+ if (handle == NULL) {
+ HDF_LOGE("MipiDsiOpen: failed!\n");
+ return;
+ }
+ /* MIPI DSI configuration parameters */
+ struct MipiCfg cfg = {0};
+ cfg.lane = DSI_4_LANES;
+ cfg.mode = DSI_CMD_MODE;
+ cfg.burstMode = VIDEO_NON_BURST_MODE_SYNC_EVENTS;
+ cfg.format = FORMAT_RGB_24_BIT;
+ cfg.pixelClk = 174;
+ cfg.phyDataRate = 384;
+ cfg.timingInfo.hsaPixels = 50;
+ cfg.timingInfo.hbpPixels = 55;
+ cfg.timingInfo.hlinePixels = 1200;
+ cfg.timingInfo.yResLines = 1800;
+ cfg.timingInfo.vbpLines = 33;
+ cfg.timingInfo.vsaLines = 76;
+ cfg.timingInfo.vfpLines = 120;
+ cfg.timingInfo.xResPixels = 1342;
+ /* Set MIPI DSI configuration parameters. */
+ ret = MipiDsiSetCfg(g_handle, &cfg);
+ if (ret != 0) {
+ HDF_LOGE("%s: SetMipiCfg fail! ret=%d\n", __func__, ret);
+ return;
+ }
+ /* Send the command for initializing the PANEL register. */
+ struct DsiCmdDesc *cmd = OsalMemCalloc(sizeof(struct DsiCmdDesc));
+ if (cmd == NULL) {
+ return;
+ }
+ cmd->dtype = DTYPE_DCS_WRITE;
+ cmd->dlen = 1;
+ cmd->payload = OsalMemCalloc(sizeof(uint8_t));
+ if (cmd->payload == NULL) {
+ HdfFree(cmd);
+ return;
+ }
+ *(cmd->payload) = DTYPE_GEN_LWRITE;
+ MipiDsiSetLpMode(mipiHandle);
+ ret = MipiDsiTx(mipiHandle, cmd);
+ MipiDsiSetHsMode(mipiHandle);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: MipiDsiTx fail! ret=%d\n", __func__, ret);
+ HdfFree(cmd->payload);
+ HdfFree(cmd);
+ return;
+ }
+ HdfFree(cmd->payload);
+ HdfFree(cmd);
+ /* Pointer to the register that reads the PANEL status */
+ uint8_t readVal = 0;
+ struct DsiCmdDesc *cmdRead = OsalMemCalloc(sizeof(struct DsiCmdDesc));
+ if (cmdRead == NULL) {
+ return;
+ }
+ cmdRead->dtype = DTYPE_DCS_READ;
+ cmdRead->dlen = 1;
+ cmdRead->payload = OsalMemCalloc(sizeof(uint8_t));
+ if (cmdRead->payload == NULL) {
+ HdfFree(cmdRead);
+ return;
+ }
+ *(cmdRead->payload) = DDIC_REG_STATUS;
+ MipiDsiSetLpMode(g_handle);
+ ret = MipiDsiRx(g_handle, cmdRead, sizeof(readVal), &readVal);
+ MipiDsiSetHsMode(g_handle);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: MipiDsiRx fail! ret=%d\n", __func__, ret);
+ HdfFree(cmdRead->payload);
+ HdfFree(cmdRead);
+ return;
+ }
+ HdfFree(cmdRead->payload);
+ HdfFree(cmdRead);
+ /* Release the MIPI DSI device handle. */
+ MipiDsiClose(handle);
+}
+```
+
diff --git a/en/device-dev/driver/drive-platform-rtc-des.md b/en/device-dev/driver/drive-platform-rtc-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..66e8a08cf14f76bd8e32165491c4387567db8f66
--- /dev/null
+++ b/en/device-dev/driver/drive-platform-rtc-des.md
@@ -0,0 +1,944 @@
+# RTC
+
+- [Overview](#section104842041574)
+ - [Available APIs](#section3373340142215)
+
+- [Usage Guidelines](#section20636145604113)
+ - [How to Use](#section16919828134215)
+ - [Creating an RTC Device Handle](#section1131212144310)
+ - [Releasing the RTC Device Handle](#section10744117144314)
+ - [Registering RtcAlarmCallback](#section14839440184320)
+ - [Performing RTC-related Operations](#section161927578433)
+
+- [Usage Example](#section1186111020456)
+
+## Overview
+
+The real-time clock \(RTC\) driver provides precise real time for the operating system \(OS\). If the OS is powered off, the RTC driver continues to keep track of the system time using an external battery.
+
+### Available APIs
+
+**Table 1** APIs provided by the RTC driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
RTC handle
+
+
RtcOpen
+
+
Opens the RTC device to obtain its handle.
+
+
+
RtcClose
+
+
Releases a specified handle of the RTC device.
+
+
+
RTC time
+
+
RtcReadTime
+
+
Reads time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
RtcWriteTime
+
+
Writes time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
RTC alarm
+
+
RtcReadAlarm
+
+
Reads the RTC alarm time that was set last time.
+
+
+
RtcWriteAlarm
+
+
Writes the RTC alarm time based on the alarm index.
+
+
+
RtcRegisterAlarmCallback
+
+
Registers RtcAlarmCallback that will be invoked when an alarm is generated at the specified time.
+
+
+
RtcAlarmInterruptEnable
+
+
Enables or disables RTC alarm interrupts.
+
+
+
RTC configuration
+
+
RtcGetFreq
+
+
Reads the frequency of the external crystal oscillator connected to the RTC driver.
+
+
+
RtcSetFreq
+
+
Sets the frequency of the external crystal oscillator connected to the RTC driver.
+
+
+
RtcReset
+
+
Resets the RTC.
+
+
+
Custom register
+
+
RtcReadReg
+
+
Reads the configuration of a custom RTC register based on the register index.
+
+
+
RtcWriteReg
+
+
Writes the configuration of a custom RTC register based on the register index.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### How to Use
+
+During the OS startup, the HDF loads the RTC driver based on the configuration file. The RTC driver detects the RTC component and initializes the driver.
+
+[Figure 1](#fig166181128151112) illustrates the process of using an RTC device.
+
+**Figure 1** Process of using an RTC device
+
+
+
+
+### Creating an RTC Device Handle
+
+After the RTC driver is loaded, you can use the API provided by the HDF and call APIs of the RTC driver.
+
+> **NOTE:**
+>Currently, only one RTC device is supported in the OS.
+
+DevHandle RtcOpen\(void\);
+
+**Table 2** Description of RtcOpen
+
+
+
Parameter
+
+
Description
+
+
+
void
+
+
NA
+
+
+
Return Value
+
+
Description
+
+
+
handle
+
+
Returns the if the operation is successful.
+
+
+
NULL
+
+
The operation fails.
+
+
+
+
+
+```
+DevHandle handle = NULL;
+
+/* Obtain the RTC device handle. */
+handle = RtcOpen();
+if (handle == NULL) {
+ /* Process the error. */
+}
+```
+
+### Releasing the RTC Device Handle
+
+You can call the following function to release the RTC device handle, thereby releasing resources of the device:
+
+void RtcClose\(DevHandle handle\);
+
+**Table 3** Description of RtcClose
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
+
+
+```
+/* Release the RTC device handle. */
+RtcClose(handle);
+```
+
+### Registering RtcAlarmCallback
+
+After the OS is started, call the following function to register **RtcAlarmCallback**, which will be invoked when an alarm is generated at the specified time:
+
+int32\_t RtcRegisterAlarmCallback\(DevHandle handle, enum RtcAlarmIndex alarmIndex, RtcAlarmCallback cb\);
+
+**Table 4** Description of RtcRegisterAlarmCallback
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
RTC device handle.
+
+
+
alarmIndex
+
+
Alarm index.
+
+
+
cb
+
+
Callback that will be invoked when an alarm is generated at the specified time.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+The following is an example of registering **RtcAlarmCallback** for processing alarm **RTC\_ALARM\_INDEX\_A**:
+
+```
+/* Register an RTC alarm callback. */
+int32_t RtcAlarmACallback(enum RtcAlarmIndex alarmIndex)
+{
+ if (alarmIndex == RTC_ALARM_INDEX_A) {
+ /* Process alarm A. */
+ } else if (alarmIndex == RTC_ALARM_INDEX_B) {
+ /* Process alarm B. */
+ } else {
+ /* Process the error. */
+ }
+ return 0;
+}
+int32_t ret;
+/* Register RtcAlarmCallback for alarm A. */
+ret = RtcRegisterAlarmCallback(handle, RTC_ALARM_INDEX_A, RtcAlarmACallback);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+### Performing RTC-related Operations
+
+- Reading RTC time
+
+Call the following function to read time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond:
+
+int32\_t RtcReadTime\(DevHandle handle, struct RtcTime \*time\);
+
+**Table 5** Description of RtcReadTime
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
time
+
+
Pointer to the time information read from the RTC driver. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+struct RtcTime tm;
+
+/* Read time information from the RTC driver. */
+ret = RtcReadTime(handle, &tm);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Setting RTC time
+
+Call the following function to set the RTC time:
+
+int32\_t RtcWriteTime\(DevHandle handle, struct RtcTime \*time\);
+
+**Table 6** Description of RtcWriteTime
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
time
+
+
Pointer to the time information written into the RTC driver. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+> **NOTE:**
+>The RTC start time is 1970/01/01 Thursday 00:00:00 \(UTC\). The maximum value of **year** must be set based on the requirements specified in the product manual of the in-use component. You do not need to configure the day of the week.
+
+```
+int32_t ret;
+struct RtcTime tm;
+
+/* Set the RTC time to UTC 2020/01/01 00:59:00 .000. */
+tm.year = 2020;
+tm.month = 01;
+tm.day = 01;
+tm.hour= 00;
+tm.minute = 59;
+tm.second = 00;
+tm.millisecond = 0;
+/* Write the RTC time information. */
+ret = RtcWriteTime(handle, &tm);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Reading the RTC alarm time
+
+Call the following function to read the alarm time:
+
+int32\_t RtcReadAlarm\(DevHandle handle, enum RtcAlarmIndex alarmIndex, struct RtcTime \*time\);
+
+**Table 7** Description of RtcReadAlarm
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
alarmIndex
+
+
Alarm index.
+
+
+
time
+
+
Pointer to the RTC alarm time information. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+struct RtcTime alarmTime;
+
+/* Read the RTC alarm time information of alarm RTC_ALARM_INDEX_A. */
+ret = RtcReadAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Setting RTC alarm time
+
+Call the following function to set the RTC alarm time based on the alarm index:
+
+int32\_t RtcWriteAlarm\(DevHandle handle, enum RtcAlarmIndex alarmIndex, struct RtcTime \*time\);
+
+**Table 8** Description of RtcWriteAlarm
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
alarmIndex
+
+
Alarm index.
+
+
+
time
+
+
Pointer to the RTC alarm time information. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+> **NOTE:**
+>The RTC start time is 1970/01/01 Thursday 00:00:00 \(UTC\). The maximum value of **year** must be set based on the requirements specified in the product manual of the in-use component. You do not need to configure the day of the week.
+
+```
+int32_t ret;
+struct RtcTime alarmTime;
+
+/* Set the RTC alarm time to 2020/01/01 00:59:59 .000. */
+alarmTime.year = 2020;
+alarmTime.month = 01;
+alarmTime.day = 01;
+alarmTime.hour = 00;
+alarmTime.minute = 59;
+alarmTime.second = 59;
+alarmTime.millisecond = 0;
+/* Set the alarm time of alarm RTC_ALARM_INDEX_A. */
+ret = RtcWriteAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Enabling or disabling alarm interrupts
+
+Before performing alarm operations, use the following function to enable alarm interrupts, so that **RtcAlarmCallback** will be called when the alarm is not generated upon a timeout:
+
+int32\_t RtcAlarmInterruptEnable\(DevHandle handle, enum RtcAlarmIndex alarmIndex, uint8\_t enable\);
+
+**Table 9** Description of RtcAlarmInterruptEnable
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
alarmIndex
+
+
Alarm index.
+
+
+
enable
+
+
Whether to enable RTC alarm interrupts. The value 1 means to enable alarm interrupts and 0 means to disable alarm interrupts.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+
+/* Enable the RTC alarm interrupts. */
+ret = RtcAlarmInterruptEnable(handle, RTC_ALARM_INDEX_A, 1);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Reading RTC external frequency
+
+Call the following function to read the frequency of the external crystal oscillator connected to the RTC driver:
+
+int32\_t RtcGetFreq\(DevHandle handle, uint32\_t \*freq\);
+
+**Table 10** Description of RtcGetFreq
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
freq
+
+
Pointer to the frequency to set for the external crystal oscillator, in Hz.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+uint32_t freq = 0;
+
+/* Read frequency of the external crystal oscillator connected to the RTC driver */
+ret = RtcGetFreq(handle, &freq);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Setting the frequency of the external crystal oscillator connected to the RTC driver
+
+Call the following function to set the frequency of the external crystal oscillator connected to the RTC driver:
+
+int32\_t RtcSetFreq\(DevHandle handle, uint32\_t freq\);
+
+**Table 11** Description of RtcSetFreq
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
freq
+
+
Frequency to set for the external crystal oscillator, in Hz
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+uint32_t freq = 32768; /* 32768 Hz */
+
+/* Set the frequency of the external crystal oscillator. Note that the frequency must be configured in accordance with the requirements specified in the product manual of the in-use component. */
+ret = RtcSetFreq(handle, freq);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Resetting the RTC driver
+
+Call the following function to perform a reset on the RTC driver \(after the reset, the registers are restored to the default values\):
+
+int32\_t RtcReset\(DevHandle handle\);
+
+**Table 12** Description of RtcReset
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+
+/* Reset the RTC driver. After the reset, the configuration registers are restored to the default values. */
+ret = RtcReset(handle);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Reading the configuration of a custom RTC register
+
+Call the following function to read the configuration of a custom RTC register based on the register index \(one index corresponds to one byte of the configuration value\):
+
+int32\_t RtcReadReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t \*value\);
+
+**Table 13** Description of RtcReadReg
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
usrDefIndex
+
+
Index of the custom register
+
+
+
value
+
+
Pointer to the register value
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t usrDefIndex = 0; /* Define index 0 for the first custom register. */
+uint8_t value = 0;
+
+/* Read the configuration of a custom RTC register based on the register index. One index corresponds to one byte of the configuration value. */
+ret = RtcReadReg(handle, usrDefIndex, &value);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+- Setting the configuration of a custom RTC register
+
+Call the following function to configure a register based on the specified register index \(one index corresponds to one byte of the configuration value\):
+
+int32\_t RtcWriteReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t value\);
+
+**Table 14** Description of RtcWriteReg
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
RTC device handle.
+
+
+
usrDefIndex
+
+
Index of the custom register
+
+
+
value
+
+
Register value
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The operation is successful.
+
+
+
Negative value
+
+
The operation fails.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t usrDefIndex = 0; /* Define index 0 for the first custom register. */
+uint8_t value = 0x10;
+
+/* Configure a register based on the specified register index. One index corresponds to one byte of the configuration value. */
+ret = RtcWriteReg(handle, usrDefIndex, value);
+if (ret != 0) {
+ /* Process the error. */
+}
+```
+
+## Usage Example
+
+This section describes the process of using RTC APIs:
+
+1. During the OS startup, the HDF identifies the RTC component in the system.
+2. The HDF initializes and creates the RTC device.
+3. You can perform operations on the RTC device by calling different APIs.
+4. Call the **RtcClose** function to release the device handle and device resources.
+
+Example:
+
+```
+#include "rtc_if.h"
+int32_t RtcAlarmACallback(enum RtcAlarmIndex alarmIndex)
+{
+ if (alarmIndex == RTC_ALARM_INDEX_A) {
+ /* Process alarm A. */
+ printf("RTC Alarm A callback function\n\r");
+ } else if (alarmIndex == RTC_ALARM_INDEX_B) {
+ /* Process alarm B. */
+ printf("RTC Alarm B callback function\n\r");
+ } else {
+ /* Process the error. */
+ }
+ return 0;
+}
+
+void RtcTestSample(void)
+{
+ int32_t ret;
+ struct RtcTime tm;
+ struct RtcTime alarmTime;
+ uint32_t freq;
+ DevHandle handle = NULL;
+
+ /* Obtain the RTC device handle. */
+ handle = RtcOpen();
+ if (handle == NULL) {
+ /* Process the error. */
+ }
+ /* Register RtcAlarmCallback for alarm A. */
+ ret = RtcRegisterAlarmCallback(handle, RTC_ALARM_INDEX_A, RtcAlarmACallback);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ /* Set the RTC external crystal frequency. Note that the frequency must be configured in accordance with the requirements specified in the product manual of the in-use component. */
+ freq = 32768; /* 32768 Hz */
+ ret = RtcSetFreq(handle, freq);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ /* Enable the RTC alarm interrupts. */
+ ret = RtcAlarmInterruptEnable(handle, RTC_ALARM_INDEX_A, 1);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ /* Set the RTC time to 2020/01/01 00:00:10 .990. */
+ tm.year = 2020;
+ tm.month = 01;
+ tm.day = 01;
+ tm.hour= 0;
+ tm.minute = 0;
+ tm.second = 10;
+ tm.millisecond = 990;
+ /* Write the RTC time information. */
+ ret = RtcWriteTime(handle, &tm);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ /* Set the RTC alarm time to 2020/01/01 00:00:30 .100. */
+ alarmTime.year = 2020;
+ alarmTime.month = 01;
+ alarmTime.day = 01;
+ alarmTime.hour = 0;
+ alarmTime.minute = 0;
+ alarmTime.second = 30;
+ alarmTime.millisecond = 100;
+ /* Set the alarm time information for RTC_ALARM_INDEX_A. When the specified time is reached, "RTC Alarm A callback function" is printed. */
+ ret = RtcWriteAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+
+ /* Read the RTC real time. */
+ ret = RtcReadTime(handle, &tm);
+ if (ret != 0) {
+ /* Process the error. */
+ }
+ sleep(5)
+ printf("RTC read time:\n\r");
+ printf("year-month-date-weekday hour:minute:second .millisecond %04u-%02u-%02u-%u %02u:%02u:%02u .%03u",
+ tm.year, tm.month, tm.day, tm.weekday, tm.hour, tm.minute, tm.second, tm.millisecond);
+ /* Release the RTC device handle. */
+ RtcClose(handle);
+}
+```
+
diff --git a/en/device-dev/driver/drive-platform-sdio-des.md b/en/device-dev/driver/drive-platform-sdio-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..4b5a27d35334ab5e75cbf0ea3cddffd9fd9341d3
--- /dev/null
+++ b/en/device-dev/driver/drive-platform-sdio-des.md
@@ -0,0 +1,1068 @@
+# SDIO
+
+- [Overview](#section1155271783811)
+ - [Available APIs](#section08064247248)
+
+- [Usage Guidelines](#section1878939192515)
+ - [How to Use](#section1490685512255)
+ - [Opening an SDIO Controller](#section10782428132616)
+ - [Claiming a Host Exclusively](#section11263172312715)
+ - [Enabling the SDIO Device](#section17861486271)
+ - [Claiming an SDIO IRQ](#section521213262286)
+ - [Performing SDIO Communication](#section85661522153420)
+ - [Releasing the SDIO IRQ](#section1683449352)
+ - [Disabling the SDIO Device](#section15379324143611)
+ - [Releasing the Exclusively Claimed Host](#section536018263713)
+ - [Closing an SDIO Controller](#section4752739183716)
+
+- [Usage Example](#section376910122382)
+
+## Overview
+
+- Secure Digital Input/Output \(SDIO\) is a peripheral interface evolved from the Secure Digital \(SD\) memory card interface. The SDIO interface is compatible with SD memory cards and can be connected to devices that support the SDIO interface.
+- SDIO is widely used. Currently, many smartphones support SDIO, and many SDIO peripherals are developed for connections to smartphones. Common SDIO peripherals include WLAN, GPS, cameras, and Bluetooth.
+- The SDIO bus has two ends, named host and device. All communication starts when the host sends a command. The device can communicate with the host as long as it can parse the command of the host. An SDIO host can connect to multiple devices, as shown in the figure below.
+
+ - CLK signal: clock signal sent from the host to the device
+ - VDD signal: power signal
+ - VSS signal: ground signal
+ - D0-3 signal: four data lines. The DAT1 signal cable is multiplexed as the interrupt line. In 1-bit mode, DAT0 is used to transmit data. In 4-bit mode, DAT0 to DAT3 are used to transmit data.
+ - CMD signal: used by the host to send commands and the device to respond to commands.
+
+ **Figure 1** Connections between the host and devices in SDIO
+
+
+ 
+
+- The SDIO interface defines a set of common methods for operating an SDIO device, including opening and closing an SDIO controller, exclusively claiming and releasing the host, enabling and disabling devices, claiming and releasing an SDIO IRQ, reading and writing data based on SDIO, and obtaining and setting common information.
+
+### Available APIs
+
+**Table 1** APIs available for the SDIO driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
SDIO device opening/closing
+
+
SdioOpen
+
+
Opens an SDIO controller with a specified bus number.
+
+
+
SdioClose
+
+
Closes an SDIO controller.
+
+
+
SDIO reading/writing
+
+
SdioReadBytes
+
+
Incrementally reads a given length of data from a specified SDIO address.
+
+
+
SdioWriteBytes
+
+
Incrementally writes a given length of data into a specified SDIO address.
+
+
+
SdioReadBytesFromFixedAddr
+
+
Reads a given length of data from a fixed SDIO address.
+
+
+
SdioWriteBytesToFixedAddr
+
+
Writes a given length of data into a fixed SDIO address.
+
+
+
SdioReadBytesFromFunc0
+
+
Reads a given length of data from the address space of SDIO function 0.
+
+
+
SdioWriteBytesToFunc0
+
+
Writes a given length of data into the address space of SDIO function 0.
+
+
+
SDIO block size setting
+
+
SdioSetBlockSize
+
+
Sets the block size.
+
+
+
SDIO common information retrieval/setting
+
+
SdioGetCommonInfo
+
+
Obtains common information.
+
+
+
SdioSetCommonInfo
+
+
Sets common information.
+
+
+
SDIO data flushing
+
+
SdioFlushData
+
+
Flushes data.
+
+
+
SDIO host exclusively claiming or releasing
+
+
SdioClaimHost
+
+
Claims a host exclusively.
+
+
+
SdioReleaseHost
+
+
Releases the exclusively claimed host.
+
+
+
SDIO device enablement
+
+
SdioEnableFunc
+
+
Enables an SDIO device.
+
+
+
SdioDisableFunc
+
+
Disables an SDIO device.
+
+
+
SDIO IRQ claiming/releasing
+
+
SdioClaimIrq
+
+
Claims an SDIO IRQ.
+
+
+
SdioReleaseIrq
+
+
Releases an SDIO IRQ.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 2](#fig1343742311264) illustrates the process of using an SDIO.
+
+**Figure 2** Process of using an SDIO
+
+
+
+
+### Opening an SDIO Controller
+
+Before performing SDIO communication, obtain the device handle of an SDIO controller by calling **SdioOpen**. This function returns the device handle of the SDIO controller with a specified bus number.
+
+DevHandle SdioOpen\(int16\_t mmcBusNum, struct SdioFunctionConfig \*config\);
+
+**Table 2** Parameters and return values of SdioOpen
+
+
+
Parameter
+
+
Description
+
+
+
+
mmcBusNum
+
+
Bus number.
+
+
+
config
+
+
SDIO functionality configurations.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to obtain the device handle of an SDIO controller.
+
+
+
Device handle
+
+
Device handle of an SDIO controller.
+
+
+
+
+
+The following example shows how to open an SDIO controller.
+
+```
+DevHandle handle = NULL;
+struct SdioFunctionConfig config;
+config.funcNr = 1;
+config.vendorId = 0x123;
+config.deviceId = 0x456;
+/* Open an SDIO controller whose bus number is 1. */
+handle = SdioOpen(1, &config);
+if (handle == NULL) {
+ HDF_LOGE("SdioOpen: failed!\n");
+}
+```
+
+### Claiming a Host Exclusively
+
+After obtaining the device handle of an SDIO controller, exclusively claim the host before performing subsequent operations on the SDIO device.
+
+void SdioClaimHost\(DevHandle handle\);
+
+**Table 3** Parameter description of SdioClaimHost
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
+
+
+The following example shows how to exclusively claim a host.
+
+```
+SdioClaimHost(handle); /* Claim a host exclusively. */
+```
+
+### Enabling the SDIO Device
+
+Before accessing a register, enable the SDIO device.
+
+int32\_t SdioEnableFunc\(DevHandle handle\);
+
+**Table 4** Parameters and return values of SdioEnableFunc
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The SDIO device is enabled.
+
+
+
Negative value
+
+
Failed to enable the SDIO device.
+
+
+
+
+
+The following example shows how to enable the SDIO device.
+
+```
+int32_t ret;
+/* Enable the SDIO device. */
+ret = SdioEnableFunc(handle);
+if (ret != 0) {
+ HDF_LOGE("SdioEnableFunc: failed, ret %d\n", ret);
+}
+```
+
+### Claiming an SDIO IRQ
+
+Before SDIO communication, claim an SDIO IRQ.
+
+int32\_t SdioClaimIrq\(DevHandle handle, SdioIrqHandler \*handler\);
+
+**Table 5** Parameters and return values of SdioClaimIrq
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
handler
+
+
Pointer to the SDIO IRQ function.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The SDIO IRQ is claimed.
+
+
+
Negative value
+
+
Failed to claim an SDIO IRQ.
+
+
+
+
+
+The following example shows how to claim an SDIO IRQ.
+
+```
+/* Implement the SDIO IRQ function based on the application. */
+static void SdioIrqFunc(void *data)
+{
+ if (data == NULL) {
+ HDF_LOGE("SdioIrqFunc: data is NULL.\n");
+ return;
+ }
+ /* You need to add specific implementations. */
+}
+
+int32_t ret;
+/* Claim an SDIO IRQ. */
+ret = SdioClaimIrq(handle, SdioIrqFunc);
+if (ret != 0) {
+ HDF_LOGE("SdioClaimIrq: failed, ret %d\n", ret);
+}
+```
+
+### Performing SDIO Communication
+
+- Incrementally write a given length of data into the SDIO device.
+
+The corresponding function is as follows:
+
+int32\_t SdioWriteBytes\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
+
+**Table 6** Parameters and return values of SdioWriteBytes
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to write.
+
+
+
addr
+
+
Start address where the data is written into.
+
+
+
size
+
+
Length of the data to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is written into the SDIO device.
+
+
+
Negative value
+
+
Failed to write data into the SDIO device.
+
+
+
+
+
+The following example shows how to incrementally write a given length of data into the SDIO device.
+
+```
+int32_t ret;
+uint8_t wbuff[] = {1,2,3,4,5};
+uint32_t addr = 0x100 + 0x09;
+/* Incrementally write 5-byte data into the start address 0x109 of the SDIO device. */
+ret = SdioWriteBytes(handle, wbuff, addr, sizeof(wbuff) / sizeof(wbuff[0]));
+if (ret != 0) {
+ HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
+}
+```
+
+- Incrementally read a given length of data from the SDIO device.
+
+The corresponding function is as follows:
+
+int32\_t SdioReadBytes\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
+
+**Table 7** Parameters and return values of SdioReadBytes
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to read.
+
+
+
addr
+
+
Start address where the data is read from.
+
+
+
size
+
+
Length of the data to read.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is read from the SDIO device.
+
+
+
Negative value
+
+
Failed to read data from the SDIO device.
+
+
+
+
+
+The following example shows how to incrementally read a given length of data from the SDIO device.
+
+```
+int32_t ret;
+uint8_t rbuff[5] = {0};
+uint32_t addr = 0x100 + 0x09;
+/* Incrementally read 5-byte data from the start address 0x109 of the SDIO device. */
+ret = SdioReadBytes(handle, rbuff, addr, 5);
+if (ret != 0) {
+ HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
+}
+```
+
+- Write a given length of data into the fixed address of an SDIO device.
+
+ The corresponding function is as follows:
+
+ int32\_t SdioWriteBytesToFixedAddr\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size, uint32\_t scatterLen\);
+
+ **Table 8** Parameters and return values of SdioWriteBytesToFixedAddr
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to write.
+
+
+
addr
+
+
Fixed address where the data is written into.
+
+
+
size
+
+
Length of the data to write.
+
+
+
scatterLen
+
+
Length of the scatter list. If the value is not 0, the data is of the scatter list type.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is written into the SDIO device.
+
+
+
Negative value
+
+
Failed to write data into the SDIO device.
+
+
+
+
+
+ The following example shows how to write a given length of data into the fixed address of an SDIO device.
+
+ ```
+ int32_t ret;
+ uint8_t wbuff[] = {1, 2, 3, 4, 5};
+ uint32_t addr = 0x100 + 0x09;
+ /* Write 5-byte data into the fixed address 0x109 of the SDIO device. */
+ ret = SdioWriteBytesToFixedAddr(handle, wbuff, addr, sizeof(wbuff) / sizeof(wbuff[0]), 0);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytesToFixedAddr: failed, ret %d\n", ret);
+ }
+ ```
+
+- Read a given length of data from the fixed address of an SDIO device.
+
+ The corresponding function is as follows:
+
+ int32\_t SdioReadBytesFromFixedAddr\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size, uint32\_t scatterLen\);
+
+ **Table 9** Parameters and return values of SdioReadBytesFromFixedAddr
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to read.
+
+
+
addr
+
+
Start address where the data is read from.
+
+
+
size
+
+
Length of the data to read.
+
+
+
scatterLen
+
+
Length of the scatter list. If the value is not 0, the data is of the scatter list type.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is read from the SDIO device.
+
+
+
Negative value
+
+
Failed to read data from the SDIO device.
+
+
+
+
+
+ The following example shows how to read a given length of data from the fixed address of an SDIO device.
+
+ ```
+ int32_t ret;
+ uint8_t rbuff[5] = {0};
+ uint32_t addr = 0x100 + 0x09;
+ /* Read 5-byte data from the fixed address 0x109 of the SDIO device. */
+ ret = SdioReadBytesFromFixedAddr(handle, rbuff, addr, 5, 0);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytesFromFixedAddr: failed, ret %d\n", ret);
+ }
+ ```
+
+
+- Writes a given length of data into the address space of SDIO function 0.
+
+Currently, only 1-byte data can be written. The corresponding function is as follows:
+
+int32\_t SdioWriteBytesToFunc0\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
+
+**Table 10** Parameters and return values of SdioWriteBytesToFunc0
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to write.
+
+
+
addr
+
+
Start address where the data is written into.
+
+
+
size
+
+
Length of the data to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is written into the SDIO device.
+
+
+
Negative value
+
+
Failed to write data into the SDIO device.
+
+
+
+
+
+The following example shows how to write a given length of data into the address space of SDIO function 0.
+
+```
+int32_t ret;
+uint8_t wbuff = 1;
+/* Write 1-byte data into the address 0x2 of SDIO function 0. */
+ret = SdioWriteBytesToFunc0(handle, &wbuff, 0x2, 1);
+if (ret != 0) {
+ HDF_LOGE("SdioWriteBytesToFunc0: failed, ret %d\n", ret);
+}
+```
+
+- Reads a given length of data from the address space of SDIO function 0.
+
+Currently, only 1-byte data can be read. The corresponding function is as follows:
+
+int32\_t SdioReadBytesFromFunc0\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
+
+**Table 11** Parameters and return values of SdioReadBytesFromFunc0
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
data
+
+
Pointer to the data to read.
+
+
+
addr
+
+
Start address where the data is read from.
+
+
+
size
+
+
Length of the data to read.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Data is read from the SDIO device.
+
+
+
Negative value
+
+
Failed to read data from the SDIO device.
+
+
+
+
+
+The following example shows how to read a given length of data from the address space of SDIO function 0.
+
+```
+int32_t ret;
+uint8_t rbuff;
+/* Read 1-byte data from the address 0x2 of SDIO function 0. */
+ret = SdioReadBytesFromFunc0(handle, &rbuff, 0x2, 1);
+if (ret != 0) {
+ HDF_LOGE("SdioReadBytesFromFunc0: failed, ret %d\n", ret);
+}
+```
+
+### Releasing the SDIO IRQ
+
+After the SDIO communication, release the SDIO IRQ.
+
+int32\_t SdioReleaseIrq\(DevHandle handle\);
+
+**Table 12** Parameters and return values of SdioReleaseIrq
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The SDIO IRQ is released.
+
+
+
Negative value
+
+
Failed to release the SDIO IRQ.
+
+
+
+
+
+The following example shows how to release the SDIO IRQ.
+
+```
+int32_t ret;
+/* Release the SDIO IRQ. */
+ret = SdioReleaseIrq(handle);
+if (ret != 0) {
+ HDF_LOGE("SdioReleaseIrq: failed, ret %d\n", ret);
+}
+```
+
+### Disabling the SDIO Device
+
+After the SDIO communication, disable the SDIO device.
+
+int32\_t SdioDisableFunc\(DevHandle handle\);
+
+**Table 13** Parameters and return values of SdioDisableFunc
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
The SDIO device is disabled.
+
+
+
Negative value
+
+
Failed to disable the SDIO device.
+
+
+
+
+
+The following example shows how to disable the SDIO device.
+
+```
+int32_t ret;
+/* Disable the SDIO device. */
+ret = SdioDisableFunc(handle);
+if (ret != 0) {
+ HDF_LOGE("SdioDisableFunc: failed, ret %d\n", ret);
+}
+```
+
+### Releasing the Exclusively Claimed Host
+
+After the SDIO communication, release the exclusively claimed host.
+
+void SdioReleaseHost\(DevHandle handle\);
+
+**Table 14** Parameter description of SdioReleaseHost
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
+
+
+The following example shows how to release the exclusively claimed host.
+
+```
+SdioReleaseHost(handle); /* Release the exclusively claimed host. */
+```
+
+### Closing an SDIO Controller
+
+After the SDIO communication, close the SDIO controller.
+
+void SdioClose\(DevHandle handle\);
+
+This function releases the resources requested.
+
+**Table 15** Parameter description of SdioClose
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Device handle of an SDIO controller.
+
+
+
+
+
+The following example shows how to close an SDIO controller.
+
+```
+SdioClose(handle); /* Close an SDIO controller. */
+```
+
+## Usage Example
+
+The following example shows how to use an SDIO device. First, open an SDIO controller whose bus number is 1, exclusively claim a host, enable the SDIO device, claim an SDIO IRQ, and then perform SDIO communication \(such as reading and writing\). After the SDIO communication, release the SDIO IRQ, disable the SDIO device, release the host, and close the SDIO controller.
+
+```
+#include "hdf_log.h"
+#include "sdio_if.h"
+
+#define TEST_FUNC_NUM 1 /* The I/O function whose ID is 1 is used. */
+#define TEST_FBR_BASE_ADDR 0x100 /* FBR base address of the I/O function whose ID is 1 */
+#define TEST_ADDR_OFFSET 9 /* Address offset of the register to read or write */
+#define TEST_DATA_LEN 3 /* Length of the data to read or write */
+#define TEST_BLOCKSIZE 2 /* Size of a data block, in bytes */
+
+/* Implement the SDIO IRQ function based on the application. */
+static void SdioIrqFunc(void *data)
+{
+ if (data == NULL) {
+ HDF_LOGE("SdioIrqFunc: data is NULL.\n");
+ return;
+ }
+ /* You need to add specific implementations. */
+}
+
+void SdioTestSample(void)
+{
+ int32_t ret;
+ DevHandle handle = NULL;
+ uint8_t data[TEST_DATA_LEN] = {0};
+ struct SdioFunctionConfig config = {1, 0x123, 0x456};
+ uint8_t val;
+ uint32_t addr;
+
+ /* Open an SDIO controller whose bus number is 1. */
+ handle = SdioOpen(1, &config);
+ if (handle == NULL) {
+ HDF_LOGE("SdioOpen: failed!\n");
+ return;
+ }
+ /* Claim a host exclusively. */
+ SdioClaimHost(handle);
+ /* Enable the SDIO device. */
+ ret = SdioEnableFunc(handle);
+ if (ret != 0) {
+ HDF_LOGE("SdioEnableFunc: failed, ret %d\n", ret);
+ goto ENABLE_ERR;
+ }
+ /* Claim an SDIO IRQ. */
+ ret = SdioClaimIrq(handle, SdioIrqFunc);
+ if (ret != 0) {
+ HDF_LOGE("SdioClaimIrq: failed, ret %d\n", ret);
+ goto CLAIM_IRQ_ERR;
+ }
+ /* Set the block size to 2 bytes. */
+ ret = SdioSetBlockSize(handle, TEST_BLOCKSIZE);
+ if (ret != 0) {
+ HDF_LOGE("SdioSetBlockSize: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Read 3-byte data from the incremental address of an SDIO device. */
+ addr = TEST_FBR_BASE_ADDR * TEST_FUNC_NUM + TEST_ADDR_OFFSET;
+ ret = SdioReadBytes(handle, data, addr, TEST_DATA_LEN);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Write 3-byte data into the incremental address of an SDIO device. */
+ ret = SdioWriteBytes(handle, data, addr, TEST_DATA_LEN);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Read 1-byte data from the SDIO device. */
+ ret = SdioReadBytes(handle, &val, addr, 1);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Write 1-byte data into the SDIO device. */
+ ret = SdioWriteBytes(handle, &val, addr, 1);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Read 3-byte data from the fixed address of an SDIO device. */
+ ret = SdioReadBytesFromFixedAddr(handle, data, addr, TEST_DATA_LEN, 0);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytesFromFixedAddr: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Write 1-byte data to the fixed address of an SDIO device. */
+ ret = SdioWriteBytesToFixedAddr(handle, data, addr, 1, 0);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytesToFixedAddr: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Read 1-byte data from SDIO function 0. */
+ addr = 0x02;
+ ret = SdioReadBytesFromFunc0(handle, &val, addr, 1);
+ if (ret != 0) {
+ HDF_LOGE("SdioReadBytesFromFunc0: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+ /* Write 1-byte data into SDIO function 0. */
+ ret = SdioWriteBytesToFunc0(handle, &val, addr, 1);
+ if (ret != 0) {
+ HDF_LOGE("SdioWriteBytesToFunc0: failed, ret %d\n", ret);
+ goto COMM_ERR;
+ }
+COMM_ERR:
+ /* Release the SDIO IRQ. */
+ ret = SdioReleaseIrq(handle);
+ if (ret != 0) {
+ HDF_LOGE("SdioReleaseIrq: failed, ret %d\n", ret);
+ }
+CLAIM_IRQ_ERR:
+ /* Disable the SDIO device. */
+ ret = SdioDisableFunc(handle);
+ if (ret != 0) {
+ HDF_LOGE("SdioDisableFunc: failed, ret %d\n", ret);
+ }
+ENABLE_ERR:
+ /* Release the exclusively claimed host. */
+ SdioReleaseHost(handle);
+ /* Close an SDIO controller. */
+ SdioClose(handle);
+}
+```
+
diff --git a/en/device-dev/driver/drive-platform-spi-des.md b/en/device-dev/driver/drive-platform-spi-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..b2c1b31147091e2d28ff902727f8ec7c1abfef80
--- /dev/null
+++ b/en/device-dev/driver/drive-platform-spi-des.md
@@ -0,0 +1,566 @@
+# SPI
+
+- [Overview](#section193356154511)
+ - [Available APIs](#section232141411476)
+
+- [Usage Guidelines](#section71363452477)
+ - [How to Use](#section32846814820)
+ - [Obtaining an SPI Device Handle](#section1927265711481)
+ - [Obtaining SPI Device Configuration Parameters](#section541133418493)
+ - [Setting SPI Device Configuration Parameters](#section7870106145010)
+ - [Performing SPI Communication](#section13324155195013)
+ - [Destroying the SPI Device Handle](#section19661632135117)
+
+- [Usage Example](#section06541058155120)
+
+## Overview
+
+- Serial Peripheral Interface \(SPI\) is a serial bus specification used for high-speed, full-duplex, and synchronous communication.
+- SPI is developed by Motorola. It is commonly used for communication with flash memory, real-time clocks, sensors, and analog-to-digital \(A/D\) converters.
+- SPI works in controller/device mode. Generally, there is one SPI controller that controls one or more SPI devices. They are connected via four wires:
+ - SCLK: clock signals output from the SPI controller
+ - MOSI: data output from the SPI controller and input into an SPI device
+ - MISO: data output from an SPI device and input into the SPI controller
+ - CS: signals enabled by an SPI device and controlled by the SPI controller
+
+
+- [Figure 1](#fig15227181812587) shows the connection between one SPI controller and two SPI devices \(device A and device B\). In this figure, device A and device B share three pins \(SCLK, MISO, and MOSI\) of the controller. CS0 of device A and CS1 of device B are connected to CS0 and CS1 of the controller, respectively.
+
+**Figure 1** SPI controller/device connection
+
+
+
+
+- SPI communication is usually initiated by the SPI controller and is operated as follows:
+
+1. A single SPI device is selected at a time via the CS to communicate with the SPI controller.
+2. Clock signals are provided for the selected SPI device via the SCLK.
+3. The SPI controller sends data to SPI devices via the MOSI, and receives data from SPI devices via the MISO.
+
+- SPI can work in one of the following four modes, equivalent to one of the four possible states for Clock Polarity \(CPOL\) and Clock Phase \(CPHA\):
+ - If both CPOL and CPHA are **0**, the clock signal level is low in the idle state and data is sampled on the first clock edge.
+ - If CPOL is **0** and CPHA is **1**, the clock signal level is low in the idle state and data is sampled on the second clock edge.
+ - If CPOL is **1** and CPHA is **0**, the clock signal level is high in the idle state and data is sampled on the first clock edge.
+ - If both CPOL and CPHA are **1**, the clock signal level is high in the idle state and data is sampled on the second clock edge.
+
+
+- SPI defines a set of common functions for operating an SPI device, including those for:
+ - Obtaining and releasing the handle of an SPI device.
+ - Reading or writing data of a specified length from or into an SPI device.
+ - Customizing data reading or writing via **SpiMsg**.
+ - Obtaining and setting SPI device configuration parameters.
+
+
+> **NOTE:**
+>Currently, these functions are only applicable in the communication initiated by the SPI controller.
+
+### Available APIs
+
+**Table 1** APIs for the SPI driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
SPI device handle obtaining/releasing
+
+
SpiOpen
+
+
Obtains an SPI device handle.
+
+
+
SpiClose
+
+
Releases an SPI device handle.
+
+
+
SPI reading/writing
+
+
SpiRead
+
+
Reads data of a specified length from an SPI device.
+
+
+
SpiWrite
+
+
Writes data of a specified length into an SPI device.
+
+
+
SpiTransfer
+
+
Transfers SPI data.
+
+
+
SPI device configuration
+
+
+
SpiSetCfg
+
+
Sets configuration parameters for an SPI device.
+
+
+
SpiGetCfg
+
+
Obtains configuration parameters of an SPI device.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel space.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 2](#fig23885455594) shows the process of using an SPI device.
+
+**Figure 2** Process of using an SPI device
+
+
+
+
+### Obtaining an SPI Device Handle
+
+Before performing SPI communication, obtain an SPI device handle by calling **SpiOpen**. This function returns an SPI device handle with a specified bus number and CS number.
+
+DevHandle SpiOpen\(const struct SpiDevInfo \*info\);
+
+**Table 2** Description of **SpiOpen**
+
+
+
Parameter
+
+
Description
+
+
+
info
+
+
Pointer to the SPI device descriptor.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to obtain an SPI device handle.
+
+
+
Device handle
+
+
Returns the pointer to the SPI device handle.
+
+
+
+
+
+The following example shows how to obtain an SPI device handle based on the assumption that both the bus number and CS number of the SPI device are **0**.
+
+```
+struct SpiDevInfo spiDevinfo; /* SPI device descriptor */
+DevHandle spiHandle = NULL; /* SPI device handle */
+spiDevinfo.busNum = 0; /* SPI device bus number */
+spiDevinfo.csNum = 0; /* SPI device CS number */
+
+/* Obtain an SPI device handle. */
+spiHandle = SpiOpen(&spiDevinfo);
+if (spiHandle == NULL) {
+ HDF_LOGE("SpiOpen: failed\n");
+ return;
+}
+```
+
+### Obtaining SPI Device Configuration Parameters
+
+After obtaining the SPI device handle, obtain the SPI device configuration parameters by calling the following function:
+
+int32\_t SpiGetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
+
+**Table 3** Description of **SpiGetCfg**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
cfg
+
+
Pointer to SPI device configuration parameters.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in obtaining SPI device configuration parameters.
+
+
+
Negative value
+
+
Failed to obtain SPI device configuration parameters.
+
+
+
+
+
+```
+int32_t ret;
+struct SpiCfg cfg = {0}; /* SPI configuration information */
+ret = SpiGetCfg(spiHandle, &cfg); /* Set SPI device configuration parameters. */
+if (ret != 0) {
+ HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret);
+}
+```
+
+### Setting SPI Device Configuration Parameters
+
+After obtaining the SPI device handle, set SPI device configuration parameters by calling the following function:
+
+int32\_t SpiSetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
+
+**Table 4** Description of **SpiSetCfg**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
cfg
+
+
Pointer to SPI device configuration parameters.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting SPI device configuration parameters.
+
+
+
Negative value
+
+
Failed to set SPI device configuration parameters.
+
+
+
+
+
+```
+int32_t ret;
+struct SpiCfg cfg = {0}; /* SPI configuration information */
+cfg.mode = SPI_MODE_LOOP; /* Communication in loopback mode */
+cfg.transferMode = PAL_SPI_POLLING_TRANSFER; /* Communication in polling mode */
+cfg.maxSpeedHz = 115200; /* Maximum transmission frequency */
+cfg.bitsPerWord = 8; /* The width of per word to be read or written is 8 bits. */
+ret = SpiSetCfg(spiHandle, &cfg); /* Set SPI device configuration parameters. */
+if (ret != 0) {
+ HDF_LOGE("SpiSetCfg: failed, ret %d\n", ret);
+}
+```
+
+### Performing SPI Communication
+
+- Writing data of a specific length into an SPI device
+
+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**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
buf
+
+
Pointer to the data to write.
+
+
+
len
+
+
Length of the data to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in writing data into an SPI device.
+
+
+
Negative value
+
+
Failed to write data into an SPI device.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t wbuff[4] = {0x12, 0x34, 0x56, 0x78};
+/* Write data of a specific length into an SPI device. */
+ret = SpiWrite(spiHandle, wbuff, 4);
+if (ret != 0) {
+ HDF_LOGE("SpiWrite: failed, ret %d\n", ret);
+}
+```
+
+- Reading data of a specific length from an SPI device
+
+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**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
buf
+
+
Pointer to the data to read.
+
+
+
len
+
+
Length of the data to read.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in reading data from an SPI device.
+
+
+
Negative value
+
+
Failed to read data from an SPI device.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t rbuff[4] = {0};
+/* 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);
+}
+```
+
+- Launching a custom transfer
+
+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**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
msgs
+
+
Pointer to the message array to be transferred.
+
+
+
count
+
+
Number of messages in the message array.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in launching the custom transfer.
+
+
+
Negative value
+
+
Failed to launch the custom transfer.
+
+
+
+
+
+```
+int32_t ret;
+uint8_t wbuff[1] = {0x12};
+uint8_t rbuff[1] = {0};
+struct SpiMsg msg; /* Custom message to be transferred */
+msg.wbuf = wbuff; /* Pointer to the data to write */
+msg.rbuf = rbuff; /* Pointer to the data to read */
+msg.len = 1; /* The length of the data to read or write is 1 bit. */
+msg.csChange = 1; /* Disable the CS before the next transfer. */
+msg.delayUs = 0; /* No delay before the next transfer */
+msg.speed = 115200; /* Speed of this transfer */
+/* Launch a custom transfer. The number of messages to be transferred is 1. */
+ret = SpiTransfer(spiHandle, &msg, 1);
+if (ret != 0) {
+ HDF_LOGE("SpiTransfer: failed, ret %d\n", ret);
+}
+```
+
+### Destroying the SPI Device Handle
+
+After the SPI communication, destroy the SPI device handle by calling the following function:
+
+void SpiClose\(DevHandle handle\);
+
+This function will release the resources previously obtained.
+
+**Table 8** Description of **SpiClose**
+
+
+
Parameter
+
+
Description
+
+
+
handle
+
+
SPI device handle.
+
+
+
+
+
+```
+PalHandleDestroy(spiHandle); /* Destroy the SPI device handle. */
+```
+
+## Usage Example
+
+The following example shows how to obtain an SPI device handle, set the configuration parameters, and then read or write data from or into the SPI device, and finally destroy the SPI device handle.
+
+```
+#include "hdf_log.h"
+#include "spi_if.h"
+
+void SpiTestSample(void)
+{
+ int32_t ret;
+ struct SpiCfg cfg; /* SPI device configuration information */
+ struct SpiDevInfo spiDevinfo; /* SPI device descriptor */
+ DevHandle spiHandle = NULL; /* SPI device handle */
+ struct SpiMsg msg; /* Custom message to be transferred */
+ uint8_t rbuff[4] = { 0 };
+ uint8_t wbuff[4] = { 0x12, 0x34, 0x56, 0x78 };
+ uint8_t wbuff2[4] = { 0xa1, 0xb2, 0xc3, 0xd4 };
+
+ spiDevinfo.busNum = 0; /* SPI device bus number */
+ spiDevinfo.csNum = 0; /* SPI device CS number */
+ spiHandle = SpiOpen(&spiDevinfo); /* Obtain an SPI device handle based on spiDevinfo. */
+ if (spiHandle == NULL) {
+ HDF_LOGE("SpiOpen: failed\n");
+ return;
+ }
+ /* Obtain configuration parameters of an SPI device. */
+ ret = SpiGetCfg(spiHandle, &cfg);
+ if (ret != 0) {
+ HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret);
+ goto err;
+ }
+ cfg.maxSpeedHz = 115200; /* Change the maximum clock frequency to 115200. */
+ cfg.bitsPerWord = 8; /* Change the word width to 8 bits. */
+ /* Set configuration parameters for an SPI device. */
+ ret = SpiSetCfg(spiHandle, &cfg);
+ if (ret != 0) {
+ HDF_LOGE("SpiSetCfg: failed, ret %d\n", ret);
+ goto err;
+ }
+ /* Write specified length of data into an SPI device. */
+ ret = SpiWrite(spiHandle, wbuff, 4);
+ if (ret != 0) {
+ HDF_LOGE("SpiWrite: failed, ret %d\n", ret);
+ goto err;
+ }
+ /* Read data of a specified length from an SPI device. */
+ ret = SpiRead(spiHandle, rbuff, 4);
+ if (ret != 0) {
+ HDF_LOGE("SpiRead: failed, ret %d\n", ret);
+ goto err;
+ }
+ msg.wbuf = wbuff2; /* Pointer to the data to write */
+ msg.rbuf = rbuff; /* Pointer to the data to read */
+ msg.len = 4; /* The length of the data to read or write is 4 bits. */
+ msg.csChange = 1; /* Disable the CS before the next transfer. */
+ msg.delayUs = 0; /* No delay before the next transfer */
+ msg.speed = 115200; /* Speed of this transfer */
+ /* Launch a custom transfer. The number of messages to be transferred is 1. */
+ ret = SpiTransfer(spiHandle, &msg, 1);
+ if (ret != 0) {
+ HDF_LOGE("SpiTransfer: failed, ret %d\n", ret);
+ goto err;
+ }
+err:
+ /* Destroy the SPI device handle. */
+ SpiClose(spiHandle);
+}
+```
+
diff --git a/en/device-dev/driver/drive-platform-uart-des.md b/en/device-dev/driver/drive-platform-uart-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..a789594525e5d6ebb9270dadd540a35e3d76f887
--- /dev/null
+++ b/en/device-dev/driver/drive-platform-uart-des.md
@@ -0,0 +1,682 @@
+# UART
+
+- [Overview](#section833012453535)
+ - [Available APIs](#section1680292311549)
+
+- [Usage Guidelines](#section12779050105412)
+ - [How to Use](#section1858116395510)
+ - [Obtaining a UART Device Handle](#section124512065617)
+ - [Setting the UART Baud Rate](#section86881004579)
+ - [Obtaining the UART Baud Rate](#section897032965712)
+ - [Setting the UART Device Attributes](#section129141884588)
+ - [Obtaining UART Device Attributes](#section18689637165812)
+ - [Setting the UART Transmission Mode](#section72713435918)
+ - [Writing Data of a Specified Length into a UART Device](#section128001736155919)
+ - [Reading Data of a Specified Length from a UART Device](#section92851601604)
+ - [Destroying the UART Device Handle](#section1477410521406)
+
+- [Usage Example](#section35404241311)
+
+## Overview
+
+- The Universal Asynchronous Receiver/Transmitter \(UART\) is a universal serial data bus used for asynchronous communication. It enables bi-directional communication between devices in full-duplex mode.
+- UART is widely used to print information for debugging or to connect to various external modules such as GPS and Bluetooth.
+- A UART is connected to other modules through two wires \(as shown in [Figure 1](#fig209936401896)\) or four wires \(as shown in [Figure 2](#fig1435614171015)\).
+ - TX: TX pin of the transmitting UART. It is connected to the RX pin of the peer UART.
+ - RX: RX pin of the receiving UART. It is connected to the TX pin of the peer UART.
+ - RTS: Request to Send signal pin. It is connected to the CTS pin of the peer UART and is used to indicate whether the local UART is ready to receive data.
+ - CTS: Clear to Send signal pin. It is connected to the RTS pin of the peer UART and is used to indicate whether the local UART is allowed to send data to the peer end.
+
+ **Figure 1** 2-wire UART communication
+
+
+ 
+
+ **Figure 2** 4-wire UART communication
+
+
+ 
+
+
+- The transmitting and receiving UARTs must ensure that they have the same settings on particular attributes such as the baud rate and data format \(start bit, data bit, parity bit, and stop bit\) before they start to communicate. During data transmission, a UART sends data to the peer end over the TX pin and receives data from the peer end over the RX pin. When the size of the buffer used by a UART for storing received data reaches the preset threshold, the RTS signal of the UART changes to **1** \(data cannot be received\), and the peer UART stops sending data to it because its CTS signal does not allow it to send data.
+- The UART interface defines a set of common functions for operating a UART port, including obtaining and releasing device handles, reading and writing data of a specified length, and obtaining and setting the baud rate, as well as the device attributes.
+
+### Available APIs
+
+**Table 1** APIs for the UART driver
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
Obtaining and releasing device handles
+
+
+
UartOpen
+
+
Obtains the UART device handle.
+
+
+
UartClose
+
+
Releases a specified UART device handle.
+
+
+
Reading and writing data
+
+
+
UartRead
+
+
Reads data of a specified length from a UART device.
+
+
+
UartWrite
+
+
Writes data of a specified length into a UART device.
+
+
+
Obtaining and setting the baud rate
+
+
UartGetBaud
+
+
Obtains the UART baud rate.
+
+
+
UartSetBaud
+
+
Sets the UART baud rate.
+
+
+
Obtaining and setting device attributes
+
+
+
UartGetAttribute
+
+
Obtains the UART device attributes.
+
+
+
UartSetAttribute
+
+
Sets the UART device attributes.
+
+
+
Setting the transmission mode
+
+
UartSetTransMode
+
+
Sets the UART transmission mode.
+
+
+
+
+
+> **NOTE:**
+>All functions provided in this document can be called only in kernel space.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 3](#fig1852173020185) shows the process of using a UART device.
+
+**Figure 3** Process of using a UART device
+
+
+
+
+### Obtaining a UART Device Handle
+
+Before performing UART communication, call **UartOpen** to obtain a UART device handle. This function returns the pointer to the UART device handle with a specified port number.
+
+DevHandle UartOpen\(uint32\_t port\);
+
+**Table 2** Description of UartOpen
+
+
+
Parameter
+
+
Description
+
+
+
+
port
+
+
UART port number.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to obtain the UART device handle.
+
+
+
Device handle
+
+
UART device handle.
+
+
+
+
+
+The following example shows how to obtain a UART device handle based on the assumption that the UART port number is **3**:
+
+```
+DevHandle handle = NULL; /* The UART device handle */
+uint32_t port = 3; /* UART port number */
+handle = UartOpen(port);
+if (handle == NULL) {
+ HDF_LOGE("UartOpen: failed!\n");
+ return;
+}
+```
+
+### Setting the UART Baud Rate
+
+After obtaining the UART device handle, set the UART baud rate by calling the following function:
+
+int32\_t UartSetBaud\(DevHandle handle, uint32\_t baudRate\);
+
+**Table 3** Description of UartSetBaud
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
baudRate
+
+
Baud rate of the UART to set.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the UART baud rate.
+
+
+
Negative value
+
+
Failed to set the UART baud rate.
+
+
+
+
+
+The following example shows how to set the UART baud rate to **9600**:
+
+```
+int32_t ret;
+/* Set the UART baud rate to 9600. */
+ret = UartSetBaud(handle, 9600);
+if (ret != 0) {
+ HDF_LOGE("UartSetBaud: failed, ret %d\n", ret);
+}
+```
+
+### Obtaining the UART Baud Rate
+
+After setting the UART baud rate, obtain the current baud rate by calling the following function:
+
+int32\_t UartGetBaud\(DevHandle handle, uint32\_t \*baudRate\);
+
+**Table 4** Description of UartGetBaud
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
baudRate
+
+
Pointer to the UART baud rate.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in obtaining the UART baud rate.
+
+
+
Negative value
+
+
Failed to obtain the UART baud rate.
+
+
+
+
+
+The following example shows how to obtain the UART baud rate:
+
+```
+int32_t ret;
+uint32_t baudRate;
+/* Obtain the UART baud rate. */
+ret = UartGetBaud(handle, &baudRate);
+if (ret != 0) {
+ HDF_LOGE("UartGetBaud: failed, ret %d\n", ret);
+}
+```
+
+### Setting the UART Device Attributes
+
+Before performing UART communication, set the UART device attributes by calling the following function:
+
+int32\_t UartSetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
+
+**Table 5** Description of UartSetAttribute
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
attribute
+
+
Pointer to the UART device attributes to set.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the UART device attributes.
+
+
+
Negative value
+
+
Failed to set the UART device attributes.
+
+
+
+
+
+The following example shows how to set the UART device attributes:
+
+```
+int32_t ret;
+struct UartAttribute attribute;
+attribute.dataBits = UART_ATTR_DATABIT_7; /* Set the number of data bits to 7. */
+attribute.parity = UART_ATTR_PARITY_NONE; /* Set the parity bit to no parity. */
+attribute.stopBits = UART_ATTR_STOPBIT_1; /* Set the stop bit to 1. */
+attribute.rts = UART_ATTR_RTS_DIS; /* Disable the RTS signal. */
+attribute.cts = UART_ATTR_CTS_DIS; /* Disable the CTS signal. */
+attribute.fifoRxEn = UART_ATTR_RX_FIFO_EN; /* Enable RX FIFO. */
+attribute.fifoTxEn = UART_ATTR_TX_FIFO_EN; /* Enable TX FIFO. */
+/* Set the UART device attributes. */
+ret = UartSetAttribute(handle, &attribute);
+if (ret != 0) {
+ HDF_LOGE("UartSetAttribute: failed, ret %d\n", ret);
+}
+```
+
+### Obtaining UART Device Attributes
+
+After setting the UART device attributes, obtain the current device attributes by calling the following function:
+
+int32\_t UartGetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
+
+**Table 6** Description of UartGetAttribute
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
attribute
+
+
Pointer to the UART device attributes.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in obtaining the UART device attributes.
+
+
+
Negative value
+
+
Failed to obtain the UART device attributes.
+
+
+
+
+
+The following example shows how to obtain the UART device attributes:
+
+```
+int32_t ret;
+struct UartAttribute attribute;
+/* Obtain the UART attributes. */
+ret = UartGetAttribute(handle, &attribute);
+if (ret != 0) {
+ HDF_LOGE("UartGetAttribute: failed, ret %d\n", ret);
+}
+```
+
+### Setting the UART Transmission Mode
+
+Before performing UART communication, set the UART transmission mode by calling the following function:
+
+int32\_t UartSetTransMode\(DevHandle handle, enum UartTransMode mode\);
+
+**Table 7** Description of UartSetTransMode
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
mode
+
+
UART transmission mode to set.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in setting the UART transmission mode.
+
+
+
Negative value
+
+
Failed to set the UART transmission mode.
+
+
+
+
+
+The following example shows how to set the transmission mode to **UART\_MODE\_RD\_BLOCK**:
+
+```
+int32_t ret;
+/* Set the UART transmission mode. */
+ret = UartSetTransMode(handle, UART_MODE_RD_BLOCK);
+if (ret != 0) {
+ HDF_LOGE("UartSetTransMode: failed, ret %d\n", ret);
+}
+```
+
+### Writing Data of a Specified Length into a UART Device
+
+To write data into a UART device, call the following function:
+
+int32\_t UartWrite\(DevHandle handle, uint8\_t \*data, uint32\_t size\);
+
+**Table 8** Description of UartWrite
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
data
+
+
Pointer to the data to write.
+
+
+
size
+
+
Length of the data to write.
+
+
+
Return Value
+
+
Description
+
+
+
0
+
+
Succeeded in writing data into the UART device.
+
+
+
Negative value
+
+
Failed to write data into the UART device.
+
+
+
+
+
+The following example shows how to write data of a specified length into the UART device:
+
+```
+int32_t ret;
+uint8_t wbuff[5] = {1, 2, 3, 4, 5};
+/* Write 5-byte data into the UART device. */
+ret = UartWrite(handle, wbuff, 5);
+if (ret != 0) {
+ HDF_LOGE("UartWrite: failed, ret %d\n", ret);
+}
+```
+
+### Reading Data of a Specified Length from a UART Device
+
+To write data into a UART device, call the following function:
+
+int32\_t UartRead\(DevHandle handle, uint8\_t \*data, uint32\_t size\);
+
+**Table 9** Description of UartRead
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
data
+
+
Pointer to the buffer for receiving the data.
+
+
+
size
+
+
Length of the data to read.
+
+
+
Return Value
+
+
Description
+
+
+
Non-negative value
+
+
Length of the data read from the UART device.
+
+
+
Negative value
+
+
Failed to read data from the UART device.
+
+
+
+
+
+The following example shows how to read data of a specified length from the UART device:
+
+```
+int32_t ret;
+uint8_t rbuff[5] = {0};
+/* Read 5-byte data from the UART device. */
+ret = UartRead(handle, rbuff, 5);
+if (ret < 0) {
+ HDF_LOGE("UartRead: failed, ret %d\n", ret);
+}
+```
+
+> **CAUTION:**
+>Data is successfully read from the UART device if a non-negative value is returned. If the return value is **0**, no valid data can be read from the UART device. If the return value is greater than **0**, the return value is the length of the data actually read from the UART device. The length is less than or equal to the value of **size** and does not exceed the maximum length of data to read at a time specified by the UART controller in use.
+
+### Destroying the UART Device Handle
+
+After the UART communication, destroy the UART device handle by calling the following function:
+
+void UartClose\(DevHandle handle\);
+
+This function will release the resources previously obtained.
+
+**Table 10** Description of UartClose
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
UART device handle.
+
+
+
+
+
+The following example shows how to destroy the UART device handle:
+
+```
+UartClose(handle); /* Destroy the UART device handle. */
+```
+
+## Usage Example
+
+The following is a usage example of a UART device, including how to obtain the UART device handle, set the baud rate, device attributes, and transmission mode, read data from or write data into the UART device, and then destroy the UART device handle.
+
+```
+#include "hdf_log.h"
+#include "uart_if.h"
+
+void UartTestSample(void)
+{
+ int32_t ret;
+ uint32_t port;
+ DevHandle handle = NULL;
+ uint8_t wbuff[5] = { 1, 2, 3, 4, 5 };
+ uint8_t rbuff[5] = { 0 };
+ struct UartAttribute attribute;
+ attribute.dataBits = UART_ATTR_DATABIT_7; /* Set the number of data bits to 7. */
+ attribute.parity = UART_ATTR_PARITY_NONE; /* Set the parity bit to no parity. */
+ attribute.stopBits = UART_ATTR_STOPBIT_1; /* Set the stop bit to 1. */
+ attribute.rts = UART_ATTR_RTS_DIS; /* Disable the RTS signal. */
+ attribute.cts = UART_ATTR_CTS_DIS; /* Disable the CTS signal. */
+ attribute.fifoRxEn = UART_ATTR_RX_FIFO_EN; /* Enable RX FIFO. */
+ attribute.fifoTxEn = UART_ATTR_TX_FIFO_EN; /* Enable TX FIFO. */
+ /* Set the UART port number actually used. */
+ port = 1;
+ /* Obtain the UART device handle. */
+ handle = UartOpen(port);
+ if (handle == NULL) {
+ HDF_LOGE("UartOpen: failed!\n");
+ return;
+ }
+ /* Set the UART baud rate to 9600. */
+ ret = UartSetBaud(handle, 9600);
+ if (ret != 0) {
+ HDF_LOGE("UartSetBaud: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+ /* Set the UART device attributes. */
+ ret = UartSetAttribute(handle, &attribute);
+ if (ret != 0) {
+ HDF_LOGE("UartSetAttribute: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+ /* Set the UART transmission mode to non-blocking mode. */
+ ret = UartSetTransMode(handle, UART_MODE_RD_NONBLOCK);
+ if (ret != 0) {
+ HDF_LOGE("UartSetTransMode: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+ /* Write 5-byte data into the UART device. */
+ ret = UartWrite(handle, wbuff, 5);
+ if (ret != 0) {
+ HDF_LOGE("UartWrite: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+ /* Read 5-byte data from the UART device. */
+ ret = UartRead(handle, rbuff, 5);
+ if (ret < 0) {
+ HDF_LOGE("UartRead: failed, ret %d\n", ret);
+ goto _ERR;
+ }
+_ERR:
+ /* Destroy the UART device handle. */
+ UartClose(handle);
+}
+```
+
diff --git a/en/device-dev/driver/drive-platform-watchdog-des.md b/en/device-dev/driver/drive-platform-watchdog-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..ddaddc1abe08efca457b46b26db353dc0df06f2e
--- /dev/null
+++ b/en/device-dev/driver/drive-platform-watchdog-des.md
@@ -0,0 +1,557 @@
+# Watchdog
+
+- [Overview](#section14918241977)
+ - [Available APIs](#section20177131219818)
+
+- [Usage Guidelines](#section10103184312813)
+ - [How to Use](#section10181195910815)
+ - [Opening a Watchdog](#section66089201107)
+ - [Obtaining the Watchdog Status](#section786624341011)
+ - [Setting the Timeout Duration](#section182386137111)
+ - [Obtaining the Timeout Duration](#section1883310371114)
+ - [Starting a Watchdog](#section82501405123)
+ - [Feeding a Watchdog](#section3547530101211)
+ - [Stopping a Watchdog](#section944595841217)
+ - [Closing a Watchdog](#section96561824121311)
+
+- [Usage Example](#section1724514523135)
+
+## Overview
+
+A watchdog, also called a watchdog timer, is a hardware timing device. If an error occurs in the main program of the system and fails to reset the watchdog timer, the watchdog timer sends a reset signal to restore the system to a normal state.
+
+### Available APIs
+
+**Table 1** Watchdog APIs
+
+
+
Capability
+
+
Function
+
+
Description
+
+
+
+
Open/Close
+
+
WatchdogOpen
+
+
Opens a watchdog.
+
+
+
WatchdogClose
+
+
Closes a watchdog.
+
+
+
Start/Stop
+
+
WatchdogStart
+
+
Starts a watchdog.
+
+
+
WatchdogStop
+
+
Stops a watchdog.
+
+
+
Timeout duration
+
+
WatchdogSetTimeout
+
+
Sets the watchdog timeout duration.
+
+
+
WatchdogGetTimeout
+
+
Obtains the watchdog timeout duration.
+
+
+
Status
+
+
WatchdogGetStatus
+
+
Obtains the watchdog status.
+
+
+
Feeding
+
+
WatchdogFeed
+
+
Feeds a watchdog, or resets a watchdog timer.
+
+
+
+
+
+> **NOTE:**
+>All watchdog functions provided in this document can be called only in kernel mode.
+
+## Usage Guidelines
+
+### How to Use
+
+[Figure 1](#fig19134125410189) illustrates the process of using a watchdog.
+
+**Figure 1** Process of using a watchdog
+
+
+
+
+### Opening a Watchdog
+
+Use **WatchdogOpen** to open a watchdog. A system may have multiple watchdogs. You can open the specified watchdog by using the ID.
+
+int32\_t WatchdogOpen\(int16\_t wdtId\);
+
+**Table 2** Description of WatchdogOpen
+
+
+
Parameter
+
+
Description
+
+
+
+
wdtId
+
+
Watchdog ID.
+
+
+
Return Value
+
+
Description
+
+
+
NULL
+
+
Failed to open the watchdog.
+
+
+
DevHandle pointer
+
+
Pointer to the watchdog handle.
+
+
+
+
+
+```
+DevHandle handle = NULL;
+handle = WatchdogOpen(0); /* Open watchdog 0.*/
+if (handle == NULL) {
+ HDF_LOGE("WatchdogOpen: failed, ret %d\n", ret);
+ return;
+}
+```
+
+### Obtaining the Watchdog Status
+
+int32\_t WatchdogGetStatus\(DevHandle handle, int32\_t \*status\);
+
+**Table 3** Description of WatchdogGetStatus
+
+
+
+
+```
+int32_t ret;
+/* Stop the watchdog. */
+ret = WatchdogStop(handle);
+if (ret != 0) {
+ HDF_LOGE("WatchdogStop: failed, ret %d\n", ret);
+ return;
+}
+```
+
+### Closing a Watchdog
+
+If the watchdog is no longer required, call **WatchdogClose** to close the watchdog handle.
+
+void WatchdogClose\(DevHandle handle\);
+
+**Table 9** Description of WatchdogClose
+
+
+
Parameter
+
+
Description
+
+
+
+
handle
+
+
Watchdog handle.
+
+
+
+
+
+```
+/* Close the watchdog. */
+ret = WatchdogClose(handle);
+```
+
+## Usage Example
+
+This example provides a complete process for using a watchdog.
+
+In this example, open a watchdog, set the timeout duration, and start the watchdog.
+
+- Feed the watchdog periodically to ensure that the system is not reset due to timer expiry.
+- Stop feeding the watchdog and check whether the system is reset after the timer expires.
+
+Example:
+
+```
+#include "watchdog_if.h"
+#include "hdf_log.h"
+#include "osal_irq.h"
+#include "osal_time.h"
+
+#define WATCHDOG_TEST_TIMEOUT 2
+#define WATCHDOG_TEST_FEED_TIME 6
+
+static int32_t TestCaseWatchdog(void)
+{
+ int32_t i;
+ int32_t ret;
+ uint32_t timeout;
+ DevHandle handle = NULL;
+
+ /* Open watchdog 0. */
+ handle = WatchdogOpen(0);
+ if (handle == NULL) {
+ HDF_LOGE("Open watchdog fail!");
+ return -1;
+ }
+
+ /* Set the timeout duration. */
+ ret = WatchdogSetTimeout(handle, WATCHDOG_TEST_TIMEOUT);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: set timeout fail! ret:%d\n", __func__, ret);
+ WatchdogClose(handle);
+ return ret;
+ }
+
+ /* Obtain the configured timeout duration. */
+ ret = WatchdogGetTimeout(handle, &timeout);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: get timeout fail! ret:%d\n", __func__, ret);
+ WatchdogClose(handle);
+ return ret;
+ }
+ HDF_LOGI("%s: read timeout back:%u\n", __func__, timeout);
+
+ /* Start the watchdog. The timer starts. */
+ ret = WatchdogStart(handle);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: satrt fail! ret:%d\n", __func__, ret);
+ WatchdogClose(handle);
+ return ret;
+ }
+
+ /* Feed the watchdog every 1s. */
+ for (i = 0; i < WATCHDOG_TEST_FEED_TIME; i++) {
+ HDF_LOGE("%s: feeding watchdog %d times... \n", __func__, i);
+ ret = WatchdogFeed(handle);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: feed dog fail! ret:%d\n", __func__, ret);
+ WatchdogClose(handle);
+ return ret;
+ }
+ OsalSleep(1);
+ }
+ /* Because the interval for feeding the watchdog is shorter than the timeout duration, the system does not reset, and logs can be printed normally. */
+ HDF_LOGE("%s: no reset ... feeding test OK!!!\n", __func__);
+
+ /* Enable the timer to expire by stopping feeding the watchdog. */
+ for (i = 0; i < WATCHDOG_TEST_FEED_TIME; i++) {
+ HDF_LOGE("%s: watiting dog buck %d times... \n", __func__, i);
+ OsalSleep(1);
+ }
+
+ /* The system resets when the timer expires. If the code is correct, the log below is not displayed. */
+ HDF_LOGE("%s: dog has't buck!!! \n", __func__, i);
+ WatchdogClose(handle);
+ return -1;
+}
+```
+
diff --git a/en/device-dev/driver/drive-platform.md b/en/device-dev/driver/drive-platform.md
new file mode 100644
index 0000000000000000000000000000000000000000..98ac4fa19089971aa64c715e266f690fbcf45182
--- /dev/null
+++ b/en/device-dev/driver/drive-platform.md
@@ -0,0 +1,19 @@
+# Platform Drivers
+
+- **[GPIO](drive-platform-gpio-des.md)**
+
+- **[I2C](drive-platform-i2c-des.md)**
+
+- **[RTC](drive-platform-rtc-des.md)**
+
+- **[SDIO](drive-platform-sdio-des.md)**
+
+- **[SPI](drive-platform-spi-des.md)**
+
+- **[UART](drive-platform-uart-des.md)**
+
+- **[Watchdog](drive-platform-watchdog-des.md)**
+
+- **[MIPI DSI](drive-platform-mipidsi-des.md)**
+
+
diff --git a/en/device-dev/driver/drive.md b/en/device-dev/driver/drive.md
new file mode 100644
index 0000000000000000000000000000000000000000..b448704264a04fdcec3dce1e2d7886831d6e5651
--- /dev/null
+++ b/en/device-dev/driver/drive.md
@@ -0,0 +1,9 @@
+# Driver Usage Guidelines
+
+- **[HDF](drive-hdf.md)**
+
+- **[Platform Drivers](drive-platform.md)**
+
+- **[Peripherals](drive-peripherals.md)**
+
+
diff --git a/en/device-dev/driver/driver-configuration-management.md b/en/device-dev/driver/driver-configuration-management.md
deleted file mode 100644
index ed33878be0b20585b044940e475784685e7e1c6a..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/driver-configuration-management.md
+++ /dev/null
@@ -1,437 +0,0 @@
-# Driver Configuration Management
-
-- [HDF Configuration Overview](#section59914284576)
-- [Configuration Syntax](#section533713333580)
-- [Keywords](#section1316625413586)
-- [Basic Syntax](#section173481622115918)
-- [Data Types](#section96521601302)
-- [Pre-processing](#section8164295515)
-- [Commenting](#section0338205819610)
-- [Modifying a Reference](#section179799204716)
-- [Replicating Node Configuration](#section382424014712)
-- [Deleting a Node or Attribute](#section165211112586)
-- [Referencing an Attribute](#section192841514490)
-- [Keyword Template](#section520134294)
-- [Configuration Generation](#section106152531919)
-- [Introduction to HC-GEN](#section8260625101012)
-
-## HDF Configuration Overview
-
-HCS is the source code that describes the configuration of the HDF using key-value pairs. It decouples the configuration code from driver code, thereby facilitating configuration management.
-
-HDF Configuration Generator \(HC-GEN\) is a tool for converting a configuration file into a file that can be read by the target software.
-
-- In a low-performance system on a chip \(SoC\), this tool can convert a configuration file into the source code of the configuration tree so that the driver can obtain the configuration by directly calling the C library code.
-- In a high-performance SoC, this tool can convert an HCS configuration file into the HDF Configuration Binary \(HCB\) file, allowing the driver to obtain the configuration through the APIs provided by the HDF.
-
-The following figure shows the typical application scenario of the HCB mode.
-
-**Figure 1** Process of using HCS
-
-
-
-
-The HCS is compiled using the HC-GEN tool to generate an HCB file. The HCS Parser module in the HDF recreates a configuration tree using the HCB file. Then, the HDF driver modules obtain the configurations using the API provided by the HCS Paser.
-
-## Configuration Syntax
-
-The HCS syntax is described as follows:
-
-## Keywords
-
-The keywords listed in the following table below are reserved for HCS configuration files.
-
-**Table 1** Reserved keywords for HCS configuration files
-
-
-
Keywords
-
-
Description
-
-
Remarks
-
-
-
-
root
-
-
Configures the root node.
-
-
-
-
-
-
include
-
-
References other HCS configuration files.
-
-
-
-
-
-
delete
-
-
Deletes a node or an attribute.
-
-
This keyword applies only to the configuration tree imported using the include keyword.
-
-
-
template
-
-
Defines a template node.
-
-
-
-
-
-
match_attr
-
-
Marks the node attribute for matching.
-
-
During configuration parsing, the keyword value can be used to find the corresponding node.
-
-
-
-
-
-## Basic Syntax
-
-The HCS configuration file consists of configurations of attributes and nodes.
-
-**Attributes**
-
-An attribute, as the minimum configuration unit, is an independent configuration item. Its syntax is as follows:
-
-```
- attribute_name = value;
-```
-
-- The value of **attribute\_name** is a case-sensitive string of characters starting with a letter and consisting of letters, digits, and underscores \(\_\).
-
-- Available formats of **value** are as follows:
-
- - A binary, octal, decimal, or hexadecimal integer. For details, see [Data Types](#section96521601302).
-
- - A character string. The content should be enclosed in double quotation marks \(" "\).
-
- - A node reference
-
-
-- An attribute key-value pair must end with a semicolon \(;\) and belong to a node.
-
-
-**Nodes**
-
-A node is a set of attributes. Its syntax is as follows:
-
-```
- node_name {
- module = "sample";
- ...
- }
-```
-
-- The value of **node\_name** is a case-sensitive string of characters starting with a letter and consisting of letters, digits, and underscores \(\_\).
-
-- A semicolon \(;\) is not required after the curly brace \(\}\).
-
-- The reserved keyword **root** is used to declare the root node of a configuration table.
-
-- The root node must contain a **module** attribute that uses a string to represent the module to which the configuration belongs.
-
-- The **match\_attr** attribute can be added to a node. Its value is a globally unique character string. During configuration parsing, the query interface can be invoked to query the nodes with the attribute based on the attribute value.
-
-## Data Types
-
-Attributes automatically use built-in data types, including integers, strings, arrays, and booleans. You do not need to explicitly specify the data type for the attribute values.
-
-**Integer**
-
-An integer can be binary, octal, decimal, or hexadecimal. The minimum space is automatically allocated to the integer based on the actual data length.
-
-- Binary: prefixed with 0b, for example, 0b1010
-
-- Octal: prefixed with 0, for example, 0664
-- Decimal: either signed or unsigned, without a prefix, for example, 1024 or +1024. Negative integers can be read only via signed interfaces.
-
-- Hexadecimal: prefixed with 0x, for example, 0xff00 and 0xFF
-
-
-**String**
-
-A string is enclosed by double quotation marks \(" "\).
-
-**Array**
-
-The elements in an array can be integers or strings, but cannot be a combination of both. The combination of **uint32\_t** and **uint64\_t** in an integer array will enable up-casting to **uint64**. The following is an example of an integer array and a string array:
-
-```
-attr_foo = [0x01, 0x02, 0x03, 0x04];
-attr_bar = ["hello", "world"];
-```
-
-**Boolean**
-
-A Boolean data type has two possible values: **true** and **false**.
-
-## Pre-processing
-
-**include**
-
-The **include** keyword is used to import other HCS files. The syntax is as follows:
-
-```
-#include "foo.hcs"
-#include "../bar.hcs"
-```
-
-- The file names must be enclosed by double quotation marks \(" "\). Files in different directories can be referenced using relative paths. The file included must be a valid HCS file.
-- In the scenario that multiple HCS files are imported using **include**, if the same nodes exist, the latter node will override the former one, and other nodes are listed in sequence.
-
-## Commenting
-
-Comments can be formatted as follows:
-
-- Single-line comment
-
- ```
- // comment
- ```
-
-- Multi-line comment
-
- ```
- /*
- comment
- */
- ```
-
- > **NOTE:**
- >Multi-line comments cannot be nested.
-
-
-## Modifying a Reference
-
-You can use the following syntax to modify the content of any other node:
-
-```
- node :& source_node
-```
-
-This syntax indicates that the node value is a modification of the source\_node value. Example:
-
-```
-root {
- module = "sample";
- foo {
- foo_ :& root.bar{
- attr = "foo";
- }
- foo1 :& foo2 {
- attr = 0x2;
- }
- foo2 {
- attr = 0x1;
- }
- }
-
- bar {
- attr = "bar";
- }
-}
-```
-
-The following configuration tree is generated:
-
-```
-root {
- module = "sample";
- foo {
- foo2 {
- attr = 0x2;
- }
- }
- bar {
- attr = "foo";
- }
-}
-```
-
-In the preceding example, the **foo.foo\_** node changes the value of the referenced **bar.attr** to "**foo**", and the **foo.foo1** node changes the value of the referenced **foo.foo2.attr** to **0x2**. In the generated configuration tree, **foo.foo\_** and **foo.foo1** are not displayed, but their configuration modifications are presented by their referenced nodes.
-
-- A node of the same level can be referenced simply using the node name. A node of a different level must be referenced by the absolute path, and node names are separated using a period \(.\). **root** indicates the root node. The path format is the node path sequence starting with root. For example, **root.foo.bar** is a valid absolute path.
-- If multiple modifications are made to the same attribute, only one uncertain modification can take effect, and a warning will be displayed.
-
-## Replicating Node Configuration
-
-The content of a node can be replicated to another node to define the node with similar content. The syntax is as follows:
-
-```
- node : source_node
-```
-
-The preceding statement indicates that the attributes of **source\_node** are replicated to **node**. Example:
-
-```
-root {
- module = "sample";
- foo {
- attr_0 = 0x0;
- }
- bar:foo {
- attr_1 = 0x1;
- }
-}
-```
-
-The following configuration tree is generated:
-
-```
-root {
- module = "sample";
- foo {
- attr_0 = 0x0;
- }
- bar {
- attr_1 = 0x1;
- attr_0 = 0x0;
- }
-}
-```
-
-In the preceding example, the **bar** node configuration includes both the **attr\_0** and **attr\_1** values. The modification to **attr\_0** in the **bar** node does not affect the **foo** node.
-
-The path of the **foo** node is not required if the **foo** node and the **bar** node are of the same level. Otherwise, the absolute path must be used. For details, see [Modifying a Reference](#section179799204716).
-
-## Deleting a Node or Attribute
-
-You can use the keyword **delete** to delete unnecessary nodes or attributes in the base configuration tree imported by the **include** keyword. In the following example, **sample1.hcs** imports the configuration of **sample2.hcs** using **include**, and deletes the **attribute2** attribute and the **foo\_2** node using the **delete** keyword.
-
-```
-// sample2.hcs
-root {
- attr_1 = 0x1;
- attr_2 = 0x2;
- foo_2 {
- t = 0x1;
- }
-}
-
-// sample1.hcs
-#include "sample2.hcs"
-root {
- attr_2 = delete;
- foo_2 : delete {
- }
-}
-```
-
-The following configuration tree is generated:
-
-```
-root {
- attr_1 = 0x1;
-}
-```
-
-> **NOTE:**
->The **delete** keyword cannot be used in the same HCS file. It is recommended that you delete unnecessary attributes directly from the configuration source code.
-
-## Referencing an Attribute
-
-To quickly locate the associated node during configuration parsing, you can use the node as the value of the attribute and read the attribute to find the corresponding node. The syntax is as follows:
-
-```
- attribute = &node;
-```
-
-This syntax indicates that the **attribute** value is a reference to **node**. During code parsing, you can quickly locate the node using this attribute. Example:
-
-```
-node1 {
- attributes;
-}
-
-node2 {
- attr_1 = &node1;
-}
-```
-
-## Keyword Template
-
-The **template** keyword is used to generate nodes with strictly consistent syntax, thereby facilitating the traverse and management of nodes of the same type.
-
-If a node is defined using the keyword **template**, its child nodes inherit the node configuration through the double colon operator \(::\). The child nodes can modify but cannot add or delete attributes in **template**. The attributes not defined in the child nodes will use the attributes defined in **template** as the default values. Example:
-
-```
-root {
- module = "sample";
- template foo {
- attr_1 = 0x1;
- attr_2 = 0x2;
- }
-
- bar :: foo {
- }
-
- bar_1 :: foo {
- attr_1 = 0x2;
- }
-}
-```
-
-The following configuration tree is generated:
-
-```
-root {
- module = "sample";
- bar {
- attr_1 = 0x1;
- attr_2 = 0x2;
- }
- bar_1 {
- attr_1 = 0x2;
- attr_2 = 0x2;
- }
-}
-```
-
-In the preceding example, the **bar** and **bar\_1** nodes inherit the **foo** node. The structures of the generated configuration tree nodes are the same as that of the **foo** node, but the attribute values are different.
-
-## Configuration Generation
-
-The HC-GEN tool is used to generate configurations. It checks the HCS configuration syntax and converts HCS source files into HCB files.
-
-## Introduction to HC-GEN
-
-Parameter description:
-
-```
-Usage: hc-gen [Options] [File]
-options:
- -o output file name, default same as input
- -a hcb align with four bytes
- -b output binary output, default enable
- -t output config in C language source file style
- -i output binary hex dump in C language source file style
- -p prefix of generated symbol name
- -d decompile hcb to hcs
- -V show verbose info
- -v show version
- -h show this help message
-```
-
-Generate a **.c** or **.h** configuration file.
-
-```
-hc-gen -o [OutputCFileName] -t [SourceHcsFileName]
-```
-
-Generate an HCB file.
-
-```
-hc-gen -o [OutputHcbFileName] -b [SourceHcsFileName]
-```
-
-Compile an **HCB** file to an **HCS** file:
-
-```
-hc-gen -o [OutputHcsFileName] -d [SourceHcbFileName]
-```
-
diff --git a/en/device-dev/driver/driver-development.md b/en/device-dev/driver/driver-development.md
deleted file mode 100644
index f9c14ec11f06e6f5c5448751c6967e3de0dac1fa..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/driver-development.md
+++ /dev/null
@@ -1,175 +0,0 @@
-# Driver Development
-
-- [Introduction](#section157425168112)
-- [How to Develop](#section1969312275533)
-
-## Introduction
-
-The HDF is designed based on the component-based driver model. It provides more refined driver management to make driver development and deployment more standard. Device drivers of the same type are placed in the same host. You can develop and deploy the drivers separately. One driver can have multiple nodes. The following figure shows the HDF driver management model.
-
-**Figure 1** HDF driver management model
-
-
-
-
-## How to Develop
-
-Driver development based on the HDF consists of two parts: driver implementation and driver configuration. The details are as follows:
-
-1. Implement driver.
-
- To implement a driver, compile driver service code and register a driver entry.
-
- - Driver service code
-
- ```
- #include "hdf_device_desc.h" // Header file that describes the APIs provided by the HDF to the driver.
- #include "hdf_log.h" // Header file of the log interface provided by the HDF.
-
- #define HDF_LOG_TAG "sample_driver" // Tag contained in logs. If the tag is not specified, HDF_TAG is used by default.
-
- // The driver service interface must be bound to the HDF for you to use the service capability.
- int32_t HdfSampleDriverBind(struct HdfDeviceObject *deviceObject)
- {
- HDF_LOGD("Sample driver bind success");
- return 0;
- }
-
- // Initialize the driver service.
- int32_t HdfSampleDriverInit(struct HdfDeviceObject *deviceObject)
- {
- HDF_LOGD("Sample driver Init success");
- return 0;
- }
-
- // Release the driver resources.
- void HdfSampleDriverRelease(struct HdfDeviceObject *deviceObject)
- {
- HDF_LOGD("Sample driver release success");
- return;
- }
- ```
-
- - Registering the driver entry with the HDF
-
- ```
- // Define the object of the driver entry. The object must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h).
- struct HdfDriverEntry g_sampleDriverEntry = {
- .moduleVersion = 1,
- .moduleName = "sample_driver",
- .Bind = HdfSampleDriverBind,
- .Init = HdfSampleDriverInit,
- .Release = HdfSampleDriverRelease,
- };
-
- // Call HDF_INIT to register the driver entry with the HDF framework. When loading the driver, call the Bind function and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit.
- HDF_INIT(g_sampleDriverEntry);
- ```
-
-
-2. Compile the driver code.
- - Use the **Makefile** template provided by the HDF to compile the driver code.
-
- ```
- include $(LITEOSTOPDIR)/../../drivers/adapter/lite/khdf/lite.mk # (Mandatory) Import the predefined content of the HDF.
- MODULE_NAME := # Generated result file
- LOCAL_INCLUDE: = # Header file directory of the driver
- LOCAL_SRCS : = # Source code file of the driver
- LOCAL_CFLAGS : = # Custom compilation options
- include $(HDF_DRIVER) # Import the template Makefile to complete compilation.
- ```
-
- - Link the compilation result file to the kernel image by adding the result file to **hdf\_vendor.mk** in the **vendor** directory. The following is an example:
-
- ```
- LITEOS_BASELIB += -lxxx # Static library generated through linking
- 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-configuration-management.md).
-
- The driver configuration consists of the driver device description defined by the HDF and private driver configuration information.
-
- - \(Mandatory\) Driver device description
-
- The information required for the HDF to load drivers comes from the driver device description defined by the HDF. Therefore, the device description must be added to the configuration file **device\_info.hcs** defined by the HDF for drivers developed based on the HDF. The following is an example:
-
- ```
- root {
- device_info {
- match_attr = "hdf_manager";
- template host { // Host template. If the node (for example, sample_host) that inherits the template uses default values in the template, the values of the node fields can be omitted.
- hostName = "";
- priority = 100;
- template device {
- template deviceNode {
- policy = 0;
- priority = 100;
- preload = 0;
- permission = 0664;
- moduleName = "";
- serviceName = "";
- deviceMatchAttr = "";
- }
- }
- }
- sample_host :: host{
- hostName = "host0"; // Host name. The host node is used to store a certain type of drivers.
- priority = 100; // Host startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the host loading sequence is random.
- device_sample :: device { // Device node of sample
- device0 :: deviceNode { // DeviceNode of the sample driver
- policy = 1; // Driver service release policy. For details, see section Driver Service Management.
- priority = 100; // Driver startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the device loading sequence is random.
- preload = 0; // On-demand driver loading. For details, see "NOTE" at the end of this section.
- permission = 0664; // Permission for the driver to create device nodes.
- moduleName = "sample_driver"; // Driver name. The value of this field must be the same as the value of moduleName in the driver entry structure.
- serviceName = "sample_service"; // Name of the service released by the driver. The name must be unique.
- deviceMatchAttr = "sample_config"; // Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver.
- }
- }
- }
- }
- }
- ```
-
- - \(Optional\) Private configuration information of the driver
-
- If the driver has private configurations, you can add a driver configuration file to fill in the default configuration information of the driver. When loading the driver, the HDF obtains the information and saves it in the **property** of **HdfDeviceObject**, and transfers it to the driver using **Bind** and **Init** \(see [1](#li35182436435)\). The following is an example of the driver configuration information:
-
- ```
- root {
- SampleDriverConfig {
- sample_version = 1;
- sample_bus = "I2C_0";
- match_attr = "sample_config"; // The value of this field must be the same as that of deviceMatchAttr in device_info.hcs.
- }
- }
- ```
-
- After the configuration information is defined, you need to add the configuration file to the board-level configuration entry file **hdf.hcs**. \(You can use the DevEco to perform on-click configuration. For details, see the description about the driver development suite.\) The following is an example:
-
- ```
- #include "device_info/device_info.hcs"
- #include "sample/sample_config.hcs"
- ```
-
-
-
-> **NOTE:**
->On-demand loading and sequential loading are supported. The detailed usage is as follows:
->- On-demand loading
-> ```
-> typedef enum {
-> DEVICE_PRELOAD_ENABLE = 0,
-> DEVICE_PRELOAD_ENABLE_STEP2,
-> DEVICE_PRELOAD_DISABLE,
-> 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](driver-message-mechanism-management.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-message-mechanism-management.md b/en/device-dev/driver/driver-message-mechanism-management.md
deleted file mode 100644
index 3ea214d2ade48cb8955cd793fd84aadc2cc38d81..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/driver-message-mechanism-management.md
+++ /dev/null
@@ -1,193 +0,0 @@
-# Driver Message Mechanism Management
-
-- [When to Use](#section33014541954)
-- [Available APIs](#section538852311616)
-- [How to Develop](#section946912121153)
-
-## When to Use
-
-When user-level applications need to interact with kernel-level drivers, the driver message mechanism of the HDF can be used.
-
-## Available APIs
-
-The message mechanism provides the following features:
-
-1. User-level applications send messages to drivers.
-2. User-level applications receive events sent by the drivers.
-
-**Table 1** APIs for the driver message mechanism
-
-
-
int HdfDeviceRegisterEventListener(struct HdfIoService *target, struct HdfDevEventlistener *listener);
-
-
Receives events sent by the drivers.
-
-
-
int HdfDeviceSendEvent(struct HdfDeviceObject *deviceObject, uint32_t id, struct HdfSBuf *data);
-
-
Sends events.
-
-
-
-
-
-## 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](driver-service-management.md)\).
-
- ```
- device_sample :: Device {
- policy = 2;
- ...
- }
- ```
-
-2. The **permission** field in the driver configuration information indicates the permission provided for the driver to create device nodes. The default value is **0666**. You can configure the value of this field based on the actual application scenario of the driver.
-3. Implement the **Dispatch** function of the service base member **IDeviceIoService** during service implementation.
-
- ```
- // Process messages delivered by user-level applications.
- int32_t SampleDriverDispatch(struct HdfDeviceObject *device, int cmdCode, struct HdfSBuf *data, struct HdfSBuf *reply)
- {
- HDF_LOGE("sample driver lite A dispatch");
- return 0;
- }
- int32_t SampleDriverBind(struct HdfDeviceObject *device)
- {
- HDF_LOGE("test for lite os sample driver A Open!");
- if (device == NULL) {
- HDF_LOGE("test for lite os sample driver A Open failed!");
- return -1;
- }
- static struct ISampleDriverService sampleDriverA = {
- .ioService.Dispatch = SampleDriverDispatch,
- .ServiceA = SampleDriverServiceA,
- .ServiceB = SampleDriverServiceB,
- };
- device->service = (struct IDeviceIoService *)(&sampleDriverA);
- return 0;
- }
- ```
-
-4. Define the CMD type in the message processing function.
-
- ```
- #define SAMPLE_WRITE_READ 1 // Read and write operation 1
- ```
-
-5. Enable the user-level application to obtain the service interface and send messages to the driver.
-
- ```
- int SendMsg(const char *testMsg)
- {
- if (testMsg == NULL) {
- HDF_LOGE("test msg is null");
- return -1;
- }
- struct HdfIoService *serv = HdfIoServiceBind("sample_driver");
- if (serv == NULL) {
- HDF_LOGE("fail to get service");
- return -1;
- }
- struct HdfSBuf *data = HdfSBufObtainDefaultSize();
- if (data == NULL) {
- HDF_LOGE("fail to obtain sbuf data");
- return -1;
- }
- struct HdfSBuf *reply = HdfSBufObtainDefaultSize();
- if (reply == NULL) {
- HDF_LOGE("fail to obtain sbuf reply");
- ret = HDF_DEV_ERR_NO_MEMORY;
- goto out;
- }
- if (!HdfSbufWriteString(data, testMsg)) {
- HDF_LOGE("fail to write sbuf");
- ret = HDF_FAILURE;
- goto out;
- }
- int ret = serv->dispatcher->Dispatch(&serv->object, SAMPLE_WRITE_READ, data, reply);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("fail to send service call");
- goto out;
- }
- out:
- HdfSBufRecycle(data);
- HdfSBufRecycle(reply);
- HdfIoServiceRecycle(serv);
- return ret;
- }
- ```
-
-6. Enable the user-level application to receive messages reported by the driver.
- 1. Enable the user-level application to compile the function for processing messages reported by the driver.
-
- ```
- static int OnDevEventReceived(void *priv, uint32_t id, struct HdfSBuf *data)
- {
- OsalTimespec time;
- OsalGetTime(&time);
- HDF_LOGE("%s received event at %llu.%llu", (char *)priv, time.sec, time.usec);
-
- const char *string = HdfSbufReadString(data);
- if (string == NULL) {
- HDF_LOGE("fail to read string in event data");
- return -1;
- }
- HDF_LOGE("%s: dev event received: %d %s", (char *)priv, id, string);
- return 0;
- }
- ```
-
- 2. Enable the user-level application to register the function for receiving messages reported by the driver.
-
- ```
- int RegisterListen()
- {
- struct HdfIoService *serv = HdfIoServiceBind("sample_driver");
- if (serv == NULL) {
- HDF_LOGE("fail to get service");
- return -1;
- }
- static struct HdfDevEventlistener listener = {
- .callBack = OnDevEventReceived,
- .priv ="Service0"
- };
- if (HdfDeviceRegisterEventListener(serv, &listener) != 0) {
- HDF_LOGE("fail to register event listener");
- return -1;
- }
- ......
- HdfDeviceUnregisterEventListener(serv, &listener);
- HdfIoServiceRecycle(serv);
- return 0;
- }
- ```
-
- 3. Enable the driver to report events.
-
- ```
- int32_t SampleDriverDispatch(struct HdfDeviceObject *device, int cmdCode, struct HdfSBuf *data, struct HdfSBuf *reply)
- {
- ... // process api call here
- return HdfDeviceSendEvent(deviceObject, cmdCode, data);
- }
- ```
-
-
-
diff --git a/en/device-dev/driver/driver-platform.md b/en/device-dev/driver/driver-platform.md
deleted file mode 100644
index d75727d7407e71e9088a907083d02278462474e3..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/driver-platform.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Driver Platform
-
-- **[GPIO](gpio.md)**
-
-- **[I2C](i2c.md)**
-
-- **[RTC](rtc.md)**
-
-- **[SDIO](sdio.md)**
-
-- **[SPI](spi.md)**
-
-- **[UART](uart.md)**
-
-- **[WATCHDOG](watchdog.md)**
-
-- **[MIPI DSI](mipi-dsi.md)**
-
-
diff --git a/en/device-dev/driver/figures/architecture-of-the-display-driver-model.png b/en/device-dev/driver/figure/architecture-of-the-display-driver-model.png
similarity index 100%
rename from en/device-dev/driver/figures/architecture-of-the-display-driver-model.png
rename to en/device-dev/driver/figure/architecture-of-the-display-driver-model.png
diff --git a/en/device-dev/driver/figures/architecture-of-the-input-driver-model.png b/en/device-dev/driver/figure/architecture-of-the-input-driver-model.png
similarity index 100%
rename from en/device-dev/driver/figures/architecture-of-the-input-driver-model.png
rename to en/device-dev/driver/figure/architecture-of-the-input-driver-model.png
diff --git a/en/device-dev/driver/figures/architecture-of-the-sensor-driver-model.png b/en/device-dev/driver/figure/architecture-of-the-sensor-driver-model.png
similarity index 100%
rename from en/device-dev/driver/figures/architecture-of-the-sensor-driver-model.png
rename to en/device-dev/driver/figure/architecture-of-the-sensor-driver-model.png
diff --git a/en/device-dev/driver/figures/common-pins-of-the-touchscreen.png b/en/device-dev/driver/figure/common-pins-of-the-touchscreen.png
similarity index 100%
rename from en/device-dev/driver/figures/common-pins-of-the-touchscreen.png
rename to en/device-dev/driver/figure/common-pins-of-the-touchscreen.png
diff --git a/en/device-dev/driver/figures/dsi-transmitting-and-receiving-interface.png b/en/device-dev/driver/figure/dsi-transmitting-and-receiving-interface.png
similarity index 100%
rename from en/device-dev/driver/figures/dsi-transmitting-and-receiving-interface.png
rename to en/device-dev/driver/figure/dsi-transmitting-and-receiving-interface.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001053405727.png b/en/device-dev/driver/figure/en-us_image_0000001053405727.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001053405727.png
rename to en/device-dev/driver/figure/en-us_image_0000001053405727.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054280608.png b/en/device-dev/driver/figure/en-us_image_0000001054280608.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054280608.png
rename to en/device-dev/driver/figure/en-us_image_0000001054280608.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054564784.png b/en/device-dev/driver/figure/en-us_image_0000001054564784.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054564784.png
rename to en/device-dev/driver/figure/en-us_image_0000001054564784.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001057902344.png b/en/device-dev/driver/figure/en-us_image_0000001123509750.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001057902344.png
rename to en/device-dev/driver/figure/en-us_image_0000001123509750.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001072553354.png b/en/device-dev/driver/figure/en-us_image_0000001123514210.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001072553354.png
rename to en/device-dev/driver/figure/en-us_image_0000001123514210.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054440624.png b/en/device-dev/driver/figure/en-us_image_0000001123540984.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054440624.png
rename to en/device-dev/driver/figure/en-us_image_0000001123540984.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054007499.png b/en/device-dev/driver/figure/en-us_image_0000001123582482.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054007499.png
rename to en/device-dev/driver/figure/en-us_image_0000001123582482.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054728498.png b/en/device-dev/driver/figure/en-us_image_0000001123675706.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054728498.png
rename to en/device-dev/driver/figure/en-us_image_0000001123675706.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054726248.png b/en/device-dev/driver/figure/en-us_image_0000001123703482.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054726248.png
rename to en/device-dev/driver/figure/en-us_image_0000001123703482.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054142582.png b/en/device-dev/driver/figure/en-us_image_0000001123742254.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054142582.png
rename to en/device-dev/driver/figure/en-us_image_0000001123742254.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001057342245.png b/en/device-dev/driver/figure/en-us_image_0000001170187071.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001057342245.png
rename to en/device-dev/driver/figure/en-us_image_0000001170187071.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001054006983.png b/en/device-dev/driver/figure/en-us_image_0000001170227689.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001054006983.png
rename to en/device-dev/driver/figure/en-us_image_0000001170227689.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001057622716.png b/en/device-dev/driver/figure/en-us_image_0000001170229891.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001057622716.png
rename to en/device-dev/driver/figure/en-us_image_0000001170229891.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001053926237.png b/en/device-dev/driver/figure/en-us_image_0000001170262141.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001053926237.png
rename to en/device-dev/driver/figure/en-us_image_0000001170262141.png
diff --git a/en/device-dev/driver/figures/en-us_image_0000001055299108.png b/en/device-dev/driver/figure/en-us_image_0000001170383063.png
similarity index 100%
rename from en/device-dev/driver/figures/en-us_image_0000001055299108.png
rename to en/device-dev/driver/figure/en-us_image_0000001170383063.png
diff --git a/en/device-dev/driver/figures/mipi-dsi.png b/en/device-dev/driver/figure/mipi-dsi.png
similarity index 100%
rename from en/device-dev/driver/figures/mipi-dsi.png
rename to en/device-dev/driver/figure/mipi-dsi.png
diff --git a/en/device-dev/driver/figures/physical-connection-diagram-for-i2c.png b/en/device-dev/driver/figure/physical-connection-diagram-for-i2c.png
similarity index 100%
rename from en/device-dev/driver/figures/physical-connection-diagram-for-i2c.png
rename to en/device-dev/driver/figure/physical-connection-diagram-for-i2c.png
diff --git a/en/device-dev/driver/figures/ttl-interface.png b/en/device-dev/driver/figure/ttl-interface.png
similarity index 100%
rename from en/device-dev/driver/figures/ttl-interface.png
rename to en/device-dev/driver/figure/ttl-interface.png
diff --git "a/en/device-dev/driver/figures/\346\216\245\345\217\243\345\210\206\345\270\203\345\233\2764.png" "b/en/device-dev/driver/figure/\346\216\245\345\217\243\345\210\206\345\270\203\345\233\2764.png"
similarity index 100%
rename from "en/device-dev/driver/figures/\346\216\245\345\217\243\345\210\206\345\270\203\345\233\2764.png"
rename to "en/device-dev/driver/figure/\346\216\245\345\217\243\345\210\206\345\270\203\345\233\2764.png"
diff --git a/en/device-dev/driver/gpio.md b/en/device-dev/driver/gpio.md
deleted file mode 100644
index a35dc16408feb1ef8d9c6b7ad878a8d99d00fea6..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/gpio.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# GPIO
-
-- **[GPIO Overview](gpiooverview.md)**
-
-- **[GPIO Usage Guidelines](gpiousage-guidelines.md)**
-
-- **[GPIO Usage Example](gpiousage-example.md)**
-
-
diff --git a/en/device-dev/driver/gpiooverview.md b/en/device-dev/driver/gpiooverview.md
deleted file mode 100644
index a05df150d2b1b166350337754bb024e4d58e7e67..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/gpiooverview.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# GPIO Overview
-
-- [Introduction](#section15318165672215)
-- [Available APIs](#section18977142162418)
-
-## Introduction
-
-GPIO is short for general-purpose input/output. Generally, a GPIO controller manages all GPIO pins by group. Each group of GPIO pins is associated with one or more registers. The GPIO pins are operated by reading data from and writing data to the registers.
-
-The GPIO APIs define a set of standard functions for performing operations on GPIO pins, including:
-
-- Setting the pin direction, which can be input or output \(High impedance is not supported currently.\)
-
-- Reading and writing level values, which can be low or high
-- Setting an interrupt service routine \(ISR\) function and interrupt trigger mode for a pin
-- Enabling or disabling a pin interrupt
-
-## Available APIs
-
-**Table 1** APIs available for the GPIO driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
GPIO read/write
-
-
GpioRead
-
-
Reads the level value of a GPIO pin.
-
-
-
GpioWrite
-
-
Writes the level value of a GPIO pin.
-
-
-
GPIO settings
-
-
GpioSetDir
-
-
Sets the direction for a GPIO pin.
-
-
-
GpioGetDir
-
-
Obtains the direction for a GPIO pin.
-
-
-
GPIO interrupt settings
-
-
-
-
-
GpioSetIrq
-
-
Sets the ISR function for a GPIO pin.
-
-
-
GpioUnSetIrq
-
-
Cancels the setting of the ISR function for a GPIO pin.
-
-
-
GpioEnableIrq
-
-
Enables a GPIO interrupt.
-
-
-
GpioDisableIrq
-
-
Disables a GPIO interrupt.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/gpiousage-example.md b/en/device-dev/driver/gpiousage-example.md
deleted file mode 100644
index bfdb21eed1d8feece2e48d130b8d0cea1ae17a58..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/gpiousage-example.md
+++ /dev/null
@@ -1,79 +0,0 @@
-# GPIO Usage Example
-
-In this example, we test the interrupt trigger of a GPIO pin as follows: Set the ISR function for the pin, set the trigger mode to rising edge and failing edge, write high and low levels to the pin alternately to generate level fluctuation, and observe the execution of the ISR function.
-
-Select an idle GPIO pin. This example uses a Hi3516D V300 development board and GPIO pin GPIO10\_3, which is numbered GPIO83.
-
-You can select an idle GPIO pin based on the development board and schematic diagram.
-
-```
-#include "gpio_if.h"
-#include "hdf_log.h"
-#include "osal_irq.h"
-#include "osal_time.h"
-
-static uint32_t g_irqCnt;
-
-/* ISR function */
-static int32_t TestCaseGpioIrqHandler(uint16_t gpio, void *data)
-{
- HDF_LOGE("%s: irq triggered! on gpio:%u, data=%p", __func__, gpio, data);
- g_irqCnt++; /* If the ISR function is triggered, the number of global interrupts is incremented by 1. */
- return GpioDisableIrq(gpio);
-}
-
-/* Test case function */
-static int32_t TestCaseGpioIrqEdge(void)
-{
- int32_t ret;
- uint16_t valRead;
- uint16_t mode;
- uint16_t gpio = 83; /* Number of the GPIO pin to test */
- uint32_t timeout;
-
- /* Set the output direction for the pin. */
- ret = GpioSetDir(gpio, GPIO_DIR_OUT);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set dir fail! ret:%d\n", __func__, ret);
- return ret;
- }
-
- /* Disable the interrupt of the pin. */
- ret = GpioDisableIrq(gpio);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: disable irq fail! ret:%d\n", __func__, ret);
- return ret;
- }
-
- /* Set the ISR function for the pin. The trigger mode is both rising edge and falling edge. */
- mode = OSAL_IRQF_TRIGGER_RISING | OSAL_IRQF_TRIGGER_FALLING;
- HDF_LOGE("%s: mode:%0x\n", __func__, mode);
- ret = GpioSetIrq(gpio, mode, TestCaseGpioIrqHandler, NULL);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set irq fail! ret:%d\n", __func__, ret);
- return ret;
- }
-
- /* Enable the interrupt for this pin. */
- ret = GpioEnableIrq(gpio);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: enable irq fail! ret:%d\n", __func__, ret);
- (void)GpioUnSetIrq(gpio);
- return ret;
- }
-
- g_irqCnt = 0; /* Reset the global counter. */
- timeout = 0; /* Reset the waiting time. */
- /* Wait for the ISR function of this pin to trigger. The timeout duration is 1000 ms. */
- while (g_irqCnt <= 0 && timeout < 1000) {
- (void)GpioRead(gpio, &valRead);
- (void)GpioWrite(gpio, (valRead == GPIO_VAL_LOW) ? GPIO_VAL_HIGH : GPIO_VAL_LOW);
- HDF_LOGE("%s: wait irq timeout:%u\n", __func__, timeout);
- OsalMDelay(200); /* wait for irq trigger */
- timeout += 200;
- }
- (void)GpioUnSetIrq(gpio);
- return (g_irqCnt > 0) ? HDF_SUCCESS : HDF_FAILURE;
-}
-```
-
diff --git a/en/device-dev/driver/gpiousage-guidelines.md b/en/device-dev/driver/gpiousage-guidelines.md
deleted file mode 100644
index 67c29e26454fde7b66ef285e993d01d08f09d8ba..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/gpiousage-guidelines.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# GPIO Usage Guidelines
-
-- [How to Use](#section1583613406410)
-- [Determining a GPIO Pin Number](#section135943361443)
-- [Using APIs to Operate GPIO Pins](#section69151114115315)
-
-## How to Use
-
-The GPIO APIs use the GPIO pin number to specify a pin. [Figure 1](#fig1399416053717) shows the general process of using a GPIO.
-
-**Figure 1** Process of using a GPIO
-
-
-
-
-## Determining a GPIO Pin Number
-
-The method for converting GPIO pin numbers varies according to the GPIO controller model, parameters, and controller driver of different system on chips \(SoCs\).
-
-- Hi3516D V300
-
- 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
-
- Example: GPIO number of GPIO10\_3 = 10 x 8 + 3 = 83
-
-- Hi3518E V300
-
- A controller manages 10 groups of GPIO pins. Each group contains 10 GPIO pins.
-
- GPIO pin number = GPIO group index \(0–9\) x Number of GPIO pins in each group \(10\) + Offset in the group
-
- Example: GPIO pin number of GPIO7\_3 = 7 x 10 + 3 = 73
-
-
-## Using APIs to Operate GPIO Pins
-
-- Set the direction for a GPIO pin.
-
- Before performing read/write operations on a GPIO pin, call the following function to set the direction:
-
- int32\_t GpioSetDir\(uint16\_t gpio, uint16\_t dir\);
-
- **Table 1** Description of GpioSetDir
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
dir
-
-
Direction to set.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The setting is successful.
-
-
-
Negative value
-
-
The setting failed.
-
-
-
-
-
-- Read or write the level value for a GPIO pin.
-
- To read the level value of a GPIO pin, call the following function:
-
- int32\_t GpioRead\(uint16\_t gpio, uint16\_t \*val\);
-
- **Table 2** Description of GpioRead
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
val
-
-
Pointer to the level value.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in reading the level value.
-
-
-
Negative value
-
-
Failed to read the level value.
-
-
-
-
-
- To write the level value for a GPIO pin, call the following function:
-
- int32\_t GpioWrite\(uint16\_t gpio, uint16\_t val\);
-
- **Table 3** Description of GpioWrite
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
val
-
-
Level value to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in writing the level value.
-
-
-
Negative value
-
-
Failed to write the level value.
-
-
-
-
-
- Example:
-
- ```
- int32_t ret;
- uint16_t val;
- /* Set the output direction for GPIO3. */
- ret = GpioSetDir(3, GPIO_DIR_OUT);
- if (ret != 0) {
- HDF_LOGE("GpioSerDir: failed, ret %d\n", ret);
- return;
- }
- /* Write the low level GPIO_VAL_LOW for GPIO3. */
- ret = GpioWrite(3, GPIO_VAL_LOW);
- if (ret != 0) {
- HDF_LOGE("GpioWrite: failed, ret %d\n", ret);
- return;
- }
- /* Set the input direction for GPIO6. */
- ret = GpioSetDir(6, GPIO_DIR_IN);
- if (ret != 0) {
- HDF_LOGE("GpioSetDir: failed, ret %d\n", ret);
- return;
- }
- /* Read the level value of GPIO6. */
- ret = GpioRead(6, &val);
- ```
-
-
-- Set the ISR function for a GPIO pin.
-
- To set the ISR function for a GPIO pin, call the following function:
-
- int32\_t GpioSetIrq\(uint16\_t gpio, uint16\_t mode, GpioIrqFunc func, void \*arg\);
-
- **Table 4** Description of GpioSetIrq
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
mode
-
-
Interrupt trigger mode.
-
-
-
func
-
-
ISR function to set.
-
-
-
arg
-
-
Pointer to the parameters passed to the ISR function.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The setting is successful.
-
-
-
Negative value
-
-
The setting failed.
-
-
-
-
-
- > **CAUTION:**
- >Only one ISR function can be set for a GPIO pin at a time. If **GpioSetIrq** is called repeatedly, the previous IRS function will be replaced.
-
- If the ISR function is no longer required, call the following function to cancel the setting:
-
- int32\_t GpioUnSetIrq\(uint16\_t gpio\);
-
- **Table 5** Description of GpioUnSetIrq
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The ISR function is canceled.
-
-
-
Negative value
-
-
Failed to cancel the ISR function.
-
-
-
-
-
- After the ISR function is set, call the following function to enable a GPIO interrupt:
-
- int32\_t GpioEnableIrq\(uint16\_t gpio\);
-
- **Table 6** Description of GpioEnableIrq
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The GPIO interrupt is enabled.
-
-
-
Negative value
-
-
Failed to enable a GPIO interrupt.
-
-
-
-
-
- > **CAUTION:**
- >The configured ISR function can be responded only after the ISR function is enabled.
-
- Use the following function to disable the GPIO interrupt:
-
- int32\_t GpioDisableIrq\(uint16\_t gpio\);
-
- **Table 7** Description of GpioDisableIrq
-
-
-
Parameter
-
-
Description
-
-
-
gpio
-
-
GPIO pin number.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The GPIO interrupt is disabled.
-
-
-
Negative value
-
-
Failed to disable the GPIO interrupt.
-
-
-
-
-
- Example:
-
- ```
- /* ISR function */
- */
- int32_t MyCallBackFunc(uint16_t gpio, void *data)
- {
- HDF_LOGI("%s: gpio:%u interrupt service in! data=%p\n", __func__, gpio, data);
- return 0;
- }
-
- int32_t ret;
- /* Set the ISR function to MyCallBackFunc, the parameter to NULL, and the interrupt trigger mode to rising edge. */
- ret = GpioSetIrq(3, OSAL_IRQF_TRIGGER_RISING, MyCallBackFunc, NULL);
- if (ret != 0) {
- HDF_LOGE("GpioSetIrq: failed, ret %d\n", ret);
- return;
- }
-
- /* Enable an interrupt for GPIO3. */
- ret = GpioEnableIrq(3);
- if (ret != 0) {
- HDF_LOGE("GpioEnableIrq: failed, ret %d\n", ret);
- return;
- }
-
- /* Disable the interrupt for GPIO3. */
- ret = GpioDisableIrq(3);
- if (ret != 0) {
- HDF_LOGE("GpioDisableIrq: failed, ret %d\n", ret);
- return;
- }
-
- /* Cancel the ISR function for GPIO3. */
- ret = GpioUnSetIrq(3);
- if (ret != 0) {
- HDF_LOGE("GpioUnSetIrq: failed, ret %d\n", ret);
- return;
- }
- ```
-
-
diff --git a/en/device-dev/driver/hdf.md b/en/device-dev/driver/hdf.md
deleted file mode 100644
index 05183747d4acb2435125a02035725cedc28b5081..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/hdf.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# HDF
-
-- **[HDF Overview](hdfoverview.md)**
-
-- **[Driver Development](driver-development.md)**
-
-- **[Driver Service Management](driver-service-management.md)**
-
-- **[Driver Message Mechanism Management](driver-message-mechanism-management.md)**
-
-- **[Driver Configuration Management](driver-configuration-management.md)**
-
-- **[HDF Development Example](hdfdevelopment-example.md)**
-
-
diff --git a/en/device-dev/driver/hdfdevelopment-example.md b/en/device-dev/driver/hdfdevelopment-example.md
deleted file mode 100644
index 815706650b3e69638f9310ace1bdd00b93f71e38..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/hdfdevelopment-example.md
+++ /dev/null
@@ -1,238 +0,0 @@
-# HDF Development Example
-
-- [Adding Configurations](#section27261067111)
-- [Compiling the Driver Code](#section177988005)
-- [Compiling the Code for Interaction](#section6205173816412)
-
-The following example shows how to add configurations, implement the driver code, and compile the code for interaction between the user-level applications and the driver.
-
-## Adding Configurations
-
-Add the driver configurations to the HDF configuration file \(for example, **vendor/hisilicon/xxx/config/device\_info**\). Example:
-
-```
-root {
- device_info {
- match_attr = "hdf_manager";
- template host {
- hostName = "";
- priority = 100;
- template device {
- template deviceNode {
- policy = 0;
- priority = 100;
- preload = 0;
- permission = 0664;
- moduleName = "";
- serviceName = "";
- deviceMatchAttr = "";
- }
- }
- }
- sample_host :: host {
- hostName = "sample_host";
- sample_device :: device {
- device0 :: deviceNode {
- policy = 2;
- priority = 100;
- preload = 1;
- permission = 0664;
- moduleName = "sample_driver";
- serviceName = "sample_service";
- }
- }
- }
- }
-}
-```
-
-## Compiling the Driver Code
-
-A sample of driver code compiled based on the HDF is as follows:
-
-```
-#include
-#include
-#include
-#include "hdf_log.h"
-#include "hdf_base.h"
-#include "hdf_device_desc.h"
-
-#define HDF_LOG_TAG "sample_driver"
-
-#define SAMPLE_WRITE_READ 123
-
-int32_t HdfSampleDriverDispatch(
- struct HdfDeviceObject *deviceObject, int id, struct HdfSBuf *data, struct HdfSBuf *reply)
-{
- HDF_LOGE("%s: received cmd %d", __func__, id);
- if (id == SAMPLE_WRITE_READ) {
- const char *readData = HdfSbufReadString(data);
- if (readData != NULL) {
- HDF_LOGE("%s: read data is: %s", __func__, readData);
- }
- if (!HdfSbufWriteInt32(reply, INT32_MAX)) {
- HDF_LOGE("%s: reply int32 fail", __func__);
- }
- return HdfDeviceSendEvent(deviceObject, id, data);
- }
- return HDF_FAILURE;
-}
-
-void HdfSampleDriverRelease(struct HdfDeviceObject *deviceObject)
-{
- // Release resources here
- return;
-}
-
-int HdfSampleDriverBind(struct HdfDeviceObject *deviceObject)
-{
- if (deviceObject == NULL) {
- return HDF_FAILURE;
- }
- static struct IDeviceIoService testService = {
- .Dispatch = HdfSampleDriverDispatch,
- };
- deviceObject->service = &testService;
- return HDF_SUCCESS;
-}
-
-int HdfSampleDriverInit(struct HdfDeviceObject *deviceObject)
-{
- if (deviceObject == NULL) {
- HDF_LOGE("%s::ptr is null!", __func__);
- return HDF_FAILURE;
- }
- HDF_LOGE("Sample driver Init success");
- return HDF_SUCCESS;
-}
-
-struct HdfDriverEntry g_sampleDriverEntry = {
- .moduleVersion = 1,
- .moduleName = "sample_driver",
- .Bind = HdfSampleDriverBind,
- .Init = HdfSampleDriverInit,
- .Release = HdfSampleDriverRelease,
-};
-
-HDF_INIT(g_sampleDriverEntry);
-```
-
-## Compiling the Code for Interaction
-
-A sample code for interaction between the user-level application and driver compiled based on the HDF is as follows:
-
-```
-#include
-#include
-#include
-#include
-#include "hdf_log.h"
-#include "hdf_sbuf.h"
-#include "hdf_io_service_if.h"
-
-#define HDF_LOG_TAG "sample_test"
-#define SAMPLE_SERVICE_NAME "sample_service"
-
-#define SAMPLE_WRITE_READ 123
-
-int g_replyFlag = 0;
-
-static int OnDevEventReceived(void *priv, uint32_t id, struct HdfSBuf *data)
-{
- const char *string = HdfSbufReadString(data);
- if (string == NULL) {
- HDF_LOGE("fail to read string in event data");
- g_replyFlag = 1;
- return HDF_FAILURE;
- }
- HDF_LOGE("%s: dev event received: %u %s", (char *)priv, id, string);
- g_replyFlag = 1;
- return HDF_SUCCESS;
-}
-
-static int SendEvent(struct HdfIoService *serv, char *eventData)
-{
- int ret = 0;
- struct HdfSBuf *data = HdfSBufObtainDefaultSize();
- if (data == NULL) {
- HDF_LOGE("fail to obtain sbuf data");
- return 1;
- }
-
- struct HdfSBuf *reply = HdfSBufObtainDefaultSize();
- if (reply == NULL) {
- HDF_LOGE("fail to obtain sbuf reply");
- ret = HDF_DEV_ERR_NO_MEMORY;
- goto out;
- }
-
- if (!HdfSbufWriteString(data, eventData)) {
- HDF_LOGE("fail to write sbuf");
- ret = HDF_FAILURE;
- goto out;
- }
-
- ret = serv->dispatcher->Dispatch(&serv->object, SAMPLE_WRITE_READ, data, reply);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("fail to send service call");
- goto out;
- }
-
- int replyData = 0;
- if (!HdfSbufReadInt32(reply, &replyData)) {
- HDF_LOGE("fail to get service call reply");
- ret = HDF_ERR_INVALID_OBJECT;
- goto out;
- }
- HDF_LOGE("Get reply is: %d", replyData);
-out:
- HdfSBufRecycle(data);
- HdfSBufRecycle(reply);
- return ret;
-}
-
-int main()
-{
- char *sendData = "default event info";
- struct HdfIoService *serv = HdfIoServiceBind(SAMPLE_SERVICE_NAME);
- if (serv == NULL) {
- HDF_LOGE("fail to get service %s", SAMPLE_SERVICE_NAME);
- return HDF_FAILURE;
- }
-
- static struct HdfDevEventlistener listener = {
- .callBack = OnDevEventReceived,
- .priv ="Service0"
- };
-
- if (HdfDeviceRegisterEventListener(serv, &listener) != HDF_SUCCESS) {
- HDF_LOGE("fail to register event listener");
- return HDF_FAILURE;
- }
- if (SendEvent(serv, sendData)) {
- HDF_LOGE("fail to send event");
- return HDF_FAILURE;
- }
-
- while (g_replyFlag == 0) {
- sleep(1);
- }
-
- if (HdfDeviceUnregisterEventListener(serv, &listener)) {
- HDF_LOGE("fail to unregister listener");
- return HDF_FAILURE;
- }
-
- HdfIoServiceRecycle(serv);
- return HDF_SUCCESS;
-}
-```
-
-> **NOTE:**
->The code compilation of user-level applications depends on the dynamic libraries **hdf\_core** and **osal** provided by the HDF because user-level applications use the message sending interface of the HDF. In the GN compilation file, add the following dependency relationships:
->deps = \[
->"//drivers/adapter/lite/uhdf/manager:hdf\_core",
->"//drivers/adapter/lite/uhdf/posix:hdf\_posix\_osal",
->\]
-
diff --git a/en/device-dev/driver/i2c-overview.md b/en/device-dev/driver/i2c-overview.md
deleted file mode 100644
index 407a149be21029b30d63559117a93b846ce70c00..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/i2c-overview.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# I2C Overview
-
-- [Introduction](#section5361140416)
-- [Available APIs](#section7606310210)
-
-## Introduction
-
-- The Inter-Integrated Circuit \(I2C\) is a simple, bidirectional, and synchronous serial bus that uses merely two wires.
-- In an I2C communication, one controller communicates with one or more devices through the serial data line \(SDA\) and serial clock line \(SCL\), as shown in [Figure 1](#fig1135561232714).
-
-- I2C data transfer must begin with a **START** condition and end with a **STOP** condition. Data is transmitted byte-by-byte from the most significant bit to the least significant bit.
-- Each I2C node is recognized by a unique address and can serve as either a controller or a device. When the controller needs to communicate with a device, it writes the device address to the bus through broadcast. A device matching this address sends a response to set up a data transfer channel.
-
-- The I2C APIs define a set of common functions for I2C data transfer, including:
-
- - I2C controller management: opening or closing an I2C controller
- - I2C message transfer: custom transfer by using a message array
-
- **Figure 1** Physical connection diagram for I2C
- 
-
-
-## Available APIs
-
-**Table 1** APIs available for the I2C driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
I2C controller management
-
-
I2cOpen
-
-
Opens an I2C controller.
-
-
-
I2cClose
-
-
Closes an I2C controller.
-
-
-
I2C message transfer
-
-
I2cTransfer
-
-
Performs a custom transfer.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/i2c-usage-example.md b/en/device-dev/driver/i2c-usage-example.md
deleted file mode 100644
index 438961611a6aba9bcb7e9a89617650a63e7dcd36..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/i2c-usage-example.md
+++ /dev/null
@@ -1,192 +0,0 @@
-# I2C Usage Example
-
-This example describes how to use I2C APIs by using an I2C device on a development board.
-
-This example shows a simple register read/write operation on TouchPad on a Hi3516D V300 development board. The basic hardware information is as follows:
-
-- SoC: hi3516dv300
-
-- Touch IC: The I2C address is 0x38, and the bit width of Touch IC's internal register is 1 byte.
-
-- Schematic diagram: TouchPad is mounted to I2C controller 3. The reset pin of Touch IC is GPIO3.
-
-In this example, first we reset Touch IC. \(The development board supplies power to Touch IC by default after being powered on, and this use case does not consider the power supply\). Then, we perform a read/wirte operation on an internal register to test whether the I2C channel is normal.
-
-> **NOTE:**
->The example focuses on I2C device access and verifies the I2C channel. The read and write values of the device register are not concerned. The behavior caused by the read and write operations on the register is determined by the device itself.
-
-Example:
-
-```
-#include "i2c_if.h" /* Header file of I2C APIs */
-#include "gpio_if.h" /* Header file of GPIO APIs */
-#include "hdf_log.h" /* Header file for log APIs */
-#include "osal_io.h" /* Header file of I/O read and write APIs */
-#include "osal_time.h" /* Header file of delay and sleep APIs */
-
-/* Define a TP device structure to store I2C and GPIO hardware information. */
-struct TpI2cDevice {
- uint16_t rstGpio; /* Reset pin */
- uint16_t busId; /* I2C bus ID */
- uint16_t addr; /* I2C device address */
- uint16_t regLen; /* Register bit width */
- DevHandle i2cHandle; /* I2C controller handle */
-};
-
-/* I2C pin I/O configuration. For details, see the SoC register manual. */
-#define I2C3_DATA_REG_ADDR 0x112f008c /* Address of the SDA pin configuration register of I2C controller 3
-#define I2C3_CLK_REG_ADDR 0x112f0090 /* Address of the SCL pin configuration register of I2C controller 3
-#define I2C_REG_CFG 0x5f1 /* Configuration values of SDA and SCL pins of I2C controller 3
-
-static void TpSocIoCfg(void)
-{
- /* Set the I/O function of the two pins corresponding to I2C controller 3 to I2C. */
- OSAL_WRITEL(I2C_REG_CFG, IO_DEVICE_ADDR(I2C3_DATA_REG_ADDR));
- OSAL_WRITEL(I2C_REG_CFG, IO_DEVICE_ADDR(I2C3_CLK_REG_ADDR));
-}
-
-/* Initialize the reset pin of the TP. Pull up the pin for 20 ms, pull down the pin for 50 ms, and then pull up the pin for 20 ms to complete the resetting. */
-static int32_t TestCaseGpioInit(struct TpI2cDevice *tpDevice)
-{
- int32_t ret;
-
- /* Set the output direction for the reset pin. */
- ret = GpioSetDir(tpDevice->rstGpio, GPIO_DIR_OUT);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set rst dir fail!:%d", __func__, ret);
- return ret;
- }
-
- ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_HIGH);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set rst hight fail!:%d", __func__, ret);
- return ret;
- }
- OsalMSleep(20);
-
- ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_LOW);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set rst low fail!:%d", __func__, ret);
- return ret;
- }
- OsalMSleep(50);
-
- ret = GpioWrite(tpDevice->rstGpio, GPIO_VAL_HIGH);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set rst high fail!:%d", __func__, ret);
- return ret;
- }
- OsalMSleep(20);
-
- return HDF_SUCCESS;
-}
-
-/* Use I2cTransfer to encapsulate a register read/write auxiliary function. Use flag to indicate the read or write operation. */
-static int TpI2cReadWrite(struct TpI2cDevice *tpDevice, unsigned int regAddr,
- unsigned char *regData, unsigned int dataLen, uint8_t flag)
-{
- int index = 0;
- unsigned char regBuf[4] = {0};
- struct I2cMsg msgs[2] = {0};
-
- /* Perform length adaptation for the single- or dual-byte register. */
- if (tpDevice->regLen == 1) {
- regBuf[index++] = regAddr & 0xFF;
- } else {
- regBuf[index++] = (regAddr >> 8) & 0xFF;
- regBuf[index++] = regAddr & 0xFF;
- }
-
- /* Fill in the I2cMsg message structure. */
- msgs[0].addr = tpDevice->addr;
- msgs[0].flags = 0; /* The flag is 0, indicating the write operation. */
- msgs[0].len = tpDevice->regLen;
- msgs[0].buf = regBuf;
-
- msgs[1].addr = tpDevice->addr;
- msgs[1].flags = (flag == 1)? I2C_FLAG_READ: 0; /* Add the read flag. */
- msgs[1].len = dataLen;
- msgs[1].buf = regData;
-
- if (I2cTransfer(tpDevice->i2cHandle, msgs, 2) != 2) {
- HDF_LOGE("%s: i2c read err", __func__);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-
-/* TP register read function */
-static inline int TpI2cReadReg(struct TpI2cDevice *tpDevice, unsigned int regAddr,
- unsigned char *regData, unsigned int dataLen)
-{
- return TpI2cReadWrite(tpDevice, regAddr, regData, dataLen, 1);
-}
-
-/* TP register write function */
-static inline int TpI2cWriteReg(struct TpI2cDevice *tpDevice, unsigned int regAddr,
- unsigned char *regData, unsigned int dataLen)
-{
- return TpI2cReadWrite(tpDevice, regAddr, regData, dataLen, 0);
-}
-
-/* Main entry of I2C */
-static int32_t TestCaseI2c(void)
-{
- int32_t i;
- int32_t ret;
- unsigned char bufWrite[7] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xA, 0xB, 0xC };
- unsigned char bufRead[7] = {0};
- static struct TpI2cDevice tpDevice;
-
- /* I/O pin function configuration */
- TpSocIoCfg();
-
- /* Initialize TP device information. */
- tpDevice.rstGpio = 3;
- tpDevice.busId = 3;
- tpDevice.addr = 0x38;
- tpDevice.regLen = 1;
- tpDevice.i2cHandle = NULL;
-
- /* Initialize the GPIO pin. */
- ret = TestCaseGpioInit(&tpDevice);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: gpio init fail!:%d", __func__, ret);
- return ret;
- }
-
- /* Open an I2C controller. */
- tpDevice.i2cHandle = I2cOpen(tpDevice.busId);
- if (tpDevice.i2cHandle == NULL) {
- HDF_LOGE("%s: Open I2c:%u fail!", __func__, tpDevice.busId);
- return -1;
- }
-
- /* Continuously write 7-byte data to register 0xD5 of TP-IC. */
- ret = TpI2cWriteReg(&tpDevice, 0xD5, bufWrite, 7);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: tp i2c write reg fail!:%d", __func__, ret);
- I2cClose(tpDevice.i2cHandle);
- return -1;
- }
- OsalMSleep(10);
-
- /* Continuously read 7-byte data from register 0xDO of TP-IC. */
- ret = TpI2cReadReg(&tpDevice, 0xD5, bufRead, 7);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: tp i2c read reg fail!:%d", __func__, ret);
- I2cClose(tpDevice.i2cHandle);
- return -1;
- }
-
- HDF_LOGE("%s: tp i2c write&read reg success!", __func__);
- for (i = 0; i < 7; i++) {
- HDF_LOGE("%s: bufRead[%d] = 0x%x", __func__, i, bufRead[i]);
- }
-
- /* Close the I2C controller. */
- I2cClose(tpDevice.i2cHandle);
- return ret;
-}
-```
-
diff --git a/en/device-dev/driver/i2c-usage-guidelines.md b/en/device-dev/driver/i2c-usage-guidelines.md
deleted file mode 100644
index 9a207bcc3878e779d7345ae5b14b18b0b4cdc46b..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/i2c-usage-guidelines.md
+++ /dev/null
@@ -1,171 +0,0 @@
-# I2C Usage Guidelines
-
-- [How to Use](#section333203315215)
-- [Opening an I2C Controller](#section123631358135713)
-- [Performing I2C Communication](#section11091522125812)
-- [Closing an I2C Controller](#section13519505589)
-
-## How to Use
-
-[Figure 1](#fig166181128151112) illustrates the process of an I2C device.
-
-**Figure 1** Process of using an I2C device
-
-
-
-
-## Opening an I2C Controller
-
-Call the following function to open an I2C controller:
-
-DevHandle I2cOpen\(int16\_t number\);
-
-**Table 1** Description of I2cOpen
-
-
-
Parameter
-
-
Description
-
-
-
-
number
-
-
I2C controller ID.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to open the I2C controller.
-
-
-
Device handle
-
-
Handle of the I2C controller.
-
-
-
-
-
-This example assumes that the system has eight I2C controllers \(numbered from 0 to 7\) and I2C controller 3 is to open.
-
-```
-DevHandle i2cHandle = NULL; /* I2C controller handle */
-
-/* Open an I2C controller. */
-i2cHandle = I2cOpen(3);
-if (i2cHandle == NULL) {
- HDF_LOGE("I2cOpen: failed\n");
- return;
-}
-```
-
-## Performing I2C Communication
-
-Use the following function for message transfer:
-
-int32\_t I2cTransfer\(DevHandle handle, struct I2cMsg \*msgs, int16\_t count\);
-
-**Table 2** Description of I2cTransfer
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Handle of an I2C controller.
-
-
-
msgs
-
-
Message array of the data to transfer.
-
-
-
count
-
-
Length of the message array.
-
-
-
Return Value
-
-
Description
-
-
-
Positive integer
-
-
Number of message structures that are successfully transmitted.
-
-
-
Negative value
-
-
Failed to perform the message transfer.
-
-
-
-
-
-The type of an I2C message transfer is defined by **I2cMsg**. Each message structure indicates a read or write operation. Multiple read or write operations can be performed by using a message array.
-
-```
-int32_t ret;
-uint8_t wbuff[2] = { 0x12, 0x13 };
-uint8_t rbuff[2] = { 0 };
-struct I2cMsg msgs[2]; /* Custom message array for transfer */
-msgs[0].buf = wbuff; /* Data to write */
-msgs[0].len = 2; /* The length of the data to write is 2. */
-msgs[0].addr = 0x5A; /* The address of the device to write the data is 0x5A. */
-msgs[0].flags = 0; /* The flag is 0, indicating the write operation. */
-msgs[1].buf = rbuff; /* Data to read */
-msgs[1].len = 2; /* The length of the data to read is 2. */
-msgs[1].addr = 0x5A; /* The address of the device to read the data is 0x5A. */
-msgs[1].flags = I2C_FLAG_READ /* I2C_FLAG_READ is configured, indicating the read operation. */
-/* Perform a custom transfer to transfer two messages. */
-ret = I2cTransfer(i2cHandle, msgs, 2);
-if (ret != 2) {
- HDF_LOGE("I2cTransfer: failed, ret %d\n", ret);
- return;
-}
-```
-
-> **CAUTION:**
->- The device address in the **I2cMsg** structure does not contain the read/write flag bit. The read/write information is transferred by the read/write control bit in the member variable **flags**.
->- The **I2cTransfer** function does not limit the number of message structures, which is determined by the I2C controller.
->- The **I2cTransfer** function does not limit the data length of each message structure, which is determined by the I2C controller.
->- The **I2cTransfer** function may cause the system to sleep and therefore cannot be invoked in the interrupt context.
-
-## Closing an I2C Controller
-
-Call the following function to close the I2C controller after the communication is complete:
-
-void I2cClose\(DevHandle handle\);
-
-**Table 3** Description of I2cClose
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Handle of an I2C controller.
-
-
-
-
-
-```
-I2cClose(i2cHandle); /* Close the I2C controller. */
-```
-
diff --git a/en/device-dev/driver/i2c.md b/en/device-dev/driver/i2c.md
deleted file mode 100644
index 12167aeab9625b16e078335a504c96cf4cfe8422..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/i2c.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# I2C
-
-- **[I2C Overview](i2c-overview.md)**
-
-- **[I2C Usage Guidelines](i2c-usage-guidelines.md)**
-
-- **[I2C Usage Example](i2c-usage-example.md)**
-
-
diff --git a/en/device-dev/driver/lcd.md b/en/device-dev/driver/lcd.md
deleted file mode 100644
index 9930511412c592f0dc36c9fe4b50ee9f206944a9..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/lcd.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# LCD
-
-- **[LCD Overview](lcdoverview.md)**
-
-- **[LCD Development Guidelines](lcddevelopment-guidelines.md)**
-
-- **[LCD Development Example](lcddevelopment-example.md)**
-
-
diff --git a/en/device-dev/driver/lcddevelopment-example.md b/en/device-dev/driver/lcddevelopment-example.md
deleted file mode 100644
index 35122ca4fa69878a8c36e658da23082b0c0084e0..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/lcddevelopment-example.md
+++ /dev/null
@@ -1,291 +0,0 @@
-# LCD Development Example
-
-Add the device description.
-
-```
-/* Description of the display driver */
-display :: host {
- hostName = "display_host";
- /* Description of the HDF display driver */
- device_hdf_disp :: device {
- device0 :: deviceNode {
- policy = 2;
- priority = 200;
- permission = 0660;
- moduleName = "HDF_DISP";
- serviceName = "hdf_disp";
- }
- }
- /* Description of the driver device at the SoC adapter layer */
- device_hi35xx_disp :: device {
- device0 :: deviceNode {
- policy = 0;
- priority = 199;
- moduleName = "HI351XX_DISP";
- }
- }
- /* Description of the LCD driver */
- device_lcd :: device {
- device0 :: deviceNode {
- policy = 0;
- priority = 100;
- preload = 0;
- moduleName = "LCD_Sample";
- }
- device1 :: deviceNode {
- policy = 0;
- priority = 100;
- preload = 2;
- moduleName = "LCD_SampleXX";
- }
- }
-}
-```
-
-The following example shows how to adapt to the MIPI device to the Hi35xx series chips at the SoC adapter layer:
-
-```
-static int32_t MipiDsiInit(struct PanelInfo *info)
-{
- int32_t ret;
- struct DevHandle *mipiHandle = NULL;
- struct MipiCfg cfg;
-
- mipiHandle = MipiDsiOpen(0);
- if (mipiHandle == NULL) {
- HDF_LOGE("%s: MipiDsiOpen failure", __func__);
- return HDF_FAILURE;
- }
- cfg.lane = info->mipi.lane;
- cfg.mode = info->mipi.mode;
- cfg.format = info->mipi.format;
- cfg.burstMode = info->mipi.burstMode;
- cfg.timing.xPixels = info->width;
- cfg.timing.hsaPixels = info->hsw;
- cfg.timing.hbpPixels = info->hbp;
- cfg.timing.hlinePixels = info->width + info->hbp + info->hfp + info->hsw;
- cfg.timing.vsaLines = info->vsw;
- cfg.timing.vbpLines = info->vbp;
- cfg.timing.vfpLines = info->vfp;
- cfg.timing.ylines = info->height;
- /* 0 : no care */
- cfg.timing.edpiCmdSize = 0;
- cfg.pixelClk = CalcPixelClk(info);
- cfg.phyDataRate = CalcDataRate(info);
- /* config mipi device */
- ret = MipiDsiSetCfg(mipiHandle, &cfg);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s:MipiDsiSetCfg failure", __func__);
- }
- MipiDsiClose(mipiHandle);
- HDF_LOGI("%s:pixelClk = %d, phyDataRate = %d\n", __func__,
- cfg.pixelClk, cfg.phyDataRate);
- return ret;
-}
-```
-
-The following example shows code for developing an LCD driver:
-
-```
-#define RESET_GPIO 5
-#define MIPI_DSI0 0
-#define BLK_PWM1 1
-#define PWM_MAX_PERIOD 100000
-/* backlight setting */
-#define MIN_LEVEL 0
-#define MAX_LEVEL 255
-#define DEFAULT_LEVEL 100
-
-#define WIDTH 480
-#define HEIGHT 960
-#define HORIZONTAL_BACK_PORCH 20
-#define HORIZONTAL_FRONT_PORCH 20
-#define HORIZONTAL_SYNC_WIDTH 10
-#define VERTIACL_BACK_PORCH 14
-#define VERTIACL_FRONT_PORCH 16
-#define VERTIACL_SYNC_WIDTH 2
-#define FRAME_RATE 60
-
-/* Panel information structure */
-struct PanelInfo {
- uint32_t width;
- uint32_t height;
- uint32_t hbp;
- uint32_t hfp;
- uint32_t hsw;
- uint32_t vbp;
- uint32_t vfp;
- uint32_t vsw;
- uint32_t frameRate;
- enum LcdIntfType intfType;
- enum IntfSync intfSync;
- struct MipiDsiDesc mipi;
- struct BlkDesc blk;
- struct PwmCfg pwm;
-};
-
-/* Initialization sequence of the LCD panel */
-static uint8_t g_payLoad0[] = { 0xF0, 0x5A, 0x5A };
-static uint8_t g_payLoad1[] = { 0xF1, 0xA5, 0xA5 };
-static uint8_t g_payLoad2[] = { 0xB3, 0x03, 0x03, 0x03, 0x07, 0x05, 0x0D, 0x0F, 0x11, 0x13, 0x09, 0x0B };
-static uint8_t g_payLoad3[] = { 0xB4, 0x03, 0x03, 0x03, 0x06, 0x04, 0x0C, 0x0E, 0x10, 0x12, 0x08, 0x0A };
-static uint8_t g_payLoad4[] = { 0xB0, 0x54, 0x32, 0x23, 0x45, 0x44, 0x44, 0x44, 0x44, 0x60, 0x00, 0x60, 0x1C };
-static uint8_t g_payLoad5[] = { 0xB1, 0x32, 0x84, 0x02, 0x87, 0x12, 0x00, 0x50, 0x1C };
-static uint8_t g_payLoad6[] = { 0xB2, 0x73, 0x09, 0x08 };
-static uint8_t g_payLoad7[] = { 0xB6, 0x5C, 0x5C, 0x05 };
-static uint8_t g_payLoad8[] = { 0xB8, 0x23, 0x41, 0x32, 0x30, 0x03 };
-static uint8_t g_payLoad9[] = { 0xBC, 0xD2, 0x0E, 0x63, 0x63, 0x5A, 0x32, 0x22, 0x14, 0x22, 0x03 };
-static uint8_t g_payLoad10[] = { 0xb7, 0x41 };
-static uint8_t g_payLoad11[] = { 0xC1, 0x0c, 0x10, 0x04, 0x0c, 0x10, 0x04 };
-static uint8_t g_payLoad12[] = { 0xC2, 0x10, 0xE0 };
-static uint8_t g_payLoad13[] = { 0xC3, 0x22, 0x11 };
-static uint8_t g_payLoad14[] = { 0xD0, 0x07, 0xFF };
-static uint8_t g_payLoad15[] = { 0xD2, 0x63, 0x0B, 0x08, 0x88 };
-static uint8_t g_payLoad16[] = { 0xC6, 0x08, 0x15, 0xFF, 0x10, 0x16, 0x80, 0x60 };
-static uint8_t g_payLoad17[] = { 0xc7, 0x04 };
-static uint8_t g_payLoad18[] = {
- 0xC8, 0x7C, 0x50, 0x3B, 0x2C, 0x25, 0x16, 0x1C, 0x08, 0x27, 0x2B, 0x2F, 0x52, 0x43, 0x4C, 0x40,
- 0x3D, 0x30, 0x1E, 0x06, 0x7C, 0x50, 0x3B, 0x2C, 0x25, 0x16, 0x1C, 0x08, 0x27, 0x2B, 0x2F, 0x52,
- 0x43, 0x4C, 0x40, 0x3D, 0x30, 0x1E, 0x06
-};
-static uint8_t g_payLoad19[] = { 0x11 };
-static uint8_t g_payLoad20[] = { 0x29 };
-
-struct DsiCmdDesc g_OnCmd[] = {
- { 0x29, 0, sizeof(g_payLoad0), g_payLoad0 },
- { 0x29, 0, sizeof(g_payLoad1), g_payLoad1 },
- { 0x29, 0, sizeof(g_payLoad2), g_payLoad2 },
- { 0x29, 0, sizeof(g_payLoad3), g_payLoad3 },
- { 0x29, 0, sizeof(g_payLoad4), g_payLoad4 },
- { 0x29, 0, sizeof(g_payLoad5), g_payLoad5 },
- { 0x29, 0, sizeof(g_payLoad6), g_payLoad6 },
- { 0x29, 0, sizeof(g_payLoad7), g_payLoad7 },
- { 0x29, 0, sizeof(g_payLoad8), g_payLoad8 },
- { 0x29, 0, sizeof(g_payLoad9), g_payLoad9 },
- { 0x23, 0, sizeof(g_payLoad10), g_payLoad10 },
- { 0x29, 0, sizeof(g_payLoad11), g_payLoad11 },
- { 0x29, 0, sizeof(g_payLoad12), g_payLoad12 },
- { 0x29, 0, sizeof(g_payLoad13), g_payLoad13 },
- { 0x29, 0, sizeof(g_payLoad14), g_payLoad14 },
- { 0x29, 0, sizeof(g_payLoad15), g_payLoad15 },
- { 0x29, 0, sizeof(g_payLoad16), g_payLoad16 },
- { 0x23, 0, sizeof(g_payLoad17), g_payLoad17 },
- { 0x29, 1, sizeof(g_payLoad18), g_payLoad18 },
- { 0x05, 120, sizeof(g_payLoad19), g_payLoad19 },
- { 0x05, 120, sizeof(g_payLoad20), g_payLoad20 },
-};
-static DevHandle g_mipiHandle = NULL;
-static DevHandle g_pwmHandle = NULL;
-
-/* Set the status of the reset pin. */
-static int32_t LcdResetOn(void)
-{
- int32_t ret;
- ret = GpioSetDir(RESET_GPIO, GPIO_DIR_OUT);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("GpioSetDir failure, ret:%d", ret);
- return HDF_FAILURE;
- }
- ret = GpioWrite(RESET_GPIO, GPIO_VAL_HIGH);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("GpioWrite failure, ret:%d", ret);
- return HDF_FAILURE;
- }
- /* delay 20ms */
- OsalMSleep(20);
- return HDF_SUCCESS;
-}
-
-static int32_t SampleInit(void)
-{
- /* Obtain the MIPI DSI device handle. */
- g_mipiHandle = MipiDsiOpen(MIPI_DSI0);
- if (g_mipiHandle == NULL) {
- HDF_LOGE("%s: MipiDsiOpen failure", __func__);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-
-static int32_t SampleOn(void)
-{
- int32_t ret;
- /* Power on the LCD. */
- ret = LcdResetOn();
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: LcdResetOn failure", __func__);
- return HDF_FAILURE;
- }
- if (g_mipiHandle == NULL) {
- HDF_LOGE("%s: g_mipiHandle is null", __func__);
- return HDF_FAILURE;
- }
- /* Send the initialization sequence via MIPI. */
- int32_t count = sizeof(g_OnCmd) / sizeof(g_OnCmd[0]);
- int32_t i;
- for (i = 0; i < count; i++) {
- ret = MipiDsiTx(g_mipiHandle, &(g_OnCmd[i]));
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("MipiDsiTx failure");
- return HDF_FAILURE;
- }
- }
- /* Set MIPI to the high speed (HS) mode. */
- MipiDsiSetHsMode(g_mipiHandle);
- return HDF_SUCCESS;
-}
-
-/* PanelInfo structure variables */
-static struct PanelInfo g_panelInfo = {
- .width = WIDTH, /* width */
- .height = HEIGHT, /* height */
- .hbp = HORIZONTAL_BACK_PORCH, /* horizontal back porch */
- .hfp = HORIZONTAL_FRONT_PORCH, /* horizontal front porch */
- .hsw = HORIZONTAL_SYNC_WIDTH, /* horizontal sync width */
- .vbp = VERTIACL_BACK_PORCH, /* vertiacl back porch */
- .vfp = VERTIACL_FRONT_PORCH, /* vertiacl front porch */
- .vsw = VERTIACL_SYNC_WIDTH, /* vertiacl sync width */
- .frameRate = FRAME_RATE, /* frame rate */
- .intfType = MIPI_DSI, /* panel interface type */
- .intfSync = OUTPUT_USER, /* output timming type */
- /* mipi config info */
- .mipi = { DSI_2_LANES, DSI_VIDEO_MODE, VIDEO_BURST_MODE, FORMAT_RGB_24_BIT },
- /* backlight config info */
- .blk = { BLK_PWM, MIN_LEVEL, MAX_LEVEL, DEFAULT_LEVEL },
- .pwm = { BLK_PWM1, PWM_MAX_PERIOD },
-};
-
-/* Basic APIs that need to be adapted for the chip driver */
-static struct PanelData g_panelData = {
- .info = &g_panelInfo,
- .init = SampleInit,
- .on = SampleOn,
- .off = SampleOff,
- .setBacklight = SampleSetBacklight,
-};
-
-/* Entry function of the chip driver */
-int32_t SampleEntryInit(struct HdfDeviceObject *object)
-{
- HDF_LOGI("%s: enter", __func__);
- if (object == NULL) {
- HDF_LOGE("%s: param is null!", __func__);
- return HDF_FAILURE;
- }
- /* Register the chip driver APIs with the platform driver. */
- if (PanelDataRegister(&g_panelData) != HDF_SUCCESS) {
- HDF_LOGE("%s: PanelDataRegister error!", __func__);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-
-struct HdfDriverEntry g_sampleDevEntry = {
- .moduleVersion = 1,
- .moduleName = "LCD_SAMPLE",
- .Init = SampleEntryInit,
-};
-
-HDF_INIT(g_sampleDevEntry);
-```
-
diff --git a/en/device-dev/driver/lcddevelopment-guidelines.md b/en/device-dev/driver/lcddevelopment-guidelines.md
deleted file mode 100644
index a7d0f9cb7453fe32c2c9448eba76bd2cac09ec45..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/lcddevelopment-guidelines.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# LCD Development Guidelines
-
-- [How to Develop](#section3904154911218)
-
-The display driver model is developed based on the HDF, platform APIs, and APIs at the OS abstraction layer \(OSAL\), and provides a unified driver model for the LCD regardless of the OS \(LiteOS or Linux OS\) and chip platforms \(such as Hi35xx, Hi38xx, and V3S\).
-
-## How to Develop
-
-1. Add the LCD driver-related hardware descriptions.
-2. Add a driver that adapts to the chip at the SoC adapter layer.
-3. Add the LCD panel driver and register the panel driver functions in the driver entry function **Init**. The functions provide capabilities for:
- - Powering on/off the LCD device
-
- Based on the LCD hardware connection, use the GPIO interfaces provided by the platform to perform operations on the LCD pins, such as the reset pin and IOVCC pin. For details about the power-on sequence, see the SPEC provided by the LCD supplier.
-
- - Sending the initialization sequence
-
- 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/lcdoverview.md b/en/device-dev/driver/lcdoverview.md
deleted file mode 100644
index 08ba05e1f409a702a3b4334ce7124a4e80f5af57..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/lcdoverview.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# LCD Overview
-
-- [Introduction](#section3781515122118)
-- [API Description](#section20280192712120)
-
-## Introduction
-
-The Liquid Crystal Display \(LCD\) driver powers on the LCD and initializes internal LCD registers APIs to enable the LCD to work properly. The display driver is developed based on the hardware driver foundation \([HDF](hdfoverview.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
-
-
-- **Display driver model**
-
- The display driver model consists of the display common driver layer, SoC adapter layer, and third-party chip driver layer. It is developed based on the HDF and hides the differences between kernel forms through platform and OSAL APIs so the LCD driver can be migrated to different OSs and chip platforms. The display driver connects to the display common HAL, supports the implementation of Hardware Driver Interfaces \(HDIs\), and provides various driver interfaces for the graphics service through the display HDI.
-
- - Display common driver layer: connects to the display common HAL through the IOService data channel provided by the HDF to receive and process various upper-layer calls in a centralized manner.
-
- - SoC adapter layer: decouples the display driver from the SoC driver, configures parameters related to the chip platform, and passes the calls at the platform driver layer to the LCD driver layer.
-
- - Third-party chip driver layer: provides LCD-related APIs for sending the LCD initialization sequence, powering on or off the LCD device, and setting the backlight.
-
- Based on the display driver model, various capabilities, and APIs, you can greatly simplify the display driver development and improve the efficiency.
-
-
-## API Description
-
-The LCD interfaces are classified into the Mobile Industry Processor Interface \(MIPI\) Display Serial Interface \(DSI\), Transistor Transistor Logic \(TTL\) interfaces, and Low Voltage Differential Signaling \(LVDS\) interfaces. The MIPI DSI and TTL interfaces are commonly used. Here is a brief introduction to them.
-
-- MIPI DSI
-
- **Figure 2** MIPI DSI
- 
-
- The MIPI DSI is defined by MIPI Alliance. It is mainly used for mobile terminal display. The MIPI DSI is used to transmit image data, in compliance with the MIPI protocol. Generally, control information of the MIPI DSI is sent to the peer IC in the form of MIPI packets through the MIPI DSI. No additional interface is required.
-
-- TTL interface
-
- **Figure 3** TTL interface
- 
-
- TTL level signals are generated by TTL devices, which are a major type of digital integrated circuits. They are manufactured using the bipolar process and feature high speed, low power consumption, and multiple types.
-
- The TTL interface is used to transmit data in parallel mode. It transmits data signals, clock signals, and control signals \(such as line synchronization signals, frame synchronization signals, and data validity signals\) under the control of control signals. Generally, the LCD of the TTL interface and the read/write of internal registers require additional peripheral interfaces, such as the Serial Peripheral Interface \(SPI\) and Inter-Integrated Circuit \(I2C\).
-
-
diff --git a/en/device-dev/driver/mipi-dsi-overview.md b/en/device-dev/driver/mipi-dsi-overview.md
deleted file mode 100644
index ec579fba093ecad64f31fd5d00b429878829a652..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/mipi-dsi-overview.md
+++ /dev/null
@@ -1,84 +0,0 @@
-# MIPI DSI Overview
-
-- [Introduction](#section1369320102013)
-- [Available APIs](#section6577545192317)
-
-## Introduction
-
-- The Display Serial Interface \(DSI\) is a specification stipulated by the Mobile Industry Processor Interface \(MIPI\) Alliance, aiming to reduce the cost of display controllers in a mobile device. It defines a serial bus and communication protocol among the host, the source of image data, and the target device. In this way, the DSI can send pixel data or commands to peripherals \(usually LCDs or similar display devices\) in serial mode, or reads information such as status and pixel from the peripherals.
-
-- MIPI DSI is capable of working in both high speed \(HS\) mode and low power \(LP\) mode. All data lanes can only travel from the DSI host to a peripheral in HS mode, except the first data lane, which can also receive data such as status information and pixels from the peripheral in LP mode. The clock lane is dedicated to transmitting synchronization clock signals in HS mode.
- - [Figure 1](#fig1122611461203) shows a simplified DSI interface. Conceptually, a DSI-compliant interface has the same features as interfaces complying with DBI-2 and DPI-2 standards. It sends pixels or commands to a peripheral and can read status or pixel information from the peripheral. The main difference is that the DSI serializes all pixel data, commands, and events that, in traditional interfaces, are conveyed to and from the peripheral on a parallel data bus with additional control signals.
-
- **Figure 1** DSI transmitting and receiving Interface
- 
-
-
-
-## Available APIs
-
-**Table 1** APIs for MIPI DSI
-
-
-
Sets configuration parameters for a MIPI DSI device.
-
-
-
MipiDsiGetCfg
-
-
Obtains the configuration parameters of a MIPI DSI device.
-
-
-
Obtaining /Releasing device handles
-
-
MipiDsiOpen
-
-
Obtains a MIPI DSI device handle.
-
-
-
MipiDsiClose
-
-
Releases a specified MIPI DSI device handle.
-
-
-
Setting the LP or HS mode
-
-
MipiDsiSetLpMode
-
-
Sets LP mode for a MIPI DSI device.
-
-
-
MipiDsiSetHsMode
-
-
Sets HS mode for a MIPI DSI device.
-
-
-
Reading/Sending commands
-
-
MipiDsiTx
-
-
Sends a display command set (DCS) command for sending data.
-
-
-
MipiDsiRx
-
-
Receives a DCS command for reading data with the specified length.
-
-
-
-
-
-> **NOTE:**
->All functions described in this document can be called only in kernel space.
-
diff --git a/en/device-dev/driver/mipi-dsi.md b/en/device-dev/driver/mipi-dsi.md
deleted file mode 100644
index f50672962f5c2602a93f63821ac290de3271ad02..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/mipi-dsi.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# MIPI DSI
-
-- **[MIPI DSI Overview](mipi-dsi-overview.md)**
-
-- **[Usage Guidelines](usage-guidelines.md)**
-
-- **[Usage Example](usage-example.md)**
-
-
diff --git a/en/device-dev/driver/peripherals.md b/en/device-dev/driver/peripherals.md
deleted file mode 100644
index 42016f572c98cb63bfd17d6994f67367f3c8bc5d..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/peripherals.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Peripherals
-
-- **[LCD](lcd.md)**
-
-- **[TOUCHSCREEN](touchscreen.md)**
-
-- **[SENSOR](sensor.md)**
-
-- **[WLAN](wlan.md)**
-
-
diff --git a/en/device-dev/driver/public_sys-resources/icon-caution.gif b/en/device-dev/driver/public_sys-resources/icon-caution.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/driver/public_sys-resources/icon-caution.gif and /dev/null differ
diff --git a/en/device-dev/driver/public_sys-resources/icon-danger.gif b/en/device-dev/driver/public_sys-resources/icon-danger.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/driver/public_sys-resources/icon-danger.gif and /dev/null differ
diff --git a/en/device-dev/driver/public_sys-resources/icon-note.gif b/en/device-dev/driver/public_sys-resources/icon-note.gif
deleted file mode 100644
index 6314297e45c1de184204098efd4814d6dc8b1cda..0000000000000000000000000000000000000000
Binary files a/en/device-dev/driver/public_sys-resources/icon-note.gif and /dev/null differ
diff --git a/en/device-dev/driver/public_sys-resources/icon-notice.gif b/en/device-dev/driver/public_sys-resources/icon-notice.gif
deleted file mode 100644
index 86024f61b691400bea99e5b1f506d9d9aef36e27..0000000000000000000000000000000000000000
Binary files a/en/device-dev/driver/public_sys-resources/icon-notice.gif and /dev/null differ
diff --git a/en/device-dev/driver/public_sys-resources/icon-tip.gif b/en/device-dev/driver/public_sys-resources/icon-tip.gif
deleted file mode 100644
index 93aa72053b510e456b149f36a0972703ea9999b7..0000000000000000000000000000000000000000
Binary files a/en/device-dev/driver/public_sys-resources/icon-tip.gif and /dev/null differ
diff --git a/en/device-dev/driver/public_sys-resources/icon-warning.gif b/en/device-dev/driver/public_sys-resources/icon-warning.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/driver/public_sys-resources/icon-warning.gif and /dev/null differ
diff --git a/en/device-dev/driver/rtc-overview.md b/en/device-dev/driver/rtc-overview.md
deleted file mode 100644
index 97aa8a24369a26fed6689751accb5ab46ce7fa89..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/rtc-overview.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# RTC Overview
-
-- [Introduction](#section104842041574)
-- [Available APIs](#section16892932155715)
-
-## Introduction
-
-The real-time clock \(RTC\) driver provides precise real time for the operating system \(OS\). If the OS is powered off, the RTC driver continues to keep track of the system time using an external battery.
-
-## Available APIs
-
-**Table 1** APIs provided by the RTC driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
RTC handle
-
-
RtcOpen
-
-
Opens the RTC device to obtain its handle.
-
-
-
RtcClose
-
-
Releases a specified handle of the RTC device.
-
-
-
RTC time
-
-
RtcReadTime
-
-
Reads time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
RtcWriteTime
-
-
Writes time information from the RTC driver, including the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
RTC alarm
-
-
RtcReadAlarm
-
-
Reads the RTC alarm time that was set last time.
-
-
-
RtcWriteAlarm
-
-
Writes the RTC alarm time based on the alarm index.
-
-
-
RtcRegisterAlarmCallback
-
-
Registers RtcAlarmCallback that will be invoked when an alarm is generated at the specified time.
-
-
-
RtcAlarmInterruptEnable
-
-
Enables or disables RTC alarm interrupts.
-
-
-
RTC configuration
-
-
RtcGetFreq
-
-
Reads the frequency of the external crystal oscillator connected to the RTC driver.
-
-
-
RtcSetFreq
-
-
Sets the frequency of the external crystal oscillator connected to the RTC driver.
-
-
-
RtcReset
-
-
Resets the RTC.
-
-
-
Custom register
-
-
RtcReadReg
-
-
Reads the configuration of a custom RTC register based on the register index.
-
-
-
RtcWriteReg
-
-
Writes the configuration of a custom RTC register based on the register index.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/rtc-usage-example.md b/en/device-dev/driver/rtc-usage-example.md
deleted file mode 100644
index e546c2f1433a2ce6810b93b43fd26f4c17f8e5a7..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/rtc-usage-example.md
+++ /dev/null
@@ -1,97 +0,0 @@
-# RTC Usage Example
-
-This section describes the process of using RTC APIs:
-
-1. During the OS startup, the HDF identifies the RTC component in the system.
-2. The HDF initializes and creates the RTC device.
-3. You can perform operations on the RTC device by calling different APIs.
-4. Call the **RtcClose** function to release the device handle and device resources.
-
-Example:
-
-```
-#include "rtc_if.h"
-int32_t RtcAlarmACallback(enum RtcAlarmIndex alarmIndex)
-{
- if (alarmIndex == RTC_ALARM_INDEX_A) {
- /* Process alarm A. */
- printf("RTC Alarm A callback function\n\r");
- } else if (alarmIndex == RTC_ALARM_INDEX_B) {
- /* Process alarm B. */
- printf("RTC Alarm B callback function\n\r");
- } else {
- /* Process the error. */
- }
- return 0;
-}
-
-void RtcTestSample(void)
-{
- int32_t ret;
- struct RtcTime tm;
- struct RtcTime alarmTime;
- uint32_t freq;
- DevHandle handle = NULL;
-
- /* Obtain the RTC device handle. */
- handle = RtcOpen();
- if (handle == NULL) {
- /* Process the error. */
- }
- /* Register RtcAlarmCallback for alarm A. */
- ret = RtcRegisterAlarmCallback(handle, RTC_ALARM_INDEX_A, RtcAlarmACallback);
- if (ret != 0) {
- /* Process the error. */
- }
- /* Set the RTC external crystal frequency. Note that the frequency must be configured in accordance with the requirements specified in the product manual of the in-use component. */
- freq = 32768; /* 32768 Hz */
- ret = RtcSetFreq(handle, freq);
- if (ret != 0) {
- /* Process the error. */
- }
- /* Enable the RTC alarm interrupts. */
- ret = RtcAlarmInterruptEnable(handle, RTC_ALARM_INDEX_A, 1);
- if (ret != 0) {
- /* Process the error. */
- }
- /* Set the RTC time to 2020/01/01 00:00:10 .990. */
- tm.year = 2020;
- tm.month = 01;
- tm.day = 01;
- tm.hour= 0;
- tm.minute = 0;
- tm.second = 10;
- tm.millisecond = 990;
- /* Write the RTC time information. */
- ret = RtcWriteTime(handle, &tm);
- if (ret != 0) {
- /* Process the error. */
- }
- /* Set the RTC alarm time to 2020/01/01 00:00:30 .100. */
- alarmTime.year = 2020;
- alarmTime.month = 01;
- alarmTime.day = 01;
- alarmTime.hour = 0;
- alarmTime.minute = 0;
- alarmTime.second = 30;
- alarmTime.millisecond = 100;
- /* Set the alarm time information for RTC_ALARM_INDEX_A. When the specified time is reached, "RTC Alarm A callback function" is printed. */
- ret = RtcWriteAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
- if (ret != 0) {
- /* Process the error. */
- }
-
- /* Read the RTC real time. */
- ret = RtcReadTime(handle, &tm);
- if (ret != 0) {
- /* Process the error. */
- }
- sleep(5)
- printf("RTC read time:\n\r");
- printf("year-month-date-weekday hour:minute:second .millisecond %04u-%02u-%02u-%u %02u:%02u:%02u .%03u",
- tm.year, tm.month, tm.day, tm.weekday, tm.hour, tm.minute, tm.second, tm.millisecond);
- /* Release the RTC device handle. */
- RtcClose(handle);
-}
-```
-
diff --git a/en/device-dev/driver/rtc-usage-guidelines.md b/en/device-dev/driver/rtc-usage-guidelines.md
deleted file mode 100644
index 3d0a2f6638021e4ab54ec680a06b134a873685b8..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/rtc-usage-guidelines.md
+++ /dev/null
@@ -1,741 +0,0 @@
-# RTC Usage Guidelines
-
-- [How to Use](#section620515765714)
-- [Creating an RTC Device Handle](#section0702183665711)
-- [Releasing the RTC Device Handle](#section639962619542)
-- [Registering RtcAlarmCallback](#section123631358135713)
-- [Performing RTC-related Operations](#section11091522125812)
-
-## How to Use
-
-During the OS startup, the HDF loads the RTC driver based on the configuration file. The RTC driver detects the RTC component and initializes the driver.
-
-[Figure 1](#fig166181128151112) illustrates the process of an RTC device.
-
-**Figure 1** Process of using an RTC device
-
-
-
-
-## Creating an RTC Device Handle
-
-After the RTC driver is loaded successfully, you can use the API provided by the HDF and call APIs of the RTC driver.
-
-> **NOTE:**
->Currently, only one RTC device is supported in the OS.
-
-DevHandle RtcOpen\(void\);
-
-**Table 1** Description of **RtcOpen**
-
-
-
Parameter
-
-
Description
-
-
-
void
-
-
N/A
-
-
-
Return Value
-
-
Description
-
-
-
handle
-
-
Returns the pointer if the operation is successful.
-
-
-
NULL
-
-
The operation fails.
-
-
-
-
-
-```
-DevHandle handle = NULL;
-
-/* Obtain the RTC device handle. */
-handle = RtcOpen();
-if (handle == NULL) {
- /* Process the error. */
-}
-```
-
-## Releasing the RTC Device Handle
-
-You can call the following function to release the RTC device handle, thereby releasing resources of the device:
-
-void RtcClose\(DevHandle handle\);
-
-**Table 2** Description of **RtcClose**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle
-
-
-
-
-
-```
-/* Release the RTC device handle. */
-RtcClose(handle);
-```
-
-## Registering RtcAlarmCallback
-
-After the OS is started, call the following function to register **RtcAlarmCallback**, which will be invoked when an alarm is generated at the specified time:
-
-int32\_t RtcRegisterAlarmCallback\(DevHandle handle, enum RtcAlarmIndex alarmIndex, RtcAlarmCallback cb\);
-
-**Table 3** Description of **RtcRegisterAlarmCallback**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
alarmIndex
-
-
Alarm index.
-
-
-
cb
-
-
Callback that will be invoked when an alarm is generated at the specified time.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-The following is an example of registering **RtcAlarmCallback** for processing alarm **RTC\_ALARM\_INDEX\_A**:
-
-```
-/* Register an RTC alarm callback. */
-int32_t RtcAlarmACallback(enum RtcAlarmIndex alarmIndex)
-{
- if (alarmIndex == RTC_ALARM_INDEX_A) {
- /* Process alarm A. */
- } else if (alarmIndex == RTC_ALARM_INDEX_B) {
- /* Process alarm B. */
- } else {
- /* Process the error. */
- }
- return 0;
-}
-int32_t ret;
-/* Register RtcAlarmCallback for alarm A. */
-ret = RtcRegisterAlarmCallback(handle, RTC_ALARM_INDEX_A, RtcAlarmACallback);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-## Performing RTC-related Operations
-
-- Reading RTC time
-
-Call the following function to read time information from the RTC driver, including the year, month, the day fo the week, day, hour, minute, second, and millisecond:
-
-int32\_t RtcReadTime\(DevHandle handle, struct RtcTime \*time\);
-
-**Table 4** Description of **RtcReadTime**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
time
-
-
Pointer to the time information read from the RTC driver. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-struct RtcTime tm;
-
-/* Read time information from the RTC driver. */
-ret = RtcReadTime(handle, &tm);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Setting RTC time
-
-Call the following function to set the RTC time:
-
-int32\_t RtcWriteTime\(DevHandle handle, struct RtcTime \*time\);
-
-**Table 5** Description of **RtcWriteTime**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
time
-
-
Pointer to the time information written into the RTC driver. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-> **NOTE:**
->The RTC start time is 1970/01/01 Thursday 00:00:00 \(UTC\). The maximum value of **year** must be set based on the requirements specified in the product manual of the in-use component. You do not need to configure the day of the week.
-
-```
-int32_t ret;
-struct RtcTime tm;
-
-/* Set the RTC time to UTC 2020/01/01 00:59:00 .000. */
-tm.year = 2020;
-tm.month = 01;
-tm.day = 01;
-tm.hour= 00;
-tm.minute = 59;
-tm.second = 00;
-tm.millisecond = 0;
-/* Write the RTC time information. */
-ret = RtcWriteTime(handle, &tm);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Reading the RTC alarm time
-
-Call the following function to read the alarm time:
-
-int32\_t RtcReadAlarm\(DevHandle handle, enum RtcAlarmIndex alarmIndex, struct RtcTime \*time\);
-
-**Table 6** Description of **RtcReadAlarm**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
alarmIndex
-
-
Alarm index.
-
-
-
time
-
-
Pointer to the RTC alarm time information. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-struct RtcTime alarmTime;
-
-/* Read the RTC alarm time information of alarm RTC_ALARM_INDEX_A. */
-ret = RtcReadAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Setting RTC alarm time
-
-Call the following function to set the RTC alarm time based on the alarm index:
-
-int32\_t RtcWriteAlarm\(DevHandle handle, enum RtcAlarmIndex alarmIndex, struct RtcTime \*time\);
-
-**Table 7** Description of **RtcWriteAlarm**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
alarmIndex
-
-
Alarm index.
-
-
-
time
-
-
Pointer to the RTC alarm time information. The time information includes the year, month, the day of the week, day, hour, minute, second, and millisecond.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-> **NOTE:**
->The RTC start time is 1970/01/01 Thursday 00:00:00 \(UTC\). The maximum value of **year** must be set based on the requirements specified in the product manual of the in-use component. You do not need to configure the day of the week.
-
-```
-int32_t ret;
-struct RtcTime alarmTime;
-
-/* Set the RTC alarm time to 2020/01/01 00:59:59 .000. */
-alarmTime.year = 2020;
-alarmTime.month = 01;
-alarmTime.day = 01;
-alarmTime.hour = 00;
-alarmTime.minute = 59;
-alarmTime.second = 59;
-alarmTime.millisecond = 0;
-/* Set the alarm time of alarm RTC_ALARM_INDEX_A. */
-ret = RtcWriteAlarm(handle, RTC_ALARM_INDEX_A, &alarmTime);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Enabling or disabling alarm interrupts
-
-Before performing alarm operations, use this function to enable alarm interrupts, so that **RtcAlarmCallback** will be called when the alarm is not generated upon a timeout.
-
-int32\_t RtcAlarmInterruptEnable\(DevHandle handle, enum RtcAlarmIndex alarmIndex, uint8\_t enable\);
-
-**Table 8** Description of **RtcAlarmInterruptEnable**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
alarmIndex
-
-
Alarm index.
-
-
-
enable
-
-
Whether to enable RTC alarm interrupts. Value 1 means to enable alarm interrupts and value 0 means to disable alarm interrupts.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-
-/* Enable the RTC alarm interrupts. */
-ret = RtcAlarmInterruptEnable(handle, RTC_ALARM_INDEX_A, 1);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Reading RTC external frequency
-
-Call the following function to read the frequency of the external crystal oscillator connected to the RTC driver:
-
-int32\_t RtcGetFreq\(DevHandle handle, uint32\_t \*freq\);
-
-**Table 9** Description of **RtcGetFreq**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
freq
-
-
Frequency to set for the external crystal oscillator, in Hz.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-uint32_t freq = 0;
-
-/* Read frequency of the external crystal oscillator connected to the RTC driver */
-ret = RtcGetFreq(handle, &freq);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Setting the frequency of the external crystal oscillator connected to the RTC driver
-
-Call the following function to set the frequency of the external crystal oscillator connected to the RTC driver:
-
-int32\_t RtcSetFreq\(DevHandle handle, uint32\_t freq\);
-
-**Table 10** Description of **RtcSetFreq**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
freq
-
-
Frequency to set for the external crystal oscillator, in Hz.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-uint32_t freq = 32768; /* 32768 Hz */
-
-/* Set the frequency of the external crystal oscillator. Note that the frequency must be configured in accordance with the requirements specified in the product manual of the in-use component. */
-ret = RtcSetFreq(handle, freq);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Resetting the RTC driver
-
-Call the following function to perform a reset on the RTC driver. After the reset, the registers are restored to the default values:
-
-int32\_t RtcReset\(DevHandle handle\);
-
-**Table 11** Description of **RtcReset**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-
-/* Reset the RTC driver. After the reset, the configuration registers are restored to the default values. */
-ret = RtcReset(handle);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Reading the configuration of a custom RTC register
-
-Call the following function to read the configuration of a custom RTC register based on the register index \(one index corresponds to one byte of the configuration value\):
-
-int32\_t RtcReadReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t \*value\);
-
-**Table 12** Description of **RtcReadReg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
usrDefIndex
-
-
Index of the custom register.
-
-
-
value
-
-
Register value.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t usrDefIndex = 0; /* Define index 0 for the first custom register. */
-uint8_t value = 0;
-
-/* Read the configuration of a custom RTC register based on the register index. One index corresponds to one byte of the configuration value. */
-ret = RtcReadReg(handle, usrDefIndex, &value);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
-- Setting the configuration of a custom RTC register
-
-Call the following function to configure a register based on the specified register index \(one index corresponds to one byte of the configuration value\):
-
-int32\_t RtcWriteReg\(DevHandle handle, uint8\_t usrDefIndex, uint8\_t value\);
-
-**Table 13** Description of **RtcWriteReg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the RTC device handle.
-
-
-
usrDefIndex
-
-
Index of the custom register.
-
-
-
value
-
-
Register value.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The operation is successful.
-
-
-
Negative value
-
-
The operation fails.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t usrDefIndex = 0; /* Define index 0 for the first custom register. */
-uint8_t value = 0x10;
-
-/* Configure a register based on the specified register index. One index corresponds to one byte of the configuration value. */
-ret = RtcWriteReg(handle, usrDefIndex, value);
-if (ret != 0) {
- /* Process the error. */
-}
-```
-
diff --git a/en/device-dev/driver/rtc.md b/en/device-dev/driver/rtc.md
deleted file mode 100644
index 50b89f7b7c1fb24aeac3e2922dce7da627864006..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/rtc.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# RTC
-
-- **[RTC Overview](rtc-overview.md)**
-
-- **[RTC Usage Guidelines](rtc-usage-guidelines.md)**
-
-- **[RTC Usage Example](rtc-usage-example.md)**
-
-
diff --git a/en/device-dev/driver/sdio.md b/en/device-dev/driver/sdio.md
deleted file mode 100644
index 43fb762051920268c93821121065cd4ebec24ecb..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sdio.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# SDIO
-
-- **[SDIO Overview](sdiooverview.md)**
-
-- **[SDIO Usage Guidelines](sdiousage-guidelines.md)**
-
-- **[SDIO Usage Example](sdiousage-example.md)**
-
-
diff --git a/en/device-dev/driver/sdiooverview.md b/en/device-dev/driver/sdiooverview.md
deleted file mode 100644
index 9890cf8f3c60999f90d41db98e8143600066308b..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sdiooverview.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# SDIO Overview
-
-- [Introduction](#section1155271783811)
-- [Available APIs](#section10204143763819)
-
-## Introduction
-
-- Secure Digital Input/Output \(SDIO\) is a peripheral interface evolved from the Secure Digital \(SD\) memory card interface. The SDIO interface is compatible with SD memory cards and can be connected to devices that support the SDIO interface.
-- SDIO is widely used. Currently, many smartphones support SDIO, and many SDIO peripherals are developed for connections to smartphones. Common SDIO peripherals include WLAN, GPS, cameras, and Bluetooth.
-- The SDIO bus has two ends, named host and device. All communication starts when the host sends a command. The device can communicate with the host as long as it can parse the command of the host. An SDIO host can connect to multiple devices, as shown in the figure below.
-
- - CLK signal: clock signal sent from the host to the device
- - VDD signal: power signal
- - VSS signal: ground signal
- - D0-3 signal: four data lines. The DAT1 signal cable is multiplexed as the interrupt line. In 1-bit mode, DAT0 is used to transmit data. In 4-bit mode, DAT0 to DAT3 are used to transmit data.
- - CMD signal: used by the host to send commands and the device to respond to commands.
-
- **Figure 1** Connections between the host and devices in SDIO
-
-
- 
-
-- The SDIO interface defines a set of common methods for operating an SDIO device, including opening and closing an SDIO controller, exclusively claiming and releasing the host, enabling and disabling devices, claiming and releasing an SDIO IRQ, reading and writing data based on SDIO, and obtaining and setting common information.
-
-## Available APIs
-
-**Table 1** APIs available for the SDIO driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
SDIO device opening/closing
-
-
SdioOpen
-
-
Opens an SDIO controller with a specified bus number.
-
-
-
SdioClose
-
-
Closes an SDIO controller.
-
-
-
SDIO reading/writing
-
-
SdioReadBytes
-
-
Incrementally reads a given length of data from a specified SDIO address.
-
-
-
SdioWriteBytes
-
-
Incrementally writes a given length of data into a specified SDIO address.
-
-
-
SdioReadBytesFromFixedAddr
-
-
Reads a given length of data from a fixed SDIO address.
-
-
-
SdioWriteBytesToFixedAddr
-
-
Writes a given length of data into a fixed SDIO address.
-
-
-
SdioReadBytesFromFunc0
-
-
Reads a given length of data from the address space of SDIO function 0.
-
-
-
SdioWriteBytesToFunc0
-
-
Writes a given length of data into the address space of SDIO function 0.
-
-
-
SDIO block size setting
-
-
SdioSetBlockSize
-
-
Sets the block size.
-
-
-
SDIO common information retrieval/setting
-
-
SdioGetCommonInfo
-
-
Obtains common information.
-
-
-
SdioSetCommonInfo
-
-
Sets common information.
-
-
-
SDIO data flushing
-
-
SdioFlushData
-
-
Flushes data.
-
-
-
SDIO host exclusively claiming or releasing
-
-
SdioClaimHost
-
-
Claims a host exclusively.
-
-
-
SdioReleaseHost
-
-
Releases the exclusively claimed host.
-
-
-
SDIO device enablement
-
-
SdioEnableFunc
-
-
Enables an SDIO device.
-
-
-
SdioDisableFunc
-
-
Disables an SDIO device.
-
-
-
SDIO IRQ claiming/releasing
-
-
SdioClaimIrq
-
-
Claims an SDIO IRQ.
-
-
-
SdioReleaseIrq
-
-
Releases an SDIO IRQ.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/sdiousage-example.md b/en/device-dev/driver/sdiousage-example.md
deleted file mode 100644
index 558f4cf191206f4a01f28850d14d667208b592fc..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sdiousage-example.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# SDIO Usage Example
-
-The following example shows how to use an SDIO device. First, open an SDIO controller whose bus number is 1, exclusively claim a host, enable the SDIO device, claim an SDIO IRQ, and then perform SDIO communication \(such as reading and writing\). After the SDIO communication, release the SDIO IRQ, disable the SDIO device, release the host, and close the SDIO controller.
-
-```
-#include "hdf_log.h"
-#include "sdio_if.h"
-
-#define TEST_FUNC_NUM 1 /* The I/O function whose ID is 1 is used. */
-#define TEST_FBR_BASE_ADDR 0x100 /* FBR base address of the I/O function whose ID is 1 */
-#define TEST_ADDR_OFFSET 9 /* Address offset of the register to read or write */
-#define TEST_DATA_LEN 3 /* Length of the data to read or write */
-#define TEST_BLOCKSIZE 2 /* Size of a data block, in bytes */
-
-/* Implement the SDIO IRQ function based on the application. */
-static void SdioIrqFunc(void *data)
-{
- if (data == NULL) {
- HDF_LOGE("SdioIrqFunc: data is NULL.\n");
- return;
- }
- /* You need to add specific implementations. */
-}
-
-void SdioTestSample(void)
-{
- int32_t ret;
- DevHandle handle = NULL;
- uint8_t data[TEST_DATA_LEN] = {0};
- struct SdioFunctionConfig config = {1, 0x123, 0x456};
- uint8_t val;
- uint32_t addr;
-
- /* Open an SDIO controller whose bus number is 1. */
- handle = SdioOpen(1, &config);
- if (handle == NULL) {
- HDF_LOGE("SdioOpen: failed!\n");
- return;
- }
- /* Claim a host exclusively. */
- SdioClaimHost(handle);
- /* Enable the SDIO device. */
- ret = SdioEnableFunc(handle);
- if (ret != 0) {
- HDF_LOGE("SdioEnableFunc: failed, ret %d\n", ret);
- goto ENABLE_ERR;
- }
- /* Claim an SDIO IRQ. */
- ret = SdioClaimIrq(handle, SdioIrqFunc);
- if (ret != 0) {
- HDF_LOGE("SdioClaimIrq: failed, ret %d\n", ret);
- goto CLAIM_IRQ_ERR;
- }
- /* Set the block size to 2 bytes. */
- ret = SdioSetBlockSize(handle, TEST_BLOCKSIZE);
- if (ret != 0) {
- HDF_LOGE("SdioSetBlockSize: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Read 3-byte data from the incremental address of an SDIO device. */
- addr = TEST_FBR_BASE_ADDR * TEST_FUNC_NUM + TEST_ADDR_OFFSET;
- ret = SdioReadBytes(handle, data, addr, TEST_DATA_LEN);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Write 3-byte data into the incremental address of an SDIO device. */
- ret = SdioWriteBytes(handle, data, addr, TEST_DATA_LEN);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Read 1-byte data from the SDIO device. */
- ret = SdioReadBytes(handle, &val, addr, 1);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Write 1-byte data into the SDIO device. */
- ret = SdioWriteBytes(handle, &val, addr, 1);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Read 3-byte data from the fixed address of an SDIO device. */
- ret = SdioReadBytesFromFixedAddr(handle, data, addr, TEST_DATA_LEN, 0);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytesFromFixedAddr: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Write 1-byte data to the fixed address of an SDIO device. */
- ret = SdioWriteBytesToFixedAddr(handle, data, addr, 1, 0);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytesToFixedAddr: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Read 1-byte data from SDIO function 0. */
- addr = 0x02;
- ret = SdioReadBytesFromFunc0(handle, &val, addr, 1);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytesFromFunc0: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
- /* Write 1-byte data into SDIO function 0. */
- ret = SdioWriteBytesToFunc0(handle, &val, addr, 1);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytesToFunc0: failed, ret %d\n", ret);
- goto COMM_ERR;
- }
-COMM_ERR:
- /* Release the SDIO IRQ. */
- ret = SdioReleaseIrq(handle);
- if (ret != 0) {
- HDF_LOGE("SdioReleaseIrq: failed, ret %d\n", ret);
- }
-CLAIM_IRQ_ERR:
- /* Disable the SDIO device. */
- ret = SdioDisableFunc(handle);
- if (ret != 0) {
- HDF_LOGE("SdioDisableFunc: failed, ret %d\n", ret);
- }
-ENABLE_ERR:
- /* Release the exclusively claimed host. */
- SdioReleaseHost(handle);
- /* Close an SDIO controller. */
- SdioClose(handle);
-}
-```
-
diff --git a/en/device-dev/driver/sdiousage-guidelines.md b/en/device-dev/driver/sdiousage-guidelines.md
deleted file mode 100644
index 402cf305ebb98196a477530f749e0bc07f9710bd..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sdiousage-guidelines.md
+++ /dev/null
@@ -1,787 +0,0 @@
-# SDIO Usage Guidelines
-
-- [How to Use](#section1962415610383)
-- [Opening an SDIO Controller](#section814751015461)
-- [Claiming a Host Exclusively](#section49274582455)
-- [Enabling the SDIO Device](#section1431520410489)
-- [Claiming an SDIO IRQ](#section3662781537)
-- [Performing SDIO Communication](#section391941913484)
-- [Releasing the SDIO IRQ](#section56205204481)
-- [Disabling the SDIO Device](#section181181621124815)
-- [Releasing the Exclusively Claimed Host](#section657117215486)
-- [Closing an SDIO Controller](#section1898172114818)
-
-## How to Use
-
-[Figure 1](spiusage-guidelines.md#fig23885455594) illustrates the process of using an SDIO.
-
-**Figure 1** Process of using an SDIO
-
-
-
-
-## Opening an SDIO Controller
-
-Before performing SDIO communication, obtain the device handle of an SDIO controller by calling **SdioOpen**. This function returns the device handle of the SDIO controller with a specified bus number.
-
-DevHandle SdioOpen\(int16\_t mmcBusNum, struct SdioFunctionConfig \*config\);
-
-**Table 1** Parameters and return values of SdioOpen
-
-
-
Parameter
-
-
Description
-
-
-
-
mmcBusNum
-
-
Bus number.
-
-
-
config
-
-
SDIO functionality configurations.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to obtain the device handle of an SDIO controller.
-
-
-
Device handle
-
-
Device handle of an SDIO controller.
-
-
-
-
-
-The following example shows how to open an SDIO controller.
-
-```
-DevHandle handle = NULL;
-struct SdioFunctionConfig config;
-config.funcNr = 1;
-config.vendorId = 0x123;
-config.deviceId = 0x456;
-/* Open an SDIO controller whose bus number is 1. */
-handle = SdioOpen(1, &config);
-if (handle == NULL) {
- HDF_LOGE("SdioOpen: failed!\n");
-}
-```
-
-## Claiming a Host Exclusively
-
-After obtaining the device handle of an SDIO controller, exclusively claim the host before performing subsequent operations on the SDIO device.
-
-void SdioClaimHost\(DevHandle handle\);
-
-**Table 2** Parameter description of SdioClaimHost
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
-
-
-The following example shows how to exclusively claim a host.
-
-```
-SdioClaimHost(handle); /* Claim a host exclusively. */
-```
-
-## Enabling the SDIO Device
-
-Before accessing a register, enable the SDIO device.
-
-int32\_t SdioEnableFunc\(DevHandle handle\);
-
-**Table 3** Parameters and return values of SdioEnableFunc
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The SDIO device is enabled.
-
-
-
Negative value
-
-
Failed to enable the SDIO device.
-
-
-
-
-
-The following example shows how to enable the SDIO device.
-
-```
-int32_t ret;
-/* Enable the SDIO device. */
-ret = SdioEnableFunc(handle);
-if (ret != 0) {
- HDF_LOGE("SdioEnableFunc: failed, ret %d\n", ret);
-}
-```
-
-## Claiming an SDIO IRQ
-
-Before SDIO communication, claim an SDIO IRQ.
-
-int32\_t SdioClaimIrq\(DevHandle handle, SdioIrqHandler \*handler\);
-
-**Table 4** Parameters and return values of SdioClaimIrq
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
handler
-
-
Pointer to the SDIO IRQ function.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The SDIO IRQ is claimed.
-
-
-
Negative value
-
-
Failed to claim an SDIO IRQ.
-
-
-
-
-
-The following example shows how to claim an SDIO IRQ.
-
-```
-/* Implement the SDIO IRQ function based on the application. */
-static void SdioIrqFunc(void *data)
-{
- if (data == NULL) {
- HDF_LOGE("SdioIrqFunc: data is NULL.\n");
- return;
- }
- /* You need to add specific implementations. */
-}
-
-int32_t ret;
-/* Claim an SDIO IRQ. */
-ret = SdioClaimIrq(handle, SdioIrqFunc);
-if (ret != 0) {
- HDF_LOGE("SdioClaimIrq: failed, ret %d\n", ret);
-}
-```
-
-## Performing SDIO Communication
-
-- Incrementally write a given length of data into the SDIO device.
-
-The corresponding function is as follows:
-
-int32\_t SdioWriteBytes\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
-
-**Table 5** Parameters and return values of SdioWriteBytes
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to write.
-
-
-
addr
-
-
Start address where the data is written into.
-
-
-
size
-
-
Length of the data to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is written into the SDIO device.
-
-
-
Negative value
-
-
Failed to write data into the SDIO device.
-
-
-
-
-
-The following example shows how to incrementally write a given length of data into the SDIO device.
-
-```
-int32_t ret;
-uint8_t wbuff[] = {1,2,3,4,5};
-uint32_t addr = 0x100 + 0x09;
-/* Incrementally write 5-byte data into the start address 0x109 of the SDIO device. */
-ret = SdioWriteBytes(handle, wbuff, addr, sizeof(wbuff) / sizeof(wbuff[0]));
-if (ret != 0) {
- HDF_LOGE("SdioWriteBytes: failed, ret %d\n", ret);
-}
-```
-
-- Incrementally read a given length of data from the SDIO device.
-
-The corresponding function is as follows:
-
-int32\_t SdioReadBytes\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
-
-**Table 6** Parameters and return values of SdioReadBytes
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to read.
-
-
-
addr
-
-
Start address where the data is read from.
-
-
-
size
-
-
Length of the data to read.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is read from the SDIO device.
-
-
-
Negative value
-
-
Failed to read data from the SDIO device.
-
-
-
-
-
-The following example shows how to incrementally read a given length of data from the SDIO device.
-
-```
-int32_t ret;
-uint8_t rbuff[5] = {0};
-uint32_t addr = 0x100 + 0x09;
-/* Incrementally read 5-byte data from the start address 0x109 of the SDIO device. */
-ret = SdioReadBytes(handle, rbuff, addr, 5);
-if (ret != 0) {
- HDF_LOGE("SdioReadBytes: failed, ret %d\n", ret);
-}
-```
-
-- Write a given length of data into the fixed address of an SDIO device.
-
- The corresponding function is as follows:
-
- int32\_t SdioWriteBytesToFixedAddr\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size, uint32\_t scatterLen\);
-
- **Table 7** Parameters and return values of SdioWriteBytesToFixedAddr
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to write.
-
-
-
addr
-
-
Fixed address where the data is written into.
-
-
-
size
-
-
Length of the data to write.
-
-
-
scatterLen
-
-
Length of the scatter list. If the value is not 0, the data is of the scatter list type.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is written into the SDIO device.
-
-
-
Negative value
-
-
Failed to write data into the SDIO device.
-
-
-
-
-
- The following example shows how to write a given length of data into the fixed address of an SDIO device.
-
- ```
- int32_t ret;
- uint8_t wbuff[] = {1, 2, 3, 4, 5};
- uint32_t addr = 0x100 + 0x09;
- /* Write 5-byte data into the fixed address 0x109 of the SDIO device. */
- ret = SdioWriteBytesToFixedAddr(handle, wbuff, addr, sizeof(wbuff) / sizeof(wbuff[0]), 0);
- if (ret != 0) {
- HDF_LOGE("SdioWriteBytesToFixedAddr: failed, ret %d\n", ret);
- }
- ```
-
-- Read a given length of data from the fixed address of an SDIO device.
-
- The corresponding function is as follows:
-
- int32\_t SdioReadBytesFromFixedAddr\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size, uint32\_t scatterLen\);
-
- **Table 8** Parameters and return values of SdioReadBytesFromFixedAddr
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to read.
-
-
-
addr
-
-
Start address where the data is read from.
-
-
-
size
-
-
Length of the data to read.
-
-
-
scatterLen
-
-
Length of the scatter list. If the value is not 0, the data is of the scatter list type.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is read from the SDIO device.
-
-
-
Negative value
-
-
Failed to read data from the SDIO device.
-
-
-
-
-
- The following example shows how to read a given length of data from the fixed address of an SDIO device.
-
- ```
- int32_t ret;
- uint8_t rbuff[5] = {0};
- uint32_t addr = 0x100 + 0x09;
- /* Read 5-byte data from the fixed address 0x109 of the SDIO device. */
- ret = SdioReadBytesFromFixedAddr(handle, rbuff, addr, 5, 0);
- if (ret != 0) {
- HDF_LOGE("SdioReadBytesFromFixedAddr: failed, ret %d\n", ret);
- }
- ```
-
-
-- Write a given length of data into the address space of SDIO function 0.
-
-Currently, only 1-byte data can be written. The corresponding function is as follows:
-
-int32\_t SdioWriteBytesToFunc0\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
-
-**Table 9** Parameters and return values of SdioWriteBytesToFunc0
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to write.
-
-
-
addr
-
-
Start address where the data is written into.
-
-
-
size
-
-
Length of the data to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is written into the SDIO device.
-
-
-
Negative value
-
-
Failed to write data into the SDIO device.
-
-
-
-
-
-The following example shows how to write a given length of data into the address space of SDIO function 0.
-
-```
-int32_t ret;
-uint8_t wbuff = 1;
-/* Write 1-byte data into the address 0x2 of SDIO function 0. */
-ret = SdioWriteBytesToFunc0(handle, &wbuff, 0x2, 1);
-if (ret != 0) {
- HDF_LOGE("SdioWriteBytesToFunc0: failed, ret %d\n", ret);
-}
-```
-
-- Read a given length of data from the address space of SDIO function 0.
-
-Currently, only 1-byte data can be read. The corresponding function is as follows:
-
-int32\_t SdioReadBytesFromFunc0\(DevHandle handle, uint8\_t \*data, uint32\_t addr, uint32\_t size\);
-
-**Table 10** Parameters and return values of SdioReadBytesFromFunc0
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
data
-
-
Pointer to the data to read.
-
-
-
addr
-
-
Start address where the data is read from.
-
-
-
size
-
-
Length of the data to read.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Data is read from the SDIO device.
-
-
-
Negative value
-
-
Failed to read data from the SDIO device.
-
-
-
-
-
-The following example shows how to read a given length of data from the address space of SDIO function 0.
-
-```
-int32_t ret;
-uint8_t rbuff;
-/* Read 1-byte data from the address 0x2 of SDIO function 0. */
-ret = SdioReadBytesFromFunc0(handle, &rbuff, 0x2, 1);
-if (ret != 0) {
- HDF_LOGE("SdioReadBytesFromFunc0: failed, ret %d\n", ret);
-}
-```
-
-## Releasing the SDIO IRQ
-
-After the SDIO communication, release the SDIO IRQ.
-
-int32\_t SdioReleaseIrq\(DevHandle handle\);
-
-**Table 11** Parameters and return values of SdioReleaseIrq
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The SDIO IRQ is released.
-
-
-
Negative value
-
-
Failed to release the SDIO IRQ.
-
-
-
-
-
-The following example shows how to release the SDIO IRQ.
-
-```
-int32_t ret;
-/* Release the SDIO IRQ. */
-ret = SdioReleaseIrq(handle);
-if (ret != 0) {
- HDF_LOGE("SdioReleaseIrq: failed, ret %d\n", ret);
-}
-```
-
-## Disabling the SDIO Device
-
-After the SDIO communication, disable the SDIO device.
-
-int32\_t SdioDisableFunc\(DevHandle handle\);
-
-**Table 12** Parameters and return values of SdioDisableFunc
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
The SDIO device is disabled.
-
-
-
Negative value
-
-
Failed to disable the SDIO device.
-
-
-
-
-
-The following example shows how to disable the SDIO device.
-
-```
-int32_t ret;
-/* Disable the SDIO device. */
-ret = SdioDisableFunc(handle);
-if (ret != 0) {
- HDF_LOGE("SdioDisableFunc: failed, ret %d\n", ret);
-}
-```
-
-## Releasing the Exclusively Claimed Host
-
-After the SDIO communication, release the exclusively claimed host.
-
-void SdioReleaseHost\(DevHandle handle\);
-
-**Table 13** Parameter description of SdioReleaseHost
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
-
-
-The following example shows how to release the exclusively claimed host.
-
-```
-SdioReleaseHost(handle); /* Release the exclusively claimed host. */
-```
-
-## Closing an SDIO Controller
-
-After the SDIO communication, close the SDIO controller.
-
-void SdioClose\(DevHandle handle\);
-
-This function releases the resources requested.
-
-**Table 14** Parameter description of SdioClose
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Device handle of an SDIO controller.
-
-
-
-
-
-The following example shows how to close an SDIO controller.
-
-```
-SdioClose(handle); /* Close an SDIO controller. */
-```
-
diff --git a/en/device-dev/driver/sensor-driver-development-example.md b/en/device-dev/driver/sensor-driver-development-example.md
deleted file mode 100644
index acab2c70f8f15eb2f313206a50e289af4ab759db..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sensor-driver-development-example.md
+++ /dev/null
@@ -1,583 +0,0 @@
-# Sensor Driver Development Example
-
-This section provides a code example of how to load and start the acceleration sensor driver based on the HDF driver model. For details about the mechanism, see [HDF Driver Development](driver-development.md). This example uses the Bosch BMI160 acceleration sensor that communicates over I2C.
-
-1. Register the driver entry of the acceleration sensor.
-
-- Implementation of the entry function
-
-```
-/* Register the entry structure object of the acceleration sensor. */
-struct HdfDriverEntry g_sensorAccelDevEntry = {
- .moduleVersion = 1, /* Version number of the acceleration sensor module */
- .moduleName = "HDF_SENSOR_ACCEL", /* Name of the acceleration sensor module. The value must be the same as that of moduleName in the device_info.hcs file. */
- .Bind = BindAccelDriver, /* Binding function of the acceleration sensor */
- .Init = InitAccelDriver, /* Initialization function of the acceleration sensor */
- .Release = ReleaseAccelDriver, /* Resource release function of the acceleration sensor */
-};
-
-/* Call HDF_INIT to register the driver entry with the HDF. When loading the driver, the HDF calls the Bind function first and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit.
-HDF_INIT(g_sensorAccelDevEntry);
-```
-
-- Acceleration sensor configuration
-
-The acceleration sensor model uses the HCS as the configuration source code. For details about the HCS configuration fields, see [Driver Configuration Management](driver-configuration-management.md).
-
-```
-/* HCS configuration of the acceleration sensor device */
-device_sensor_accel :: device {
- device0 :: deviceNode {
- policy = 1; /* Policy for providing the driver service */
- priority = 105; /* Driver startup priority (0–200). A larger value indicates a lower priority. The default value 100 is recommended. The sequence for loading devices with the same priority is random. */
- preload = 2; /* Field for specifying whether to load the driver. Value 0 means to load the driver, and 2 means the opposite. */
- permission = 0664; /* Permission for the driver to create device nodes */
- moduleName = "HDF_SENSOR_ACCEL"; /* Driver name. The value must be the same as that of moduleName in the driver entry structure. */
- serviceName = "sensor_accel"; /* Name of the service provided by the driver. The name must be unique. */
- deviceMatchAttr = "hdf_sensor_accel_driver"; /* Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver. */
- }
-}
-```
-
-1. Initialize and deinitialize the acceleration sensor driver.
-
-- Initialization entry function **init**
-
-```
-/* Bind the service provided by the acceleration sensor driver to the HDF. */
-int32_t BindAccelDriver(struct HdfDeviceObject *device)
-{
- CHECK_NULL_PTR_RETURN_VALUE(device, HDF_ERR_INVALID_PARAM);
-
- static struct IDeviceIoService service = {
- .object = {0},
- .Dispatch = DispatchAccel,
- };
- device->service = &service;
-
- return HDF_SUCCESS;
-}
-/* After detecting that the device is in position, call RegisterAccelChipOps to register the differentiation adaptation function. */
-int32_t RegisterAccelChipOps(struct AccelOpsCall *ops)
-{
- struct AccelDrvData *drvData = NULL;
-
- CHECK_NULL_PTR_RETURN_VALUE(ops, HDF_ERR_INVALID_PARAM);
-
- drvData = AccelGetDrvData();
- drvData->ops.Init = ops->Init;
- drvData->ops.ReadData = ops->ReadData;
- return HDF_SUCCESS;
-}
-/* Hook the acceleration sensor driver normalization function. */
-static int32_t InitAccelOps(struct SensorDeviceInfo *deviceInfo)
-{
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- (void)memset_s((void *)deviceInfo, sizeof(*deviceInfo), 0, sizeof(*deviceInfo));
- deviceInfo->ops.GetInfo = SetAccelInfo;
- deviceInfo->ops.Enable = SetAccelEnable;
- deviceInfo->ops.Disable = SetAccelDisable;
- deviceInfo->ops.SetBatch = SetAccelBatch;
- deviceInfo->ops.SetMode = SetAccelMode;
- deviceInfo->ops.SetOption = SetAccelOption;
-
- if (memcpy_s(&deviceInfo->sensorInfo, sizeof(deviceInfo->sensorInfo),
- &drvData->accelCfg->sensorInfo, sizeof(drvData->accelCfg->sensorInfo)) != EOK) {
- HDF_LOGE("%s: copy sensor info failed", __func__);
- return HDF_FAILURE;
- }
- /* The sensor type ID can be configured in the HCS configuration file or here. */
- drvData->accelCfg->sensorInfo.sensorTypeId = SENSOR_TAG_ACCELEROMETER;
- drvData->accelCfg->sensorInfo.sensorId = SENSOR_TAG_ACCELEROMETER;
-
- return HDF_SUCCESS;
-}
-/* Initialize the sensor register. */
-static int32_t InitAccelAfterConfig(void)
-{
- struct SensorDeviceInfo deviceInfo;
-
- if (InitAccelConfig() != HDF_SUCCESS) {
- HDF_LOGE("%s: init accel config failed", __func__);
- return HDF_FAILURE;
- }
-
- if (InitAccelOps(&deviceInfo) != HDF_SUCCESS) {
- HDF_LOGE("%s: init accel ops failed", __func__);
- return HDF_FAILURE;
- }
-
- if (AddSensorDevice(&deviceInfo) != HDF_SUCCESS) {
- HDF_LOGE("%s: add accel device failed", __func__);
- return HDF_FAILURE;
- }
-
- return HDF_SUCCESS;
-}
-/* Call the device detection function to hook the differentiated device function. */
-static int32_t DetectAccelChip(void)
-{
- int32_t num;
- int32_t ret;
- int32_t loop;
- struct AccelDrvData *drvData = AccelGetDrvData();
- CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
-
- num = sizeof(g_accelDetectIfList) / sizeof(g_accelDetectIfList[0]);
- for (loop = 0; loop < num; ++loop) {
- if (g_accelDetectIfList[loop].DetectChip != NULL) {
- ret = g_accelDetectIfList[loop].DetectChip(drvData->accelCfg);
- if (ret == HDF_SUCCESS) {
- drvData->detectFlag = true;
- break;
- }
- }
- }
-
- if (loop == num) {
- HDF_LOGE("%s: detect accel device failed", __func__);
- drvData->detectFlag = false;
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-/* The entry function of the acceleration sensor driver is used to initialize the structure object of the sensor private data, allocate space for the HCS data configuration object of the sensor, invoke the entry function for initializing the sensor HCS data configuration, detect whether the sensor device is in position, create the sensor data reporting timer, implement the sensor normalization API, and register the sensor device. */
-int32_t InitAccelDriver(struct HdfDeviceObject *device)
-{
- /* Obtain the private data structure object of the sensor. */
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- /* When detecting sensors of the same type from different vendors, the function checks whether this type of sensors is in position. If yes, it no longer detects the other sensors of this type and directly returns the result. */
- if (drvData->detectFlag) {
- HDF_LOGE("%s: accel sensor have detected", __func__);
- return HDF_SUCCESS;
- }
-
- CHECK_NULL_PTR_RETURN_VALUE(device, HDF_ERR_INVALID_PARAM);
- /* Allocate space for the private data structure objects for storing sensor data configurations. The allocated space needs to be released when the driver is released. */
- drvData->accelCfg = (struct SensorCfgData *)OsalMemCalloc(sizeof(*cfg));
- if (drvData->accelCfg == NULL) {
- HDF_LOGE("%s: malloc sensor config data failed", __func__);
- return HDF_FAILURE;
- }
-
- drvData->accelCfg->regCfgGroup = &g_regCfgGroup[0];
- /* Initializing the sensor configuration data aims to parse the configuration information of the sensor communication bus, basic sensor information, sensor attributes, whether the sensor is in position, and register group information. */
- if (GetSensorBaseConfigData(device->property, drvData->accelCfg) != HDF_SUCCESS) {
- HDF_LOGE("%s: get sensor base config failed", __func__);
- goto Base_CONFIG_EXIT;
- }
-
- if (DetectAccelChip() != HDF_SUCCESS) {
- HDF_LOGE("%s: accel sensor detect device no exist", __func__);
- goto DETECT_CHIP_EXIT;
- }
- drvData->detectFlag = true;
- if (ParseSensorRegConfig(drvData->accelCfg) != HDF_SUCCESS) {
- HDF_LOGE("%s: detect sensor device failed", __func__);
- goto REG_CONFIG_EXIT;
- }
-
- if (InitAccelAfterConfig() != HDF_SUCCESS) {
- HDF_LOGE("%s: init accel after config failed", __func__);
- goto INIT_EXIT;
- }
-
- HDF_LOGI("%s: init accel driver success", __func__);
- return HDF_SUCCESS;
-
-INIT_EXIT:
- DestroySensorThread(&drvData->thread, &drvData->threadStatus);
- (void)DeleteSensorDevice(SENSOR_TAG_ACCELEROMETER);
-REG_CONFIG_EXIT:
- ReleaseSensorAllRegConfig(drvData->accelCfg);
- (void)ReleaseSensorBusHandle(&drvData->accelCfg->busCfg);
-DETECT_CHIP_EXIT:
- drvData->detectFlag = false;
-BASE_CONFIG_EXIT:
- drvData->accelCfg->root = NULL;
- drvData->accelCfg->regCfgGroup = NULL;
- OsalMemFree(drvData->accelCfg);
- drvData->accelCfg = NULL;
- return HDF_FAILURE;
-}
-
-/* Release the resources allocated during driver initialization. */
-void ReleaseAccelDriver(struct HdfDeviceObject *device)
-{
- (void)device;
- struct AccelDrvData *drvData = NULL;
-
- drvData = AccelGetDrvData();
- (void)DestroySensorThread(&drvData->thread, &drvData->threadStatus);
- (void)DeleteSensorDevice(SENSOR_TAG_ACCELEROMETER);
- drvData->detectFlag = false;
-
- if (drvData->accelCfg != NULL) {
- drvData->accelCfg->root = NULL;
- drvData->accelCfg->regCfgGroup = NULL;
- ReleaseSensorAllRegConfig(drvData->accelCfg);
- (void)ReleaseSensorBusHandle(&drvData->accelCfg->busCfg);
- OsalMemFree(drvData->accelCfg);
- drvData->accelCfg = NULL;
- }
-
- drvData->initStatus = false;
-}
-```
-
-1. Configure the acceleration sensor register group.
-
-You only need to configure the acceleration sensor data according to the template. Template configuration parsing has been implemented via the **InitSensorConfigData** function and only needs to be called during initialization. If new configuration items are added, you need to modify this function accordingly.
-
-```
-Acceleration sensor data configuration template (accel_config.hcs)
-root {
- sensorAccelConfig {
- accelChipConfig {
- /* Sensor information template */
- template sensorInfo {
- sensorName = "accelerometer"; /* Acceleration sensor name. The value contains a maximum of 16 bytes. */
- vendorName = "borsh_bmi160"; /* Sensor vendor name. The value contains a maximum of 16 bytes. */
- firmwareVersion = "1.0"; /* Sensor firmware version number. The default value is 1.0. The value contains a maximum of 16 bytes. */
- hardwareVersion = "1.0"; /* Sensor hardware version number. The default value is 1.0. The value contains a maximum of 16 bytes. */
- sensorTypeId = 1; /* Sensor type ID. For details, see SensorTypeTag. */
- sensorId = 1; /* Sensor ID, which is defined by the sensor driver developer. The SensorTypeTag enums are recommended. */
- maxRange = 8; /* Maximum measurement range of the sensor. Set this parameter based on your business requirements. */
- precision = 0; /* Sensor accuracy, which is used together with sensor data reporting. For details, see SensorEvents. */
- power = 230; /* Power consumption of the sensor */
- }
- /* Template of the bus type and configuration information used by the sensor */
- template sensorBusConfig {
- busType = 0; /* 0 for the I2C bus and 1 for the SPI bus */
- busNum = 6; /* Device ID allocated to the sensor on the chip */
- busAddr = 0; /* Address allocated to the sensor on the chip */
- regWidth = 1; /* Width of the sensor register address */
- regBigEndian = 0; /* Endian mode of the sensor register */
- }
- /* Sensor attribute template */
- template sensorAttr {
- chipName = ""; /* Sensor chip name */
- chipIdRegister = 0xf; /* Address of the register detecting whether the sensor is in position */
- chipIdValue = 0xd1; /* Value of the register detecting whether the sensor is in position */
- }
- }
- }
-}
-
-/* You can modify the template configuration based on the differences of sensor devices. If no modification is made, the default template configuration is used. */
-root {
- sensorAccelConfig {
- accel_bmi160_chip_config : accelChipConfig {
- match_attr = "hdf_sensor_accel_driver"; /* The value must be the same as the match_attr field configured for the acceleration sensor. */
- accelInfo :: sensorInfo {
- vendorName = "borsh_bmi160";
- sensorTypeId = 1;
- sensorId = 1;
- }
- accelBusConfig :: sensorBusConfig {
- busType = 0; /* I2C communication mode */
- busNum = 6;
- busAddr = 0x68;
- regWidth = 1; /* 1-byte bit width */
- }
- accelAttr :: sensorAttr {
- chipName = "bmi160";
- chipIdRegister = 0x00;
- chipIdValue = 0xd1;
- }
- accelRegConfig {
- /* regAddr: Register address
- value: Register value
- mask: Mask of the register value
- len: Length (in bytes) of the register value
- delay: Register delay (in milliseconds)
- opsType: Operation type. The options can be 0 (no operation), 1 (read), 2 (write), 3 (read and check), and 4 (bit update).
- calType: Calculation type. The options can be 0 (none), 1 (write), 2 (negate), 3 (XOR) 4, (left shift), and 5 (right shift).
- shiftNum: Number of shifts
- debug: Debugging switch. The value can be 0 (disabled) or 1 (enabled).
- save: Data saving switch. The value can be 0 (not save data) or 1 (save data).
- */
- /* Groups of sensor register operations. Registers can be configured in sequence based on the groups. */
- /* Register address, register value, mask of the register value, data length of the register value, register delay, operation type, calculation type, number of shifts, debugging switch, data saving switch */
- /* Initialize the register groups. */
- initSeqConfig = [
- 0x7e, 0xb6, 0xff, 1, 5, 2, 0, 0, 0, 0,
- 0x7e, 0x10, 0xff, 1, 5, 2, 0, 0, 0, 0
- ];
- /* Enable the register groups. */
- enableSeqConfig = [
- 0x7e, 0x11, 0xff, 1, 5, 2, 0, 0, 0, 0,
- 0x41, 0x03, 0xff, 1, 0, 2, 0, 0, 0, 0,
- 0x40, 0x08, 0xff, 1, 0, 2, 0, 0, 0, 0
- ];
- /* Disable the register groups. */
- disableSeqConfig = [
- 0x7e, 0x10, 0xff, 1, 5, 2, 0, 0, 0, 0
- ];
- }
- }
- }
-}
-```
-
-1. Implement APIs for acceleration sensor driver operations.
-
-You need to implement normalized APIs based on sensor types.
-
-```
-/* Leave a function empty if it is not used. */
-static int32_t SetAccelInfo(struct SensorBasicInfo *info)
-{
- (void)info;
-
- return HDF_ERR_NOT_SUPPORT;
-}
-/* Deliver the configuration of enabling the register groups. */
-static int32_t SetAccelEnable(void)
-{
- int32_t ret;
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
- ret = SetSensorRegCfgArray(&drvData->accelCfg->busCfg, drvData->accelCfg->regCfgGroup[SENSOR_ENABLE_GROUP]);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: accel sensor disable config failed", __func__);
- return HDF_FAILURE;
- }
-
- drvData->threadStatus = SENSOR_THREAD_RUNNING;
-
- return HDF_SUCCESS;
-}
-/* Deliver the configuration of disabling the register groups. */
-static int32_t SetAccelDisable(void)
-{
- int32_t ret;
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- CHECK_NULL_PTR_RETURN_VALUE(drvData->accelCfg, HDF_ERR_INVALID_PARAM);
-
- ret = SetSensorRegCfgArray(&drvData->accelCfg->busCfg, drvData->accelCfg->regCfgGroup[SENSOR_DISABLE_GROUP]);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: accel sensor disable config failed", __func__);
- return HDF_FAILURE;
- }
-
- drvData->threadStatus = SENSOR_THREAD_STOPPED;
-
- return HDF_SUCCESS;
-}
-/* Set the sampling interval and data reporting interval of the sensor. */
-static int32_t SetAccelBatch(int64_t samplingInterval, int64_t interval)
-{
- (void)interval;
-
- struct AccelDrvData *drvData = AccelGetDrvData();
- drvData->interval = samplingInterval;
-
- return HDF_SUCCESS;
-}
-/* Set the data reporting mode of the sensor. Currently, the real-time mode is supported. */
-static int32_t SetAccelMode(int32_t mode)
-{
- return (mode == SENSOR_WORK_MODE_REALTIME) ? HDF_SUCCESS : HDF_FAILURE;
-}
-/* Set the sensor options. */
-static int32_t SetAccelOption(uint32_t option)
-{
- (void)option;
- return HDF_ERR_NOT_SUPPORT;
-}
-```
-
-- Differentiated processing APIs
-
- ```
- /* If a device is successfully detected, register the differentiated processing function to the accel driver model. */
- int32_t DetectAccelBim160Chip(struct SensorCfgData *data)
- {
- int32_t ret;
- struct AccelOpsCall ops;
- CHECK_NULL_PTR_RETURN_VALUE(data, HDF_ERR_INVALID_PARAM);
-
- if (strcmp(ACCEL_CHIP_NAME_BMI160, data->sensorAttr.chipName) != 0) {
- return HDF_SUCCESS;
- }
- ret = InitAccelPreConfig();
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: init BMI160 bus mux config", __func__);
- return HDF_FAILURE;
- }
- if (DetectSensorDevice(data) != HDF_SUCCESS) {
- return HDF_FAILURE;
- }
-
- /* Differentiated processing function */
- ops.Init = InitBmi160;
- ops.ReadData = ReadBmi160Data;
- ret = RegisterAccelChipOps(&ops);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: register BMI160 accel failed", __func__);
- (void)ReleaseSensorBusHandle(&data->busCfg);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
- }
- /* Initialization processing function */
- static int32_t InitBmi160(struct SensorCfgData *data)
- {
- int32_t ret;
-
- CHECK_NULL_PTR_RETURN_VALUE(data, HDF_ERR_INVALID_PARAM);
- ret = SetSensorRegCfgArray(&data->busCfg, data->regCfgGroup[SENSOR_INIT_GROUP]);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: bmi160 sensor init config failed", __func__);
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
- }
- /* Data processing function */
- int32_t ReadBmi160Data(struct SensorCfgData *data)
- {
- int32_t ret;
- struct AccelData rawData = { 0, 0, 0 };
- int32_t tmp[ACCEL_AXIS_NUM];
- struct SensorReportEvent event;
-
- (void)memset_s(&event, sizeof(event), 0, sizeof(event));
-
- ret = ReadBmi160RawData(data, &rawData, &event.timestamp);
- if (ret != HDF_SUCCESS) {
- return HDF_FAILURE;
- }
-
- event.sensorId = SENSOR_TAG_ACCELEROMETER;
- event.option = 0;
- event.mode = SENSOR_WORK_MODE_REALTIME;
-
- rawData.x = rawData.x * BMI160_ACC_SENSITIVITY_2G;
- rawData.y = rawData.y * BMI160_ACC_SENSITIVITY_2G;
- rawData.z = rawData.z * BMI160_ACC_SENSITIVITY_2G;
-
- tmp[ACCEL_X_AXIS] = (rawData.x * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
- tmp[ACCEL_Y_AXIS] = (rawData.y * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
- tmp[ACCEL_Z_AXIS] = (rawData.z * SENSOR_1K_UNIT) / SENSOR_CONVERT_UNIT;
-
- event.dataLen = sizeof(tmp);
- event.data = (uint8_t *)&tmp;
- ret = ReportSensorEvent(&event);
- return ret;
- }
- ```
-
-- Data processing function
-
-Create a sensor timer to periodically sample data based on the configured sampling interval and report the data to the data subscriber.
-
-```
-/* Scheduled working thread of the sensor */
-static int32_t ReadAccelDataThreadWorker(void *arg)
-{
- (void)arg;
- int64_t interval;
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- drvData->threadStatus = SENSOR_THREAD_START;
- while (true) {
- if (drvData->threadStatus == SENSOR_THREAD_RUNNING) {
- if (drvData->ops.ReadData != NULL) {
- (void)drvData->ops.ReadData(drvData->accelCfg);
- }
- interval = OsalDivS64(drvData->interval, (SENSOR_CONVERT_UNIT * SENSOR_CONVERT_UNIT));
- OsalMSleep(interval);
- } else if (drvData->threadStatus == SENSOR_THREAD_DESTROY) {
- break;
- } else {
- OsalMSleep(ACC_DEFAULT_SAMPLING_200_MS / SENSOR_CONVERT_UNIT / SENSOR_CONVERT_UNIT);
- }
-
- if ((!drvData->initStatus) || (drvData->interval < 0) || drvData->threadStatus != SENSOR_THREAD_RUNNING) {
- continue;
- }
- }
-
- return HDF_SUCCESS;
-}
-/* Create a sensor timer and initialize the sensor device. */
-static int32_t InitAccelConfig(void)
-{
- int32_t ret;
- struct AccelDrvData *drvData = AccelGetDrvData();
-
- if (drvData->threadStatus != SENSOR_THREAD_NONE && drvData->threadStatus != SENSOR_THREAD_DESTROY) {
- HDF_LOGE("%s: accel thread have created", __func__);
- return HDF_SUCCESS;
- }
-
- ret = CreateSensorThread(&drvData->thread, ReadAccelDataThreadWorker, "hdf_sensor_accel", drvData);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: accel create thread failed", __func__);
- drvData->threadStatus = SENSOR_THREAD_NONE;
- return HDF_FAILURE;
- }
-
- CHECK_NULL_PTR_RETURN_VALUE(drvData->ops.Init, HDF_ERR_INVALID_PARAM);
-
- ret = drvData->ops.Init(drvData->accelCfg);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: accel create thread failed", __func__);
- drvData->threadStatus = SENSOR_THREAD_NONE;
- return HDF_FAILURE;
- }
- drvData->initStatus = true;
- return HDF_SUCCESS;
-}
-```
-
-- Major data structures
-
-```
-/* Sensor conversion units */
-#define SENSOR_CONVERT_UNIT 1000
-#define SENSOR_1K_UNIT 1024
-/* Sensitivity conversion value of the sensor with a 2g measurement range */
-#define BMI160_ACC_SENSITIVITY_2G 61
-/* Address of the sensor data sampling register */
-#define BMI160_ACCEL_X_LSB_ADDR 0X12
-#define BMI160_ACCEL_X_MSB_ADDR 0X13
-#define BMI160_ACCEL_Y_LSB_ADDR 0X14
-#define BMI160_ACCEL_Y_MSB_ADDR 0X15
-#define BMI160_ACCEL_Z_LSB_ADDR 0X16
-#define BMI160_ACCEL_Z_MSB_ADDR 0X17
-/* Data dimension of the sensor */
-enum AccelAxisNum {
- ACCEL_X_AXIS = 0,
- ACCEL_Y_AXIS = 1,
- ACCEL_Z_AXIS = 2,
- ACCEL_AXIS_NUM = 3,
-};
-/* Each dimension of the sensor */
-struct AccelData {
- int32_t x;
- int32_t y;
- int32_t z;
-};
-/* Private data structure of the sensor */
-struct AccelDrvData {
- bool detectFlag;
- uint8_t threadStatus;
- uint8_t initStatus;
- int64_t interval;
- struct SensorCfgData *accelCfg;
- struct OsalThread thread;
- struct AccelOpsCall ops;
-};
-/* Differentiation adaptation function */
-struct AccelOpsCall {
- int32_t (*Init)(struct SensorCfgData *data);
- int32_t (*ReadData)(struct SensorCfgData *data);
-};
-```
-
diff --git a/en/device-dev/driver/sensor-driver-development-guidelines.md b/en/device-dev/driver/sensor-driver-development-guidelines.md
deleted file mode 100644
index afbb833cac70c19f9612461c6d2f9983f58ef544..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sensor-driver-development-guidelines.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# Sensor Driver Development Guidelines
-
-- [How to Develop](#section18816105182315)
-
-Regardless of the OS and system on a chip \(SoC\), the sensor driver is developed based on the HDF, platform, and OSAL APIs to provide a unified driver model for sensor devices. This section uses the acceleration sensor as an example to describe how to develop a sensor driver.
-
-## How to Develop
-
-1. Register the acceleration sensor driver. The HDF provides a unified driver management model. The HDF identifies and loads the target module driver based on the configuration information of the acceleration sensor module.
-2. Initialize and deinitialize the acceleration sensor driver. Using the **init** function, the HDF starts loading the sensor device driver and allocating configuration resources for sensor device data, respectively. Using the **release** function, the HDF releases the resources and configurations loaded by the driver.
-3. Parse the configurations of the acceleration sensor register group. For different types of sensors, you need to configure their respective HCS configuration files in the HCS, check whether the sensor device is in position during the device driver startup, and then load the corresponding configuration file to generate the configuration structure object.
-4. Implement APIs for acceleration sensor driver operations. The driver APIs for various types of sensors, such as **init**, **GetInfo**, **Enable**, **Disable**, **SetBatch**, **SetMode**, **SetOption**, and **ReadSensorData**, are normalized to deliver sensor driver configurations and report sensor data.
-
-> **NOTE:**
->The sensor driver model provides a collection of APIs to implement sensor driver capabilities, including the driver device management capabilities, abstract bus and platform operation capabilities, general configuration capabilities, and configuration parsing capabilities. For details about the APIs, see [Table 2](sensor-driver-overview.md#table1156812588320). You need to implement the following APIs: some operations to perform on sensors \([Table 3](sensor-driver-overview.md#table1083014911336)\), differentiated data configuration of the sensor HCS, and verification of basic driver functions.
-
diff --git a/en/device-dev/driver/sensor-driver-overview.md b/en/device-dev/driver/sensor-driver-overview.md
deleted file mode 100644
index b3d5e86797f93b7c753fdece5fa02adb18f8fbba..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sensor-driver-overview.md
+++ /dev/null
@@ -1,244 +0,0 @@
-# Sensor Driver Overview
-
-- [Introduction](#section667413271505)
-- [Available APIs](#section7255104114110)
-
-## Introduction
-
-The sensor driver module provides APIs for upper-layer sensor services to implement basic sensor capabilities, including querying the sensor list, enabling or disabling a sensor, subscribing to or unsubscribing from sensor data, and setting sensor options. The sensor driver model is developed based on the Hardware Driver Foundation \(HDF\) and supports functions such as cross-OS migration and differentiated device configuration. The following figure shows the architecture of the sensor driver model.
-
-**Figure 1** Architecture of the sensor driver model
-
-
-The sensor driver model offers the following APIs:
-
-- Hardware Driver Interfaces \(HDIs\) for sensors: Facilitate service development.
-- APIs for implementing sensor driver model capabilities: Implement the capabilities of registering, loading, and unregistering sensor drivers as well as detecting sensor devices depending on the HDF, normalize APIs for sensor devices of the same type, and offer APIs for parsing register configurations, abstract APIs for bus access, and abstract platform APIs.
-- APIs to be implemented by developers: Based on the HDF Configuration Source \(HCS\), implement differentiated configuration for sensors of the same type and serialized configuration of sensor device parameters, and offer APIs for some sensor device operations to simplify sensor driver development.
-
-## Available APIs
-
-The following table lists the APIs provided by the sensor driver model.
-
-**Table 1** External APIs provided by the sensor driver model
-
-
-
Obtains information about all sensors in the system. The information about a sensor generally includes the sensor name, sensor vendor, firmware version, hardware version, sensor type ID, sensor ID, maximum measurement range, accuracy, and power.
-
-
-
Setting
-
-
int32_t Enable(int32_t sensorId)
-
-
Enables the sensor that has been subscribed to. The subscriber can obtain the sensor data only after the sensor is enabled.
-
-The following table lists the APIs provided by the sensor driver model for driver developers. You can directly call these APIs without any implementations.
-
-**Table 2** APIs provided by the sensor driver model for driver developers
-
-
-
Obtains basic configuration information such as sensor, bus, and attribute configurations based on the HCS resource configuration of the sensor device, and initializes the basic configuration data structure.
-
-The following table lists the APIs that need to be implemented by driver developers.
-
-**Table 3** APIs that need to be implemented by driver developers
-
-
-
Category
-
-
API
-
-
Description
-
-
-
-
Basic functions
-
-
int32_t init(void)
-
-
Initializes the configuration of a sensor device after it is detected successfully.
-
-
-
int32_t GetInfo(struct SensorBasicInfo *info)
-
-
Obtains the basic information about the current sensor device from the HCS of sensor devices.
-
-
-
int32_t Enable(void)
-
-
Enables the current sensor device by delivering the register configuration in the operation group based on the HCS of the current sensor device.
-
-
-
int32_t Disable(void)
-
-
Disables the current sensor device by delivering the register configuration in the operation group based on the HCS of the current sensor device.
Sets the processing time of the data reporting thread for the current sensor device based on the data sampling interval and data reporting interval.
-
-
-
int32_t SetMode(int32_t mode)
-
-
Sets the data reporting mode of the current sensor device.
-
-
-
int32_t SetOption(uint32_t option)
-
-
Sets the register configuration such as the measurement range and accuracy based on sensor options.
-
-
-
void ReadSensorData(void)
-
-
Reads sensor data.
-
-
-
-
-
-For details about the API implementation, see the [sensor driver development example](sensor-driver-development-example.md).
-
diff --git a/en/device-dev/driver/sensor-driver-test-guidelines.md b/en/device-dev/driver/sensor-driver-test-guidelines.md
deleted file mode 100644
index 042112036cdad78e9aa732e54c8423f8c3ed115e..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sensor-driver-test-guidelines.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# Sensor Driver Test Guidelines
-
-After the driver is developed, you can develop self-test cases in the sensor unit test to verify the basic functions of the driver. The developer self-test platform is used as the test environment.
-
-```
-/* Specify whether to report sensor data. */
-static int32_t g_sensorDataFlag = 0;
-/* Retain the address of the sensor interface instance. */
-static const struct SensorInterface *g_sensorDev = nullptr;
-
-/* Register the data reporting function. */
-static int SensorTestDataCallback(struct SensorEvents *event)
-{
- if (event == nullptr) {
- return -1;
- }
- float *data = (float*)event->data;
- printf("time [%lld] sensor id [%d] x-[%f] y-[%f] z-[%f]\n\r", event->timestamp,
- event->sensorId, (*data), *(data + 1), *(data + g_axisZ));
- if (*data > 1e-5) {
- g_sensorDataFlag = 1;
- }
- return 0;
-}
-/* Initialize the sensor interface instance before executing the test cases. */
-void HdfSensorTest::SetUpTestCase()
-{
- g_sensorDev = NewSensorInterfaceInstance();
- if (g_sensorDev == nullptr) {
- printf("test sensorHdi get Module instace failed\n\r");
- }
-}
-/* Release case resources. */
-void HdfSensorTest::TearDownTestCase()
-{
- if (g_sensorDev != nullptr) {
- FreeSensorInterfaceInstance();
- g_sensorDev = nullptr;
- }
-}
-/* Verify the sensor driver. */
-HWTEST_F(HdfSensorTest,TestAccelDriver_001, TestSize.Level0)
-{
- int32_t sensorInterval = 1000000000; /* Data sampling interval, in nanoseconds */
- int32_t pollTime = 5; /* Data sampling duration, in seconds */
- int32_t accelSensorId = 1; /* Acceleration sensor type ID, which is 1 */
- int32_t count = 0;
- int ret;
- struct SensorInformation *sensorInfo = nullptr;
-
- ret = g_sensorDev->Register(SensorTestDataCallback)
- EXPECT_EQ(SENSOR_NULL_PTR, ret);
-
- ret = g_sensorDev->GetAllSensors(&sensorInfo, &count);
- EXPECT_EQ(0, ret);
- if (sensorInfo == nullptr) {
- EXPECT_NE(nullptr, sensorInfo);
- return;
- }
- /* Print the obtained sensor list. */
- for (int i = 0; i < count; i++) {
- printf("get sensoriId[%d], info name[%s]\n\r", sensorInfo[i]->sensorId, sensorInfo[i]->sensorName);
- }
- ret = g_sensorDev->Enable(accelSensorId);
- EXPECT_EQ(0, ret);
- g_sensorDataFlag = 0;
-
- ret = g_sensorDev->SetBatch(accelSensorId, sensorInterval, pollTime);
- EXPECT_EQ(0, ret);
- /* Observe the printed data within the period specified by pollTime. */
- OsalSleep(pollTime);
- EXPECT_EQ(1, g_sensorDataFlag);
-
- ret = g_sensorDev->Disable(accelSensorId);
- g_sensorDataFlag = 0;
- EXPECT_EQ(0, ret);
-
- ret = g_sensorDev->Unregister();
- EXPECT_EQ(0, ret);
-}
-```
-
diff --git a/en/device-dev/driver/sensor.md b/en/device-dev/driver/sensor.md
deleted file mode 100644
index f9e8d552c0cbad2c430e9457122a25b1d62ee4df..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/sensor.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# SENSOR
-
-- **[Sensor Driver Overview](sensor-driver-overview.md)**
-
-- **[Sensor Driver Development Guidelines](sensor-driver-development-guidelines.md)**
-
-- **[Sensor Driver Development Example](sensor-driver-development-example.md)**
-
-- **[Sensor Driver Test Guidelines](sensor-driver-test-guidelines.md)**
-
-
diff --git a/en/device-dev/driver/spi.md b/en/device-dev/driver/spi.md
deleted file mode 100644
index c635810c74cbb62be99562f6848983e4b7437058..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/spi.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# SPI
-
-- **[SPI Overview](spioverview.md)**
-
-- **[SPI Usage Guidelines](spiusage-guidelines.md)**
-
-- **[SPI Usage Example](spiusage-example.md)**
-
-
diff --git a/en/device-dev/driver/spioverview.md b/en/device-dev/driver/spioverview.md
deleted file mode 100644
index 46303b336baaec8295a11afacc466aed62809c29..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/spioverview.md
+++ /dev/null
@@ -1,107 +0,0 @@
-# SPI Overview
-
-- [Introduction](#section9202632114011)
-- [Available APIs](#section1859594134119)
-
-## Introduction
-
-- Serial Peripheral Interface \(SPI\) is a serial bus specification used for high-speed, full-duplex, and synchronous communication.
-- SPI is developed by Motorola. It is commonly used for communication with flash memory, real-time clocks, sensors, and analog-to-digital \(A/D\) converters.
-- SPI works in controller/device mode. Generally, there is one SPI controller that controls one or more SPI devices. They are connected via four wires:
- - SCLK: clock signals output from the SPI controller
- - MOSI: data output from the SPI controller and input into an SPI device
- - MISO: data output from an SPI device and input into the SPI controller
- - CS: signals enabled by an SPI device and controlled by the SPI controller
-
-
-- [Figure 1](#fig15227181812587) shows the connection between one SPI controller and two SPI devices \(device A and device B\). In this figure, device A and device B share three pins \(SCLK, MISO, and MOSI\) of the controller. CS0 of device A and CS1 of device B are connected to CS0 and CS1 of the controller, respectively.
-
-**Figure 1** SPI controller/device connection
-
-
-
-
-- SPI communication is usually initiated by the SPI controller and is operated as follows:
-
-1. A single SPI device is selected at a time via the CS to communicate with the SPI controller.
-2. Clock signals are provided for the selected SPI device via the SCLK.
-3. The SPI controller sends data to SPI devices via the MOSI, and receives data from SPI devices via the MISO.
-
-- SPI can work in one of the following four modes, equivalent to one of the four possible states for Clock Polarity \(CPOL\) and Clock Phase \(CPHA\):
- - If both CPOL and CPHA are **0**, the clock signal level is low in the idle state and data is sampled on the first clock edge.
- - If CPOL is **0** and CPHA is **1**, the clock signal level is low in the idle state and data is sampled on the second clock edge.
- - If CPOL is **1** and CPHA is **0**, the clock signal level is high in the idle state and data is sampled on the first clock edge.
- - If both CPOL and CPHA are **1**, the clock signal level is high in the idle state and data is sampled on the second clock edge.
-
-
-- SPI defines a set of common functions for operating an SPI device, including those for:
- - Obtaining and releasing the handle of an SPI device.
- - Reading or writing data of a specified length from or into an SPI device.
- - Customizing data reading or writing via **SpiMsg**.
- - Obtaining and setting SPI device configuration parameters.
-
-
-> **NOTE:**
->Currently, these functions are only applicable in the communication initiated by the SPI controller.
-
-## Available APIs
-
-**Table 1** APIs for the SPI driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
SPI device handle obtaining/releasing
-
-
SpiOpen
-
-
Obtains an SPI device handle.
-
-
-
SpiClose
-
-
Releases an SPI device handle.
-
-
-
SPI reading/writing
-
-
SpiRead
-
-
Reads data of a specified length from an SPI device.
-
-
-
SpiWrite
-
-
Writes data of a specified length into an SPI device.
-
-
-
SpiTransfer
-
-
Transfers SPI data.
-
-
-
SPI device configuration
-
-
-
SpiSetCfg
-
-
Sets configuration parameters for an SPI device.
-
-
-
SpiGetCfg
-
-
Obtains configuration parameters of an SPI device.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel space.
-
diff --git a/en/device-dev/driver/spiusage-example.md b/en/device-dev/driver/spiusage-example.md
deleted file mode 100644
index f3d6cb2b6f667233355952efa8c7c91e780bc182..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/spiusage-example.md
+++ /dev/null
@@ -1,70 +0,0 @@
-# SPI Usage Example
-
-The following is a usage example of an SPI device, including how to obtain an SPI device handle, set the configuration parameters, and then read or write data from or into the SPI device, and finally destroy the SPI device handle.
-
-```
-#include "hdf_log.h"
-#include "spi_if.h"
-
-void SpiTestSample(void)
-{
- int32_t ret;
- struct SpiCfg cfg; /* SPI device configuration information */
- struct SpiDevInfo spiDevinfo; /* SPI device descriptor */
- DevHandle spiHandle = NULL; /* SPI device handle */
- struct SpiMsg msg; /* Custom message to be transferred */
- uint8_t rbuff[4] = { 0 };
- uint8_t wbuff[4] = { 0x12, 0x34, 0x56, 0x78 };
- uint8_t wbuff2[4] = { 0xa1, 0xb2, 0xc3, 0xd4 };
-
- spiDevinfo.busNum = 0; /* SPI device bus number */
- spiDevinfo.csNum = 0; /* SPI device CS number */
- spiHandle = SpiOpen(&spiDevinfo); /* Obtain an SPI device handle based on spiDevinfo. */
- if (spiHandle == NULL) {
- HDF_LOGE("SpiOpen: failed\n");
- return;
- }
- /* Obtain configuration parameters of an SPI device. */
- ret = SpiGetCfg(spiHandle, &cfg);
- if (ret != 0) {
- HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret);
- goto err;
- }
- cfg.maxSpeedHz = 115200; /* Change the maximum clock frequency to 115200. */
- cfg.bitsPerWord = 8; /* Change the word width to 8 bits. */
- /* Set configuration parameters for an SPI device. */
- ret = SpiSetCfg(spiHandle, &cfg);
- if (ret != 0) {
- HDF_LOGE("SpiSetCfg: failed, ret %d\n", ret);
- goto err;
- }
- /* Write specified length of data into an SPI device. */
- ret = SpiWrite(spiHandle, wbuff, 4);
- if (ret != 0) {
- HDF_LOGE("SpiWrite: failed, ret %d\n", ret);
- goto err;
- }
- /* Read data of a specified length from an SPI device. */
- ret = SpiRead(spiHandle, rbuff, 4);
- if (ret != 0) {
- HDF_LOGE("SpiRead: failed, ret %d\n", ret);
- goto err;
- }
- msg.wbuf = wbuff2; /* Pointer to the data to write */
- msg.rbuf = rbuff; /* Pointer to the data to read */
- msg.len = 4; /* The length of the data to be read or written is 4 bits. */
- msg.csChange = 1; /* Disable the CS before the next transfer. */
- msg.delayUs = 0; /* No delay before the next transfer */
- msg.speed = 115200; /* Speed of this transfer */
- /* Launch a custom transfer. The number of messages to be transferred is 1. */
- ret = SpiTransfer(spiHandle, &msg, 1);
- if (ret != 0) {
- HDF_LOGE("SpiTransfer: failed, ret %d\n", ret);
- goto err;
- }
-err:
- /* Destroy the SPI device handle. */
- SpiClose(spiHandle);
-}
-```
-
diff --git a/en/device-dev/driver/spiusage-guidelines.md b/en/device-dev/driver/spiusage-guidelines.md
deleted file mode 100644
index f5f9c482c055005b3544881cf16ef8e4e197abc3..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/spiusage-guidelines.md
+++ /dev/null
@@ -1,386 +0,0 @@
-# SPI Usage Guidelines
-
-- [How to Use](#section691514116412)
-- [Obtaining an SPI Device Handle](#section12372204616215)
-- [Obtaining SPI Device Configuration Parameters](#section17121446171311)
-- [Setting SPI Device Configuration Parameters](#section97691946634)
-- [Performing SPI Communication](#section197116254416)
-- [Destroying the SPI Device Handle](#section117661819108)
-
-## How to Use
-
-[Figure 1](#fig23885455594) shows the process of using an SPI device.
-
-**Figure 1** Process of using an SPI device
-
-
-
-
-## Obtaining an SPI Device Handle
-
-Before performing SPI communication, obtain an SPI device handle by calling **SpiOpen**. This function returns an SPI device handle with a specified bus number and CS number.
-
-DevHandle SpiOpen\(const struct SpiDevInfo \*info\);
-
-**Table 1** Description of **SpiOpen**
-
-
-
Parameter
-
-
Description
-
-
-
info
-
-
Pointer to the SPI device descriptor.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to obtain an SPI device handle.
-
-
-
Device handle
-
-
Returns the pointer to the SPI device handle.
-
-
-
-
-
-The following example shows how to obtain an SPI device handle based on the assumption that both the bus number and CS number of the SPI device are **0**.
-
-```
-struct SpiDevInfo spiDevinfo; /* SPI device descriptor */
-DevHandle spiHandle = NULL; /* SPI device handle */
-spiDevinfo.busNum = 0; /* SPI device bus number */
-spiDevinfo.csNum = 0; /* SPI device CS number */
-
-/* Obtain an SPI device handle. */
-spiHandle = SpiOpen(&spiDevinfo);
-if (spiHandle == NULL) {
- HDF_LOGE("SpiOpen: failed\n");
- return;
-}
-```
-
-## Obtaining SPI Device Configuration Parameters
-
-After obtaining the SPI device handle, obtain the SPI device configuration parameters by calling the following function:
-
-int32\_t SpiGetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
-
-**Table 2** Description of **SpiGetCfg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
cfg
-
-
Pointer to SPI device configuration parameters.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in obtaining SPI device configuration parameters.
-
-
-
Negative value
-
-
Failed to obtain SPI device configuration parameters.
-
-
-
-
-
-```
-int32_t ret;
-struct SpiCfg cfg = {0}; /* SPI configuration information */
-ret = PalSpiSetCfg(spiHandle, &cfg); /* Set SPI device configuration parameters. */
-if (ret != 0) {
- HDF_LOGE("SpiGetCfg: failed, ret %d\n", ret);
-}
-```
-
-## Setting SPI Device Configuration Parameters
-
-After obtaining the SPI device handle, set SPI device configuration parameters by calling the following function:
-
-int32\_t SpiSetCfg\(DevHandle handle, struct SpiCfg \*cfg\);
-
-**Table 3** Description of **SpiSetCfg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
cfg
-
-
Pointer to SPI device configuration parameters.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting SPI device configuration parameters.
-
-
-
Negative value
-
-
Failed to set SPI device configuration parameters.
-
-
-
-
-
-```
-int32_t ret;
-struct SpiCfg cfg = {0}; /* SPI configuration information */
-cfg.mode = SPI_MODE_LOOP; /* Communicate in loopback mode. */
-cfg.comMode = PAL_SPI_POLLING_TRANSFER; /* Communicate in polling mode. */
-cfg.maxSpeedHz = 115200; /* Maximum transmission frequency */
-cfg.bitsPerWord = 8; /* The width of per word to be read or written is 8 bits. */
-ret = SpiSetCfg(spiHandle, &cfg); /* Set SPI device configuration parameters. */
-if (ret != 0) {
- HDF_LOGE("SpiSetCfg: failed, ret %d\n", ret);
-}
-```
-
-## Performing SPI Communication
-
-- Writing data of a specified length into an SPI device
-
-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 4** Description of **SpiWrite**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
buf
-
-
Pointer to the data to write.
-
-
-
len
-
-
Length of the data to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in writing data into an SPI device.
-
-
-
Negative value
-
-
Failed to write data into an SPI device.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t wbuff[4] = {0x12, 0x34, 0x56, 0x78};
-/* Write data of a specified length into an SPI device. */
-ret = SpiWrite(spiHandle, wbuff, 4);
-if (ret != 0) {
- HDF_LOGE("SpiWrite: failed, ret %d\n", ret);
-}
-```
-
-- Reading data of a specified length from an SPI device
-
-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 5** Description of **SpiRead**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
buf
-
-
Pointer to the data to read.
-
-
-
len
-
-
Length of the data to read.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in reading data from an SPI device.
-
-
-
Negative value
-
-
Failed to read data from an SPI device.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t rbuff[4] = {0};
-/* Read data of a specified length from an SPI device. */
-ret = SpiRead(spiHandle, rbuff, 4);
-if (ret != 0) {
- HDF_LOGE("SpiRead: failed, ret %d\n", ret);
-}
-```
-
-- Launching a custom transfer
-
-To launch a custom transfer, call the following function:
-
-int32\_t SpiTransfer\(DevHandle handle, struct SpiMsg \*msgs, uint32\_t count\);
-
-**Table 6** Description of **SpiTransfer**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle.
-
-
-
msgs
-
-
Pointer to the message array to be transferred.
-
-
-
count
-
-
Length of the message array.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in launching the custom transfer.
-
-
-
Negative value
-
-
Failed to launch the custom transfer.
-
-
-
-
-
-```
-int32_t ret;
-uint8_t wbuff[1] = {0x12};
-uint8_t rbuff[1] = {0};
-struct SpiMsg msg; /* Custom message to be transferred */
-msg.wbuf = wbuff; /* Pointer to the data to read */
-msg.rbuf = rbuff; /* Pointer to the data to read */
-msg.len = 1; /* The length of the data to be read or written is 1 bit. */
-msg.csChange = 1; /* Disable the CS before the next transfer. */
-msg.delayUs = 0; /* No delay before the next transfer */
-msg.speed = 115200; /* Speed of this transfer */
-/* Launch a custom transfer. The number of messages to be transferred is 1. */
-ret = SpiTransfer(spiHandle, &msg, 1);
-if (ret != 0) {
- HDF_LOGE("SpiTransfer: failed, ret %d\n", ret);
-}
-```
-
-## Destroying the SPI Device Handle
-
-After the SPI communication, destroy the SPI device handle by calling the following function:
-
-void SpiClose\(DevHandle handle\);
-
-This function will release the resources previously obtained.
-
-**Table 7** Description of **SpiClose**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
Pointer to the SPI device handle
-
-
-
-
-
-```
-PalHandleDestroy(spiHandle); /* Destroy the SPI device handle. */
-```
-
diff --git a/en/device-dev/driver/touchscreen.md b/en/device-dev/driver/touchscreen.md
deleted file mode 100644
index 49b35d23fb1f1ea0438f92292ae22e794a155dbb..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/touchscreen.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# TOUCHSCREEN
-
-- **[Touchscreen Overview](touchscreenoverview.md)**
-
-- **[Touchscreen Development Guidelines](touchscreendevelopment-guidelines.md)**
-
-- **[Touchscreen Development Example](touchscreendevelopment-example.md)**
-
-
diff --git a/en/device-dev/driver/touchscreendevelopment-example.md b/en/device-dev/driver/touchscreendevelopment-example.md
deleted file mode 100644
index 8d49343af5e1b1c2e1aaaa1fc113d75f2dc8a540..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/touchscreendevelopment-example.md
+++ /dev/null
@@ -1,300 +0,0 @@
-# Touchscreen Development Example
-
-- [Device Description Configuration](#section85281142102317)
-- [Board-level Hardware Configuration and Private Data Configuration](#section189081946192410)
-- [Adding the Touchscreen Driver](#section19856687253)
-
-This example describes how to develop the touchscreen driver.
-
-## Device Description Configuration
-
-The information about modules of the input driver model is shown as follows and enables the HDF to load the modules in sequence. For details, see [Driver Development](driver-development.md).
-
-```
-input :: host {
- hostName = "input_host";
- priority = 100;
- device_input_manager :: device {
- device0 :: deviceNode {
- policy = 2; // Publish services externally.
- priority = 100; // Loading priority. The input device manager in the input driver has the highest priority.
- preload = 0; // Value 0 indicates that the driver is to be loaded, and value 1 indicates the opposite.
- permission = 0660;
- moduleName = "HDF_INPUT_MANAGER";
- serviceName = "input_dev_manager";
- deviceMatchAttr = "";
- }
- }
- device_hdf_touch :: device {
- device0 :: deviceNode {
- policy = 2;
- priority = 120;
- preload = 0;
- permission = 0660;
- moduleName = "HDF_TOUCH";
- serviceName = "event1";
- deviceMatchAttr = "touch_device1";
- }
- }
-
- device_touch_chip :: device {
- device0 :: deviceNode {
- policy = 0;
- priority = 130;
- preload = 0;
- permission = 0660;
- moduleName = "HDF_TOUCH_SAMPLE";
- serviceName = "hdf_touch_sample_service";
- deviceMatchAttr = "zsj_sample_5p5";
- }
- }
-}
-```
-
-## Board-level Hardware Configuration and Private Data Configuration
-
-The following describes the configuration of the board-level hardware and private data of the touchscreen. You can modify the configuration based on the service requirements.
-
-```
-root {
- input_config {
- touchConfig {
- touch0 {
- boardConfig {
- match_attr = "touch_device1";
- inputAttr {
- inputType = 0; // Value 0 indicates that the input device is a touchscreen.
- solutionX = 480;
- solutionY = 960;
- devName = "main_touch"; // Device name
- }
- busConfig {
- busType = 0; // Value 0 indicates the I2C bus.
- busNum = 6;
- clkGpio = 86;
- dataGpio = 87;
- i2cClkIomux = [0x114f0048, 0x403]; // Register configuration of the i2c_clk pin
- i2cDataIomux = [0x114f004c, 0x403]; // Register configuration of the i2c_data pin
- }
- pinConfig {
- rstGpio = 3;
- intGpio = 4;
- rstRegCfg = [0x112f0094, 0x400]; // Register configuration of the reset pin
- intRegCfg = [0x112f0098, 0x400]; // Register configuration of the interrupt pin
- }
- powerConfig {
- vccType = 2; // Values 1, 2, and 3 indicate the low-dropout regulator (LDO), GPIO, and PMIC, respectively.
- vccNum = 20; // The GPIO number is 20.
- vccValue = 1800; // The voltage amplitude is 1800 mV.
- vciType = 1;
- vciNum = 12;
- vciValue = 3300;
- }
- featureConfig {
- capacitanceTest = 0;
- gestureMode = 0;
- gloverMOde = 0;
- coverMode = 0;
- chargerMode = 0;
- knuckleMode = 0;
- }
- }
- chipConfig {
- template touchChip {
- match_attr = "";
- chipName = "sample";
- vendorName = "zsj";
- chipInfo = "AAAA11222"; // The first four characters indicate the product name. The fifth and sixth characters indicate the IC model. The last three characters indicate the chip model.
- busType = 0;
- deviceAddr = 0x5D;
- irqFlag = 2; // Values 1 and 2 indicate that the interrupt is triggered on the rising and falling edges, respectively. Values 4 and 8 indicate that the interrupt is triggered by the high and low levels, respectively.
- maxSpeed = 400;
- chipVersion = 0;
- powerSequence {
- /* Power-on sequence is described as follows:
- [Type, status, direction, delay]
- Value 0 indicates the power or pin is empty. Values 1 and 2 indicate the VCC (1.8 V) and VCI (3.3 V) power, respectively. Values 3 and 4 indicate the reset and interrupt pins, respectively.
- Values 0 and 1 indicate the power-off or pull-down, and the power-on or pull-up, respectively. Value 2 indicates that no operation is performed.
- Values 0 and 1 indicate the input and output directions, respectively. Value 2 indicates that no operation is performed.
- Delay time, in milliseconds.
- */
- powerOnSeq = [4, 0, 1, 0,
- 3, 0, 1, 10,
- 3, 1, 2, 60,
- 4, 2, 0, 0];
- suspendSeq = [3, 0, 2, 10];
- resumeSeq = [3, 1, 2, 10];
- powerOffSeq = [3, 0, 2, 10,
- 1, 0, 2, 20];
- }
- }
- chip0 :: touchChip {
- match_attr = "zsj_sample_5p5";
- chipInfo = "ZIDN45100";
- chipVersion = 0;
- }
- }
- }
- }
- }
-}
-```
-
-## Adding the Touchscreen Driver
-
-The following example shows how to implement the differentiated APIs provided by the platform driver to obtain and parse the touchscreen data. You can adjust the development process based on the board and touchscreen in use.
-
-```
-/* Parse the touch reporting data read from the touchscreen into coordinates. */
-static void ParsePointData(ChipDevice *device, FrameData *frame, uint8_t *buf, uint8_t pointNum)
-{
- int32_t resX = device->driver->boardCfg->attr.resolutionX;
- int32_t resY = device->driver->boardCfg->attr.resolutionY;
-
- for (int32_t i = 0; i < pointNum; i++) {
- frame->fingers[i].y = (buf[GT_POINT_SIZE * i + GT_X_LOW] & ONE_BYTE_MASK) |
- ((buf[GT_POINT_SIZE * i + GT_X_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
- frame->fingers[i].x = (buf[GT_POINT_SIZE * i + GT_Y_LOW] & ONE_BYTE_MASK) |
- ((buf[GT_POINT_SIZE * i + GT_Y_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
- frame->fingers[i].valid = true;
- }
-}
-/* Obtain the touch reporting data from the chip. */
-static int32_t ChipDataHandle(ChipDevice *device)
-{
- int32_t ret;
- uint8_t touchStatus = 0;
- uint8_t pointNum;
- uint8_t buf[GT_POINT_SIZE * MAX_SUPPORT_POINT] = {0};
- InputI2cClient *i2cClient = &device->driver->i2cClient;
- uint8_t reg[GT_ADDR_LEN] = {0};
- FrameData *frame = &device->driver->frameData;
- reg[0] = (GT_BUF_STATE_ADDR >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
- reg[1] = GT_BUF_STATE_ADDR & ONE_BYTE_MASK;
- ret = InputI2cRead(i2cClient, reg, GT_ADDR_LEN, &touchStatus, 1);
- if (ret < 0 || touchStatus == GT_EVENT_INVALID) {
- return HDF_FAILURE;
- }
- OsalMutexLock(&device->driver->mutex);
- (void)memset_s(frame, sizeof(FrameData), 0, sizeof(FrameData));
- if (touchStatus == GT_EVENT_UP) {
- frame->realPointNum = 0;
- frame->definedEvent = TOUCH_UP;
- goto exit;
- }
- reg[0] = (GT_X_LOW_BYTE_BASE >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
- reg[1] = GT_X_LOW_BYTE_BASE & ONE_BYTE_MASK;
- pointNum = touchStatus & GT_FINGER_NUM_MASK;
- if (pointNum <= 0 || pointNum > MAX_SUPPORT_POINT) {
- HDF_LOGE("%s: pointNum is invalid, %d", __func__, pointNum);
- (void)ChipCleanBuffer(i2cClient);
- OsalMutexUnlock(&device->driver->mutex);
- return HDF_FAILURE;
- }
- frame->realPointNum = pointNum;
- frame->definedEvent = TOUCH_DOWN;
- /* Read the touch reporting data from the register. */
- (void)InputI2cRead(i2cClient, reg, GT_ADDR_LEN, buf, GT_POINT_SIZE * pointNum);
- /* Parse the touch reporting data. */
- ParsePointData(device, frame, buf, pointNum);
-exit:
- OsalMutexUnlock(&device->driver->mutex);
- if (ChipCleanBuffer(i2cClient) != HDF_SUCCESS) {
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
-}
-
-static struct TouchChipOps g_sampleChipOps = {
- .Init = ChipInit,
- .Detect = ChipDetect,
- .Resume = ChipResume,
- .Suspend = ChipSuspend,
- .DataHandle = ChipDataHandle,
-};
-
-static TouchChipCfg *ChipConfigInstance(struct HdfDeviceObject *device)
-{
- TouchChipCfg *chipCfg = (TouchChipCfg *)OsalMemAlloc(sizeof(TouchChipCfg));
- if (chipCfg == NULL) {
- HDF_LOGE("%s: instance chip config failed", __func__);
- return NULL;
- }
- (void)memset_s(chipCfg, sizeof(TouchChipCfg), 0, sizeof(TouchChipCfg));
- /* Parse the private configuration of the touchscreen. */
- if (ParseTouchChipConfig(device->property, chipCfg) != HDF_SUCCESS) {
- HDF_LOGE("%s: parse chip config failed", __func__);
- OsalMemFree(chipCfg);
- chipCfg = NULL;
- }
- return chipCfg;
-}
-
-static ChipDevice *ChipDeviceInstance(void)
-{
- ChipDevice *chipDev = (ChipDevice *)OsalMemAlloc(sizeof(ChipDevice));
- if (chipDev == NULL) {
- HDF_LOGE("%s: instance chip device failed", __func__);
- return NULL;
- }
- (void)memset_s(chipDev, sizeof(ChipDevice), 0, sizeof(ChipDevice));
- return chipDev;
-}
-
-static void FreeChipConfig(TouchChipCfg *config)
-{
- if (config->pwrSeq.pwrOn.buf != NULL) {
- OsalMemFree(config->pwrSeq.pwrOn.buf);
- }
- if (config->pwrSeq.pwrOff.buf != NULL) {
- OsalMemFree(config->pwrSeq.pwrOff.buf);
- }
- OsalMemFree(config);
-}
-
-static int32_t HdfSampleChipInit(struct HdfDeviceObject *device)
-{
- TouchChipCfg *chipCfg = NULL;
- ChipDevice *chipDev = NULL;
- HDF_LOGE("%s: enter", __func__);
- if (device == NULL) {
- return HDF_ERR_INVALID_PARAM;
- }
- /* Parse the private configuration of the touchscreen. */
- chipCfg = ChipConfigInstance(device);
- if (chipCfg == NULL) {
- return HDF_ERR_MALLOC_FAIL;
- }
- /* Instantiate the touchscreen device. */
- chipDev = ChipDeviceInstance();
- if (chipDev == NULL) {
- goto freeCfg;
- }
- chipDev->chipCfg = chipCfg;
- chipDev->ops = &g_sampleChipOps;
- chipDev->chipName = chipCfg->chipName;
- chipDev->vendorName = chipCfg->vendorName;
-
- /* Register the touchscreen device with the platform driver. */
- if (RegisterChipDevice(chipDev) != HDF_SUCCESS) {
- goto freeDev;
- }
- HDF_LOGI("%s: exit succ, chipName = %s", __func__, chipCfg->chipName);
- return HDF_SUCCESS;
-
-freeDev:
- OsalMemFree(chipDev);
-freeCfg:
- FreeChipConfig(chipCfg);
- return HDF_FAILURE;
-}
-
-struct HdfDriverEntry g_touchSampleChipEntry = {
- .moduleVersion = 1,
- .moduleName = "HDF_TOUCH_SAMPLE",
- .Init = HdfSampleChipInit,
-};
-
-HDF_INIT(g_touchSampleChipEntry);
-```
-
diff --git a/en/device-dev/driver/touchscreendevelopment-guidelines.md b/en/device-dev/driver/touchscreendevelopment-guidelines.md
deleted file mode 100644
index 9e1543c1e668c4bdc8aa62be3073a6539ff5f1de..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/touchscreendevelopment-guidelines.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Touchscreen Development Guidelines
-
-- [How to Develop](#section1255740132616)
-
-Regardless of the OS and system on a chip \(SoC\), the input driver is developed based on the HDF, platform, and OSAL APIs to provide a unified driver model for touchscreen devices.
-
-- The following uses the touchscreen driver as an example to describe the loading process of the input driver model:
- - Add the touchscreen driver-related descriptions: You can add the touchscreen driver-related descriptions, such as the loading priority, board-level hardware information, and private data, by referring to the existing template.
-
- - Load the input device manager driver: The HDF automatically loads the input device manager driver, which then creates the device manager and initializes it.
-
- - Load the touchscreen common driver: The HDF automatically loads the touchscreen common driver, which then parses the board-level configuration, initializes the hardware, and provides the API for registering the touchscreen.
-
- - Load the touchscreen chip driver: The HDF automatically loads the touchscreen chip driver, which then instantiates the touchscreen device, parses the private data, and implements differentiated APIs provided by the platform.
-
- - Register the touchscreen device with the platform driver: Register the instantiated touchscreen device with the platform driver, bind this device to the platform driver, and complete touchscreen initialization such as interrupt registration and power-on and power-off.
-
- - Register the input device: Instantiate the input device and register it with the input manager after the touchscreen is initialized.
-
-
-## How to Develop
-
-1. Add the touchscreen driver-related descriptions.
-
- Currently, the input driver is developed based on the HDF and is loaded and started by the HDF. Register the driver information, such as whether to load the driver and the loading priority in the configuration file. Then, the HDF starts the registered driver modules one by one. For details about the driver configuration, see [How to Develop](driver-development.md#section1969312275533).
-
-2. Complete the board-level configuration and private data configuration of the touchscreen.
-
- Configure the required I/O pins. For example, configure a register for the I2C pin reserved for the touchscreen to use I2C for transmitting data.
-
-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 Usage Guidelines](gpiousage-guidelines.md).
-
-
diff --git a/en/device-dev/driver/touchscreenoverview.md b/en/device-dev/driver/touchscreenoverview.md
deleted file mode 100644
index b136894e5ade080a07e5ff457b20fd74eefd33b9..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/touchscreenoverview.md
+++ /dev/null
@@ -1,71 +0,0 @@
-# Touchscreen Overview
-
-- [Introduction](#section124332411260)
-- [Available APIs](#section10542625172618)
-
-## Introduction
-
-- **Functions of the Touchscreen driver**
-
- The Touchscreen driver is used to power on its integrated circuit \(IC\), configure and initialize hardware pins, register interrupts, configure Inter-Integrated Circuit \(I2C\) or SPI APIs, set input-related configurations, and download and update firmware.
-
-
-- **Layers of the Touchscreen driver**
-
- This section describes how to develop the touchscreen driver based on the input driver model. [Figure 1](#fig6251184817261) shows an overall architecture of the touchscreen driver.
-
- The input driver is developed based on the hardware driver foundation \(HDF\), platform APIs, and operating system abstraction layer \(OSAL\) APIs. It provides hardware driver capabilities through the input Hardware Driver Interfaces \(HDIs\) for upper-layer input services to control the touchscreen.
-
-
-**Figure 1** Architecture of the input driver model
-
-
-- **Input driver model**
-
- The input driver model mainly consists of the device manager, common drivers, and chip drivers. The platform data channel provides capabilities for sending data generated by the touchscreen from the kernel to the user space. The driver model adapts to different touchscreen devices and hardware platforms via the configuration file, improving the efficiency of the touchscreen development. The description for each part of the input driver model is as follows:
-
- - Input device manager: provides various input device drivers with the APIs for registering or unregistering input devices and manages the input device list.
-
- - Input common driver: provides common abstract drivers \(such as the touchscreen common driver\) of various input devices for initializing the board-level hardware, processing hardware interrupts, and registering input devices with the input device manager.
-
- - Input chip driver: provides different chip drivers of each vendor. You can minimize the workload for the input chip driver development by calling differentiated APIs reserved by the input platform driver.
-
- - Event hub: provides a unified data reporting channel, which enables various input devices to report input events.
-
- - HDF input config: parses and manages the board-level configuration as well as the private configuration of input devices.
-
-
-- **Advantages of developing drivers based on the HDF**
-
- The touchscreen driver is developed based on the HDF and is implemented via calls to the OSAL and platform APIs, including bus APIs and OS native APIs \(such as memory, lock, thread, and timer\). The OSAL and platform APIs hide the differences of underlying hardware, so that the touchscreen driver can be migrated across platforms and OSs. In this regard, you can develop the touchscreen driver only once but deploy it on multiple devices.
-
-
-## Available APIs
-
-Based on the attributes of the pins, interfaces on the touchscreens can be classified into the following types:
-
-- Power interfaces
-- I/O control interfaces
-- Communications interfaces
-
-**Figure 2** Common pins of the touchscreen
-
-
-The interfaces shown in the figure are described as follows:
-
-1. **Power interfaces**
- - LDO\_1P8: 1.8 V digital circuits
- - LDO\_3P3: 3.3 V analog circuits
-
- 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 Usage Guidelines](i2c-usage-guidelines.md).
- - 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 Usage Guidelines](spiusage-guidelines.md).
-
-
diff --git a/en/device-dev/driver/uart.md b/en/device-dev/driver/uart.md
deleted file mode 100644
index 9abd98bb4e661a01011d233577ae4109bcdd208e..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/uart.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# UART
-
-- **[UART Overview](uartoverview.md)**
-
-- **[UART Usage Guidelines](uartusage-guidelines.md)**
-
-- **[UART Usage Example](uartusage-example.md)**
-
-
diff --git a/en/device-dev/driver/uartoverview.md b/en/device-dev/driver/uartoverview.md
deleted file mode 100644
index 2238f2ca5564f4f1faa35bf16590c51a6492ad07..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/uartoverview.md
+++ /dev/null
@@ -1,106 +0,0 @@
-# UART Overview
-
-- [Introduction](#section14770623164917)
-- [Available APIs](#section149505462492)
-
-## Introduction
-
-- The Universal Asynchronous Receiver/Transmitter \(UART\) is a universal serial data bus used for asynchronous communication. It enables bi-directional communication between devices in full-duplex mode.
-- UART is widely used to print information for debugging or to connect to various external modules such as GPS and Bluetooth.
-- A UART is connected to other modules through two wires \(as shown in [Figure 1](#fig209936401896)\) or four wires \(as shown in [Figure 2](#fig1435614171015)\).
- - TX: TX pin of the transmitting UART. It is connected to the RX pin of the peer UART.
- - RX: RX pin of the receiving UART. It is connected to the TX pin of the peer UART.
- - RTS: Request to Send signal pin. It is connected to the CTS pin of the peer UART and is used to indicate whether the local UART is ready to receive data.
- - CTS: Clear to Send signal pin. It is connected to the RTS pin of the peer UART and is used to indicate whether the local UART is allowed to send data to the peer end.
-
- **Figure 1** 2-wire UART communication
-
-
- 
-
- **Figure 2** 4-wire UART communication
-
-
- 
-
-
-- The transmitting and receiving UARTs must ensure that they have the same settings on particular attributes such as the baud rate and data format \(start bit, data bit, parity bit, and stop bit\) before they start to communicate. During data transmission, a UART sends data to the peer end over the TX pin and receives data from the peer end over the RX pin. When the size of the buffer used by a UART for storing received data reaches the preset threshold, the RTS signal of the UART changes to **1** \(data cannot be received\), and the peer UART stops sending data to it because its CTS signal does not allow it to send data.
-- The UART interface defines a set of common functions for operating a UART port, including obtaining and releasing device handles, reading and writing data of a specified length, and obtaining and setting the baud rate, as well as the device attributes.
-
-## Available APIs
-
-**Table 1** APIs for the UART driver
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
Obtaining and releasing device handles
-
-
-
UartOpen
-
-
Obtains the UART device handle.
-
-
-
UartClose
-
-
Releases a specified UART device handle.
-
-
-
Reading and writing data
-
-
-
UartRead
-
-
Reads data of a specified length from a UART device.
-
-
-
UartWrite
-
-
Writes data of a specified length into a UART device.
-
-
-
Obtaining and setting the baud rate
-
-
UartGetBaud
-
-
Obtains the UART baud rate.
-
-
-
UartSetBaud
-
-
Sets the UART baud rate.
-
-
-
Obtaining and setting device attributes
-
-
-
UartGetAttribute
-
-
Obtains the UART device attributes.
-
-
-
UartSetAttribute
-
-
Sets the UART device attributes.
-
-
-
Setting the transmission mode
-
-
UartSetTransMode
-
-
Sets the UART transmission mode.
-
-
-
-
-
-> **NOTE:**
->All functions provided in this document can be called only in kernel space.
-
diff --git a/en/device-dev/driver/uartusage-example.md b/en/device-dev/driver/uartusage-example.md
deleted file mode 100644
index 32572d405213dc537c54c2dafdd7c1902e64a048..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/uartusage-example.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# UART Usage Example
-
-The following is a usage example of a UART device, including how to obtain the UART device handle, set the baud rate, device attributes, and transmission mode, read data from or write data into the UART device, and then destroy the UART device handle.
-
-```
-#include "hdf_log.h"
-#include "uart_if.h"
-
-void UartTestSample(void)
-{
- int32_t ret;
- uint32_t port;
- DevHandle handle = NULL;
- uint8_t wbuff[5] = { 1, 2, 3, 4, 5 };
- uint8_t rbuff[5] = { 0 };
- struct UartAttribute attribute;
- attribute.dataBits = UART_ATTR_DATABIT_7; /* Set the number of data bits to 7. */
- attribute.parity = UART_ATTR_PARITY_NONE; /* Set the parity bit to no parity. */
- attribute.stopBits = UART_ATTR_STOPBIT_1; /* Set the stop bit to 1. */
- attribute.rts = UART_ATTR_RTS_DIS; /* Disable the RTS signal. */
- attribute.cts = UART_ATTR_CTS_DIS; /* Disable the CTS signal. */
- attribute.fifoRxEn = UART_ATTR_RX_FIFO_EN; /* Enable RX FIFO. */
- attribute.fifoTxEn = UART_ATTR_TX_FIFO_EN; /* Enable TX FIFO. */
- /* Set the UART port number actually used. */
- port = 1;
- /* Obtain the UART device handle. */
- handle = UartOpen(port);
- if (handle == NULL) {
- HDF_LOGE("UartOpen: failed!\n");
- return;
- }
- /* Set the UART baud rate to 9600. */
- ret = UartSetBaud(handle, 9600);
- if (ret != 0) {
- HDF_LOGE("UartSetBaud: failed, ret %d\n", ret);
- goto _ERR;
- }
- /* Set the UART device attributes. */
- ret = UartSetAttribute(handle, &attribute);
- if (ret != 0) {
- HDF_LOGE("UartSetAttribute: failed, ret %d\n", ret);
- goto _ERR;
- }
- /* Set the UART transmission mode to non-blocking mode. */
- ret = UartSetTransMode(handle, UART_MODE_RD_NONBLOCK);
- if (ret != 0) {
- HDF_LOGE("UartSetTransMode: failed, ret %d\n", ret);
- goto _ERR;
- }
- /* Write 5-byte data into the UART device. */
- ret = UartWrite(handle, wbuff, 5);
- if (ret != 0) {
- HDF_LOGE("UartWrite: failed, ret %d\n", ret);
- goto _ERR;
- }
- /* Read 5-byte data from the UART device. */
- ret = UartRead(handle, rbuff, 5);
- if (ret < 0) {
- HDF_LOGE("UartRead: failed, ret %d\n", ret);
- goto _ERR;
- }
-_ERR:
- /* Destroy the UART device handle. */
- UartClose(handle);
-}
-```
-
diff --git a/en/device-dev/driver/uartusage-guidelines.md b/en/device-dev/driver/uartusage-guidelines.md
deleted file mode 100644
index edd894e92db887d324ef8b51934c720791bb8b5e..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/uartusage-guidelines.md
+++ /dev/null
@@ -1,506 +0,0 @@
-# UART Usage Guidelines
-
-- [How to Use](#section47784125013)
-- [Obtaining a UART Device Handle](#section146445153110)
-- [Setting the UART Baud Rate](#section1862705516339)
-- [Obtaining the UART Baud Rate](#section1263651563414)
-- [Setting the UART Device Attributes](#section1770091483814)
-- [Obtaining UART Device Attributes](#section117543316384)
-- [Setting the UART Transmission Mode](#section187233112369)
-- [Writing Data of a Specified Length into a UART Device](#section82416423368)
-- [Reading Data of a Specified Length from a UART Device](#section192177171373)
-- [Destroying the UART Device Handle](#section63131236354)
-
-## How to Use
-
-[Figure 1](#fig1852173020185) shows the process of using a UART device.
-
-**Figure 1** Process of using a UART device
-
-
-
-
-## Obtaining a UART Device Handle
-
-Before performing UART communication, call **UartOpen** to obtain a UART device handle. This function returns the pointer to the UART device handle with a specified port number.
-
-DevHandle UartOpen\(uint32\_t port\);
-
-**Table 1** Description of **UartOpen**
-
-
-
Parameter
-
-
Description
-
-
-
-
port
-
-
UART port number.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to obtain the UART device handle.
-
-
-
Device handle
-
-
Pointer to the UART device handle.
-
-
-
-
-
-The following example shows how to obtain a UART device handle based on the assumption that the UART port number is **3**:
-
-```
-DevHandle handle = NULL; /* The UART device handle */
-uint32_t port = 3; /* UART port number */
-handle = UartOpen(port);
-if (handle == NULL) {
- HDF_LOGE("UartOpen: failed!\n");
- return;
-}
-```
-
-## Setting the UART Baud Rate
-
-After obtaining the UART device handle, set the UART baud rate by calling the following function:
-
-int32\_t UartSetBaud\(DevHandle handle, uint32\_t baudRate\);
-
-**Table 2** Description of **UartSetBaud**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
baudRate
-
-
Baud rate of the UART to set.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting the UART baud rate.
-
-
-
Negative value
-
-
Failed to set the UART baud rate.
-
-
-
-
-
-The following example shows how to set the UART baud rate to **9600**:
-
-```
-int32_t ret;
-/* Set the UART baud rate to 9600. */
-ret = UartSetBaud(handle, 9600);
-if (ret != 0) {
- HDF_LOGE("UartSetBaud: failed, ret %d\n", ret);
-}
-```
-
-## Obtaining the UART Baud Rate
-
-After setting the UART baud rate, obtain the current baud rate by calling the following function:
-
-int32\_t UartGetBaud\(DevHandle handle, uint32\_t \*baudRate\);
-
-**Table 3** Description of **UartGetBaud**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
baudRate
-
-
Pointer to the UART baud rate.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in obtaining the UART baud rate.
-
-
-
Negative value
-
-
Failed to obtain the UART baud rate.
-
-
-
-
-
-The following example shows how to obtain the UART baud rate:
-
-```
-int32_t ret;
-uint32_t baudRate;
-/* Obtain the UART baud rate. */
-ret = UartGetBaud(handle, &baudRate);
-if (ret != 0) {
- HDF_LOGE("UartGetBaud: failed, ret %d\n", ret);
-}
-```
-
-## Setting the UART Device Attributes
-
-Before performing UART communication, set the UART device attributes by calling the following function:
-
-int32\_t UartSetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
-
-**Table 4** Description of **UartSetAttribute**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
attribute
-
-
Pointer to the UART device attributes to set.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting the UART device attributes.
-
-
-
Negative value
-
-
Failed to set the UART device attributes.
-
-
-
-
-
-The following example shows how to set the UART device attributes:
-
-```
-int32_t ret;
-struct UartAttribute attribute;
-attribute.dataBits = UART_ATTR_DATABIT_7; /* Set the number of data bits to 7. */
-attribute.parity = UART_ATTR_PARITY_NONE; /* Set the parity bit to no parity. */
-attribute.stopBits = UART_ATTR_STOPBIT_1; /* Set the stop bit to 1. */
-attribute.rts = UART_ATTR_RTS_DIS; /* Disable the RTS signal. */
-attribute.cts = UART_ATTR_CTS_DIS; /* Disable the CTS signal. */
-attribute.fifoRxEn = UART_ATTR_RX_FIFO_EN; /* Enable RX FIFO. */
-attribute.fifoTxEn = UART_ATTR_TX_FIFO_EN; /* Enable TX FIFO. */
-/* Set the UART device attributes. */
-ret = UartSetAttribute(handle, &attribute);
-if (ret != 0) {
- HDF_LOGE("UartSetAttribute: failed, ret %d\n", ret);
-}
-```
-
-## Obtaining UART Device Attributes
-
-After setting the UART device attributes, obtain the current device attributes by calling the following function:
-
-int32\_t UartGetAttribute\(DevHandle handle, struct UartAttribute \*attribute\);
-
-**Table 5** Description of **UartGetAttribute**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
attribute
-
-
Pointer to the UART device attributes.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in obtaining the UART device attributes.
-
-
-
Negative value
-
-
Failed to obtain the UART device attributes.
-
-
-
-
-
-The following example shows how to obtain the UART device attributes:
-
-```
-int32_t ret;
-struct UartAttribute attribute;
-/* Obtain the UART attributes. */
-ret = UartGetAttribute(handle, &attribute);
-if (ret != 0) {
- HDF_LOGE("UartGetAttribute: failed, ret %d\n", ret);
-}
-```
-
-## Setting the UART Transmission Mode
-
-Before performing UART communication, set the UART transmission mode by calling the following function:
-
-int32\_t UartSetTransMode\(DevHandle handle, enum UartTransMode mode\);
-
-**Table 6** Description of **UartSetTransMode**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
mode
-
-
UART transmission mode to set.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting the UART transmission mode.
-
-
-
Negative value
-
-
Failed to set the UART transmission mode.
-
-
-
-
-
-The following example shows how to set the transmission mode to **UART\_MODE\_RD\_BLOCK**:
-
-```
-int32_t ret;
-/* Set the UART transmission mode. */
-ret = UartSetTransMode(handle, UART_MODE_RD_BLOCK);
-if (ret != 0) {
- HDF_LOGE("UartSetTransMode: failed, ret %d\n", ret);
-}
-```
-
-## Writing Data of a Specified Length into a UART Device
-
-To write data into a UART device, call the following function:
-
-int32\_t UartWrite\(DevHandle handle, uint8\_t \*data, uint32\_t size\);
-
-**Table 7** Description of **UartWrite**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
data
-
-
Pointer to the data to write.
-
-
-
size
-
-
Length of the data to write.
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in writing data into the UART device.
-
-
-
Negative value
-
-
Failed to write data into the UART device.
-
-
-
-
-
-The following example shows how to write data of a specified length into the UART device:
-
-```
-int32_t ret;
-uint8_t wbuff[5] = {1, 2, 3, 4, 5};
-/* Write 5-byte data into the UART device. */
-ret = UartWrite(handle, wbuff, 5);
-if (ret != 0) {
- HDF_LOGE("UartWrite: failed, ret %d\n", ret);
-}
-```
-
-## Reading Data of a Specified Length from a UART Device
-
-To read data from a UART device, call the following function:
-
-int32\_t UartRead\(DevHandle handle, uint8\_t \*data, uint32\_t size\);
-
-**Table 8** Description of **UartRead**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle.
-
-
-
data
-
-
Pointer to the buffer for receiving the data.
-
-
-
size
-
-
Length of the data to read.
-
-
-
Return Value
-
-
Description
-
-
-
Non-negative value
-
-
Length of the data read from the UART device.
-
-
-
Negative value
-
-
Failed to read data from the UART device.
-
-
-
-
-
-The following example shows how to read data of a specified length from the UART device:
-
-```
-int32_t ret;
-uint8_t rbuff[5] = {0};
-/* Read 5-byte data from the UART device. */
-ret = UartRead(handle, rbuff, 5);
-if (ret < 0) {
- HDF_LOGE("UartRead: failed, ret %d\n", ret);
-}
-```
-
-> **CAUTION:**
->Data is successfully read from the UART device if a non-negative value is returned. If the return value is **0**, no valid data can be read from the UART device. If the return value is greater than **0**, the return value is the length of the data actually read from the UART device. The length is less than or equal to the value of **size** and does not exceed the maximum length of data to read at a time specified by the UART controller in use.
-
-## Destroying the UART Device Handle
-
-After the UART communication, destroy the UART device handle by calling the following function:
-
-void UartClose\(DevHandle handle\);
-
-This function will release the resources previously obtained.
-
-**Table 9** Description of **UartClose**
-
-
-
Parameter
-
-
Description
-
-
-
-
handle
-
-
Pointer to the UART device handle
-
-
-
-
-
-The following example shows how to destroy the UART device handle:
-
-```
-UartClose(handle); /* Destroy the UART device handle. */
-```
-
diff --git a/en/device-dev/driver/usage-example.md b/en/device-dev/driver/usage-example.md
deleted file mode 100644
index e16e8f2eeadcc12bd537fa8655692af0e88c9893..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/usage-example.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# Usage Example
-
-The following is an example of using a MIPI DSI device:
-
-```
-#include "hdf.h"
-#include "mipi_dsi_if.h"
-
-void PalMipiDsiTestSample(void)
-{
- uint8_t chnId;
- int32_t ret;
- DevHandle handle = NULL;
-
- /* Device channel ID */
- chnId = 0;
- /* Obtain the MIPI DSI device handle based on a specified channel ID. */
- handle = MipiDsiOpen(chnId);
- if (handle == NULL) {
- HDF_LOGE("MipiDsiOpen: failed!\n");
- return;
- }
- /* MIPI DSI configuration parameters */
- struct MipiCfg cfg = {0};
- cfg.lane = DSI_4_LANES;
- cfg.mode = DSI_CMD_MODE;
- cfg.burstMode = VIDEO_NON_BURST_MODE_SYNC_EVENTS;
- cfg.format = FORMAT_RGB_24_BIT;
- cfg.pixelClk = 174;
- cfg.phyDataRate = 384;
- cfg.timingInfo.hsaPixels = 50;
- cfg.timingInfo.hbpPixels = 55;
- cfg.timingInfo.hlinePixels = 1200;
- cfg.timingInfo.yResLines = 1800;
- cfg.timingInfo.vbpLines = 33;
- cfg.timingInfo.vsaLines = 76;
- cfg.timingInfo.vfpLines = 120;
- cfg.timingInfo.xResPixels = 1342;
- /* Set MIPI DSI configuration parameters. */
- ret = MipiDsiSetCfg(g_handle, &cfg);
- if (ret != 0) {
- HDF_LOGE("%s: SetMipiCfg fail! ret=%d\n", __func__, ret);
- return;
- }
- /* Send the command for initializing the PANEL register. */
- struct DsiCmdDesc *cmd = OsalMemCalloc(sizeof(struct DsiCmdDesc));
- if (cmd == NULL) {
- return;
- }
- cmd->dtype = DTYPE_DCS_WRITE;
- cmd->dlen = 1;
- cmd->payload = OsalMemCalloc(sizeof(uint8_t));
- if (cmd->payload == NULL) {
- HdfFree(cmd);
- return;
- }
- *(cmd->payload) = DTYPE_GEN_LWRITE;
- MipiDsiSetLpMode(mipiHandle);
- ret = MipiDsiTx(mipiHandle, cmd);
- MipiDsiSetHsMode(mipiHandle);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: MipiDsiTx fail! ret=%d\n", __func__, ret);
- HdfFree(cmd->payload);
- HdfFree(cmd);
- return;
- }
- HdfFree(cmd->payload);
- HdfFree(cmd);
- /* Pointer to the register that reads the PANEL status */
- uint8_t readVal = 0;
- struct DsiCmdDesc *cmdRead = OsalMemCalloc(sizeof(struct DsiCmdDesc));
- if (cmdRead == NULL) {
- return;
- }
- cmdRead->dtype = DTYPE_DCS_READ;
- cmdRead->dlen = 1;
- cmdRead->payload = OsalMemCalloc(sizeof(uint8_t));
- if (cmdRead->payload == NULL) {
- HdfFree(cmdRead);
- return;
- }
- *(cmdRead->payload) = DDIC_REG_STATUS;
- MipiDsiSetLpMode(g_handle);
- ret = MipiDsiRx(g_handle, cmdRead, sizeof(readVal), &readVal);
- MipiDsiSetHsMode(g_handle);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: MipiDsiRx fail! ret=%d\n", __func__, ret);
- HdfFree(cmdRead->payload);
- HdfFree(cmdRead);
- return;
- }
- HdfFree(cmdRead->payload);
- HdfFree(cmdRead);
- /* Release the MIPI DSI device handle. */
- MipiDsiClose(handle);
-}
-```
-
diff --git a/en/device-dev/driver/usage-guidelines.md b/en/device-dev/driver/usage-guidelines.md
deleted file mode 100644
index 1934eaf6e0bb68cb83d76d0114635f10f5ec59b7..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/usage-guidelines.md
+++ /dev/null
@@ -1,365 +0,0 @@
-# Usage Guidelines
-
-- [How to Use](#section8982671284)
-- [Obtaining a MIPI DSI Device Handle](#section57982569176)
-- [Setting MIPI DSI Configuration Parameters](#section5935410201815)
-- [Sending/Receiving the Pointer to a Command](#section611661316194)
-- [Releasing the MIPI DSI Device Handle](#section217313211199)
-
-## How to Use
-
-[Figure 1](#fig99821771782) shows the process of using a MIPI DSI device.
-
-**Figure 1** Process of using a MIPI DSI device
-
-
-
-
-## Obtaining a MIPI DSI Device Handle
-
-Before performing MIPI DSI communication, obtain a MIPI DSI device handle by calling **MipiDsiOpen**. This function returns a MIPI DSI device handle with a specified channel ID.
-
-DevHandle MipiDsiOpen\(uint8\_t id\);
-
-**Table 1** Description of **MipiDsiOpen**
-
-
-
Parameter
-
-
Description
-
-
-
id
-
-
MIPI DSI channel ID.
-
-
-
Return Value
-
-
Description
-
-
-
NULL
-
-
Failed to obtain the MIPI DSI channel ID.
-
-
-
Device handle
-
-
MIPI DSI device handle with a specified channel ID, whose data type is DevHandle.
-
-
-
-
-
-The following example shows how to obtain a MIPI DSI device handle with the channel ID **0**:
-
-```
-DevHandle mipiDsiHandle = NULL; /* Device handle */
-chnId = 0; /* MIPI DSI channel ID */
-
-/* Obtain the MIPI DSI device handle based on a specified channel ID. */
-mipiDsiHandle = MipiDsiOpen(chnId);
-if (mipiDsiHandle == NULL) {
- HDF_LOGE("MipiDsiOpen: failed\n");
- return;
-}
-```
-
-## Setting MIPI DSI Configuration Parameters
-
-- Set MIPI DSI configuration parameters by calling the following function:
-
-int32\_t MipiDsiSetCfg\(DevHandle handle, struct MipiCfg \*cfg\);
-
-**Table 2** Description of **MipiDsiSetCfg**
-
-
-
Parameter
-
-
Description
-
-
-
handle
-
-
MIPI DSI device handle
-
-
-
cfg
-
-
Pointer to MIPI DSI configuration parameters
-
-
-
Return Value
-
-
Description
-
-
-
0
-
-
Succeeded in setting MIPI DSI configuration parameters.
-
-```
-MipiDsiClose(mipiHandle); /* Release the MIPI DSI device handle */
-```
-
diff --git a/en/device-dev/driver/watchdog.md b/en/device-dev/driver/watchdog.md
deleted file mode 100644
index b8f20d1dad97959da8207df5b166e177854a35a9..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/watchdog.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# WATCHDOG
-
-- **[Watchdog Overview](watchdogoverview.md)**
-
-- **[Watchdog Usage Guidelines](watchdogusage-guidelines.md)**
-
-- **[Watchdog Usage Example](watchdogusage-example.md)**
-
-
diff --git a/en/device-dev/driver/watchdogoverview.md b/en/device-dev/driver/watchdogoverview.md
deleted file mode 100644
index 04b3b373d03c4773f5bc45ba9ef3ca8cabc29a85..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/watchdogoverview.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# Watchdog Overview
-
-- [Introduction](#section3579126111816)
-- [Available APIs](#section17429111981812)
-
-## Introduction
-
-A watchdog, also called a watchdog timer, is a hardware timing device. If an error occurs in the main program of the system and fails to reset the watchdog timer, the watchdog timer sends a reset signal to restore the system to a normal state.
-
-## Available APIs
-
-**Table 1** Watchdog APIs
-
-
-
Capability
-
-
Function
-
-
Description
-
-
-
-
Open/Close
-
-
WatchdogOpen
-
-
Opens a watchdog.
-
-
-
WatchdogClose
-
-
Closes a watchdog.
-
-
-
Start/Stop
-
-
WatchdogStart
-
-
Starts a watchdog.
-
-
-
WatchdogStop
-
-
Stops a watchdog.
-
-
-
Timeout duration
-
-
WatchdogSetTimeout
-
-
Sets the watchdog timeout duration.
-
-
-
WatchdogGetTimeout
-
-
Obtains the watchdog timeout duration.
-
-
-
Status
-
-
WatchdogGetStatus
-
-
Obtains the watchdog status.
-
-
-
Feeding
-
-
WatchdogFeed
-
-
Feeds a watchdog, or resets a watchdog timer.
-
-
-
-
-
-> **NOTE:**
->All watchdog functions provided in this document can be called only in kernel mode.
-
diff --git a/en/device-dev/driver/watchdogusage-example.md b/en/device-dev/driver/watchdogusage-example.md
deleted file mode 100644
index 98f6acfa0e383b059ed257df8411ef03f3f9ee72..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/watchdogusage-example.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# Watchdog Usage Example
-
-This example provides a complete process for using a watchdog.
-
-In this example, open a watchdog, set the timeout duration, and start the watchdog.
-
-- Feed the watchdog periodically to ensure that the system is not reset due to timer expiry.
-- Stop feeding the watchdog and check whether the system is reset after the timer expires.
-
-Example:
-
-```
-#include "watchdog_if.h"
-#include "hdf_log.h"
-#include "osal_irq.h"
-#include "osal_time.h"
-
-#define WATCHDOG_TEST_TIMEOUT 2
-#define WATCHDOG_TEST_FEED_TIME 6
-
-static int32_t TestCaseWatchdog(void)
-{
- int32_t i;
- int32_t ret;
- uint32_t timeout;
- DevHandle handle = NULL;
-
- /* Open watchdog 0. */
- handle = WatchdogOpen(0);
- if (handle == NULL) {
- HDF_LOGE("Open watchdog fail!");
- return -1;
- }
-
- /* Set the timeout duration. */
- ret = WatchdogSetTimeout(handle, WATCHDOG_TEST_TIMEOUT);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: set timeout fail! ret:%d\n", __func__, ret);
- WatchdogClose(handle);
- return ret;
- }
-
- /* Obtain the configured timeout duration. */
- ret = WatchdogGetTimeout(handle, &timeout);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: get timeout fail! ret:%d\n", __func__, ret);
- WatchdogClose(handle);
- return ret;
- }
- HDF_LOGI("%s: read timeout back:%u\n", __func__, timeout);
-
- /* Start the watchdog. The timer starts. */
- ret = WatchdogStart(handle);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: satrt fail! ret:%d\n", __func__, ret);
- WatchdogClose(handle);
- return ret;
- }
-
- /* Feed the watchdog every 1s. */
- for (i = 0; i < WATCHDOG_TEST_FEED_TIME; i++) {
- HDF_LOGE("%s: feeding watchdog %d times... \n", __func__, i);
- ret = WatchdogFeed(handle);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: feed dog fail! ret:%d\n", __func__, ret);
- WatchdogClose(handle);
- return ret;
- }
- OsalSleep(1);
- }
- /* Because the interval for feeding the watchdog is shorter than the timeout duration, the system does not reset, and logs can be printed normally. */
- HDF_LOGE("%s: no reset ... feeding test OK!!!\n", __func__);
-
- /* Enable the timer to expire by stopping feeding the watchdog. */
- for (i = 0; i < WATCHDOG_TEST_FEED_TIME; i++) {
- HDF_LOGE("%s: watiting dog buck %d times... \n", __func__, i);
- OsalSleep(1);
- }
-
- /* The system resets when the timer expires. If the code is correct, the log below is not displayed. */
- HDF_LOGE("%s: dog has't buck!!! \n", __func__, i);
- WatchdogClose(handle);
- return -1;
-}
-```
-
diff --git a/en/device-dev/driver/watchdogusage-guidelines.md b/en/device-dev/driver/watchdogusage-guidelines.md
deleted file mode 100644
index e3eb5c091fb98497a9bc2f31dfe40cb69df93244..0000000000000000000000000000000000000000
--- a/en/device-dev/driver/watchdogusage-guidelines.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# Watchdog Usage Guidelines
-
-- [How to Use](#section0719414187)
-- [Opening a Watchdog](#section198171379261)
-- [Obtaining the Watchdog Status](#section206592910275)
-- [Setting the Timeout Duration](#section19605128182714)
-- [Obtaining the Timeout Duration](#section11111516208)
-- [Starting a Watchdog](#section141174192814)
-- [Feeding a Watchdog](#section179101435113910)
-- [Stopping a Watchdog](#section15282123192816)
-- [Closing a Watchdog](#section7857850173411)
-
-## How to Use
-
-[Figure 1](#fig19134125410189) illustrates the process of using a watchdog.
-
-**Figure 1** Process of using a watchdog
-
-
-
-
-## Opening a Watchdog
-
-Use **WatchdogOpen** to open a watchdog. A system may have multiple watchdogs. You can open a specified watchdog by using the ID.
-
-int32\_t WatchdogOpen\(int16\_t wdtId\);
-
-.
-
-**Table 1** Description of WatchdogOpen
-
-
-
-
-The WLAN driver module provides APIs for driver developers, such as initializing/deregistering, opening/stopping a **NetDevice**, and obtaining the state of a **NetDevice**. [Table 2](#table74613501475) provides some APIs.
-
-**Table 2** APIs for driver developers of WLAN vendors to implement
-
-
-
-
-The WLAN driver provides the HDI layer with the APIs for creating and destroying an **IWiFi** object and setting the MAC address. [Table 3](#table141076311618) provides some APIs.
-
-**Table 3** APIs provided by the WLAN HAL module
-
-
-
-
-## Preparations
-
-Before using the Docker environment, perform the following operations:
-
-1. Install Docker. For details, see [Install Docker Engine](https://docs.docker.com/engine/install/).
-2. Obtain the OpenHarmony source code. For details, see [Source Code Acquisition](source-code-acquisition.md).
-
- > **NOTE:**
- >You do not need to obtain the source code for the HPM-based Docker environment.
-
-
-## Standalone Docker Environment
-
-The Docker image of OpenHarmony is hosted on [HUAWEI CLOUD SWR](https://console.huaweicloud.com/swr/?region=cn-south-1&locale=en-us#/app/warehouse/warehouseMangeDetail/goldensir/openharmony-docker/openharmony-docker?type=ownImage). Using the Docker image will help simplify environment configurations needed for the building. The following describes the detailed procedure.
-
-### Setting Up the Docker Environment for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)
-
-**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
-
-1. Obtain the Docker image.
-
- ```
- docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
- ```
-
-2. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
-
- Run the following command in Ubuntu:
-
- ```
- docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
- ```
-
- Run the following command in Windows \(assuming that the source code directory is **D:\\OpenHarmony**\):
-
- ```
- docker run -it -v D:\OpenHarmony:/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
- ```
-
-
-**Method 2: Using the Dockerfile to Build a Local Docker Image**
-
-1. Obtain the Dockerfile script for a local Docker image.
-
- ```
- git clone https://gitee.com/openharmony/docs.git
- ```
-
-2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
-
- ```
- cd docs/docker
- ./build.sh
- ```
-
-3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
-
- Run the following command in Ubuntu:
-
- ```
- docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
- ```
-
- Run the following command in Windows \(assuming that the source code directory is **D:\\OpenHarmony**\):
-
- ```
- docker run -it -v D:\OpenHarmony:/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
- ```
-
-
-### Building for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)
-
-The following uses the Hi3516 platform as an example to describe the build procedure.
-
-Set the build path to the current path.
-
-```
-hb set
- .
-```
-
-**Figure 1** Setting page
-
-
-
-
-> **NOTE:**
->The mapping between the development board and the building GUI:
->- Hi3861: wifiiot\_hispark\_pegasus@hisilicon
->- Hi3516: ipcamera\_hispark\_taurus@hisilicon
->- Hi3518: ipcamera\_hispark\_aries@hisilicon
-
-1. Select **ipcamera\_hispark\_taurus@hisilicon** and press **Enter**.
-2. Start building.
-
- ```
- hb build -f
- ```
-
-3. View the build result.
-
- The files will be generated in the **out/hispark\_taurus/ipcamera\_hispark\_taurus** directory.
-
-
-### Setting Up the Docker Environment for Standard-System Devices \(reference memory ≥ 128 MB\)
-
-**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
-
-1. Obtain the Docker image.
-
- ```
- docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
- ```
-
-2. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
-
- ```
- docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
- ```
-
-
-**Method 2: Using the Dockerfile to Build a Local Docker Image**
-
-1. Obtain the Dockerfile script for a local Docker image.
-
- ```
- git clone https://gitee.com/openharmony/docs.git
- ```
-
-2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
-
- ```
- cd docs/docker/standard
- ./build.sh
- ```
-
-3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
-
- ```
- docker run -it -v $(pwd):/home/openharmony openharmony-docker-standard:0.0.1
- ```
-
-
-### Building for Standard-System Devices \(reference memory ≥ 128 MB\)
-
-1. Run the preprocessing script in the root directory of the source code.
-
- ```
- ../scripts/prepare.sh
- ```
-
-2. Run the following script to start building for standard-system devices \(reference memory ≥ 128 MB\).
-
- ```
- ./build.sh --product-name {product_name}
- ```
-
- **product\_name** indicates the platform supported by the current distribution, for example, Hi3516D V300.
-
- Files generated during building 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.
-
-
-> **NOTE:**
->You can exit Docker by simply running the **exit** command.
-
-## HPM-based Docker Environment
-
-**docker\_dist** is a template component in the [HPM](https://hpm.harmonyos.com/#/en/home) system. It helps to quickly initialize an HPM project and use the Docker image to quickly build a distribution of OpenHarmony, greatly simplifying environment configurations needed for building. After configuring the Ubuntu and [hpm-cli](https://device.harmonyos.com/en/docs/develop/bundles/oem_bundle_guide_prepare-0000001050129846) development environments, perform the following steps to access the Docker environment:
-
-### Setting Up the Docker Environment
-
-1. Initialize the installation template by running the following command in any of the working directories:
-
- ```
- hpm init -t @ohos/docker_dist
- ```
-
-2. Modify the **publishAs** field.
-
- The obtained bundle is of the template type. Open the **bundle.json** file in the current directory and change the value of **publishAs** from **template** to **distribution** as needed.
-
-
-### Obtaining and Building Source Code
-
-Start building. Docker can be automatically installed only in Ubuntu. If you are using any other operating system, manually install Docker before pulling the image.
-
-- **Automatically Installing Docker \(Ubuntu\)**
-
- Running the following command will automatically install Docker, pull the Docker image, and start the pulling and building of the corresponding solution in the container.
-
- **Method 1:**
-
- Add a parameter to specify the solution. For example:
-
- ```
- hpm run docker solution={product}
- ```
-
- **\{product\}** indicates the solution, for example, **@ohos/hispark\_taurus**, **@ohos/hispark\_aries**, and **@ohos/hispark\_pegasus**.
-
- **Method 2:**
-
- Set an environment variable to specify the solution, and then run the build command.
-
- 1. Select the desired solution.
-
- ```
- export solution={product}
- ```
-
- **\{product\}** indicates the solution, for example, **@ohos/hispark\_taurus**, **@ohos/hispark\_aries**, and **@ohos/hispark\_pegasus**.
-
- 2. Obtain and build the source code.
-
- ```
- 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!
- @ohos/hispark_taurus: distribution building completed.
- ```
-
-
-- **Manually Installing Docker \(Non-Ubuntu\)**
-
- Perform the following operations to install Docker:
-
- ```
- # Pull the image.
- docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.3# Compile the Docker image in the Linux environment.
- hpm run distWithDocker solution={product}
- # When using Windows, make sure to configure the Git Bash.
- hpm config set shellPath "Git Bash path"
- hpm run distWithDocker solution={product}
- ```
-
-
diff --git a/en/device-dev/get-code/figures/3.png b/en/device-dev/get-code/figure/3-22.png
similarity index 100%
rename from en/device-dev/get-code/figures/3.png
rename to en/device-dev/get-code/figure/3-22.png
diff --git a/en/device-dev/get-code/figures/en-us_image_0000001101413884.png b/en/device-dev/get-code/figure/en-us_image_0000001101413884.png
similarity index 100%
rename from en/device-dev/get-code/figures/en-us_image_0000001101413884.png
rename to en/device-dev/get-code/figure/en-us_image_0000001101413884.png
diff --git a/en/device-dev/get-code/figures/en-us_image_0000001119755646.png b/en/device-dev/get-code/figure/en-us_image_0000001119755646.png
similarity index 100%
rename from en/device-dev/get-code/figures/en-us_image_0000001119755646.png
rename to en/device-dev/get-code/figure/en-us_image_0000001119755646.png
diff --git a/en/device-dev/get-code/figures/en-us_image_0000001119915556.png b/en/device-dev/get-code/figure/en-us_image_0000001119915556.png
similarity index 100%
rename from en/device-dev/get-code/figures/en-us_image_0000001119915556.png
rename to en/device-dev/get-code/figure/en-us_image_0000001119915556.png
diff --git a/en/device-dev/get-code/figures/en-us_image_0000001166715379.png b/en/device-dev/get-code/figure/en-us_image_0000001166715379.png
similarity index 100%
rename from en/device-dev/get-code/figures/en-us_image_0000001166715379.png
rename to en/device-dev/get-code/figure/en-us_image_0000001166715379.png
diff --git a/en/device-dev/get-code/gettools-acquire.md b/en/device-dev/get-code/gettools-acquire.md
new file mode 100644
index 0000000000000000000000000000000000000000..453cce21c04f24a2a64605a38e8f5f433ffe6994
--- /dev/null
+++ b/en/device-dev/get-code/gettools-acquire.md
@@ -0,0 +1,313 @@
+# Docker Environment
+
+- [Introduction](#section107932281315)
+- [Preparations](#section7337134183512)
+- [Standalone Docker Environment](#section2858536103611)
+ - [Setting Up the Docker Environment for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)](#section319412277287)
+ - [Building for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)](#section631485163615)
+ - [Setting Up the Docker Environment for Standard-System Devices \(reference memory ≥ 128 MB\)](#section13585262391)
+ - [Building for Standard-System Devices \(reference memory ≥ 128 MB\)](#section193711513406)
+
+- [HPM-based Docker Environment](#section485713518337)
+ - [Setting Up the Docker Environment](#section3295842510)
+ - [Obtaining and Building Source Code](#section69141039143518)
+
+
+## Introduction
+
+OpenHarmony provides the following two types of Docker environments for you to quickly get the development environment ready:
+
+- Standalone Docker environment: applicable when using Ubuntu or Windows to build a distribution
+- HPM-based Docker environment: applicable when using the HarmonyOS Package Manager \(HPM\) to build a distribution
+
+**Table 1** Docker image
+
+
+
+
+## Preparations
+
+Before using the Docker environment, perform the following operations:
+
+1. Install Docker. For details, see [Install Docker Engine](https://docs.docker.com/engine/install/).
+2. Obtain the OpenHarmony source code. For details, see [Source Code Acquisition](sourcecode-acquire.md).
+
+ > **NOTE:**
+ >You do not need to obtain the source code for the HPM-based Docker environment.
+
+
+## Standalone Docker Environment
+
+The Docker image of OpenHarmony is hosted on [HUAWEI CLOUD SWR](https://console.huaweicloud.com/swr/?region=cn-south-1&locale=en-us#/app/warehouse/warehouseMangeDetail/goldensir/openharmony-docker/openharmony-docker?type=ownImage). Using the Docker image will help simplify environment configurations needed for the building. The following describes the detailed procedure.
+
+### Setting Up the Docker Environment for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)
+
+**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
+
+1. Obtain the Docker image.
+
+ ```
+ docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+2. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ Run the following command in Ubuntu:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+ Run the following command in Windows \(assuming that the source code directory is **D:\\OpenHarmony**\):
+
+ ```
+ docker run -it -v D:\OpenHarmony:/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+
+**Method 2: Using the Dockerfile to Build a Local Docker Image**
+
+1. Obtain the Dockerfile script for a local Docker image.
+
+ ```
+ git clone https://gitee.com/openharmony/docs.git
+ ```
+
+2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
+
+ ```
+ cd docs/docker
+ ./build.sh
+ ```
+
+3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ Run the following command in Ubuntu:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+ Run the following command in Windows \(assuming that the source code directory is **D:\\OpenHarmony**\):
+
+ ```
+ docker run -it -v D:\OpenHarmony:/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.5
+ ```
+
+
+### Building for Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\)
+
+The following uses the Hi3516 platform as an example to describe the build procedure.
+
+Set the build path to the current path.
+
+```
+hb set
+ .
+```
+
+**Figure 1** Setting page
+
+
+
+
+> **NOTE:**
+>The mapping between the development board and the building GUI:
+>- Hi3861: wifiiot\_hispark\_pegasus@hisilicon
+>- Hi3516: ipcamera\_hispark\_taurus@hisilicon
+>- Hi3518: ipcamera\_hispark\_aries@hisilicon
+
+1. Select **ipcamera\_hispark\_taurus@hisilicon** and press **Enter**.
+2. Start building.
+
+ ```
+ hb build -f
+ ```
+
+3. View the build result.
+
+ The files will be generated in the **out/hispark\_taurus/ipcamera\_hispark\_taurus** directory.
+
+
+### Setting Up the Docker Environment for Standard-System Devices \(reference memory ≥ 128 MB\)
+
+**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
+
+1. Obtain the Docker image.
+
+ ```
+ docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
+ ```
+
+2. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
+ ```
+
+
+**Method 2: Using the Dockerfile to Build a Local Docker Image**
+
+1. Obtain the Dockerfile script for a local Docker image.
+
+ ```
+ git clone https://gitee.com/openharmony/docs.git
+ ```
+
+2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
+
+ ```
+ cd docs/docker/standard
+ ./build.sh
+ ```
+
+3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony openharmony-docker-standard:0.0.1
+ ```
+
+
+### Building for Standard-System Devices \(reference memory ≥ 128 MB\)
+
+1. Run the preprocessing script in the root directory of the source code.
+
+ ```
+ ../scripts/prepare.sh
+ ```
+
+2. Run the following script to start building for standard-system devices \(reference memory ≥ 128 MB\).
+
+ ```
+ ./build.sh --product-name {product_name}
+ ```
+
+ **product\_name** indicates the platform supported by the current distribution, for example, Hi3516D V300.
+
+ Files generated during building 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.
+
+
+> **NOTE:**
+>You can exit Docker by simply running the **exit** command.
+
+## HPM-based Docker Environment
+
+**docker\_dist** is a template component in the [HPM](https://hpm.harmonyos.com/#/en/home) system. It helps to quickly initialize an HPM project and use the Docker image to quickly build a distribution of OpenHarmony, greatly simplifying environment configurations needed for building. After configuring the Ubuntu and [hpm-cli](../bundles/bundles-guide-prepare.md) development environments, perform the following steps to access the Docker environment:
+
+### Setting Up the Docker Environment
+
+1. Initialize the installation template by running the following command in any of the working directories:
+
+ ```
+ hpm init -t @ohos/docker_dist
+ ```
+
+2. Modify the **publishAs** field.
+
+ The obtained bundle is of the template type. Open the **bundle.json** file in the current directory and change the value of **publishAs** from **template** to **distribution** as needed.
+
+
+### Obtaining and Building Source Code
+
+Start building. Docker can be automatically installed only in Ubuntu. If you are using any other operating system, manually install Docker before pulling the image.
+
+- **Automatically Installing Docker \(Ubuntu\)**
+
+ Running the following command will automatically install Docker, pull the Docker image, and start the pulling and building of the corresponding solution in the container.
+
+ **Method 1:**
+
+ Add a parameter to specify the solution. For example:
+
+ ```
+ hpm run docker solution={product}
+ ```
+
+ **\{product\}** indicates the solution, for example, **@ohos/hispark\_taurus**, **@ohos/hispark\_aries**, and **@ohos/hispark\_pegasus**.
+
+ **Method 2:**
+
+ Set an environment variable to specify the solution, and then run the build command.
+
+ 1. Select the desired solution.
+
+ ```
+ export solution={product}
+ ```
+
+ **\{product\}** indicates the solution, for example, **@ohos/hispark\_taurus**, **@ohos/hispark\_aries**, and **@ohos/hispark\_pegasus**.
+
+ 2. Obtain and build the source code.
+
+ ```
+ 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!
+ @ohos/hispark_taurus: distribution building completed.
+ ```
+
+
+- **Manually Installing Docker \(Non-Ubuntu\)**
+
+ Perform the following operations to install Docker:
+
+ ```
+ # Pull the image.
+ docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker:0.0.3# Compile the Docker image in the Linux environment.
+ hpm run distWithDocker solution={product}
+ # When using Windows, make sure to configure the Git Bash.
+ hpm config set shellPath "Git Bash path"
+ hpm run distWithDocker solution={product}
+ ```
+
+
diff --git a/en/device-dev/get-code/gettools-ide.md b/en/device-dev/get-code/gettools-ide.md
new file mode 100644
index 0000000000000000000000000000000000000000..ec5de1cf9a48fb2b4039f55dbd702de396b4e2c0
--- /dev/null
+++ b/en/device-dev/get-code/gettools-ide.md
@@ -0,0 +1,17 @@
+# IDE
+
+- [Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)](#section2452141120244)
+- [Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)](#section0904101019258)
+
+## Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)
+
+HUAWEI DevEco Device Tool is a one-stop integrated development environment \(IDE\) provided to develop applications for OpenHarmony devices. It allows on-demand customization of OpenHarmony components, code editing, building, burning, and debugging, and supports C and C++ languages. This tool is installed in Visual Studio Code as a plug-in. For details, see [HUAWEI DevEco Device Tool](https://device.harmonyos.com/en/ide) and [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905).
+
+The roadmap of Huawei DevEco Device Tool for supporting OpenHarmony device development is shown in the figure below.
+
+
+
+## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)
+
+HUAWEI DevEco Studio \(DevEco Studio for short\) is a one-stop IDE oriented to Huawei devices in all scenarios. It provides E2E OpenHarmony application development services, ranging from project template creation to development, building, debugging, and release. With DevEco Studio, you will be able to efficiently develop OpenHarmony applications with distributed capabilities while speeding up innovation. For details, see [HUAWEI DevEco Studio](https://developer.harmonyos.com/en/develop/deveco-studio) and [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387).
+
diff --git a/en/device-dev/get-code/gettools.md b/en/device-dev/get-code/gettools.md
new file mode 100644
index 0000000000000000000000000000000000000000..95366cdb4c3f08c8783e132e5489b026622d262a
--- /dev/null
+++ b/en/device-dev/get-code/gettools.md
@@ -0,0 +1,7 @@
+# Tool Acquisition
+
+- **[Docker Environment](gettools-acquire.md)**
+
+- **[IDE](gettools-ide.md)**
+
+
diff --git a/en/device-dev/get-code/ide.md b/en/device-dev/get-code/ide.md
deleted file mode 100644
index f3551de3126341e207afe450d509d8d37cc0979a..0000000000000000000000000000000000000000
--- a/en/device-dev/get-code/ide.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# IDE
-
-- [Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)](#section2452141120244)
-- [Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)](#section0904101019258)
-
-## Acquiring the Device Development Tool \(HUAWEI DevEco Device Tool\)
-
-HUAWEI DevEco Device Tool is a one-stop integrated development environment \(IDE\) provided to develop applications for OpenHarmony devices. It allows on-demand customization of OpenHarmony components, code editing, building, burning, and debugging, and supports C and C++ languages. This tool is installed in Visual Studio Code as a plug-in. For details, see [HUAWEI DevEco Device Tool](https://device.harmonyos.com/en/ide) and [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905).
-
-The roadmap of Huawei DevEco Device Tool for supporting OpenHarmony device development is shown in the figure below.
-
-
-
-## Acquiring the Application Development Tool \(HUAWEI DevEco Studio\)
-
-HUAWEI DevEco Studio \(DevEco Studio for short\) is a one-stop IDE oriented to Huawei devices in all scenarios. It provides E2E OpenHarmony application development services, ranging from project template creation to development, building, debugging, and release. With DevEco Studio, you will be able to efficiently develop OpenHarmony applications with distributed capabilities while speeding up innovation. For details, see [HUAWEI DevEco Studio](https://developer.harmonyos.com/en/develop/deveco-studio) and [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387).
-
diff --git a/en/device-dev/get-code/public_sys-resources/icon-caution.gif b/en/device-dev/get-code/public_sys-resources/icon-caution.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/get-code/public_sys-resources/icon-caution.gif and /dev/null differ
diff --git a/en/device-dev/get-code/public_sys-resources/icon-danger.gif b/en/device-dev/get-code/public_sys-resources/icon-danger.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/get-code/public_sys-resources/icon-danger.gif and /dev/null differ
diff --git a/en/device-dev/get-code/public_sys-resources/icon-note.gif b/en/device-dev/get-code/public_sys-resources/icon-note.gif
deleted file mode 100644
index 6314297e45c1de184204098efd4814d6dc8b1cda..0000000000000000000000000000000000000000
Binary files a/en/device-dev/get-code/public_sys-resources/icon-note.gif and /dev/null differ
diff --git a/en/device-dev/get-code/public_sys-resources/icon-notice.gif b/en/device-dev/get-code/public_sys-resources/icon-notice.gif
deleted file mode 100644
index 86024f61b691400bea99e5b1f506d9d9aef36e27..0000000000000000000000000000000000000000
Binary files a/en/device-dev/get-code/public_sys-resources/icon-notice.gif and /dev/null differ
diff --git a/en/device-dev/get-code/public_sys-resources/icon-tip.gif b/en/device-dev/get-code/public_sys-resources/icon-tip.gif
deleted file mode 100644
index 93aa72053b510e456b149f36a0972703ea9999b7..0000000000000000000000000000000000000000
Binary files a/en/device-dev/get-code/public_sys-resources/icon-tip.gif and /dev/null differ
diff --git a/en/device-dev/get-code/public_sys-resources/icon-warning.gif b/en/device-dev/get-code/public_sys-resources/icon-warning.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/get-code/public_sys-resources/icon-warning.gif and /dev/null differ
diff --git a/en/device-dev/get-code/source-code-acquisition.md b/en/device-dev/get-code/source-code-acquisition.md
deleted file mode 100644
index a7d68fe82d7e7b64663197b7d915710410e46069..0000000000000000000000000000000000000000
--- a/en/device-dev/get-code/source-code-acquisition.md
+++ /dev/null
@@ -1,429 +0,0 @@
-# Source Code Acquisition
-
-- [About OpenHarmony](#section6370143622110)
-- [Overview of Source Code Acquisition](#section12763342204)
-- [Method 1: Acquiring Source Code from a Code Repository](#section537312010229)
- - [When to Use](#section10881513459)
- - [Prerequisites](#section102871547153314)
- - [How to Use](#section429012478331)
-
-- [Method 2: Acquiring Source Code from HPM](#section463013147412)
- - [When to Use](#section26661067443)
- - [Prerequisites](#section17544943123315)
- - [How to Use](#section954619433333)
-
-- [Method 3: Acquiring Source Code from Image Sites](#section1186691118430)
-- [Source Code Directories](#section1072115612811)
-
-## About OpenHarmony
-
-OpenHarmony is an open-source project launched by the OpenAtom Foundation. The purpose of this project is to build an open, distributed operating system \(OS\) framework for smart IoT devices in the full-scenario, full-connectivity, and full-intelligence era.
-
-The open-source code repositories are available at [https://openharmony.gitee.com](https://openharmony.gitee.com).
-
-> **NOTE:**
->At present, OpenHarmony source code can only be compiled in the Linux environment.
-
-## Overview of Source Code Acquisition
-
-This document describes how to acquire OpenHarmony source code and provides its directory structure. The OpenHarmony code is open to you as [bundles](../bundles/overview.md), which can be obtained in any of the following ways:
-
-- **Method 1**: Acquire the source code from a code repository. You can use the **repo** or **git** tool to download the latest code from the code repository.
-- **Method 2**: Obtain the source code from the HarmonyOS Package Manager \(HPM\). Visit the [HPM](https://hpm.harmonyos.com/#/en/home) website, search for your desired open-source distribution, and download the bundle list \(or customize bundles and download the bundle list\). Then use **hpm-cli** to download and install the bundles and compilation toolchain on your local PC.
-- **Method 3**: Download the compressed file of a distribution from an image site. This method provides a fast download speed, so you can also use this method for obtaining the source code of an earlier version.
-
-## Method 1: Acquiring Source Code from a Code Repository
-
-### When to Use
-
-- You want to establish a baseline based on stable OpenHarmony releases and distribute the baseline to your customers.
-
-- You have interconnected your software with OpenHarmony and need official certification from OpenHarmony.
-
-- You want to contribute code to the OpenHarmony community after chips, modules, and applications are certified by OpenHarmony.
-
-- You need to address OpenHarmony issues.
-
-- You want to learn OpenHarmony source code.
-
-
-### Prerequisites
-
-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.
-
- ```
- git config --global user.name "yourname"
- git config --global user.email "your-email-address"
- git config --global credential.helper store
- ```
-
-4. Run the following commands to install the **repo** tool:
-
- ```
- curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
- chmod a+x /usr/local/bin/repo
- pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
- ```
-
-
-### How to Use
-
-**Obtaining the Source Code for Mini, Small, and Standard Systems \(2.0 Canary\)**
-
-> **NOTE:**
->You can obtain the latest features from the master code, and develop commercial functionalities based on the release code, which is more stable.
-
-- **Obtaining OpenHarmony master code**
-
- Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\)
-
- ```
- repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify
- repo sync -c
- repo forall -c 'git lfs pull'
- ```
-
- Method 2 \(recommended\): Use the **repo** tool to download the source code over HTTPS.
-
- ```
- repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
- repo sync -c
- repo forall -c 'git lfs pull'
- ```
-
-
-- **Obtaining Latest OpenHarmony\_1.0.1\_release code**
-
- > **NOTE:**
- >Currently, only the source code for mini and small systems can be obtained through this release.
-
- Use the **repo** tool to download the release code.
-
- ```
- repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony_1.0.1_release --no-repo-verify
- repo sync -c
- repo forall -c 'git lfs pull'
- ```
-
-- Obtaining the source code of other OpenHarmony releases
-
- For details about how to obtain the source code of other releases, see the [Release Notes](https://gitee.com/openharmony/docs/blob/master/en/release-notes/OpenHarmony-Release-Notes.md).
-
-
-## Method 2: Acquiring Source Code from HPM
-
-### When to Use
-
-If OpenHarmony is new to you, sample solutions are helpful to your development. You can obtain an open-source distribution from the [HPM](https://hpm.harmonyos.com/#/en/home) website, or customize a distribution by adding or deleting bundles of an open-source distribution. Then use **hpm-cli** to download and install the bundles and compilation toolchain on your local PC.
-
-### Prerequisites
-
-You must install **Node.js** and HPM on your local PC. The installation procedure is as follows:
-
-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**.
-
- Open the CMD window and run the following command:
-
- ```
- npm install -g @ohos/hpm-cli
- ```
-
-3. Run the following command to check whether the installation is successful. If the HPM version is displayed, the installation is successful.
-
- ```
- hpm -V or hpm --version
- ```
-
-4. Run the following command to upgrade the HPM version:
-
- ```
- npm update -g @ohos/hpm-cli
- ```
-
-
-### How to Use
-
-1. Search for distributions.
- 1. Access the [HPM](https://hpm.harmonyos.com/#/en/home) page, and click the **Distribution** tab, as shown in the following figure.
- 2. Enter a keyword \(for example: **camera**\) in the search box. All matched distributions are found.
- 3. Specify filter criteria, such as the bundle type \(for example: **Board support** and **Kernel support**\), to further filter the distributions.
- 4. Locate your desired distribution and click it to view details.
-
- **Figure 1** HPM page
-
-
- 
-
-
-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.
- 2. Click **Download** to download the distribution to your local PC.
- 3. Click **Custom** to add or delete bundles of the distribution.
-
- **Figure 2** Example distribution
-
-
- 
-
-3. Customize bundles.
- 1. Access the **Custom solution** page, as shown in the following figure.
- 2. Set the toggle switch next to a specific optional bundle to delete it from the distribution, or click **Add bundle** to add new bundles.
- 3. Enter the basic information about your project, including the bundle name, version, and description, on the right pane.
- 4. Click **Download**. The system then generates the OpenHarmony code structure file \(for example, **my\_cust\_dist.zip**\) and saves it to your local PC.
-
- **Figure 3** Customizing bundles
-
-
- 
-
-
-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.
- 3. The downloaded bundles are stored in the **ohos\_bundles** folder under the project directory. \(The source code of some bundles will be copied to a specified directory after the bundles are installed.\)
-
-
-## Method 3: Acquiring Source Code from Image Sites
-
-To ensure the download performance, you are advised to download the source code or the corresponding solution from the image library of the respective site listed in the table below.
-
-> **NOTE:**
->- The table below provides only the sites for downloading the source code of the latest OpenHarmony Master and LTS versions. For details about earlier versions and how to obtain their source code, see the [Release Notes](https://gitee.com/openharmony/docs/tree/master/en/release-notes).
->- The Master 1.0 version is no longer maintained.
-
-**Table 1** Sites for acquiring source code from image sites
-
-
-
Basic software service subsystem set and hardware service subsystem set
-
-
-
build
-
-
Bundle-based compilation, building, and configuration scripts
-
-
-
docs
-
-
Reference documents
-
-
-
domains
-
-
Enhanced software service subsystem set
-
-
-
drivers
-
-
Driver subsystem
-
-
-
foundation
-
-
Basic system capability subsystem set
-
-
-
kernel
-
-
Kernel subsystem
-
-
-
prebuilts
-
-
Compiler and tool chain subsystem
-
-
-
test
-
-
Testing subsystem
-
-
-
third_party
-
-
Open-source third-party software
-
-
-
utils
-
-
Commonly used development tools
-
-
-
vendor
-
-
Vendor-provided software
-
-
-
build.py
-
-
Compilation script file
-
-
-
-
-
diff --git a/en/device-dev/get-code/sourcecode-acquire.md b/en/device-dev/get-code/sourcecode-acquire.md
new file mode 100644
index 0000000000000000000000000000000000000000..5fc6a1f3a1274206f8863b147f40401c031ab7e0
--- /dev/null
+++ b/en/device-dev/get-code/sourcecode-acquire.md
@@ -0,0 +1,429 @@
+# Source Code Acquisition
+
+- [About OpenHarmony](#section6370143622110)
+- [Overview of Source Code Acquisition](#section12763342204)
+- [Method 1: Acquiring Source Code from a Code Repository](#section537312010229)
+ - [When to Use](#section10881513459)
+ - [Prerequisites](#section102871547153314)
+ - [How to Use](#section429012478331)
+
+- [Method 2: Acquiring Source Code from HPM](#section463013147412)
+ - [When to Use](#section26661067443)
+ - [Prerequisites](#section17544943123315)
+ - [How to Use](#section954619433333)
+
+- [Method 3: Acquiring Source Code from Image Sites](#section1186691118430)
+- [Source Code Directories](#section1072115612811)
+
+## About OpenHarmony
+
+OpenHarmony is an open-source project launched by the OpenAtom Foundation. The purpose of this project is to build an open, distributed operating system \(OS\) framework for smart IoT devices in the full-scenario, full-connectivity, and full-intelligence era.
+
+The open-source code repositories are available at [https://openharmony.gitee.com](https://openharmony.gitee.com).
+
+> **NOTE:**
+>At present, OpenHarmony source code can only be compiled in the Linux environment.
+
+## Overview of Source Code Acquisition
+
+This document describes how to acquire OpenHarmony source code and provides its directory structure. The OpenHarmony code is open to you as [bundles](../bundles/bundles-standard-rules.md), which can be obtained in any of the following ways:
+
+- **Method 1**: Acquire the source code from a code repository. You can use the **repo** or **git** tool to download the latest code from the code repository.
+- **Method 2**: Obtain the source code from the HarmonyOS Package Manager \(HPM\). Visit the [HPM](https://hpm.harmonyos.com/#/en/home) website, search for your desired open-source distribution, and download the bundle list \(or customize bundles and download the bundle list\). Then use **hpm-cli** to download and install the bundles and compilation toolchain on your local PC.
+- **Method 3**: Download the compressed file of a distribution from an image site. This method provides a fast download speed, so you can also use this method for obtaining the source code of an earlier version.
+
+## Method 1: Acquiring Source Code from a Code Repository
+
+### When to Use
+
+- You want to establish a baseline based on stable OpenHarmony releases and distribute the baseline to your customers.
+
+- You have interconnected your software with OpenHarmony and need official certification from OpenHarmony.
+
+- You want to contribute code to the OpenHarmony community after obtaining official OpenHarmony certification for chips, modules, and applications.
+
+- You need to rectify OpenHarmony issues.
+
+- You want to learn OpenHarmony source code.
+
+
+### Prerequisites
+
+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.
+
+ ```
+ git config --global user.name "yourname"
+ git config --global user.email "your-email-address"
+ git config --global credential.helper store
+ ```
+
+4. Run the following commands to install the **repo** tool:
+
+ ```
+ curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
+ chmod a+x /usr/local/bin/repo
+ pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
+ ```
+
+
+### How to Use
+
+**Obtaining the Source Code for Mini/Small/Standard Systems \(2.0 Canary\)**
+
+> **NOTE:**
+>You can obtain the latest features from the master code, and develop commercial functionalities based on the release code, which is more stable.
+
+- **Obtaining OpenHarmony master code**
+
+ Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\)
+
+ ```
+ repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify
+ repo sync -c
+ repo forall -c 'git lfs pull'
+ ```
+
+ Method 2 \(recommended\): Use the **repo** tool to download the source code over HTTPS.
+
+ ```
+ repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
+ repo sync -c
+ repo forall -c 'git lfs pull'
+ ```
+
+
+- **Obtaining Latest OpenHarmony\_1.0.1\_release code**
+
+ > **NOTE:**
+ >Currently, only the source code for mini and small systems can be obtained through this release.
+
+ Use the **repo** tool to download the release code.
+
+ ```
+ repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony_1.0.1_release --no-repo-verify
+ repo sync -c
+ repo forall -c 'git lfs pull'
+ ```
+
+- Obtaining the source code of other OpenHarmony releases
+
+ For details about how to obtain the source code of other OpenHarmony releases, see the [Release Notes](https://gitee.com/openharmony/docs/blob/master/en/release-notes/OpenHarmony-Release-Notes.md).
+
+
+## Method 2: Acquiring Source Code from HPM
+
+### When to Use
+
+If OpenHarmony is new to you, sample solutions are helpful to your development. You can obtain an open-source distribution from the [HPM](https://hpm.harmonyos.com/#/en/home) website, or customize a distribution by adding or deleting bundles of an open-source distribution. Then use **hpm-cli** to download and install the bundles and compilation toolchain on your local PC.
+
+### Prerequisites
+
+You must install **Node.js** and HPM on your local PC. The installation procedure is as follows:
+
+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**.
+
+ Open the CMD window and run the following command:
+
+ ```
+ npm install -g @ohos/hpm-cli
+ ```
+
+3. Run the following command to check whether the installation is successful. If the HPM version is displayed, the installation is successful.
+
+ ```
+ hpm -V or hpm --version
+ ```
+
+4. Run the following command to upgrade the HPM version:
+
+ ```
+ npm update -g @ohos/hpm-cli
+ ```
+
+
+### How to Use
+
+1. Search for distributions.
+ 1. Access the [HPM](https://hpm.harmonyos.com/#/en/home) page, and click the **Distribution** tab, as shown in the following figure.
+ 2. Enter a keyword \(for example: **camera**\) in the search box. All matched distributions are found.
+ 3. Specify filter criteria, such as the bundle type \(for example: **Board support** and **Kernel support**\), to further filter the distributions.
+ 4. Locate your desired distribution and click it to view details.
+
+ **Figure 1** HPM page
+
+
+ 
+
+
+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.
+ 2. Click **Download** to download the distribution to your local PC.
+ 3. Click **Custom** to add or delete bundles of the distribution.
+
+ **Figure 2** Example distribution
+
+
+ 
+
+3. Customize bundles.
+ 1. Access the **Custom solution** page, as shown in the following figure.
+ 2. Set the toggle switch next to a specific optional bundle to delete it from the distribution, or click **Add bundle** to add new bundles.
+ 3. Enter the basic information about your project, including the bundle name, version, and description, on the right pane.
+ 4. Click **Download**. The system then generates the OpenHarmony code structure file \(for example, **my\_cust\_dist.zip**\) and saves it to your local PC.
+
+ **Figure 3** Customizing bundles
+
+
+ 
+
+
+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.
+ 3. The downloaded bundles are stored in the **ohos\_bundles** folder under the project directory. \(The source code of some bundles will be copied to a specified directory after the bundles are installed.\)
+
+
+## Method 3: Acquiring Source Code from Image Sites
+
+To ensure the download performance, you are advised to download the source code or the corresponding solution from the image library of the respective site listed in the table below.
+
+> **NOTE:**
+>- The table below provides only the sites for downloading the latest OpenHarmony master and LTS code. For details about how to obtain the source code of earlier versions, see the [Release Notes](https://gitee.com/openharmony/docs/tree/master/en/release-notes).
+>- The Master 1.0 version is no longer maintained.
+
+**Table 1** Sites for acquiring source code from image sites
+
+
+
Basic software service subsystem set and hardware service subsystem set
+
+
+
build
+
+
Bundle-based compilation, building, and configuration scripts
+
+
+
docs
+
+
Reference documents
+
+
+
domains
+
+
Enhanced software service subsystem set
+
+
+
drivers
+
+
Driver subsystem
+
+
+
foundation
+
+
Basic system capability subsystem set
+
+
+
kernel
+
+
Kernel subsystem
+
+
+
prebuilts
+
+
Compiler and tool chain subsystem
+
+
+
test
+
+
Testing subsystem
+
+
+
third_party
+
+
Open-source third-party software
+
+
+
utils
+
+
Commonly used development tools
+
+
+
vendor
+
+
Vendor-provided software
+
+
+
build.py
+
+
Compilation script file
+
+
+
+
+
diff --git a/en/device-dev/get-code/sourcecode.md b/en/device-dev/get-code/sourcecode.md
new file mode 100644
index 0000000000000000000000000000000000000000..5e118ce26fcaab05055610b3ca990fd6c3f676b0
--- /dev/null
+++ b/en/device-dev/get-code/sourcecode.md
@@ -0,0 +1,5 @@
+# Source Code Acquisition
+
+- **[Source Code Acquisition](sourcecode-acquire.md)**
+
+
diff --git a/en/device-dev/get-code/tool-acquisition.md b/en/device-dev/get-code/tool-acquisition.md
deleted file mode 100644
index dd1797b10426918c0921386817fb51c1b9e83a3b..0000000000000000000000000000000000000000
--- a/en/device-dev/get-code/tool-acquisition.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Tool Acquisition
-
-- **[Docker Environment](docker-environment.md)**
-
-- **[IDE](ide.md)**
-
-
diff --git a/en/device-dev/glossary/Readme-EN.md b/en/device-dev/glossary/Readme-EN.md
new file mode 100644
index 0000000000000000000000000000000000000000..1e7ccafe473286de0e48494b45a313bedad2c4e1
--- /dev/null
+++ b/en/device-dev/glossary/Readme-EN.md
@@ -0,0 +1,4 @@
+# Glossary
+
+[Glossary](glossary.md)
+
diff --git a/en/device-dev/guide/Readme-EN.md b/en/device-dev/guide/Readme-EN.md
index 31bb3cfd5f930e15379766651d890690ab24f29c..f5cbdaea83a60faf5a5aefe3efc7c9c7e0c2d7b2 100644
--- a/en/device-dev/guide/Readme-EN.md
+++ b/en/device-dev/guide/Readme-EN.md
@@ -1,72 +1,32 @@
# Development Examples
-- [WLAN-connected Products](wlan-connected-products.md)
- - [LED Peripheral Control](led-peripheral-control.md)
- - [Overview](overview.md)
- - [Development](development.md)
- - [Verification](verification.md)
-
-- [Cameras Without a Screen](cameras-without-a-screen.md)
- - [Camera Control](camera-control.md)
- - [Overview](overview-0.md)
- - [Development Guidelines](development-guidelines.md)
- - [Photographing](photographing.md)
- - [Video Recording](video-recording.md)
-
- - [Use Case](use-case.md)
-
-- [Cameras with a Screen](cameras-with-a-screen.md)
- - [Screen and Camera Control](screen-and-camera-control.md)
- - [Overview](overview-1.md)
- - [Development Guidelines](development-guidelines-2.md)
- - [Photographing](photographing-3.md)
- - [Video Recording](video-recording-4.md)
- - [Previewing](previewing.md)
-
- - [Use Case](use-case-5.md)
-
- - [Visual Application Development](visual-application-development.md)
- - [Overview](overview-6.md)
- - [Preparations](preparations.md)
- - [Adding Pages](adding-pages.md)
- - [Building the Home Page](building-the-home-page.md)
- - [Building the Details Page](building-the-details-page.md)
- - [Debugging and Packaging](debugging-and-packaging.md)
- - [Running on the Device](running-on-the-device.md)
- - [FAQs](faqs.md)
-
-- [Development Example for Clock Apps](development-example-for-clock-apps.md)
- - [Overview](overview-7.md)
- - [Preparations](preparations-8.md)
- - [How to Develop](how-to-develop.md)
- - [Signing and Packaging](signing-and-packaging.md)
- - [Running on the Device](running-on-the-device-9.md)
-
-- [Development Example for Platform Drivers](development-example-for-platform-drivers.md)
- - [Overview](overview-10.md)
- - [Preparations](preparations-11.md)
- - [Development](development-12.md)
- - [Building and Burning](building-and-burning.md)
-
-- [Development Example for Peripheral Drivers](development-example-for-peripheral-drivers.md)
- - [Overview](overview-13.md)
- - [Hardware Resources](hardware-resources.md)
- - [Input Driver Model](input-driver-model.md)
-
- - [Setting Up the Environment](setting-up-the-environment.md)
- - [Developing a Touchscreen Driver](developing-a-touchscreen-driver.md)
- - [Configuring Device Driver Descriptions](configuring-device-driver-descriptions.md)
- - [Configuring the Touchscreen](configuring-the-touchscreen.md)
- - [Adapting to the Private Drivers of the Touchscreen](adapting-to-the-private-drivers-of-the-touchscreen.md)
-
- - [Building and Burning](building-and-burning-14.md)
- - [Debugging and Verification](debugging-and-verification.md)
- - [Startup Log Analysis](startup-log-analysis.md)
-
- - [Input Driver Model Workflow Analysis](input-driver-model-workflow-analysis.md)
- - [Parsing Private Configuration Data](parsing-private-configuration-data.md)
- - [Initializing the Input Device Manager and Registering the Driver with the HDF](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](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](initializing-the-input-chip-driver-and-registering-the-driver-with-the-hdf.md)
- - [Function Invocation Logic](function-invocation-logic.md)
-
+- [WLAN-connected Products](device-wifi.md)
+ - [LED Peripheral Control](device-wifi-led-outcontrol.md)
+ - [Third-Party SDK Integration](device-wifi-sdk.md)
+- [Cameras Without a Screen](device-iotcamera.md)
+ - [Camera Control](device-iotcamera-control.md)
+ - [Overview](device-iotcamera-control-overview.md)
+ - [Development Guidelines](device-iotcamera-control-demo.md)
+ - [Photographing](device-iotcamera-control-demo-photodevguide.md)
+ - [Video Recording](device-iotcamera-control-demo-videodevguide.md)
+ - [Use Case](device-iotcamera-control-example.md)
+- [Cameras with a Screen](device-camera.md)
+ - [Screen and Camera Control](device-camera-control.md)
+ - [Overview](device-camera-control-overview.md)
+ - [Development Guidelines](device-camera-control-demo.md)
+ - [Photographing](device-camera-control-demo-photoguide.md)
+ - [Video Recording](device-camera-control-demo-videoguide.md)
+ - [Previewing](device-camera-control-demo-previewguide.md)
+ - [Use Case](device-camera-control-example.md)
+ - [Visual Application Development](device-camera-visual.md)
+ - [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 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 Example for Platform Drivers](device-drive-demo.md)
+- [Development Example for Peripheral Drivers](device-outerdrive-demo.md)
\ No newline at end of file
diff --git a/en/device-dev/guide/adapting-to-the-private-drivers-of-the-touchscreen.md b/en/device-dev/guide/adapting-to-the-private-drivers-of-the-touchscreen.md
deleted file mode 100644
index 80f6ba5513c1e2db8ecb7d566f91c82536311a5f..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/adapting-to-the-private-drivers-of-the-touchscreen.md
+++ /dev/null
@@ -1,99 +0,0 @@
-# Adapting to the Private Drivers of the Touchscreen
-
-The input driver model consists of three parts of drivers. To develop a brand-new touchscreen driver, you only need to adapt your code with the input chip driver and implement differentiated APIs. The sample code in this section illustrates how you will complete the adaptation.
-
-1. Implement differentiated APIs for the touchscreen to adapt to the input chip driver.
-
- You can obtain the sample code at **./drivers/framework/model/input/driver/touchscreen/touch\_gt911.c**.
-
- ```
- static struct TouchChipOps g_gt911ChipOps = { // IC options of the touchscreen
- .Init = ChipInit, // Initialize the chip.
- .Detect = ChipDetect, // Detect the chip.
- .Resume = ChipResume, // Resume the chip.
- .Suspend = ChipSuspend, // Suspend the chip.
- .DataHandle = ChipDataHandle, // Read the chip data.
- .UpdateFirmware = UpdateFirmware, // Update the firmware.
- };
-
- /* The ICs may be different depending on the touchscreen vendors, and the corresponding register operations are also different. Therefore, the code for the input chip driver focuses only on the adaptation of differentiated APIs. The following sample code demonstrates the data parsing of GT911. */
-
- static int32_t ChipDataHandle(ChipDevice *device)
- {
- ...
- /* Read the status register before GT911 obtains coordinates. */
- reg[0] = (GT_BUF_STATE_ADDR >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
- reg[1] = GT_BUF_STATE_ADDR & ONE_BYTE_MASK;
- ret = InputI2cRead(i2cClient, reg, GT_ADDR_LEN, &touchStatus, 1);
- if (ret < 0 || touchStatus == GT_EVENT_INVALID) {
- return HDF_FAILURE;
- }
- ...
- /* Read data from the data register based on the value of the status register. */
- reg[0] = (GT_X_LOW_BYTE_BASE >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
- reg[1] = GT_X_LOW_BYTE_BASE & ONE_BYTE_MASK;
- pointNum = touchStatus & GT_FINGER_NUM_MASK;
- if (pointNum == 0 || pointNum > MAX_SUPPORT_POINT) {
- HDF_LOGE("%s: pointNum is invalid, %u", __func__, pointNum);
- (void)ChipCleanBuffer(i2cClient);
- OsalMutexUnlock(&device->driver->mutex);
- return HDF_FAILURE;
- }
- frame->realPointNum = pointNum;
- frame->definedEvent = TOUCH_DOWN;
- (void)InputI2cRead(i2cClient, reg, GT_ADDR_LEN, buf, GT_POINT_SIZE * pointNum);
- /* Parse the obtained data. */
- ParsePointData(device, frame, buf, pointNum);
- ...
- }
- static void ParsePointData(ChipDevice *device, FrameData *frame, uint8_t *buf, uint8_t pointNum)
- {
- ...
- /* Each coordinate value consists of two bytes. Obtain the final coordinate value by combining the obtained single-byte data. */
- for (i = 0; i < pointNum; i++) {
- frame->fingers[i].trackId = buf[GT_POINT_SIZE * i + GT_TRACK_ID];
- frame->fingers[i].y = (buf[GT_POINT_SIZE * i + GT_X_LOW] & ONE_BYTE_MASK) |
- ((buf[GT_POINT_SIZE * i + GT_X_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
- frame->fingers[i].x = (buf[GT_POINT_SIZE * i + GT_Y_LOW] & ONE_BYTE_MASK) |
- ((buf[GT_POINT_SIZE * i + GT_Y_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
- /* Print the parsed coordinate value. */
- HDF_LOGD("%s: x = %d, y = %d", __func__, frame->fingers[i].x, frame->fingers[i].y);
- }
- }
- ```
-
-2. Initialize the input chip driver and register the driver with the HDF.
-
- You can obtain the sample code at **./drivers/framework/model/input/driver/touchscreen/touch\_gt911.c**.
-
- ```
- static int32_t HdfGoodixChipInit(struct HdfDeviceObject *device)
- {
- ...
- /* Use the chipCfg structure to allocate memory, parse the configuration information, and mount the parsed data. */
- chipCfg = ChipConfigInstance(device);
- ...
- /* Instantiate the touchscreen device. */
- chipDev = ChipDeviceInstance();
- ...
- /* Mount touchscreen chip configuration and private operation data. */
- chipDev->chipCfg = chipCfg;
- chipDev->ops = &g_gt911ChipOps;
- ...
- /* Register the chip driver with the platform driver. */
- RegisterChipDevice(chipDev);
- ...
- }
- struct HdfDriverEntry g_touchGoodixChipEntry = {
- .moduleVersion = 1,
- .moduleName = "HDF_TOUCH_GT911", // The value must match the moduleName field of the chip driver in the device_info.hcs file.
- .Init = HdfGoodixChipInit, // Initialize the touchscreen chip driver.
- };
- HDF_INIT(g_touchGoodixChipEntry); // Register the touchscreen chip driver with the HDF.
- ```
-
- The private chip drivers present the major differentiations among chip vendors, such as hibernation and wakeup, data parsing, and firmware update.
-
- Now, you have completed the adaptation for the touchscreen driver based on the HDF and input driver model.
-
-
diff --git a/en/device-dev/guide/adding-pages.md b/en/device-dev/guide/adding-pages.md
deleted file mode 100644
index 42eae0107fbdff36aff7879586df0fedebc792b2..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/adding-pages.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Adding Pages
-
-- [Creating the Home Page](#section16935511143715)
-- [Creating the Details Page](#section122131729173819)
-
-## Creating the Home Page
-
-Upon creation of the project, the **index** page is automatically generated, which is the home page of AirQuality. [Figure 1](#fig16545205773718) shows the project directory.
-
-**Figure 1** Project directory
-
-
-## Creating the Details Page
-
-To the details page, perform the following steps:
-
-1. Right-click **pages** and choose **New** \> **JS Page** from the shortcut menu.
-
- **Figure 2** Adding a page
- 
-
-2. Enter the page name.
-
- **Figure 3** Entering the page name
- 
-
-3. Confirm the creation.
-
- The following figure shows the application project directory after the **detail** page is created. It contains a **.hml** layout file, a **.css** file, and a **.js** file \(containing service logic code\).
-
- **Figure 4** Complete project directory
- 
-
-
diff --git a/en/device-dev/guide/building-and-burning-14.md b/en/device-dev/guide/building-and-burning-14.md
deleted file mode 100644
index d905b787acbb3639912138621c808faa46645a10..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/building-and-burning-14.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Building and Burning
-
-1. Compile the Makefile and add the following content in this example.
-
- The file is available at **./drivers/adapter/khdf/linux/model/input/Makefile**.
-
- Add the following content:
-
- ```
- obj-$(CONFIG_DRIVERS_HDF_TP_5P5_GT911) += \
- $(INPUT_ROOT_DIR)/touchscreen/touch_gt911.o
- ```
-
- **touch\_gt911.o** is the content added in this example.
-
-2. Conduct building and burn. For details about the building and burning operations, see [Build and Burn in Getting Started with Standard System](../quick-start/standard-system.md).
-
diff --git a/en/device-dev/guide/building-and-burning.md b/en/device-dev/guide/building-and-burning.md
deleted file mode 100644
index 25f895cc93816b552eee5058a96b098ec7fdf7e9..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/building-and-burning.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Building and Burning
-
-1. Edit the Makefile and add a source file to it, as shown in the following example:
-
- ```
- include drivers/hdf/khdf/platform/platform.mk
-
- obj-y += $(HDF_PLATFORM_FRAMEWORKS_ROOT)/src/i2c_core.o \
- $(HDF_PLATFORM_FRAMEWORKS_ROOT)/src/i2c_if.o \
- ./i2c_adapter.o \
- ./i2c_sample.o
- ```
-
- **./i2c\_sample.o** is the source file added to the Makefile in this example.
-
-2. Build the version and burn the system image to the development board.
-
- For details about the building and burning operations, see [Build and Burn in Getting Started with Standard System](../quick-start/standard-system.md).
-
-
diff --git a/en/device-dev/guide/building-the-details-page.md b/en/device-dev/guide/building-the-details-page.md
deleted file mode 100644
index 915c74a318163d6a50cab13e46f919b129690d1d..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/building-the-details-page.md
+++ /dev/null
@@ -1,396 +0,0 @@
-# Building the Details Page
-
-- [detail.hml](#section275215487291)
-- [detail.css](#section2589154215301)
-- [detail.js](#section163410883117)
-
-The **detail** page displays the air quality data of a week in a chart. There are two parts on the page: title bar and chart bar. Considering the display effect of the chart bar, use multiple **** components in stead of one **** component.
-
-Add a root ****, set the **flex-direction** attribute to **column** to arrange the two bars vertically. The example code is as follows:
-
-```
-
-
-
-
- History
-
-
-
-
-
-```
-
-In the preceding example, **onclick="backMain"** indicates that the application returns to the home page when the click event is triggered. The example code for **detail.js** is as follows:
-
-```
-import router from '@system.router'
-
-export default {
- backMain() {
- router.replace({
- // Home page URL
- uri: 'pages/index/index',
- params: {
- // Parameters to pass to the home page
- selectedCityIndex: this.selectedCityIndex
- }
- });
- }
-}
-```
-
-Add **** components to the **** component to form a chart.
-
-The complete example code in the three files is as follows.
-
-## detail.hml
-
-```
-
-```
-
-## detail.css
-
-```
-.location {
- text-align: center;
- color: #ffffff;
- width: 960px;
- height: 52px;
- font-size: 40px;
-}
-.container {
- height: 480px;
- width: 960px;
- flex-direction: column;
-}
-
-.header {
- width: 960px;
- height: 72px;
-}
-
-.back {
- width: 36px;
- height: 36px;
- margin-left: 39px;
- margin-top: 23px;
-}
-
-.title {
- width: 296px;
- height: 40px;
- margin-top: 20px;
- margin-left: 21px;
- color: #e6e6e6;
-}
-
-.chart-list {
- width: 960px;
- height: 408px;
-}
-
-.list-item-title {
- width: 960px;
- height: 52px;
-}
-
-.list-item-chart {
- width: 960px;
- height: 280px;
-}
-
-.chart-wrapper {
- width: 308px;
- height: 256px;
- flex-direction: column;
-}
-
-.gas-name {
- width: 308px;
- height: 35px;
- text-align: left;
-}
-
-.chart {
- width: 308px;
- height: 155px;
- margin-top: 10px;
- justify-content: flex-start;
- align-items: flex-end;
-}
-
-.chart-item {
- width: 24px;
- margin-left: 18px;
- border-radius: 3px;
-}
-
-.white-line {
- width: 308px;
- height: 2px;
- background-color: #ffffff;
- margin-top: 22px;
-}
-
-.week {
- width: 308px;
- height: 17px;
- margin-top: 6px;
- border-color: #ffffff;
- border-radius: 2px;
- margin-top: 6px;
-}
-
-.day {
- width: 26px;
- height: 17px;
- font-size: 10px;
- margin-left: 16px;
- text-align: center;
-}
-```
-
-## detail.js
-
-```
-import router from '@system.router'
-
-export default {
- data: {
- location: ''
- },
- onInit() {
- if (this.selectedCityIndex === 0) {
- this.location = 'Dongguan';
- } else {
- this.location = 'Shenzhen';
- }
- },
- backMain() {
- router.replace({
- uri: 'pages/index/index',
- params: {
- selectedCityIndex: this.selectedCityIndex
- }
- });
- }
-}
-```
-
diff --git a/en/device-dev/guide/building-the-home-page.md b/en/device-dev/guide/building-the-home-page.md
deleted file mode 100644
index e50391cee73cb565eb6537ec06a70eb53ee996aa..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/building-the-home-page.md
+++ /dev/null
@@ -1,581 +0,0 @@
-# Building the Home Page
-
-The application home page displays air quality information of different cities. The home page provides two screens \(for two information bars\), which can be added as required. Each screen displays the air quality information of one city, including the Air Quality Index \(AQI\), city name, pollution level, update time, and data source.
-
-The home page of AirQuality consists of three parts:
-
-- Title bar: displays the page title and provides an exit button. The title bar is fixed at the top of the page.
-- Information bar: displays air quality information. Multiple information bars can be added based on user requirements and support looping scroll.
-- Indicator bar: shows the position of the current screen among all screens. The indicator bar is fixed at the bottom of the page.
-
-The following steps describe how to build the home page with a flexible layout that has three rows vertically arranged.
-
-1. Add a root **** to the **.hml** file. Note that each **.hml** file can contain only one root component. The example code is as follows:
-
- ```
-
-
- ```
-
- **class="container"** indicates the style used by the component. The **container** is a style class defined in the **index.css** file.
-
- ```
- .container {
- flex-direction: column;
- height: 480px;
- width: 960px;
- }
- ```
-
- The height and width of the root component **** are set in the style class. Note that the height and width must be explicitly specified \(except for some components, such as ****\). Otherwise, the component may fail to display. In the **container** style class, the **flex-direction** attribute is set to **column**, which means that child components of **** are vertically arranged from top to bottom for implementing the flexible page layout.
-
-2. Add the title bar. The title bar consists of an exit button and title text that are horizontally arranged. Add a **** to hold the title bar and set the **flex-direction** attribute to **row** to arrange the child components from left to right. Add an **** and a **** component in sequence. The example code is as follows:
-
- ```
-
-
-
-
- Air quality
-
-
-
- ```
-
- Set component attributes, including the height, width, margin, and color.
-
- ```
- .header {
- width: 960px;
- height: 72px;
- }
- .back {
- width: 36px;
- height: 36px;
- margin-left: 39px;
- margin-top: 23px;
- }
- .title {
- width: 296px;
- height: 40px;
- margin-top: 20px;
- margin-left: 21px;
- color: #e6e6e6;
- }
- ```
-
- In the **.hml** file, **onclick="exitApp"** sets the click event for the **** component. When the click event is triggered, the **exitApp\(\)** function is executed. The example definition of **exitApp\(\)** in **index.js** is as follows:
-
- ```
- exitApp() {
- console.log('start exit');
- app.terminate();
- console.log('end exit');
- }
- ```
-
- The **app.terminate\(\)** function is used to exit the program. Before using this function, you must import the **app** module by adding the following code at the beginning of **index.js**:
-
- ```
- import app from '@system.app'
- ```
-
- After the code is compiled, run the project on the simulator. The following figure shows the display effect.
-
- **Figure 1** Title bar
- 
-
-3. The **** component is required to implement the switching between screens.
-
- Add a **** to the root node.
-
- ```
-
-
-
-
- Air quality
-
-
-
-
-
- ```
-
- - Use **class="**swiper**"** to set the height and width of the component. The sample code is as follows:
-
- ```
- .swiper {
- height: 385px;
- width: 960px;
- }
- ```
-
-
- - **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:
-
- ```
- // Import the router module for page switching.
- import router from'@system.router'
- import app from '@system.app'
-
- export default {
- // Define parameters.
- data: {
- // By default, the first page is displayed.
- swiperPage: 0
- },
- onInit () {
- },
- exitApp(){
- console.log('start exit');
- app.terminate();
- console.log('end exit');
- },
- // Swiping event, which saves the index value of the current . The index value is saved to the swiperPage variable each time a swiping occurs.
- swiperChange (e) {
- this.swiperPage = e.index;
- }
- }
- ```
-
-
-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:
-
- ```
-
-
-
- ------Air quality
- ------City name
- -----Progress bar
- -------A cloud image
- --------AQI value
- AQI------AQI
-
--------AQI details
-
-
--------Update time, website, and other information
-
-
-
-
-
-
-
-
-
-
-
-
-
- ```
-
- After the code is compiled, the display effect on the simulator is as follows.
-
- **Figure 2** Title bar and information bar
- 
-
-5. Add the indicator bar. Currently, the **** component does not support indicator settings. You need to implement a dots indicator by adding **** components and setting the style. Add a **** as a child component to the root node and set the style. Add two **** to the parent ****, set **border-radius** for the two child ****, and dynamically change the background colors of the **** components in the swiping event.
-
- ```
-
-
-
-
- ```
-
- **Figure 3** Indicator bar
- 
-
-6. Set the style, animation effect, and dynamic data binding for all components. The complete example code is as follows:
-
- - **index.hml**
-
- ```
-
- ```
-
- - **index.css**
-
- A **.css** file contains many classes. Each class defines the position, size, font, color, and background color of a component. Each child component is added to its parent component, and the style file of the parent component affects how the child component will be displayed.
-
- ```
- .aqi-value {
- text-align: center;
- font-size: 65px;
- color: #f0ffff;
- width: 156px;
- height: 92px;
- top: 134px;
- left: 210px;
- }
- .aqi {
- text-align: center;
- color: #a2c4a2;
- width: 156px;
- height: 45px;
- top: 90px;
- left: 210px;
- }
- .airquality {
- top: 222px;
- text-align: center;
- width: 156px;
- height: 45px;
- left: 210px;
- }
- .image {
- top: 285px;
- left: 274px;
- width: 32px;
- height: 32px;
- }
- .location-text {
- text-align: center;
- color: #ffffff;
- width: 200px;
- height: 52px;
- font-size: 40px;
- left: 380px;
- top: 16px;
- }
- .container {
- flex-direction: column;
- height: 480px;
- width: 960px;
- }
- .circle-progress {
- center-x: 128px;
- center-y: 128px;
- radius: 128px;
- startAngle: 198;
- totalAngle: 320;
- strokeWidth: 24px;
- width: 256px;
- height: 256px;
- left: 160px;
- top: 58px;
- }
- .detail {
- width: 256px;
- height: 265px;
- left: 544px;
- top: 58px;
- flex-direction: column;
- }
- .text-wrapper {
- width: 256px;
- height: 35px;
- margin-top: 6px;
- }
- .gas-name {
- width: 128px;
- height: 35px;
- text-align: left;
- }
- .gas-value {
- width: 128px;
- height: 35px;
- text-align: right;
- }
- .btn {
- width: 180px;
- height: 50px;
- margin-top: 6px;
- margin-left: 38px;
- background-color: #1a1a1a;
- color: #1085CE;
- }
- .footer {
- top: 326px;
- width: 960px;
- height: 28px;
- }
- .header {
- width: 960px;
- height: 72px;
- }
- .back {
- width: 36px;
- height: 36px;
- margin-left: 39px;
- margin-top: 23px;
- }
- .title {
- width: 296px;
- height: 40px;
- margin-top: 20px;
- margin-left: 21px;
- color: #e6e6e6;
- }
- .swiper {
- height: 385px;
- width: 960px;
- }
- .images {
- width: 60px;
- height: 15px;
- margin-left: 450px;
- }
- .update-time {
- width: 480px;
- height: 28px;
- font-size: 20px;
- color: #A9A9A9;
- text-align: right;
- }
- .info-source {
- width: 450px;
- height: 28px;
- font-size: 20px;
- color: #A9A9A9;
- text-align: left;
- margin-left: 24px;
- }
- .circle-div {
- width: 12px;
- height: 12px;
- border-radius: 6px;
- }
- ```
-
- - **index.js**
-
- A **.js** file is used to implement interaction logic of your application. In the **.js** file of the home page, implement page switching and enable text content and progress bar color to change dynamically according to AQI values.
-
- ```
- // Import router and app modules.
- import router from '@system.router'
- import app from '@system.app'
-
- export default {
- data: {
- // Bind data.
- textColor1: '#00ff00',
- textColor2: '#00ff00',
- bgColor1: '#669966',
- bgColor2: '#669966',
- swiperPage: 0,
- percent1: 40,
- percent2: 90,
- iconUncheckedColor: '#262626',
- iconcheckedColor: '#ffffff',
- iconcheckedBR: '6px',
- src1: 'common/cloud_green.png',
- src2: 'common/cloud_green.png',
- airData: [{
- location: 'Dongguan',
- airQuality: 'Good',
- detailData: 40
- }, {
- location: 'Shenzhen',
- airQuality: 'Polluted',
- detailData: 90
- }]
- },
- onInit () {
- // Set the font, background color, and background image for different value ranges.
- if(this.airData[0].detailData > 100){
- this.src1 = 'common/cloud_red.png';
- this.textColor1 = '#ff0000';
- this.bgColor1 = '#9d7462';
- } else if(50 < this.airData[0].detailData && this.airData[0].detailData <= 100){
- this.src1 = 'common/cloud_yellow.png';
- this.textColor1 = '#ecf19a';
- this.bgColor1 = '#9d9d62';
- }
- if(this.airData[1].detailData > 100){
- this.src2 = 'common/cloud_red.png';
- this.textColor2 = '#ff0000';
- this.bgColor2 = '#9d7462';
- } else if(50 < this.airData[1].detailData && this.airData[1].detailData <= 100){
- this.src2 = 'common/cloud_yellow.png';
- this.textColor2 = '#ecf19a';
- this.bgColor2 = '#9d9d62';
- }
- if(this.selectedCityIndex){
- this.swiperPage = this.selectedCityIndex;
- if(this.swiperPage == 0){
- this.iconcheckedColor = '#ffffff';
- this.iconUncheckedColor = '#262626';
- }else{
- this.iconcheckedColor = '#262626';
- this.iconUncheckedColor = '#ffffff';
- }
- }
- },
- // Switch to the details page.
- openDetail () {
- router.replace({
- uri: 'pages/detail/detail',
- params: {selectedCityIndex:this.swiperPage}
- });
- },
- // Exit the application.
- exitApp(){
- console.log('start exit');
- app.terminate();
- console.log('end exit');
- },
- // Define the swiping event. Change the indicator dots when the user swipes the screen.
- swiperChange (e) {
- this.swiperPage = e.index;
- if(e.index == 0){
- this.iconcheckedColor = '#ffffff';
- this.iconUncheckedColor = '#262626';
- }else{
- this.iconcheckedColor = '#262626';
- this.iconUncheckedColor = '#ffffff';
- }
- }
- }
- ```
-
-
diff --git a/en/device-dev/guide/camera-control.md b/en/device-dev/guide/camera-control.md
deleted file mode 100644
index 5694352afcf41a300ab8936b6dc2abfed5bc1a56..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/camera-control.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Camera Control
-
-- **[Overview](overview-0.md)**
-
-- **[Development Guidelines](development-guidelines.md)**
-
-- **[Use Case](use-case.md)**
-
-
diff --git a/en/device-dev/guide/cameras-with-a-screen.md b/en/device-dev/guide/cameras-with-a-screen.md
deleted file mode 100644
index b212cc236c70be6403f659c5eabdaeebfc7d677a..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/cameras-with-a-screen.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Cameras with a Screen
-
-- **[Screen and Camera Control](screen-and-camera-control.md)**
-
-- **[Visual Application Development](visual-application-development.md)**
-
-
diff --git a/en/device-dev/guide/cameras-without-a-screen.md b/en/device-dev/guide/cameras-without-a-screen.md
deleted file mode 100644
index abb3a6616a0364c5ca1d5e19a48fa040c798c2bc..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/cameras-without-a-screen.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Cameras Without a Screen
-
-- **[Camera Control](camera-control.md)**
-
-
diff --git a/en/device-dev/guide/configuring-device-driver-descriptions.md b/en/device-dev/guide/configuring-device-driver-descriptions.md
deleted file mode 100644
index d19a91a732b43d0f059d6c5dbd4d8430a386ce98..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/configuring-device-driver-descriptions.md
+++ /dev/null
@@ -1,64 +0,0 @@
-# Configuring Device Driver Descriptions
-
-You can configure the device driver description in the configuration file at **./drivers/adapter/khdf/linux/hcs/device\_info/device\_info.hcs**.
-
-The **device\_info.hcs** file contains all necessary information for registering drivers in the input driver model with the HDF. You do not need to make any modification for the information unless otherwise required in special scenarios. The private configuration data of each driver uses the **deviceMatchAttr** field to match the **match\_attr** field in the **input\_config.hcs** file.
-
-The input-related content in the configuration file is as follows \(For details about these fields, see [Driver Development](https://device.harmonyos.com/en/docs/develop/drive/oem_drive_hdfdev_load-0000001051276785)[Driver Development](../driver/driver-development.md)\):
-
-```
-input :: host {
- hostName = "input_host";
- priority = 100;
- device_input_manager :: device { // Specify the device driver description of the input device manager.
- device0 :: deviceNode {
- policy = 2; // Services are released to both the kernel space and the user space.
- priority = 100; // The default priority for the input device manager is 100.
- preload = 0; // Load the driver.
- permission = 0660; // Specify the permission for the driver to create device nodes.
- moduleName = "HDF_INPUT_MANAGER"; // Match the moduleName in the driver entry structure.
- serviceName = "hdf_input_host"; // Specify the device node name to be generated by the HDF.
- deviceMatchAttr = ""; // Leave this field empty because private configuration data is not required by the input device manager currently.
- }
- }
-
- device_hdf_touch :: device { // Specify the device driver description of the input common driver.
- device0 :: deviceNode {
- policy = 2; // Services are released to both the kernel space and the user space.
- priority = 120; // The default priority for the input common driver is 120.
- preload = 0; // Load the driver.
- permission = 0660; // Specify the permission for the driver to create device nodes.
- moduleName = "HDF_TOUCH"; // Match the moduleName in the driver entry structure.
- serviceName = "hdf_input_event1"; // Specify the device node name to be generated by the HDF.
- deviceMatchAttr = "touch_device1"; // Keep this value the same as the match_attr value in the private configuration data.
- }
- }
-
- device_touch_chip :: device { // Specify the device description of the input chip driver.
- device0 :: deviceNode {
- policy = 0; // Services are not released to both the kernel space and the user space.
- priority = 130; // The default priority for the input chip driver is 130.
- preload = 0; // Load the driver.
- permission = 0660; // Specify the permission for the driver to create device nodes.
- moduleName = "HDF_TOUCH_GT911"; // Match the moduleName in the driver entry structure.
- serviceName = "hdf_touch_gt911_service";// Specify the device node name to be generated by the HDF.
- deviceMatchAttr = "zsj_gt911_5p5"; // Keep this value the same as the match_attr value in the private configuration data.
- }
- }
- }
-```
-
-Pay attention to the following fields in the configuration file:
-
-**priority**: specifies the driver loading priority.
-
-**preload**: specifies whether to load the driver.
-
-**moduleName**: This value must be the same as the **moduleName** value in the driver entry structure.
-
-**serviceName**: This value is used by the HDF to create a device node name.
-
-**deviceMatchAttr**: This value must be the same as the **match\_attr** value in the private configuration data.
-
-After the device descriptions are configured, the HDF matches the configuration with the code registered with the driver entry structure based on the **moduleName** field, ensuring that drivers can be loaded properly. If multiple drivers are configured, the **priority** field determines the loading sequence of each driver.
-
diff --git a/en/device-dev/guide/configuring-the-touchscreen.md b/en/device-dev/guide/configuring-the-touchscreen.md
deleted file mode 100644
index 6a6cc59f6aded4d77aea594e683f9e6e682324ed..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/configuring-the-touchscreen.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# Configuring the Touchscreen
-
-You can configure the touchscreen in the configuration file at **./drivers/adapter/khdf/linux/hcs/input/input\_config.hcs**.
-
-The **input\_config.hcs** file consists of the private configuration data of both the common driver and chip driver. Information of this file is read and parsed by the driver code. The configuration in the file includes the board-level hardware information and private configuration of the touchscreen. You can tailor the configuration during your development.
-
-```
-root {
- input_config {
- touchConfig {
- touch0 { // Configure the first touchscreen.
- boardConfig { // Specify the board-level hardware information.
- match_attr = "touch_device1"; // Keep this value the same as the match_attr field in the private configuration data of the input common driver in the device description.
- inputAttr {
- /* 0:touch 1:key 2:keyboard 3:mouse 4:button 5:crown 6:encoder */
- inputType = 0; // Set the input type to touch.
- solutionX = 480; // Set the resolution in the X-axis.
- solutionY = 960; // Set the resolution in the Y-axis.
- devName = "main_touch"; // Set the device name.
- }
- busConfig {
- /* 0:i2c 1:spi */
- busType = 0; // GT911 uses the I2C bus for communication.
- busNum = 6; // Use the sixth bus of the chip to communicate with the development board through I2C.
- clkGpio = 86; // Set the SCL pin of the chip.
- dataGpio = 87; // Set the SDA pin of the chip.
- i2cClkIomux = [0x114f0048, 0x403]; // Configure the SCL pin information.
- i2cDataIomux = [0x114f004c, 0x403]; // Configure the SDA pin information.
- }
- pinConfig {
- rstGpio = 3; // Set the reset pin.
- intGpio = 4; // Set the interrupt pin.
- rstRegCfg = [0x112f0094, 0x400]; // Configure the reset pin information.
- intRegCfg = [0x112f0098, 0x400]; // Configure the interrupt pin information.
- }
- powerConfig {
- /* Value 0 indicates that power supply is not used; value 1 indicates the LDO power supply; value 2 indicates the GPIO power supply; value 3 indicates the PMIC power supply. */
- vccType = 2; // Set the VCC type. Value 2 indicates the GPIO power supply.
- vccNum = 20; // Set the VCC number. The GPIO number is 20.
- vccValue = 1800; // Set the voltage amplitude to 1800 mV.
- vciType = 1; // Set the VCI type. Value 1 indicates the LDO power supply.
- vciNum = 12; // Set the VCI number. The LDO number is 12.
- vciValue = 3300; // Set the voltage amplitude to 3300 mV.
- }
-
- featureConfig {
- capacitanceTest = 0; // Configure the capacitance test.
- gestureMode = 0; // Configure the gesture mode.
- gloverMode = 0; // Configure the gloves mode.
- coverMode = 0; // Configure the cover mode.
- chargerMode = 0; // Configure the charging mode.
- knuckleMode = 0; // Configure the knuckle mode.
- }
- }
- chipConfig { // Configure the private data of the touchscreen chip.
- template touchChip { // Template
- match_attr = "";
- chipName = "gt911"; // Set the touchscreen IC model.
- vendorName = "zsj"; // Set the vendor name.
- chipInfo = "AAAA11222"; // The first four characters indicate the product name. The fifth and sixth characters indicate the IC model. The last three characters indicate the chip model.
- busType = 0; // 0 indicates the I2C bus, and 1 indicates the SPI bus.
- deviceAddr = 0x5D; // Set the IC communication address.
- irqFlag = 2; // Values 1 and 2 indicate that the interrupt is triggered on the rising and falling edges, respectively. Values 4 and 8 indicate that the interrupt is triggered by the high and low levels, respectively.
- maxSpeed = 400; // Set the maximum communication rate to 400 Hz.
- chipVersion = 0; // Set the touchscreen IC version.
- powerSequence {
- /* Power-on sequence is described as follows:
- [Type, status, direction, delay]
- Value 0 indicates the power or pin is empty. Values 1 and 2 indicate the VCC (1.8 V) and VCI (3.3 V) power, respectively. Values 3 and 4 indicate the reset and interrupt pins, respectively.
- Values 0 and 1 indicate the power-off or pull-down, and the power-on or pull-up, respectively. Value 2 indicates that no operation is performed.
- Values 0 and 1 indicate the input and output directions, respectively. Value 2 indicates that no operation is performed.
- Delay time, in milliseconds.
- */
- powerOnSeq = [4, 0, 1, 0, // Set the output direction for the interrupt pin and pull down the pin.
- 3, 0, 1, 10, // Set the output direction for the reset pin and pull down the pin, with a delay of 10 ms.
- 3, 1, 2, 60, // No operation is performed on the reset pin. Pull up the pin, with a delay of 60 ms.
- 4, 2, 0, 0]; // Set the input direction for the interrupt pin.
- suspendSeq = [3, 0, 2, 10]; // No operation is performed on the reset pin. Pull down the pin, with a delay of 10 ms.
- resumeSeq = [3, 1, 2, 10]; // No operation is performed on the reset pin. Pull up the pin, with a delay of 10 ms.
- powerOffSeq = [3, 0, 2, 10, // No operation is performed on the reset pin. Pull down the pin, with a delay of 10 ms.
- 1, 0, 2, 20]; // No operation is performed on the positive pin. Pull down the pin, with a delay of 20 ms.
- }
- }
-
- chip0 :: touchChip {
- match_attr = "zsj_gt911_5p5"; // Keep this value the same as the match_attr field in the touchscreen private configuration data in the device description.
- chipInfo = "ZIDN45100"; // The chip information is composed of the product name, module number, and chip number, used to identity the current touchscreen in user space.
- chipVersion = 0; // IC model version
- }
- }
- }
- }
- }
-}
-```
-
-In the example, **touchConfig** contains the **touch0** configuration, which describes the **boardConfig** and **chipConfig** configuration information. The **boardConfig** field provides the board-level hardware information of Hi3516D V300, and the **chipConfig** field provides the private configuration data of the touchscreen. To use another touchscreen, you can change the value of the **chipConfig** field. You can also configure multiple touchscreens for your product. In this example, **touch0** represents the hardware interface and chip configuration of the default touchscreen. If you need to configure a secondary touchscreen, add a **touch1** block parallel to **touch0**.
-
diff --git a/en/device-dev/guide/debugging-and-packaging.md b/en/device-dev/guide/debugging-and-packaging.md
deleted file mode 100644
index 97df7e21ab4e36ac3420ba1494bf8452fa5f226e..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/debugging-and-packaging.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Debugging and Packaging
-
-After the code is compiled, debug your application and package it into an App Pack. For details about how to debug and package an application, see [Debugging Your App](https://developer.harmonyos.com/en/docs/documentation/doc-guides/debug_overview-0000001053822404) and [Building Your App](https://developer.harmonyos.com/en/docs/documentation/doc-guides/build_overview-0000001055075201) in the [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387). Currently, IPCamera applications do not support signature. You should release an unsigned App Pack.
-
diff --git a/en/device-dev/guide/debugging-and-verification.md b/en/device-dev/guide/debugging-and-verification.md
deleted file mode 100644
index 13a210d84987d51e46caf248980815b123107c74..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/debugging-and-verification.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Debugging and Verification
-
-- **[Startup Log Analysis](startup-log-analysis.md)**
-
-
diff --git a/en/device-dev/guide/developing-a-touchscreen-driver.md b/en/device-dev/guide/developing-a-touchscreen-driver.md
deleted file mode 100644
index 6fa833ae11f7f29760c9ec5f3822e7f8f41c28af..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/developing-a-touchscreen-driver.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Developing a Touchscreen Driver
-
-Complete the following tasks to adapt a touchscreen IC based on the input driver model:
-
-1. Configure the touchscreen driver description required for registering the driver with the HDF, for example, whether the driver is loaded and what is the loading priority.
-
-2. Configure the private data of the touchscreen \(such as the power-on and power-off sequence\) and the platform hardware information \(such as the GPIO port that connects the touchscreen to the development board\).
-
-3. Adapt to the private drivers of the touchscreen. The input driver model abstracts the development process of input devices. You only need to adapt to the input chip driver without making any modifications for the input device manager and common driver.
-
-- **[Configuring Device Driver Descriptions](configuring-device-driver-descriptions.md)**
-
-- **[Configuring the Touchscreen](configuring-the-touchscreen.md)**
-
-- **[Adapting to the Private Drivers of the Touchscreen](adapting-to-the-private-drivers-of-the-touchscreen.md)**
-
-
diff --git a/en/device-dev/guide/development-12.md b/en/device-dev/guide/development-12.md
deleted file mode 100644
index 59fb5d8e5ee93659cfe90543390f8065bcae6b5b..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/development-12.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# Development
-
-- [Instantiating the Driver Entry](#section6586911816)
-- [Setting Related Parameters](#section114323217503)
-- [Adding a Controller](#section115187812516)
-
-Platform driver development includes the following procedures:
-
-1. Instantiate the driver entry: Instantiate an **HdfDriverEntry** object as the driver entry.
-2. Set related parameters: Configure the **device\_info.hcs** file and obtain and parse device configuration parameters from the HCS to ensure that the driver can be correctly loaded.
-3. Add a controller: Initialize the controller hardware, call core-layer APIs to add or delete devices to or from the core layer, and implement a hook.
-
-The following table lists the files involved in this example and their paths.
-
-**Table 1** File description
-
-
-
-
-> **CAUTION:**
->The file paths involved in this example are used for demonstration only. Determine the paths for storing the source files as required when developing your driver.
-
-## Instantiating the Driver Entry
-
-The driver entry must be a global variable of the **HdfDriverEntry** type \(which is defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. When loading the driver, the HDF calls the **Bind** function first and then the **Init** function. If an error occurred during the calling of the **Init** function, the HDF calls **Release** to release the driver resource and exit.
-
-The **Bind** function is not implemented in the I2C driver because the I2C controller is managed by the I2C manager and the **Bind** function has been implemented in the manager. Therefore, services do not need to be bound in the I2C driver.
-
-The sample code for instantiating the driver entry is as follows:
-
-```
-/* Define a driver entry object. It must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h). */
-struct HdfDriverEntry g_sampleI2cDriverEntry = {
- .moduleVersion = 1,
- .Init = SampleI2cInit,
- .Release = SampleI2cRelease,
- .moduleName = "demo_i2c_driver",
-};
-/* Call HDF_INIT to register the driver entry with the HDF. */
-HDF_INIT(g_sampleI2cDriverEntry);
-```
-
-## Setting Related Parameters
-
-1. \(Mandatory\) Add a device service node.
-
- Edit the **device\_info.hcs** file and add a driver device service node under **device\_i2c :: device**. The following is an example:
-
- ```
- root {
- device_info {
- match_attr = "hdf_manager";
- device_i2c :: device { // I2C devices
- device2 :: deviceNode { // Device node of an I2C driver
- policy = 0; // Policy for releasing the driver service
- priority = 55; // Driver startup priority
- permission = 0644; // Permission for the driver to create a device node.
- moduleName = "demo_i2c_driver"; // Driver name. The value of this field must be the same as the value of moduleName in the driver entry data structure.
- serviceName = "DEMO_I2C_DRIVER"; // Name of the service released by the driver. The name must be unique.
- deviceMatchAttr = "demo_i2c_config"; // Keyword matching the private data of the driver. The value must be the same as that of
- // match_attr in the private configuration data table of the driver.
- }
- }
- }
- }
- ```
-
- > **NOTICE:**
- >The **priority** attribute \(an integer ranging from 0 to 200\) in the configuration file indicates the priority of a host or drivers. Drivers in a host with a smaller priority value have a higher loading priority than those in other hosts. The driver with a smaller priority value in a host has a higher loading priority than the other drivers in the host. The loading sequence is random for drivers with the same priority.
-
-2. \(Optional\) Add configuration parameters.
-
- The driver may require private configuration information to ensure that the register configuration meets the requirements of different products. If private configuration data is required, you can add a driver configuration file to store some default configuration information about the driver. When loading the driver, the HDF obtains the specified configuration information, saves it in the **property** attribute of **HdfDeviceObject**, and passes it to the driver via **Bind** and **Init**. For details about how to use **Bind** and **Init**, see [Driver Development](../driver/driver-development.md). You can create a configuration file and reference it in the **hdf.hcs** file of the board-level driver. In this example, configuration parameters are directly added to the existing configuration file **i2c\_config.hcs**.
-
- The following configuration parameters are added to the **i2c\_config.hcs** file:
-
- ```
- root {
- platform {
- i2c_config_demo {
- match_attr = "demo_i2c_config"; // The value of this field must be the same as the value of deviceMatchAttr in device_info.hcs.
-
- template i2c_controller { // Parameter template
- bus = 0;
- reg_pbase = 0x120b0000;
- reg_size = 0xd1;
- }
-
- controller_demo_0 :: i2c_controller { // Two sample I2C controllers
- bus = 8;
- }
- controller_demo_1 :: i2c_controller {
- bus = 9;
- }
- }
- }
- }
- ```
-
- The value of **match\_attr** must be the same as that of **deviceMatch\_Attr** in the **device\_info.hcs** file. The **match\_attr** attribute is used to match the configured parameters in the configuration file \(**i2c\_config.hcs** in this example\) with the particular driver, so that the driver can call **DeviceResourceGetIfaceInstance\(\)** in the **Bind** or **Init** function to obtain these configuration parameters.
-
- If you create a new configuration file to set parameters, reference this file in the board-level configuration entry file **hdf.hcs**. For example:
-
- ```
- #include "device_info/device_info.hcs"
- #include "i2c/i2c_config.hcs"
- ```
-
- In this development example, we use an existing configuration file **i2c\_config.hcs** to add parameters, and therefore do not need to add it to the board-level configuration entry file.
-
-3. Enable the driver to obtain configuration parameters from the HCS.
-
- In this example, the driver needs to obtain configuration parameters, such as the physical base address of the register, register size, and bus number, through the HCS to correctly configure the controller.
-
- ```
- /* Obtain configuration parameters from the HCS. */
- static int32_t SampleI2cReadDrs(struct SampleI2cCntlr *sampleCntlr, const struct DeviceResourceNode *node)
- {
- int32_t ret;
- struct DeviceResourceIface *drsOps = NULL;
-
- drsOps = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);
- if (drsOps == NULL || drsOps->GetUint32 == NULL) { // Ensure that the GetUint32 function is available.
- HDF_LOGE("%s: invalid drs ops fail!", __func__);
- return HDF_FAILURE;
- }
-
- ret = drsOps->GetUint32(node, "reg_pbase", &sampleCntlr->regBasePhy, 0); // Read the physical base address from the HCS.
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: read regBase fail!", __func__);
- return ret;
- }
-
- ret = drsOps->GetUint16(node, "reg_size", &sampleCntlr->regSize, 0); // Read the register size from the HCS.
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: read regsize fail!", __func__);
- return ret;
- }
-
- ret = drsOps->GetUint16(node, "bus", (uint16_t *)&sampleCntlr->bus, 0); // Read the bus number from the HCS.
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: read bus fail!", __func__);
- return ret;
- }
-
- return HDF_SUCCESS;
- }
- ```
-
-
-## Adding a Controller
-
-1. Define an I2C controller structure, implement a hook, and assign the hook to the function pointer.
-
- The **I2cMethod** structure is defined in the **i2c\_core.h** header file. This structure defines the functions to be implemented by the I2C driver by using function pointers. The **SampleI2cTransfer** function is a hook used for data transmission, which must be implemented in the driver and must be assigned to a function pointer.
-
- The sample code is as follows:
-
- ```
- /* Custom device structure, which is inherited from I2cCntlr */
- struct SampleI2cCntlr {
- struct I2cCntlr cntlr;
- OsalSpinlock spin;
- volatile unsigned char *regBase;
- uint16_t regSize;
- int16_t bus;
- uint32_t regBasePhy;
- };
-
- /* Message structure, which is inherited from I2cMsg */
- struct SampleTransferData {
- struct I2cMsg *msgs;
- int16_t index;
- int16_t count;
- };
- /* Implement the SampleI2cTransfer hook. */
- static int32_t SampleI2cTransfer(struct I2cCntlr *cntlr, struct I2cMsg *msgs, int16_t count)
- {
- int32_t ret = HDF_SUCCESS;
- struct SampleI2cCntlr *sampleCntlr = NULL;
- struct SampleTransferData td;
-
- if (cntlr == NULL || cntlr->priv == NULL) {
- HDF_LOGE("SampleI2cTransfer: cntlr lor sampleCntlr is null!");
- return HDF_ERR_INVALID_OBJECT;
- }
- sampleCntlr = (struct SampleI2cCntlr *)cntlr;
-
- if (msgs == NULL || count <= 0) {
- HDF_LOGE("SampleI2cTransfer: err parms! count:%d", count);
- return HDF_ERR_INVALID_PARAM;
- }
- td.msgs = msgs;
- td.count = count;
- td.index = 0;
-
- HDF_LOGE("Successfully transmitted!"); // Data transmission is successful.
-
- td.index = count; // The total number of sent messages is returned. The message handling process is not provided in this sample code.
- return (td.index > 0) ? td.index : ret;
- }
- /* Assign the hook to a function pointer. */
- static struct I2cMethod g_method = {
- .transfer = SampleI2cTransfer,
- };
- ```
-
-2. Write a driver initialization function.
-
- This example uses **SampleI2cInit** as the name of the driver initialization function \(you can name your own function\). This function must be assigned to the **Init** function in the driver entry structure so that the HDF can call it to initialize the driver. The driver initialization function needs to parse the configuration parameters obtained from the HCS and create a controller based on these parameters. The sample code is as follows:
-
- ```
- /* Parse parameters, apply for memory, and create a controller. */
- static int32_t SampleI2cParseAndInit(struct HdfDeviceObject *device, const struct DeviceResourceNode *node)
- {
- int32_t ret;
- struct SampleI2cCntlr *sampleCntlr = NULL;
- (void)device;
-
- sampleCntlr = (struct SampleI2cCntlr *)OsalMemCalloc(sizeof(*sampleCntlr));
- if (sampleCntlr == NULL) {
- HDF_LOGE("%s: malloc sampleCntlr fail!", __func__);
- return HDF_ERR_MALLOC_FAIL;
- }
-
- ret = SampleI2cReadDrs(sampleCntlr, node); // Obtain configuration parameters from the HCS.
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: read drs fail! ret:%d", __func__, ret);
- goto __ERR__;
- }
-
- sampleCntlr->regBase = OsalIoRemap(sampleCntlr->regBasePhy, sampleCntlr->regSize);
- if (sampleCntlr->regBase == NULL) {
- HDF_LOGE("%s: ioremap regBase fail!", __func__);
- ret = HDF_ERR_IO;
- goto __ERR__;
- }
-
- HDF_LOGE("The controller has been initialized!"); // The controller has been initialized successfully. (The initialization process is not provided here.)
-
- sampleCntlr->cntlr.priv = (void *)node;
- sampleCntlr->cntlr.busId = sampleCntlr->bus;
- sampleCntlr->cntlr.ops = &g_method;
- (void)OsalSpinInit(&sampleCntlr->spin); // Initialize the spin lock.
- ret = I2cCntlrAdd(&sampleCntlr->cntlr); // Add a controller to the core layer.
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: add i2c controller fail:%d!", __func__, ret);
- goto __ERR__;
- }
-
- return HDF_SUCCESS;
- __ERR__: // Handle errors.
- if (sampleCntlr != NULL) {
- if (sampleCntlr->regBase != NULL) {
- OsalIoUnmap((void *)sampleCntlr->regBase); // Cancel address mapping.
- sampleCntlr->regBase = NULL;
- }
- OsalMemFree(sampleCntlr); // Release the memory.
- sampleCntlr = NULL;
- }
- return ret;
- }
- /* Driver initialization function */
- static int32_t SampleI2cInit(struct HdfDeviceObject *device)
- {
- int32_t ret;
- const struct DeviceResourceNode *childNode = NULL;
-
- HDF_LOGE("%s: Enter", __func__);
- if (device == NULL || device->property == NULL) {
- HDF_LOGE("%s: device or property is NULL", __func__);
- return HDF_ERR_INVALID_OBJECT;
- }
-
- ret = HDF_SUCCESS;
- DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) {
- ret = SampleI2cParseAndInit(device, childNode); // Call the function for parsing parameters and creating a controller.
- if (ret != HDF_SUCCESS) {
- break;
- }
- }
- return ret;
- }
- ```
-
-3. Write a driver release function.
-
- This example uses **SampleI2cRelease** as the name of the driver release function \(you can name your own function\). This function must be assigned to the **Release** function in the driver entry structure so that the HDF can call it to initialize the driver if the driver fails to be initialized via **Init**. The driver release function must contain operations for releasing the memory and deleting the controller. The sample code is as follows:
-
- ```
- /* Function for deleting the controller */
- static void SampleI2cRemoveByNode(const struct DeviceResourceNode *node)
- {
- int32_t ret;
- int16_t bus;
- struct I2cCntlr *cntlr = NULL;
- struct SampleI2cCntlr *sampleCntlr = NULL;
- struct DeviceResourceIface *drsOps = NULL;
-
- drsOps = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);
- if (drsOps == NULL || drsOps->GetUint32 == NULL) {
- HDF_LOGE("%s: invalid drs ops fail!", __func__);
- return;
- }
-
- ret = drsOps->GetUint16(node, "bus", (uint16_t *)&bus, 0); // Obtain the I2C bus number from the HCS.
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: read bus fail!", __func__);
- return;
- }
-
- cntlr = I2cCntlrGet(bus);
- if (cntlr != NULL && cntlr->priv == node) { // Delete the controller based on the I2C bus number.
- I2cCntlrPut(cntlr);
- I2cCntlrRemove(cntlr);
- sampleCntlr = (struct SampleI2cCntlr *)cntlr;
- OsalIoUnmap((void *)sampleCntlr->regBase);
- OsalMemFree(sampleCntlr);
- }
- return;
- }
- /* Release resources. */
- static void SampleI2cRelease(struct HdfDeviceObject *device)
- {
- const struct DeviceResourceNode *childNode = NULL;
-
- HDF_LOGI("%s: enter", __func__);
-
- if (device == NULL || device->property == NULL) {
- HDF_LOGE("%s: device or property is NULL", __func__);
- return;
- }
-
- DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) {
- SampleI2cRemoveByNode(childNode); // Delete a controller.
- }
- }
- ```
-
-
diff --git a/en/device-dev/guide/development-example-for-clock-apps.md b/en/device-dev/guide/development-example-for-clock-apps.md
deleted file mode 100644
index d461a0dd393f8283f806ded37aa1b4830e13a56f..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/development-example-for-clock-apps.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Development Example for Clock Apps
-
-- **[Overview](overview-7.md)**
-
-- **[Preparations](preparations-8.md)**
-
-- **[How to Develop](how-to-develop.md)**
-
-- **[Signing and Packaging](signing-and-packaging.md)**
-
-- **[Running on the Device](running-on-the-device-9.md)**
-
-- **[FAQs](faqs-10.md)**
-
-
diff --git a/en/device-dev/guide/development-example-for-peripheral-drivers.md b/en/device-dev/guide/development-example-for-peripheral-drivers.md
deleted file mode 100644
index 4333c26e067bd1ce6981ef3e0a558e5f03578822..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/development-example-for-peripheral-drivers.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Development Example for Peripheral Drivers
-
-- **[Overview](overview-13.md)**
-
-- **[Setting Up the Environment](setting-up-the-environment.md)**
-
-- **[Developing a Touchscreen Driver](developing-a-touchscreen-driver.md)**
-
-- **[Building and Burning](building-and-burning-14.md)**
-
-- **[Debugging and Verification](debugging-and-verification.md)**
-
-- **[Input Driver Model Workflow Analysis](input-driver-model-workflow-analysis.md)**
-
-
diff --git a/en/device-dev/guide/development-example-for-platform-drivers.md b/en/device-dev/guide/development-example-for-platform-drivers.md
deleted file mode 100644
index fbb47fb7d32d8b300c97f77d4f5fff0f1d616501..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/development-example-for-platform-drivers.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Development Example for Platform Drivers
-
-- **[Overview](overview-10.md)**
-
-- **[Preparations](preparations-11.md)**
-
-- **[Development](development-12.md)**
-
-- **[Building and Burning](building-and-burning.md)**
-
-
diff --git a/en/device-dev/guide/development-guidelines-2.md b/en/device-dev/guide/development-guidelines-2.md
deleted file mode 100644
index 6b5c9a629e1720512db8fa5d6f64388b80fb33fa..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/development-guidelines-2.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Development Guidelines
-
-- **[Photographing](photographing-3.md)**
-
-- **[Video Recording](video-recording-4.md)**
-
-- **[Previewing](previewing.md)**
-
-
diff --git a/en/device-dev/guide/development-guidelines.md b/en/device-dev/guide/development-guidelines.md
deleted file mode 100644
index fd34356bfaf087978ff851847b5339180b529037..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/development-guidelines.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Development Guidelines
-
-- **[Photographing](photographing.md)**
-
-- **[Video Recording](video-recording.md)**
-
-
diff --git a/en/device-dev/guide/development.md b/en/device-dev/guide/development.md
deleted file mode 100644
index c02ffef834486c29a0693ab8ad4074b77f52462a..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/development.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# Development
-
-1. Complete the operations described in [Getting Started with Hi3861](../quick-start/hi3861-development-board.md).
-
- LED control examples are stored in the file **applications/sample/wifi-iot/app/iothardware/led\_example.c**.
-
-2. Refer to the schematic diagram to understand the cable connections. The LED of Hispark Pegasus should be connected to pin 9.
-
- ```
- #define LED_TEST_GPIO 9
- ```
-
- > **NOTE:**
- >For details about the schematic diagram of the development board, contact the Hi3861 customer service personnel.
-
-3. Initialize the GPIO pin, specify the pin usage, and create a task to turn on or off the LED periodically so that the LED blinks.
-
- ```
- static void LedExampleEntry(void)
- {
- osThreadAttr_t attr;
-
- /* Initialize the GPIO pin. */
- IoTGpioInit(LED_TEST_GPIO);
- /* Set pin 9 as the output direction. */
- IoTGpioSetDir(LED_TEST_GPIO, IOT_GPIO_DIR_OUT);
-
- attr.name = "LedTask";
- attr.attr_bits = 0U;
- attr.cb_mem = NULL;
- attr.cb_size = 0U;
- attr.stack_mem = NULL;
- attr.stack_size = LED_TASK_STACK_SIZE;
- attr.priority = LED_TASK_PRIO;
-
- /* Start the task. */
- if (osThreadNew((osThreadFunc_t)LedTask, NULL, &attr) == NULL) {
- printf("[LedExample] Failed to create LedTask!\n");
- }
- }
- ```
-
-4. Use a cyclic task in which the LED periodically turns on and off to implement LED blinking.
-
- ```
- static void *LedTask(const char *arg)
- {
- (void)arg;
- while (1) {
- switch (g_ledState) {
- case LED_ON:
- IoTGpioSetOutputVal(LED_TEST_GPIO, 1);
- usleep(LED_INTERVAL_TIME_US);
- break;
- case LED_OFF:
- IoTGpioSetOutputVal(LED_TEST_GPIO, 0);
- usleep(LED_INTERVAL_TIME_US);
- break;
- case LED_SPARK:
- IoTGpioSetOutputVal(LED_TEST_GPIO, 0);
- usleep(LED_INTERVAL_TIME_US);
- IoTGpioSetOutputVal(LED_TEST_GPIO, 1);
- usleep(LED_INTERVAL_TIME_US);
- break;
- default:
- usleep(LED_INTERVAL_TIME_US);
- break;
- }
- }
- return NULL;
- }
- ```
-
-5. Call **SYS\_RUN\(\)** of OpenHarmony to start the service. \(**SYS\_RUN** is defined in the **ohos\_init.h** file.\)
-
- ```
- SYS_RUN(LedExampleEntry);
- ```
-
-6. Change the **applications/sample/wifi-iot/app/BUILD.gn** file to enable **led\_example.c** to participate in compilation.
-
- ```
- import("//build/lite/config/component/lite_component.gni")
- lite_component("app") {
- features = [
- "iothardware:led_example"
- ]
- }
- ```
-
-
diff --git a/en/device-dev/guide/device-camera-control-demo-photoguide.md b/en/device-dev/guide/device-camera-control-demo-photoguide.md
new file mode 100644
index 0000000000000000000000000000000000000000..eda733f15340836efaf5e6d25417821836bc333d
--- /dev/null
+++ b/en/device-dev/guide/device-camera-control-demo-photoguide.md
@@ -0,0 +1,396 @@
+# Photographing
+
+- [When to Use](#en-us_topic_0000001052170554_section1963312376119)
+- [Available APIs](#en-us_topic_0000001052170554_section56549532016)
+- [Limitations and Constraints](#en-us_topic_0000001052170554_section1165911177314)
+- [How to Develop](#en-us_topic_0000001052170554_section138543918214)
+
+## When to Use
+
+Use the camera module APIs to capture frames \(photographing\).
+
+## Available APIs
+
+**Table 1** APIs for photographing
+
+
+
+
+## Limitations and Constraints
+
+None
+
+## How to Develop
+
+1. Extend the **CameraDeviceCallback** class and call **OnCameraStatus** to customize operations when the camera device changes, for example, when a camera becomes available or unavailable.
+
+ ```
+ class SampleCameraDeviceCallback : public CameraDeviceCallback {
+ void OnCameraStatus(std::string cameraId, int32_t status) override
+ {
+ // Do something when camera is available or unavailable.
+ }
+ };
+ ```
+
+2. Extend the **FrameStateCallback** class. After obtaining the frame data, save the data as a file.
+
+ ```
+ static void SampleSaveCapture(const char *p, uint32_t size)
+ {
+ cout << "Start saving picture" << endl;
+ struct timeval tv;
+ gettimeofday(&tv, NULL);
+ struct tm *ltm = localtime(&tv.tv_sec);
+ if (ltm != nullptr) {
+ ostringstream ss("Capture_");
+ ss << "Capture" << ltm->tm_hour << "-" << ltm->tm_min << "-" << ltm->tm_sec << ".jpg";
+
+ ofstream pic("/sdcard/" + ss.str(), ofstream::out | ofstream::trunc);
+ cout << "write " << size << " bytes" << endl;
+ pic.write(p, size);
+ cout << "Saving picture end" << endl;
+ }
+ }
+
+ class TestFrameStateCallback : public FrameStateCallback {
+ void OnFrameFinished(Camera &camera, FrameConfig &fc, FrameResult &result) override
+ {
+ cout << "Receive frame complete inform." << endl;
+ if (fc.GetFrameConfigType() == FRAME_CONFIG_CAPTURE) {
+ cout << "Capture frame received." << endl;
+ list surfaceList = fc.GetSurfaces();
+ for (Surface *surface : surfaceList) {
+ SurfaceBuffer *buffer = surface->AcquireBuffer();
+ if (buffer != nullptr) {
+ char *virtAddr = static_cast(buffer->GetVirAddr());
+ if (virtAddr != nullptr) {
+ SampleSaveCapture(virtAddr, buffer->GetSize());
+ }
+ surface->ReleaseBuffer(buffer);
+ }
+ delete surface;
+ }
+ delete &fc;
+ }
+ }
+ };
+ ```
+
+3. Extend the **CameraStateCallback** class and customize operations when the camera state changes \(configuration successful or failed, and creation successful or failed\).
+
+ ```
+ class SampleCameraStateMng : public CameraStateCallback {
+ public:
+ SampleCameraStateMng() = delete;
+ SampleCameraStateMng(EventHandler &eventHdlr) : eventHdlr_(eventHdlr) {}
+ ~SampleCameraStateMng()
+ {
+ if (recordFd_ != -1) {
+ close(recordFd_);
+ }
+ }
+ void OnCreated(Camera &c) override
+ {
+ cout << "Sample recv OnCreate camera." << endl;
+ auto config = CameraConfig::CreateCameraConfig();
+ config->SetFrameStateCallback(&fsCb_, &eventHdlr_);
+ c.Configure(*config);
+ cam_ = &c;
+ }
+ void OnCreateFailed(const std::string cameraId, int32_t errorCode) override {}
+ void OnReleased(Camera &c) override {}
+ };
+ ```
+
+4. Create a **CameraKit** instance to set and obtain camera information.
+
+ ```
+ CameraKit *camKit = CameraKit::GetInstance();
+ list camList = camKit->GetCameraIds();
+ string camId;
+ for (auto &cam : camList) {
+ cout << "camera name:" << cam << endl;
+ const CameraAbility *ability = camKit->GetCameraAbility(cam);
+ /* Find the camera that fits your ability. */
+ list sizeList = ability->GetSupportedSizes(0);
+ if (find(sizeList.begin(), sizeList.end(), CAM_PIC_1080P) != sizeList.end()) {
+ camId = cam;
+ break;
+ }
+ }
+ ```
+
+5. Create a **Camera** instance.
+
+ ```
+ EventHandler eventHdlr; // Create a thread to handle callback events.
+ SampleCameraStateMng CamStateMng(eventHdlr);
+
+ camKit->CreateCamera(camId, CamStateMng, eventHdlr);
+ ```
+
+6. In the main process, synchronize configurations set by callback functions implemented in [step 1](#en-us_topic_0000001052170554_li378084192111), [step 2](#en-us_topic_0000001052170554_li8716104682913), and [step 3](#en-us_topic_0000001052170554_li6671035102514).
+
+ ```
+ void OnCreated(Camera &c) override
+ {
+ cout << "Sample recv OnCreate camera." << endl;
+ auto config = CameraConfig::CreateCameraConfig();
+ config->SetFrameStateCallback(&fsCb_, &eventHdlr_);
+ c.Configure(*config);
+ cam_ = &c;
+ }
+
+ void Capture()
+ {
+ if (cam_ == nullptr) {
+ cout << "Camera is not ready." << endl;
+ return;
+ }
+ FrameConfig *fc = new FrameConfig(FRAME_CONFIG_CAPTURE);
+ Surface *surface = Surface::CreateSurface();
+ if (surface == nullptr) {
+ delete fc;
+ return;
+ }
+ surface->SetWidthAndHeight(1920, 1080); /* 1920:width,1080:height */
+ fc->AddSurface(*surface);
+ cam_->TriggerSingleCapture(*fc);
+ }
+ ```
+
+
diff --git a/en/device-dev/guide/previewing.md b/en/device-dev/guide/device-camera-control-demo-previewguide.md
similarity index 100%
rename from en/device-dev/guide/previewing.md
rename to en/device-dev/guide/device-camera-control-demo-previewguide.md
diff --git a/en/device-dev/guide/video-recording-4.md b/en/device-dev/guide/device-camera-control-demo-videoguide.md
similarity index 100%
rename from en/device-dev/guide/video-recording-4.md
rename to en/device-dev/guide/device-camera-control-demo-videoguide.md
diff --git a/en/device-dev/guide/device-camera-control-demo.md b/en/device-dev/guide/device-camera-control-demo.md
new file mode 100644
index 0000000000000000000000000000000000000000..48b36ad9d6493fe655779cd63e2c9b8be7c2e1f4
--- /dev/null
+++ b/en/device-dev/guide/device-camera-control-demo.md
@@ -0,0 +1,9 @@
+# Development Guidelines
+
+- **[Photographing](device-camera-control-demo-photoguide.md)**
+
+- **[Video Recording](device-camera-control-demo-videoguide.md)**
+
+- **[Previewing](device-camera-control-demo-previewguide.md)**
+
+
diff --git a/en/device-dev/guide/device-camera-control-example.md b/en/device-dev/guide/device-camera-control-example.md
new file mode 100644
index 0000000000000000000000000000000000000000..9e77598359a5ec1e410e39d9354f0d541ac367fb
--- /dev/null
+++ b/en/device-dev/guide/device-camera-control-example.md
@@ -0,0 +1,64 @@
+# Use Case
+
+This use case takes **camera\_sample** \(contained in the source code\) as an example for photographing, recording, and previewing on the development board.
+
+- You can obtain source code of the sample from **applications/sample/camera/media/camera\_sample.cpp**.
+- Before running the sample camera, you need to compile, burn, and run the image. For details, see [Hi3516 Development Board](../quick-start/quickstart-lite-introduction-hi3516.md#section26131214194212).
+
+ > **NOTE:**
+ >After the development board is started, the home screen is loaded and displayed above the media layer by default. To prevent covering **camera\_sample**, you should remove the home screen during compilation or packaging.
+ >How to Remove: In **build/lite/components/applications.json**, comment out or delete the **//applications/sample/camera/launcher:launcher\_hap** line from the **target** field of **camera\_sample\_app**.
+
+- The compilation result of the sample code is stored in **out/hi3516dv300/ipcamera\_hi3516dv300\_liteos/dev\_tools/bin**. To ensure that the code can be executed on the development board, you can copy the file to a TF card through a card reader, or modify the compilation script of **camera\_sample** to copy the compilation result to **rootfs.img**.
+
+ Modify the first **output\_dir** in the source code path **applications/sample/camera/media/BUILD.gn**.
+
+ - Before: **output\_dir = "$root\_out\_dir/dev\_ools"**
+ - After: **output\_dir = "$root\_out\_dir/"**
+
+ Recompile the source code repository and burn the code into the development board. Then you can find the **camera\_sample** file in the **bin** directory of the board.
+
+ > **NOTICE:**
+ >You should insert a TF card \(up to 128 GB supported\) for photographing and video recording before system startup. This way, the TF card will be automatically mounted to the **/sdcard** directory. If you insert the TF card after the system is started, you have to manually mount the TF card.
+ >To view the photos and videos in the TF card, copy them to a computer. If you just want to preview photos and videos, you do not need to insert a TF card.
+
+- Perform the following steps to run the sample:
+
+1. Run the **cd** command to go to the end path of the executable program and start **camera\_sample** by running the command in the following figure.
+
+ **Figure 1** Starting camera\_sample
+ 
+
+ The control commands are displayed as shown in the preceding figure. Press **S** to stop the current operation \(including video recording and preview\), and press **Q** to exit the program.
+
+2. Press **1** to take a photo in JPG format. The photo is saved in the **/sdcard** directory and named **Capture\***.
+
+ **Figure 2** Serial port logs displayed after the photographing command is executed
+ 
+
+ To view the saved file, exit the program and enter the file system. To start the program again, return to the previous step.
+
+ **Figure 3** Saved files
+ 
+
+3. Press **2** to start recording. The video file is in MP4 format and saved in the **/sdcard** directory with the name **Record\***. Press **S** to stop recording.
+
+ **Figure 4** Serial port logs displayed after the recording command is executed
+ 
+
+4. Press **3** to start preview. The preview is displayed on the screen. Press **S** to stop preview.
+
+ **Figure 5** Serial port logs displayed after the preview command is executed
+ 
+
+ The following figure shows the preview.
+
+ **Figure 6** Preview effect
+ 
+
+5. Press **Q** to exit.
+
+ **Figure 7** Serial port logs displayed after the exit command is executed
+ 
+
+
diff --git a/en/device-dev/guide/device-camera-control-overview.md b/en/device-dev/guide/device-camera-control-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..61f5aa13eb0b6a3e4cdf4362bd5355846f7f4135
--- /dev/null
+++ b/en/device-dev/guide/device-camera-control-overview.md
@@ -0,0 +1,10 @@
+# Overview
+
+This document describes how to use the IoT camera development board \(Hi3516D V300\) and its camera and screen to implement photographing, video recording, and video preview.
+
+This document helps you take a deep dive into OpenHarmony camera control. With this reference, you can develop devices, such as peephole cameras, smart rear-view mirrors, and smart displays.
+
+If you want to view the running effect first, see [Use Case](device-camera-control-example.md). To customize application behavior, modify the sample code by referring to APIs described in the "Development Guidelines" section.
+
+For basic concepts of camera development, see [Camera Development Overview](../subsystems/subsys-multimedia-camera-overview.md).
+
diff --git a/en/device-dev/guide/device-camera-control.md b/en/device-dev/guide/device-camera-control.md
new file mode 100644
index 0000000000000000000000000000000000000000..062b965f7a68b9f00b602b2dfb8fe3b1cbacfbc1
--- /dev/null
+++ b/en/device-dev/guide/device-camera-control.md
@@ -0,0 +1,9 @@
+# Screen and Camera Control
+
+- **[Overview](device-camera-control-overview.md)**
+
+- **[Development Guidelines](device-camera-control-demo.md)**
+
+- **[Use Case](device-camera-control-example.md)**
+
+
diff --git a/en/device-dev/guide/device-camera-visual-addpage.md b/en/device-dev/guide/device-camera-visual-addpage.md
new file mode 100644
index 0000000000000000000000000000000000000000..2315fb68c61761574e12018baebf214b3006792a
--- /dev/null
+++ b/en/device-dev/guide/device-camera-visual-addpage.md
@@ -0,0 +1,34 @@
+# Adding Pages
+
+- [Creating the Home Page](#section16935511143715)
+- [Creating the Details Page](#section122131729173819)
+
+## Creating the Home Page
+
+Upon creation of the project, the **index** page is automatically generated, which is the home page of AirQuality. [Figure 1](#fig16545205773718) shows the project directory.
+
+**Figure 1** Project directory
+
+
+## Creating the Details Page
+
+To the details page, perform the following steps:
+
+1. Right-click **pages** and choose **New** \> **JS Page** from the shortcut menu.
+
+ **Figure 2** Adding a page
+ 
+
+2. Enter the page name.
+
+ **Figure 3** Entering the page name
+ 
+
+3. Confirm the creation.
+
+ The following figure shows the application project directory after the **detail** page is created. It contains a **.hml** layout file, a **.css** file, and a **.js** file \(containing service logic code\).
+
+ **Figure 4** Complete project directory
+ 
+
+
diff --git a/en/device-dev/guide/device-camera-visual-debug.md b/en/device-dev/guide/device-camera-visual-debug.md
new file mode 100644
index 0000000000000000000000000000000000000000..2d4c192fb9c4948b510b6f0ad85d9e50f0a50a03
--- /dev/null
+++ b/en/device-dev/guide/device-camera-visual-debug.md
@@ -0,0 +1,4 @@
+# Debugging and Packaging
+
+After the code is compiled, debug your application and package it into an App Pack. For details about how to debug and package an application, see [Debugging Your App](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ide_debug_device-0000001053822404) and [Building Your App](https://developer.harmonyos.com/en/docs/documentation/doc-guides/build_overview-0000001055075201) in the [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387). Currently, IPCamera applications do not support signature. You should release an unsigned App Pack.
+
diff --git a/en/device-dev/guide/device-camera-visual-details.md b/en/device-dev/guide/device-camera-visual-details.md
new file mode 100644
index 0000000000000000000000000000000000000000..60bd585e6dd6d90cbfe47c6e68cc7a7b5dc85dee
--- /dev/null
+++ b/en/device-dev/guide/device-camera-visual-details.md
@@ -0,0 +1,396 @@
+# Building the Details Page
+
+- [detail.hml](#section275215487291)
+- [detail.css](#section2589154215301)
+- [detail.js](#section163410883117)
+
+The **detail** page displays the air quality data of a week in a chart. There are two parts on the page: title bar and chart bar. Considering the display effect of the chart bar, use multiple **** components instead of one **** component.
+
+Add a root ****, set the **flex-direction** attribute to **column** to arrange the two bars vertically. The sample code is as follows:
+
+```
+
+
+
+
+ History
+
+
+
+
+
+```
+
+In the preceding example, **onclick="backMain"** indicates that the application returns to the home page when the click event is triggered. The sample code for **detail.js** is as follows:
+
+```
+import router from '@system.router'
+
+export default {
+ backMain() {
+ router.replace({
+ // Home page URL
+ uri: 'pages/index/index',
+ params: {
+ // Parameters to pass to the home page
+ selectedCityIndex: this.selectedCityIndex
+ }
+ });
+ }
+}
+```
+
+Add **** components to the **** component to form a chart.
+
+The complete sample code in the three files is as follows.
+
+## detail.hml
+
+```
+
+```
+
+## detail.css
+
+```
+.location {
+ text-align: center;
+ color: #ffffff;
+ width: 960px;
+ height: 52px;
+ font-size: 40px;
+}
+.container {
+ height: 480px;
+ width: 960px;
+ flex-direction: column;
+}
+
+.header {
+ width: 960px;
+ height: 72px;
+}
+
+.back {
+ width: 36px;
+ height: 36px;
+ margin-left: 39px;
+ margin-top: 23px;
+}
+
+.title {
+ width: 296px;
+ height: 40px;
+ margin-top: 20px;
+ margin-left: 21px;
+ color: #e6e6e6;
+}
+
+.chart-list {
+ width: 960px;
+ height: 408px;
+}
+
+.list-item-title {
+ width: 960px;
+ height: 52px;
+}
+
+.list-item-chart {
+ width: 960px;
+ height: 280px;
+}
+
+.chart-wrapper {
+ width: 308px;
+ height: 256px;
+ flex-direction: column;
+}
+
+.gas-name {
+ width: 308px;
+ height: 35px;
+ text-align: left;
+}
+
+.chart {
+ width: 308px;
+ height: 155px;
+ margin-top: 10px;
+ justify-content: flex-start;
+ align-items: flex-end;
+}
+
+.chart-item {
+ width: 24px;
+ margin-left: 18px;
+ border-radius: 3px;
+}
+
+.white-line {
+ width: 308px;
+ height: 2px;
+ background-color: #ffffff;
+ margin-top: 22px;
+}
+
+.week {
+ width: 308px;
+ height: 17px;
+ margin-top: 6px;
+ border-color: #ffffff;
+ border-radius: 2px;
+ margin-top: 6px;
+}
+
+.day {
+ width: 26px;
+ height: 17px;
+ font-size: 10px;
+ margin-left: 16px;
+ text-align: center;
+}
+```
+
+## detail.js
+
+```
+import router from '@system.router'
+
+export default {
+ data: {
+ location: ''
+ },
+ onInit() {
+ if (this.selectedCityIndex === 0) {
+ this.location = 'Dongguan';
+ } else {
+ this.location = 'Shenzhen';
+ }
+ },
+ backMain() {
+ router.replace({
+ uri: 'pages/index/index',
+ params: {
+ selectedCityIndex: this.selectedCityIndex
+ }
+ });
+ }
+}
+```
+
diff --git a/en/device-dev/guide/faqs.md b/en/device-dev/guide/device-camera-visual-faqs.md
similarity index 100%
rename from en/device-dev/guide/faqs.md
rename to en/device-dev/guide/device-camera-visual-faqs.md
diff --git a/en/device-dev/guide/device-camera-visual-first-page.md b/en/device-dev/guide/device-camera-visual-first-page.md
new file mode 100644
index 0000000000000000000000000000000000000000..5fe705f70f0dee725e2d4f485e7cf8652497b3b9
--- /dev/null
+++ b/en/device-dev/guide/device-camera-visual-first-page.md
@@ -0,0 +1,581 @@
+# Building the Home Page
+
+The application home page displays air quality information of different cities. The home page provides two screens \(for two information bars\), which can be added as required. Each screen displays the air quality information of one city, including the Air Quality Index \(AQI\), city name, pollution level, update time, and data source.
+
+The home page of AirQuality consists of three parts:
+
+- Title bar: displays the page title and provides an exit button. The title bar is fixed at the top of the page.
+- Information bar: displays air quality information. Multiple information bars can be added based on user requirements and support looping scroll.
+- Indicator bar: shows the position of the current screen among all screens. The indicator bar is fixed at the bottom of the page.
+
+The following steps describe how to build the home page with a flexible layout that has three rows vertically arranged.
+
+1. Add a root **** to the **.hml** file. Note that each **.hml** file can contain only one root component. The sample code is as follows:
+
+ ```
+
+
+ ```
+
+ **class="container"** indicates the style used by the component. The **container** is a style class defined in the **index.css** file.
+
+ ```
+ .container {
+ flex-direction: column;
+ height: 480px;
+ width: 960px;
+ }
+ ```
+
+ The height and width of the root component **** are set in the style class. Note that the height and width must be explicitly specified \(except for some components, such as ****\). Otherwise, the component may fail to display. In the **container** style class, the **flex-direction** attribute is set to **column**, which means that child components of **** are vertically arranged from top to bottom for implementing the flexible page layout.
+
+2. Add the title bar. The title bar consists of an exit button and title text that are horizontally arranged. Add a **** to hold the title bar and set the **flex-direction** attribute to **row** to arrange the child components from left to right. Add an **** and a **** component in sequence. The sample code is as follows:
+
+ ```
+
+
+
+
+ Air quality
+
+
+
+ ```
+
+ Set component attributes, including the height, width, margin, and color.
+
+ ```
+ .header {
+ width: 960px;
+ height: 72px;
+ }
+ .back {
+ width: 36px;
+ height: 36px;
+ margin-left: 39px;
+ margin-top: 23px;
+ }
+ .title {
+ width: 296px;
+ height: 40px;
+ margin-top: 20px;
+ margin-left: 21px;
+ color: #e6e6e6;
+ }
+ ```
+
+ In the **.hml** file, **onclick="exitApp"** sets the click event for the **** component. When the click event is triggered, the **exitApp\(\)** function is executed. The example definition of **exitApp\(\)** in **index.js** is as follows:
+
+ ```
+ exitApp() {
+ console.log('start exit');
+ app.terminate();
+ console.log('end exit');
+ }
+ ```
+
+ The **app.terminate\(\)** function is used to exit the program. Before using this function, you must import the **app** module by adding the following code at the beginning of **index.js**:
+
+ ```
+ import app from '@system.app'
+ ```
+
+ After the code is compiled, run the project on the simulator. The following figure shows the display effect.
+
+ **Figure 1** Title bar
+ 
+
+3. The **** component is required to implement the switching between screens.
+
+ Add a **** to the root node.
+
+ ```
+
+
+
+
+ Air quality
+
+
+
+
+
+ ```
+
+ - Use **class="**swiper**"** to set the height and width of the component. The sample code is as follows:
+
+ ```
+ .swiper {
+ height: 385px;
+ width: 960px;
+ }
+ ```
+
+
+ - **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:
+
+ ```
+ // Import the router module for page switching.
+ import router from'@system.router'
+ import app from '@system.app'
+
+ export default {
+ // Define parameters.
+ data: {
+ // By default, the first page is displayed.
+ swiperPage: 0
+ },
+ onInit () {
+ },
+ exitApp(){
+ console.log('start exit');
+ app.terminate();
+ console.log('end exit');
+ },
+ // Swiping event, which saves the index value of the current . The index value is saved to the swiperPage variable each time a swiping occurs.
+ swiperChange (e) {
+ this.swiperPage = e.index;
+ }
+ }
+ ```
+
+
+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:
+
+ ```
+
+
+
+ ------Air quality
+ ------City name
+ -----Progress bar
+ -------A cloud image
+ --------AQI value
+ AQI------AQI
+
--------AQI details
+
+
--------Update time, website, and other information
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ```
+
+ After the code is compiled, the display effect on the simulator is as follows.
+
+ **Figure 2** Title bar and information bar
+ 
+
+5. Add the indicator bar. Currently, the **** component does not support indicator settings. You need to implement a dots indicator by adding **** components and setting the style. Add a **** as a child component to the root node and set the style. Add two **** to the parent ****, set **border-radius** for the two child ****, and dynamically change the background colors of the **** components in the swiping event.
+
+ ```
+
+
+
+
+ ```
+
+ **Figure 3** Indicator bar
+ 
+
+6. Set the style, animation effect, and dynamic data binding for all components. The complete sample code is as follows:
+
+ - **index.hml**
+
+ ```
+
+ ```
+
+ - **index.css**
+
+ A **.css** file contains many classes. Each class defines the position, size, font, color, and background color of a component. Each child component is added to its parent component, and the style file of the parent component affects how the child component will be displayed.
+
+ ```
+ .aqi-value {
+ text-align: center;
+ font-size: 65px;
+ color: #f0ffff;
+ width: 156px;
+ height: 92px;
+ top: 134px;
+ left: 210px;
+ }
+ .aqi {
+ text-align: center;
+ color: #a2c4a2;
+ width: 156px;
+ height: 45px;
+ top: 90px;
+ left: 210px;
+ }
+ .airquality {
+ top: 222px;
+ text-align: center;
+ width: 156px;
+ height: 45px;
+ left: 210px;
+ }
+ .image {
+ top: 285px;
+ left: 274px;
+ width: 32px;
+ height: 32px;
+ }
+ .location-text {
+ text-align: center;
+ color: #ffffff;
+ width: 200px;
+ height: 52px;
+ font-size: 40px;
+ left: 380px;
+ top: 16px;
+ }
+ .container {
+ flex-direction: column;
+ height: 480px;
+ width: 960px;
+ }
+ .circle-progress {
+ center-x: 128px;
+ center-y: 128px;
+ radius: 128px;
+ startAngle: 198;
+ totalAngle: 320;
+ strokeWidth: 24px;
+ width: 256px;
+ height: 256px;
+ left: 160px;
+ top: 58px;
+ }
+ .detail {
+ width: 256px;
+ height: 265px;
+ left: 544px;
+ top: 58px;
+ flex-direction: column;
+ }
+ .text-wrapper {
+ width: 256px;
+ height: 35px;
+ margin-top: 6px;
+ }
+ .gas-name {
+ width: 128px;
+ height: 35px;
+ text-align: left;
+ }
+ .gas-value {
+ width: 128px;
+ height: 35px;
+ text-align: right;
+ }
+ .btn {
+ width: 180px;
+ height: 50px;
+ margin-top: 6px;
+ margin-left: 38px;
+ background-color: #1a1a1a;
+ color: #1085CE;
+ }
+ .footer {
+ top: 326px;
+ width: 960px;
+ height: 28px;
+ }
+ .header {
+ width: 960px;
+ height: 72px;
+ }
+ .back {
+ width: 36px;
+ height: 36px;
+ margin-left: 39px;
+ margin-top: 23px;
+ }
+ .title {
+ width: 296px;
+ height: 40px;
+ margin-top: 20px;
+ margin-left: 21px;
+ color: #e6e6e6;
+ }
+ .swiper {
+ height: 385px;
+ width: 960px;
+ }
+ .images {
+ width: 60px;
+ height: 15px;
+ margin-left: 450px;
+ }
+ .update-time {
+ width: 480px;
+ height: 28px;
+ font-size: 20px;
+ color: #A9A9A9;
+ text-align: right;
+ }
+ .info-source {
+ width: 450px;
+ height: 28px;
+ font-size: 20px;
+ color: #A9A9A9;
+ text-align: left;
+ margin-left: 24px;
+ }
+ .circle-div {
+ width: 12px;
+ height: 12px;
+ border-radius: 6px;
+ }
+ ```
+
+ - **index.js**
+
+ A **.js** file is used to implement interaction logic of your application. In the **.js** file of the home page, implement page switching and enable text content and progress bar color to change dynamically according to AQI values.
+
+ ```
+ // Import router and app modules.
+ import router from '@system.router'
+ import app from '@system.app'
+
+ export default {
+ data: {
+ // Bind data.
+ textColor1: '#00ff00',
+ textColor2: '#00ff00',
+ bgColor1: '#669966',
+ bgColor2: '#669966',
+ swiperPage: 0,
+ percent1: 40,
+ percent2: 90,
+ iconUncheckedColor: '#262626',
+ iconcheckedColor: '#ffffff',
+ iconcheckedBR: '6px',
+ src1: 'common/cloud_green.png',
+ src2: 'common/cloud_green.png',
+ airData: [{
+ location: 'Dongguan',
+ airQuality: 'Good',
+ detailData: 40
+ }, {
+ location: 'Shenzhen',
+ airQuality: 'Polluted',
+ detailData: 90
+ }]
+ },
+ onInit () {
+ // Set the font, background color, and background image for different value ranges.
+ if(this.airData[0].detailData > 100){
+ this.src1 = 'common/cloud_red.png';
+ this.textColor1 = '#ff0000';
+ this.bgColor1 = '#9d7462';
+ } else if(50 < this.airData[0].detailData && this.airData[0].detailData <= 100){
+ this.src1 = 'common/cloud_yellow.png';
+ this.textColor1 = '#ecf19a';
+ this.bgColor1 = '#9d9d62';
+ }
+ if(this.airData[1].detailData > 100){
+ this.src2 = 'common/cloud_red.png';
+ this.textColor2 = '#ff0000';
+ this.bgColor2 = '#9d7462';
+ } else if(50 < this.airData[1].detailData && this.airData[1].detailData <= 100){
+ this.src2 = 'common/cloud_yellow.png';
+ this.textColor2 = '#ecf19a';
+ this.bgColor2 = '#9d9d62';
+ }
+ if(this.selectedCityIndex){
+ this.swiperPage = this.selectedCityIndex;
+ if(this.swiperPage == 0){
+ this.iconcheckedColor = '#ffffff';
+ this.iconUncheckedColor = '#262626';
+ }else{
+ this.iconcheckedColor = '#262626';
+ this.iconUncheckedColor = '#ffffff';
+ }
+ }
+ },
+ // Switch to the details page.
+ openDetail () {
+ router.replace({
+ uri: 'pages/detail/detail',
+ params: {selectedCityIndex:this.swiperPage}
+ });
+ },
+ // Exit the application.
+ exitApp(){
+ console.log('start exit');
+ app.terminate();
+ console.log('end exit');
+ },
+ // Define the swiping event. Change the indicator dots when the user swipes the screen.
+ swiperChange (e) {
+ this.swiperPage = e.index;
+ if(e.index == 0){
+ this.iconcheckedColor = '#ffffff';
+ this.iconUncheckedColor = '#262626';
+ }else{
+ this.iconcheckedColor = '#262626';
+ this.iconUncheckedColor = '#ffffff';
+ }
+ }
+ }
+ ```
+
+
diff --git a/en/device-dev/guide/device-camera-visual-overview.md b/en/device-dev/guide/device-camera-visual-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..bf44297f7f42964b9883c939893a07bbbfe94a18
--- /dev/null
+++ b/en/device-dev/guide/device-camera-visual-overview.md
@@ -0,0 +1,15 @@
+# Overview
+
+- [Display Effects](#section3997224182313)
+
+This document describes how to quickly set up an application development environment \(using the Hi3516D V300 development board\) for event data recorders running on OpenHarmony. An air quality monitoring application, AirQuality, is used as an example to describe how to create, develop, and debug your application.
+
+## Display Effects
+
+AirQuality displays information about the urban air quality on two pages, the home page and details page. The following GIF shows AirQuality on the DevEco Studio simulator.
+
+**Figure 1** Display effects of the AirQuality
+
+
+
+
diff --git a/en/device-dev/guide/device-camera-visual-prepare.md b/en/device-dev/guide/device-camera-visual-prepare.md
new file mode 100644
index 0000000000000000000000000000000000000000..52beaf139d6ebb7fbe8460cc8bb01fea5b1aa78c
--- /dev/null
+++ b/en/device-dev/guide/device-camera-visual-prepare.md
@@ -0,0 +1,27 @@
+# Preparations
+
+- [Setting Up the Development Environment](#section1912530122716)
+- [Creating a Project](#section1456035192720)
+
+## Setting Up the Development Environment
+
+Download and install DevEco Studio. For details, see the [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/software_install-0000001053582415).
+
+## Creating a Project
+
+1. Open the project wizard using either of the following methods:
+ - If no project is open, select **Create HarmonyOS Project** on the welcome page.
+ - If a project is already open, go to **File** \> **New** \> **New Project** on the menu bar.
+
+2. Choose the **Smart Vision** for **Device** and **Empty Feature Ability** for **Template**.
+
+ 
+
+3. Click **Next** and configure the project.
+ - **Project Name**: project name.
+ - **Package Name**: software package name. By default, this name will also be used as your application ID. Your application must have a unique ID to be released.
+ - **Save Location**: path for storing project files. The path cannot contain Chinese characters or spaces.
+ - **Compatible API Version**: compatible API version.
+
+4. Click **Finish**. DevEco Studio will automatically generate the sample code and resources that match your project type. Wait until the project is created.
+
diff --git a/en/device-dev/guide/device-camera-visual-run.md b/en/device-dev/guide/device-camera-visual-run.md
new file mode 100644
index 0000000000000000000000000000000000000000..3668d68d278d34f1aae9f34c0fcda9ca1157269d
--- /dev/null
+++ b/en/device-dev/guide/device-camera-visual-run.md
@@ -0,0 +1,29 @@
+# Running on the Device
+
+Before you install the application 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 compile, burn, and run an image, see the [Hi3516 Development Board](../quick-start/quickstart-lite-introduction-hi3516.md#section26131214194212). After the image is running normally and the system is started properly, perform the following steps to install or uninstall the application:
+
+1. Store the compiled unsigned application installation package and installation tool in an SD card and insert the SD card into the development board slot. The installation tool is in **dev\_tools** of the directory where the image file is generated.
+2. Run the following command to disable signature verification, which is enabled by default for application installation:
+
+ ```
+ ./sdcard/dev_tools/bin/bm set -s disable
+ ```
+
+3. Run the following command to install the application:
+
+ ```
+ ./sdcard/dev_tools/bin/bm install -p /sdcard/airquality.hap
+ ```
+
+ The **dev\_tools** directory stores the installation tool, and **airquality.hap** is the application installation package. Replace it with actual the package name.
+
+4. After the application is installed, touch the application icon on the home screen to enter the application.
+
+ **Figure 1** Home screen
+ 
+
+5. \(Optional\) Uninstall the application.
+
+ Touch and hold the application icon on the home screen, and touch the uninstall button in the displayed menu.
+
+
diff --git a/en/device-dev/guide/device-camera-visual.md b/en/device-dev/guide/device-camera-visual.md
new file mode 100644
index 0000000000000000000000000000000000000000..183a3c5758f90bb42becc05c09e74379f53a9c28
--- /dev/null
+++ b/en/device-dev/guide/device-camera-visual.md
@@ -0,0 +1,19 @@
+# Visual Application Development
+
+- **[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 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)**
+
+
diff --git a/en/device-dev/guide/device-camera.md b/en/device-dev/guide/device-camera.md
new file mode 100644
index 0000000000000000000000000000000000000000..3fab60c51ec77fb4f023d1337edc3327aa29dbc0
--- /dev/null
+++ b/en/device-dev/guide/device-camera.md
@@ -0,0 +1,7 @@
+# Cameras with a Screen
+
+- **[Screen and Camera Control](device-camera-control.md)**
+
+- **[Visual Application Development](device-camera-visual.md)**
+
+
diff --git a/en/device-dev/guide/device-drive-demo.md b/en/device-dev/guide/device-drive-demo.md
new file mode 100644
index 0000000000000000000000000000000000000000..7abded8c938797c7c3992528bc3f5a07600d4cb3
--- /dev/null
+++ b/en/device-dev/guide/device-drive-demo.md
@@ -0,0 +1,453 @@
+# Development Example for Platform Drivers
+
+- [Overview](#section194201316174215)
+- [Preparations](#section6926133918422)
+- [Development](#section65801539470)
+ - [File Description](#section0708184454414)
+ - [Instantiating the Driver Entry](#section85325864412)
+ - [Setting Related Parameters](#section8155172019453)
+ - [Adding a Controller](#section1335374114452)
+
+- [Building Source Code and Burning Images](#section164824754712)
+
+## Overview
+
+This document uses the I2C driver as an example to describe how to develop platform drivers based on the hardware driver foundation \(HDF\).
+
+> **CAUTION:**
+>The sample code in this document is for reference only and cannot be directly used for commercial integration.
+
+The HDF provides a standard driver framework for common peripherals. To use the APIs provided by the HDF to perform operations on peripherals, you only need to adapt the specific driver to the HDF.
+
+In this example, an I2C driver is used. [Figure 1](#fig148041484161) shows the sequence diagram of the I2C driver.
+
+**Figure 1** I2C driver sequence diagram
+
+
+
+
+- User Business: business-triggered driver
+- i2cManagerEntry: entry to the I2C manager, which is used to register the I2C manager with the HDF
+- I2cManager: I2C manager, which manages the I2C controller
+- I2cCntlr: I2C controller
+- i2cDriverEntry: entry to the I2C controller, which is used to register the I2C controller with the HDF
+
+## Preparations
+
+Follow the instructions in [Environment Setup for Standard System](../quick-start/quickstart-standard.md).
+
+> **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.
+
+## Development
+
+### File Description
+
+The following table lists the files involved in this example and their paths.
+
+**Table 1** File description
+
+
+
+
+> **CAUTION:**
+>The file paths involved in this example are used for demonstration only. Determine the paths for storing the source files as required when developing your driver.
+
+### Instantiating the Driver Entry
+
+Instantiate an **HdfDriverEntry** object as the driver entry. The driver entry must be a global variable of the **HdfDriverEntry** type \(which is defined in **hdf\_device\_desc.h**\), and the value of **moduleName** must be the same as that in **device\_info.hcs**. When loading the driver, the HDF calls the **Bind** function first and then the **Init** function. If an error occurred during the calling of the **Init** function, the HDF calls **Release** to release the driver resource and exit.
+
+The **Bind** function is not implemented in the I2C driver because the I2C controller is managed by the I2C manager and the **Bind** function has been implemented in the manager. Therefore, services do not need to be bound in the I2C driver.
+
+The sample code for instantiating the driver entry is as follows:
+
+```
+/* Define a driver entry object. It must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h). */
+struct HdfDriverEntry g_sampleI2cDriverEntry = {
+ .moduleVersion = 1,
+ .Init = SampleI2cInit,
+ .Release = SampleI2cRelease,
+ .moduleName = "demo_i2c_driver",
+};
+/* Call HDF_INIT to register the driver entry with the HDF. */
+HDF_INIT(g_sampleI2cDriverEntry);
+```
+
+### Setting Related Parameters
+
+Configure the **device\_info.hcs** file and obtain and parse device configuration parameters from the HCS to ensure that the driver can be correctly loaded.
+
+1. \(Mandatory\) Add a device service node.
+
+ Edit the **device\_info.hcs** file and add a driver device service node under **device\_i2c :: device**. The following is an example:
+
+ ```
+ root {
+ device_info {
+ match_attr = "hdf_manager";
+ device_i2c :: device { // I2C devices
+ device2 :: deviceNode { // Device node of an I2C driver
+ policy = 0; // Policy for releasing the driver service
+ priority = 55; // Driver startup priority
+ permission = 0644; // Permission for the driver to create a device node
+ moduleName = "demo_i2c_driver"; // Driver name. The value of this field must be the same as that of moduleName in the driver entry data structure.
+ serviceName = "DEMO_I2C_DRIVER"; // Name of the service released by the driver. The name must be unique.
+ deviceMatchAttr = "demo_i2c_config"; // Keyword matching the private data of the driver. The value must be the same as that of
+ // match_attr in the private configuration data table of the driver.
+ }
+ }
+ }
+ }
+
+ ```
+
+ > **NOTICE:**
+ >The **priority** attribute \(an integer ranging from 0 to 200\) in the configuration file indicates the priority of a host or drivers. Drivers in a host with a smaller priority value have a higher loading priority than those in other hosts. The driver with a smaller priority value in a host has a higher loading priority than the other drivers in the host. The loading sequence is random for drivers with the same priority.
+
+2. \(Optional\) Add configuration parameters.
+
+ The driver may require private configuration information to ensure that the register configuration meets the requirements of different products. If private configuration data is required, you can add a driver configuration file to store some default configuration information about the driver. When loading the driver, the HDF obtains the specified configuration information, saves it in the **property** attribute of **HdfDeviceObject**, and passes it to the driver via **Bind** and **Init**. For details about how to use **Bind** and **Init**, see [Driver Development](../driver/drive-hdf-development.md). You can create a configuration file and reference it in the **hdf.hcs** file of the board-level driver. In this example, configuration parameters are directly added to the existing configuration file **i2c\_config.hcs**.
+
+ The following configuration parameters are added to the **i2c\_config.hcs** file:
+
+ ```
+ root {
+ platform {
+ i2c_config_demo {
+ match_attr = "demo_i2c_config"; // The value of this field must be the same as that of deviceMatchAttr in device_info.hcs.
+
+ template i2c_controller { // Parameter template
+ bus = 0;
+ reg_pbase = 0x120b0000;
+ reg_size = 0xd1;
+ }
+
+ controller_demo_0 :: i2c_controller { // Two sample I2C controllers
+ bus = 8;
+ }
+ controller_demo_1 :: i2c_controller {
+ bus = 9;
+ }
+ }
+ }
+ }
+ ```
+
+ The value of **match\_attr** must be the same as that of **deviceMatch\_Attr** in the **device\_info.hcs** file. The **match\_attr** attribute is used to match the configured parameters in the configuration file \(**i2c\_config.hcs** in this example\) with the particular driver, so that the driver can call **DeviceResourceGetIfaceInstance\(\)** in the **Bind** or **Init** function to obtain these configuration parameters.
+
+ If you create a new configuration file to set parameters, reference this file in the board-level configuration entry file **hdf.hcs**. For example:
+
+ ```
+ #include "device_info/device_info.hcs"
+ #include "i2c/i2c_config.hcs"
+ ```
+
+ In this development example, we use an existing configuration file **i2c\_config.hcs** to add parameters, and therefore do not need to add it to the board-level configuration entry file.
+
+3. Enable the driver to obtain configuration parameters from the HCS.
+
+ In this example, the driver needs to obtain configuration parameters, such as the physical base address of the register, register size, and bus number, from the HCS to correctly configure the controller.
+
+ ```
+ /* Obtain configuration parameters from the HCS. */
+ static int32_t SampleI2cReadDrs(struct SampleI2cCntlr *sampleCntlr, const struct DeviceResourceNode *node)
+ {
+ int32_t ret;
+ struct DeviceResourceIface *drsOps = NULL;
+
+ drsOps = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);
+ if (drsOps == NULL || drsOps->GetUint32 == NULL) { // Ensure that the GetUint32 function is available.
+ HDF_LOGE("%s: invalid drs ops fail!", __func__);
+ return HDF_FAILURE;
+ }
+
+ ret = drsOps->GetUint32(node, "reg_pbase", &sampleCntlr->regBasePhy, 0); // Read the physical base address from the HCS.
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: read regBase fail!", __func__);
+ return ret;
+ }
+
+ ret = drsOps->GetUint16(node, "reg_size", &sampleCntlr->regSize, 0); // Read the register size from the HCS.
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: read regsize fail!", __func__);
+ return ret;
+ }
+
+ ret = drsOps->GetUint16(node, "bus", (uint16_t *)&sampleCntlr->bus, 0); // Read the bus number from the HCS.
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: read bus fail!", __func__);
+ return ret;
+ }
+
+ return HDF_SUCCESS;
+ }
+ ```
+
+
+### Adding a Controller
+
+Initialize the controller hardware, call core-layer APIs to add or delete devices to or from the core layer, and implement a hook.
+
+1. Define an I2C controller structure, implement a hook, and assign the hook to the function pointer.
+
+ The **I2cMethod** structure is defined in the **i2c\_core.h** header file. This structure defines the functions to be implemented by the I2C driver by using function pointers. The **SampleI2cTransfer** function is a hook used for data transmission, which must be implemented in the driver and must be assigned to a function pointer.
+
+ The sample code is as follows:
+
+ ```
+ /* Custom device structure, which is inherited from I2cCntlr */
+ struct SampleI2cCntlr {
+ struct I2cCntlr cntlr;
+ OsalSpinlock spin;
+ volatile unsigned char *regBase;
+ uint16_t regSize;
+ int16_t bus;
+ uint32_t regBasePhy;
+ };
+
+ /* Message structure, which is inherited from I2cMsg */
+ struct SampleTransferData {
+ struct I2cMsg *msgs;
+ int16_t index;
+ int16_t count;
+ };
+ /* Hook implementation */
+ static int32_t SampleI2cTransfer(struct I2cCntlr *cntlr, struct I2cMsg *msgs, int16_t count)
+ {
+ int32_t ret = HDF_SUCCESS;
+ struct SampleI2cCntlr *sampleCntlr = NULL;
+ struct SampleTransferData td;
+
+ if (cntlr == NULL || cntlr->priv == NULL) {
+ HDF_LOGE("SampleI2cTransfer: cntlr lor sampleCntlr is null!");
+ return HDF_ERR_INVALID_OBJECT;
+ }
+ sampleCntlr = (struct SampleI2cCntlr *)cntlr;
+
+ if (msgs == NULL || count <= 0) {
+ HDF_LOGE("SampleI2cTransfer: err parms! count:%d", count);
+ return HDF_ERR_INVALID_PARAM;
+ }
+ td.msgs = msgs;
+ td.count = count;
+ td.index = 0;
+
+ HDF_LOGE("Successfully transmitted!"); // Data transmission is successful.
+
+ td.index = count; // The total number of sent messages is returned. The message handling process is not provided in this sample code.
+ return (td.index > 0) ? td.index : ret;
+ }
+ /* Assign the hook to a function pointer. */
+ static struct I2cMethod g_method = {
+ .transfer = SampleI2cTransfer,
+ };
+ ```
+
+2. Write a driver initialization function.
+
+ This example uses **SampleI2cInit** as the name of the driver initialization function \(this function name is configurable\). This function must be assigned to the **Init** function in the driver entry structure so that the HDF can call it to initialize the driver. The driver initialization function needs to parse the configuration parameters obtained from the HCS and create a controller based on these parameters. The sample code is as follows:
+
+ ```
+ /* Parse parameters, apply for memory, and create a controller. */
+ static int32_t SampleI2cParseAndInit(struct HdfDeviceObject *device, const struct DeviceResourceNode *node)
+ {
+ int32_t ret;
+ struct SampleI2cCntlr *sampleCntlr = NULL;
+ (void)device;
+
+ sampleCntlr = (struct SampleI2cCntlr *)OsalMemCalloc(sizeof(*sampleCntlr));
+ if (sampleCntlr == NULL) {
+ HDF_LOGE("%s: malloc sampleCntlr fail!", __func__);
+ return HDF_ERR_MALLOC_FAIL;
+ }
+
+ ret = SampleI2cReadDrs(sampleCntlr, node); // Obtain configuration parameters from the HCS.
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: read drs fail! ret:%d", __func__, ret);
+ goto __ERR__;
+ }
+
+ sampleCntlr->regBase = OsalIoRemap(sampleCntlr->regBasePhy, sampleCntlr->regSize);
+ if (sampleCntlr->regBase == NULL) {
+ HDF_LOGE("%s: ioremap regBase fail!", __func__);
+ ret = HDF_ERR_IO;
+ goto __ERR__;
+ }
+
+ HDF_LOGE("The controller has been initialized!"); // The controller has been initialized successfully. (The initialization process is not provided here.)
+
+ sampleCntlr->cntlr.priv = (void *)node;
+ sampleCntlr->cntlr.busId = sampleCntlr->bus;
+ sampleCntlr->cntlr.ops = &g_method;
+ (void)OsalSpinInit(&sampleCntlr->spin); // Initialize the spin lock.
+ ret = I2cCntlrAdd(&sampleCntlr->cntlr); // Add a controller to the core layer.
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: add i2c controller fail:%d!", __func__, ret);
+ goto __ERR__;
+ }
+
+ return HDF_SUCCESS;
+ __ERR__: // Handle errors.
+ if (sampleCntlr != NULL) {
+ if (sampleCntlr->regBase != NULL) {
+ OsalIoUnmap((void *)sampleCntlr->regBase); // Cancel address mapping.
+ sampleCntlr->regBase = NULL;
+ }
+ OsalMemFree(sampleCntlr); // Release the memory.
+ sampleCntlr = NULL;
+ }
+ return ret;
+ }
+ /* Driver initialization function */
+ static int32_t SampleI2cInit(struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ const struct DeviceResourceNode *childNode = NULL;
+
+ HDF_LOGE("%s: Enter", __func__);
+ if (device == NULL || device->property == NULL) {
+ HDF_LOGE("%s: device or property is NULL", __func__);
+ return HDF_ERR_INVALID_OBJECT;
+ }
+
+ ret = HDF_SUCCESS;
+ DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) {
+ ret = SampleI2cParseAndInit(device, childNode); // Call the function for parsing parameters and creating a controller.
+ if (ret != HDF_SUCCESS) {
+ break;
+ }
+ }
+ return ret;
+ }
+ ```
+
+3. Write a driver release function.
+
+ This example uses **SampleI2cRelease** as the name of the driver release function \(you can name your own function\). This function must be assigned to the **Release** function in the driver entry structure so that the HDF can call it to initialize the driver if the driver fails to be initialized via **Init**. The driver release function must contain operations for releasing the memory and deleting the controller. The sample code is as follows:
+
+ ```
+ /* Function for deleting the controller */
+ static void SampleI2cRemoveByNode(const struct DeviceResourceNode *node)
+ {
+ int32_t ret;
+ int16_t bus;
+ struct I2cCntlr *cntlr = NULL;
+ struct SampleI2cCntlr *sampleCntlr = NULL;
+ struct DeviceResourceIface *drsOps = NULL;
+
+ drsOps = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);
+ if (drsOps == NULL || drsOps->GetUint32 == NULL) {
+ HDF_LOGE("%s: invalid drs ops fail!", __func__);
+ return;
+ }
+
+ ret = drsOps->GetUint16(node, "bus", (uint16_t *)&bus, 0); // Obtain the I2C bus number from the HCS.
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: read bus fail!", __func__);
+ return;
+ }
+
+ cntlr = I2cCntlrGet(bus);
+ if (cntlr != NULL && cntlr->priv == node) { // Delete the controller based on the I2C bus number.
+ I2cCntlrPut(cntlr);
+ I2cCntlrRemove(cntlr);
+ sampleCntlr = (struct SampleI2cCntlr *)cntlr;
+ OsalIoUnmap((void *)sampleCntlr->regBase);
+ OsalMemFree(sampleCntlr);
+ }
+ return;
+ }
+ /* Release resources. */
+ static void SampleI2cRelease(struct HdfDeviceObject *device)
+ {
+ const struct DeviceResourceNode *childNode = NULL;
+
+ HDF_LOGI("%s: enter", __func__);
+
+ if (device == NULL || device->property == NULL) {
+ HDF_LOGE("%s: device or property is NULL", __func__);
+ return;
+ }
+
+ DEV_RES_NODE_FOR_EACH_CHILD_NODE(device->property, childNode) {
+ SampleI2cRemoveByNode(childNode); // Delete a controller.
+ }
+ }
+ ```
+
+
+## Building Source Code and Burning Images
+
+1. Edit the Makefile and add a source file to it, as shown in the following example:
+
+ ```
+ include drivers/hdf/khdf/platform/platform.mk
+
+ obj-y += $(HDF_PLATFORM_FRAMEWORKS_ROOT)/src/i2c_core.o \
+ $(HDF_PLATFORM_FRAMEWORKS_ROOT)/src/i2c_if.o \
+ ./i2c_adapter.o \
+ ./i2c_sample.o
+ ```
+
+ **./i2c\_sample.o** is the source file added to the Makefile in this example.
+
+2. Build source code and burn images to the development board.
+
+ For details, see the related sections in [Getting Started for Standard System](../quick-start/quickstart-standard.md).
+
+
diff --git a/en/device-dev/guide/device-iotcamera-control-demo-photodevguide.md b/en/device-dev/guide/device-iotcamera-control-demo-photodevguide.md
new file mode 100644
index 0000000000000000000000000000000000000000..a8da63373f6c284ee608836d504e38e5ee7c1569
--- /dev/null
+++ b/en/device-dev/guide/device-iotcamera-control-demo-photodevguide.md
@@ -0,0 +1,396 @@
+# Photographing
+
+- [When to Use](#en-us_topic_0000001052170554_section1963312376119)
+- [Available APIs](#en-us_topic_0000001052170554_section56549532016)
+- [Limitations and Constraints](#en-us_topic_0000001052170554_section1165911177314)
+- [How to Develop](#en-us_topic_0000001052170554_section138543918214)
+
+## When to Use
+
+Use the camera module APIs to capture frames \(photographing\).
+
+## Available APIs
+
+**Table 1** APIs for photographing
+
+
+
+
+## Limitations and Constraints
+
+None
+
+## How to Develop
+
+1. Extend the **CameraDeviceCallback** class and call **OnCameraStatus** to customize operations when the camera device changes, for example, when a camera becomes available or unavailable.
+
+ ```
+ class SampleCameraDeviceCallback : public CameraDeviceCallback {
+ void OnCameraStatus(std::string cameraId, int32_t status) override
+ {
+ // Do something when camera is available or unavailable.
+ }
+ };
+ ```
+
+2. Extend the **FrameStateCallback** class. After obtaining the frame data, save the data as a file.
+
+ ```
+ static void SampleSaveCapture(const char *p, uint32_t size)
+ {
+ cout << "Start saving picture" << endl;
+ struct timeval tv;
+ gettimeofday(&tv, NULL);
+ struct tm *ltm = localtime(&tv.tv_sec);
+ if (ltm != nullptr) {
+ ostringstream ss("Capture_");
+ ss << "Capture" << ltm->tm_hour << "-" << ltm->tm_min << "-" << ltm->tm_sec << ".jpg";
+
+ ofstream pic("/sdcard/" + ss.str(), ofstream::out | ofstream::trunc);
+ cout << "write " << size << " bytes" << endl;
+ pic.write(p, size);
+ cout << "Saving picture end" << endl;
+ }
+ }
+
+ class TestFrameStateCallback : public FrameStateCallback {
+ void OnFrameFinished(Camera &camera, FrameConfig &fc, FrameResult &result) override
+ {
+ cout << "Receive frame complete inform." << endl;
+ if (fc.GetFrameConfigType() == FRAME_CONFIG_CAPTURE) {
+ cout << "Capture frame received." << endl;
+ list surfaceList = fc.GetSurfaces();
+ for (Surface *surface : surfaceList) {
+ SurfaceBuffer *buffer = surface->AcquireBuffer();
+ if (buffer != nullptr) {
+ char *virtAddr = static_cast(buffer->GetVirAddr());
+ if (virtAddr != nullptr) {
+ SampleSaveCapture(virtAddr, buffer->GetSize());
+ }
+ surface->ReleaseBuffer(buffer);
+ }
+ delete surface;
+ }
+ delete &fc;
+ }
+ }
+ };
+ ```
+
+3. Extend the **CameraStateCallback** class and customize operations when the camera state changes \(configuration successful or failed, and creation successful or failed\).
+
+ ```
+ class SampleCameraStateMng : public CameraStateCallback {
+ public:
+ SampleCameraStateMng() = delete;
+ SampleCameraStateMng(EventHandler &eventHdlr) : eventHdlr_(eventHdlr) {}
+ ~SampleCameraStateMng()
+ {
+ if (recordFd_ != -1) {
+ close(recordFd_);
+ }
+ }
+ void OnCreated(Camera &c) override
+ {
+ cout << "Sample recv OnCreate camera." << endl;
+ auto config = CameraConfig::CreateCameraConfig();
+ config->SetFrameStateCallback(&fsCb_, &eventHdlr_);
+ c.Configure(*config);
+ cam_ = &c;
+ }
+ void OnCreateFailed(const std::string cameraId, int32_t errorCode) override {}
+ void OnReleased(Camera &c) override {}
+ };
+ ```
+
+4. Create a **CameraKit** instance to set and obtain camera information.
+
+ ```
+ CameraKit *camKit = CameraKit::GetInstance();
+ list camList = camKit->GetCameraIds();
+ string camId;
+ for (auto &cam : camList) {
+ cout << "camera name:" << cam << endl;
+ const CameraAbility *ability = camKit->GetCameraAbility(cam);
+ /* Find the camera that fits your ability. */
+ list sizeList = ability->GetSupportedSizes(0);
+ if (find(sizeList.begin(), sizeList.end(), CAM_PIC_1080P) != sizeList.end()) {
+ camId = cam;
+ break;
+ }
+ }
+ ```
+
+5. Create a **Camera** instance.
+
+ ```
+ EventHandler eventHdlr; // Create a thread to handle callback events.
+ SampleCameraStateMng CamStateMng(eventHdlr);
+
+ camKit->CreateCamera(camId, CamStateMng, eventHdlr);
+ ```
+
+6. In the main process, synchronize configurations set by callback functions implemented in [step 1](#en-us_topic_0000001052170554_li378084192111), [step 2](#en-us_topic_0000001052170554_li8716104682913), and [step 3](#en-us_topic_0000001052170554_li6671035102514).
+
+ ```
+ void OnCreated(Camera &c) override
+ {
+ cout << "Sample recv OnCreate camera." << endl;
+ auto config = CameraConfig::CreateCameraConfig();
+ config->SetFrameStateCallback(&fsCb_, &eventHdlr_);
+ c.Configure(*config);
+ cam_ = &c;
+ }
+
+ void Capture()
+ {
+ if (cam_ == nullptr) {
+ cout << "Camera is not ready." << endl;
+ return;
+ }
+ FrameConfig *fc = new FrameConfig(FRAME_CONFIG_CAPTURE);
+ Surface *surface = Surface::CreateSurface();
+ if (surface == nullptr) {
+ delete fc;
+ return;
+ }
+ surface->SetWidthAndHeight(1920, 1080); /* 1920:width,1080:height */
+ fc->AddSurface(*surface);
+ cam_->TriggerSingleCapture(*fc);
+ }
+ ```
+
+
diff --git a/en/device-dev/guide/video-recording.md b/en/device-dev/guide/device-iotcamera-control-demo-videodevguide.md
similarity index 100%
rename from en/device-dev/guide/video-recording.md
rename to en/device-dev/guide/device-iotcamera-control-demo-videodevguide.md
diff --git a/en/device-dev/guide/device-iotcamera-control-demo.md b/en/device-dev/guide/device-iotcamera-control-demo.md
new file mode 100644
index 0000000000000000000000000000000000000000..6f187156291b9c813d199060c055e0d205e295db
--- /dev/null
+++ b/en/device-dev/guide/device-iotcamera-control-demo.md
@@ -0,0 +1,7 @@
+# Development Guidelines
+
+- **[Photographing](device-iotcamera-control-demo-photodevguide.md)**
+
+- **[Video Recording](device-iotcamera-control-demo-videodevguide.md)**
+
+
diff --git a/en/device-dev/guide/device-iotcamera-control-example.md b/en/device-dev/guide/device-iotcamera-control-example.md
new file mode 100644
index 0000000000000000000000000000000000000000..bb9875ea20896e4319e8124befa33a74a6c3f280
--- /dev/null
+++ b/en/device-dev/guide/device-iotcamera-control-example.md
@@ -0,0 +1,45 @@
+# Use Case
+
+- For details about the development board, compilation, burning, and image running, see [Hi3518 Development Board](../quick-start/quickstart-lite-introduction-hi3518.md#section14815247616). A compilation result file of sample code is stored in **out/ipcamera\_hi3518ev300/dev\_tools/bin/camera\_sample**. You can copy the file to a TF card, or modify the compilation script of **camera\_sample** to copy the result to **rootfs.img**.
+
+ Modify **output\_dir** in **applications/sample/camera/media/BUILD.gn**.
+
+ - Before: **output\_dir = "$root\_out\_dir/dev\_tools"**
+ - After: **output\_dir = "$root\_out\_dir/"**
+
+ Recompile the source code repository and burn the code into the development board. Then you can find the **camera\_sample** file in the **bin** directory of the board.
+
+- The sample code for camera development is stored in **applications/sample/camera/media/camera\_sample.cpp**.
+
+ > **NOTICE:**
+ >You should insert a TF card \(maximum capacity: 128 GB\) for photographing and video recording functions. After the system is started, the TF card is automatically mounted to the **/sdcard** directory. If the TF card is inserted after the system is started, you have to manually mount the TF card. To view the photos and videos in the TF card, copy the content to a computer. The preview function does not require a TF card.
+
+
+1. Run the **cd** command to go to the end path of the executable program and start **camera\_sample** by running the command in the following figure.
+
+ **Figure 1** Starting camera\_sample
+ 
+
+ The control commands are displayed as shown in the preceding figure. Press **S** to stop the current operation \(including video recording and preview\), and press **Q** to exit the program.
+
+2. Press **1** to take a photo in JPG format. The photo is saved in the **/sdcard** directory and named **Capture\***.
+
+ **Figure 2** Serial port logs displayed after the photographing command is executed
+ 
+
+ To view the saved file, exit the program and enter the file system. To start the program again, return to the previous step.
+
+ **Figure 3** Saved files
+ 
+
+3. Press **2** to start recording. The video file is in MP4 format and saved in the **/sdcard** directory with the name **Record\***. Press **S** to stop recording.
+
+ **Figure 4** Serial port logs displayed after the recording command is executed
+ 
+
+4. Press **Q** to exit.
+
+ **Figure 5** Serial port logs displayed after the exit command is executed
+ 
+
+
diff --git a/en/device-dev/guide/device-iotcamera-control-overview.md b/en/device-dev/guide/device-iotcamera-control-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..d5a493f3a209e1fd4dc4deb2b2c195956bcac273
--- /dev/null
+++ b/en/device-dev/guide/device-iotcamera-control-overview.md
@@ -0,0 +1,10 @@
+# Overview
+
+This document describes how to use the IoT camera development board and the built-in camera of the development kit to implement photographing and video recording.
+
+You can perform operations provided in [Use Case](device-iotcamera-control-example.md) to learn more about development board peripheral control and then develop devices such as cameras.
+
+If you want to view the sample effect first, see [Use Case](device-iotcamera-control-example.md). To customize application behavior, modify the sample code by referring to APIs described in the next section.
+
+For details about basic concepts for camera development, see the [camera development overview](../subsystems/subsys-multimedia-camera-overview.md).
+
diff --git a/en/device-dev/guide/device-iotcamera-control.md b/en/device-dev/guide/device-iotcamera-control.md
new file mode 100644
index 0000000000000000000000000000000000000000..f2720769bb74584a87e538a45093ee13bfb95869
--- /dev/null
+++ b/en/device-dev/guide/device-iotcamera-control.md
@@ -0,0 +1,9 @@
+# Camera Control
+
+- **[Overview](device-iotcamera-control-overview.md)**
+
+- **[Development Guidelines](device-iotcamera-control-demo.md)**
+
+- **[Use Case](device-iotcamera-control-example.md)**
+
+
diff --git a/en/device-dev/guide/device-iotcamera.md b/en/device-dev/guide/device-iotcamera.md
new file mode 100644
index 0000000000000000000000000000000000000000..7cbb7f06d6d084d8c3876d78b30514b95cc7b948
--- /dev/null
+++ b/en/device-dev/guide/device-iotcamera.md
@@ -0,0 +1,5 @@
+# Cameras Without a Screen
+
+- **[Camera Control](device-iotcamera-control.md)**
+
+
diff --git a/en/device-dev/guide/device-outerdrive-demo.md b/en/device-dev/guide/device-outerdrive-demo.md
new file mode 100644
index 0000000000000000000000000000000000000000..06e6ef8f47906aab8c38e7bafac7f886aa8de108
--- /dev/null
+++ b/en/device-dev/guide/device-outerdrive-demo.md
@@ -0,0 +1,483 @@
+# Development Example for Peripheral Drivers
+
+- [Overview](#section86753818426)
+ - [Hardware Resources](#section123071189431)
+ - [Input Driver Model](#section53684425430)
+
+- [Setting Up the Environment](#section661075474418)
+- [Developing a Touchscreen Driver](#section15233162984520)
+ - [Configuring Device Driver Descriptions](#section16761205604515)
+ - [Configuring the Touchscreen](#section156331030144617)
+ - [Adapting to the Private Drivers of the Touchscreen](#section17127331595)
+
+- [Building Source Code and Burning Images](#section16465031164711)
+- [Debugging and Verification](#section62577313482)
+- [Input Driver Model Workflow Analysis](#section1578569154917)
+ - [Parsing Private Configuration Data](#section1310113815495)
+ - [Initializing the Input Device Manager and Registering the Driver with the HDF](#section614512119500)
+ - [Initializing the Input Common Driver and Registering the Driver with the HDF](#section16194201755019)
+ - [Initializing the Input Chip Driver and Registering the Driver with the HDF](#section1090743312505)
+ - [Function Invocation Logic](#section81801147529)
+
+
+## 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.
+
+### Hardware Resources
+
+The touchscreen integrated circuit \(IC\) provided by the Hi3516D V300 development board is GT911, which uses the standard inter-integrated circuit \(I2C\) to communicate with the development board and connects to the main board through the 6-pin flexible flat cable. The following figure shows the distribution of the 6 pins and their connection.
+
+
+
+### Input Driver Model
+
+The input driver model mainly consists of the device manager, common drivers, and chip drivers.
+
+- Input device manager: provides various input device drivers with the APIs for registering or unregistering input devices and manages the input device list.
+- Input common driver: provides common drivers for initializing the board-level hardware, processing hardware interrupts, and registering input devices with the input device manager.
+- Input chip driver: calls differentiated APIs reserved by the input platform driver to minimize the workload for input chip driver development.
+
+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).
+
+## Setting Up the Environment
+
+Follow the instructions in [Environment Setup for Standard System](../quick-start/quickstart-standard.md).
+
+> **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.
+
+## Developing a Touchscreen Driver
+
+Complete the following tasks to adapt a touchscreen IC based on the input driver model.
+
+### Configuring Device Driver Descriptions
+
+Configure the touchscreen driver description required for registering the driver with the HDF, for example, whether the driver is loaded and what is the loading priority.
+
+You can configure the device driver description in the configuration file at **./drivers/adapter/khdf/linux/hcs/device\_info/device\_info.hcs**.
+
+The **device\_info.hcs** file contains all necessary information for registering drivers in the input driver model with the HDF. You do not need to make any modification for the information unless otherwise required in special scenarios. The private configuration data of each driver uses the **deviceMatchAttr** field to match the **match\_attr** field in the **input\_config.hcs** file.
+
+The input-related fields in the configuration file are as follows. For details about these fields, see [Driver Development](../driver/drive-hdf-development.md).
+
+```
+input :: host {
+ hostName = "input_host";
+ priority = 100;
+ device_input_manager :: device { // Specify the device driver description of the input device manager.
+ device0 :: deviceNode {
+ policy = 2; // Services are released to both the kernel space and the user space.
+ priority = 100; // The default priority for the input device manager is 100.
+ preload = 0; // Load the driver.
+ permission = 0660; // Specify the permission for the driver to create device nodes.
+ moduleName = "HDF_INPUT_MANAGER"; // Match the moduleName in the driver entry structure.
+ serviceName = "hdf_input_host"; // Specify the device node name to be generated by the HDF.
+ deviceMatchAttr = ""; // Leave this field empty because private configuration data is not required by the input device manager currently.
+ }
+ }
+
+ device_hdf_touch :: device { // Specify the device driver description of the input common driver.
+ device0 :: deviceNode {
+ policy = 2; // Services are released to both the kernel space and the user space.
+ priority = 120; // The default priority for the input common driver is 120.
+ preload = 0; // Load the driver.
+ permission = 0660; // Specify the permission for the driver to create device nodes.
+ moduleName = "HDF_TOUCH"; // Match the moduleName in the driver entry structure.
+ serviceName = "hdf_input_event1"; // Specify the device node name to be generated by the HDF.
+ deviceMatchAttr = "touch_device1"; // Keep this value the same as the match_attr value in the private configuration data.
+ }
+ }
+
+ device_touch_chip :: device { // Specify the device description of the input chip driver.
+ device0 :: deviceNode {
+ policy = 0; // Services are not released to the kernel space or the user space.
+ priority = 130; // The default priority for the input chip driver is 130.
+ preload = 0; // Load the driver.
+ permission = 0660; // Specify the permission for the driver to create device nodes.
+ moduleName = "HDF_TOUCH_GT911"; // Match the moduleName in the driver entry structure.
+ serviceName = "hdf_touch_gt911_service";// Specify the device node name to be generated by the HDF.
+ deviceMatchAttr = "zsj_gt911_5p5"; // Keep this value the same as the match_attr value in the private configuration data.
+ }
+ }
+ }
+```
+
+Pay attention to the following fields in the configuration file:
+
+**priority**: specifies the driver loading priority.
+
+**preload**: specifies whether to load the driver.
+
+**moduleName**: This value must be the same as the **moduleName** value in the driver entry structure.
+
+**serviceName**: This value is used by the HDF to create a device node name.
+
+**deviceMatchAttr**: This value must be the same as the **match\_attr** value in the private configuration data.
+
+After the device descriptions are configured, the HDF matches the configuration with the code registered with the driver entry structure based on the **moduleName** field, ensuring that drivers can be loaded properly. If multiple drivers are configured, the **priority** field determines the loading sequence of each driver.
+
+### Configuring the Touchscreen
+
+The private data includes the power-on and power-off sequence, and the platform hardware information includes the GPIO port that connects the touchscreen to the main board.
+
+You can configure the touchscreen in the configuration file at **./drivers/adapter/khdf/linux/hcs/input/input\_config.hcs**.
+
+The **input\_config.hcs** file consists of the private configuration data of both the common driver and chip driver. Information of this file is read and parsed by the driver code. The configuration in the file includes the board-level hardware information and private configuration of the touchscreen. You can tailor the configuration during your development.
+
+```
+root {
+ input_config {
+ touchConfig {
+ touch0 { // Configure the first touchscreen.
+ boardConfig { // Specify the board-level hardware information.
+ match_attr = "touch_device1"; // Keep this value the same as the match_attr field in the private configuration data of the input common driver in the device description.
+ inputAttr {
+ /* 0:touch 1:key 2:keyboard 3:mouse 4:button 5:crown 6:encoder */
+ inputType = 0; // Set the input type to touch.
+ solutionX = 480; // Set the resolution in the X-axis.
+ solutionY = 960; // Set the resolution in the Y-axis.
+ devName = "main_touch"; // Set the device name.
+ }
+ busConfig {
+ /* 0:i2c 1:spi */
+ busType = 0; // GT911 uses the I2C bus for communication.
+ busNum = 6; // Use the sixth bus of the chip to communicate with the development board through I2C.
+ clkGpio = 86; // Set the SCL pin of the chip.
+ dataGpio = 87; // Set the SDA pin of the chip.
+ i2cClkIomux = [0x114f0048, 0x403]; // Configure the SCL pin information.
+ i2cDataIomux = [0x114f004c, 0x403]; // Configure the SDA pin information.
+ }
+ pinConfig {
+ rstGpio = 3; // Set the reset pin.
+ intGpio = 4; // Set the interrupt pin.
+ rstRegCfg = [0x112f0094, 0x400]; // Configure the reset pin information.
+ intRegCfg = [0x112f0098, 0x400]; // Configure the interrupt pin information.
+ }
+ powerConfig {
+ /* 0:unused 1:ldo 2:gpio 3:pmic */
+ vccType = 2; // Set the VCC type. Value 2 indicates the GPIO power supply.
+ vccNum = 20; // gpio20
+ vccValue = 1800; // Set the voltage amplitude to 1800 mV.
+ vciType = 1; // Set the VCI type. Value 1 indicates the LDO power supply.
+ vciNum = 12; // ldo12
+ vciValue = 3300; // Set the voltage amplitude to 3300 mV.
+ }
+
+ featureConfig {
+ capacitanceTest = 0; // Configure the capacitance test.
+ gestureMode = 0; // Configure the gesture mode.
+ gloverMode = 0; // Configure the gloves mode.
+ coverMode = 0; // Configure the cover mode.
+ chargerMode = 0; // Configure the charging mode.
+ knuckleMode = 0; // Configure the knuckle mode.
+ }
+ }
+ chipConfig { // Configure the private data of the touchscreen chip.
+ template touchChip { // Set the template.
+ match_attr = "";
+ chipName = "gt911"; // Set the touchscreen IC model.
+ vendorName = "zsj"; // Set the vendor name.
+ chipInfo = "AAAA11222"; // The first four characters indicate the product name. The fifth and sixth characters indicate the IC model. The last three characters indicate the chip model.
+ busType = 0; // 0 indicates the I2C bus, and 1 indicates the SPI bus.
+ deviceAddr = 0x5D; // Set the IC communication address.
+ irqFlag = 2; // Values 1 and 2 indicate that the interrupt is triggered on the rising and falling edges, respectively. Values 4 and 8 indicate that the interrupt is triggered by the high and low levels, respectively.
+ maxSpeed = 400; // Set the maximum communication rate to 400 Hz.
+ chipVersion = 0; // Set the touchscreen IC version.
+ powerSequence {
+ /* Power-on sequence is described as follows:
+ [Type, status, direction, delay]
+ Value 0 indicates the power or pin is empty. Values 1 and 2 indicate the VCC (1.8 V) and VCI (3.3 V) power, respectively. Values 3 and 4 indicate the reset and interrupt pins, respectively.
+ Values 0 and 1 indicate the power-off or pull-down, and the power-on or pull-up, respectively. Value 2 indicates that no operation is performed.
+ Values 0 and 1 indicate the input and output directions, respectively. Value 2 indicates that no operation is performed.
+ Delay time, in milliseconds.
+ */
+ powerOnSeq = [4, 0, 1, 0, // Set the output direction for the interrupt pin and pull down the pin.
+ 3, 0, 1, 10, // Set the output direction for the reset pin and pull down the pin, with a delay of 10 ms.
+ 3, 1, 2, 60, // No operation is performed on the reset pin. Pull up the pin, with a delay of 60 ms.
+ 4, 2, 0, 0]; // Set the input direction for the interrupt pin.
+ suspendSeq = [3, 0, 2, 10]; // No operation is performed on the reset pin. Pull down the pin, with a delay of 10 ms.
+ resumeSeq = [3, 1, 2, 10]; // No operation is performed on the reset pin. Pull up the pin, with a delay of 10 ms.
+ powerOffSeq = [3, 0, 2, 10, // No operation is performed on the reset pin. Pull down the pin, with a delay of 10 ms.
+ 1, 0, 2, 20]; // No operation is performed on the positive pin. Pull down the pin, with a delay of 20 ms.
+ }
+ }
+
+ chip0 :: touchChip {
+ match_attr = "zsj_gt911_5p5"; // Keep this value the same as the match_attr field in the touchscreen private configuration data in the device description.
+ chipInfo = "ZIDN45100"; // The chip information is composed of the product name, module number, and chip number, used to identity the current touchscreen in user space.
+ chipVersion = 0; // Set the IC model version.
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+In the example, **touchConfig** contains the **touch0** configuration, which describes the **boardConfig** and **chipConfig** configuration information. The **boardConfig** field provides the board-level hardware information of Hi3516D V300, and the **chipConfig** field provides the private configuration data of the touchscreen. To use another touchscreen, you can change the value of the **chipConfig** field. You can also configure multiple touchscreens for your product. In this example, **touch0** represents the hardware interface and chip configuration of the default touchscreen. If you need to configure a secondary touchscreen, add a **touch1** block parallel to **touch0**.
+
+### Adapting to the Private Drivers of the Touchscreen
+
+The input driver model abstracts the development process of input devices. You only need to adapt to the input chip driver without making any modifications for the input device manager and common driver.
+
+The input driver model consists of three parts of drivers. To develop a brand-new touchscreen driver, you only need to adapt your code with the input chip driver and implement differentiated APIs. The sample code in this section illustrates how you will complete the adaptation.
+
+1. Implement differentiated APIs for the touchscreen to adapt to the input chip driver.
+
+ You can obtain the sample code at **./drivers/framework/model/input/driver/touchscreen/touch\_gt911.c**.
+
+ ```
+ static struct TouchChipOps g_gt911ChipOps = { // IC options of the touchscreen
+ .Init = ChipInit, // Initialize the chip.
+ .Detect = ChipDetect, // Detect the chip.
+ .Resume = ChipResume, // Resume the chip.
+ .Suspend = ChipSuspend, // Suspend the chip.
+ .DataHandle = ChipDataHandle, // Read the chip data.
+ .UpdateFirmware = UpdateFirmware, // Update the firmware.
+ };
+
+ /* The ICs may be different depending on the touchscreen vendors, and the corresponding register operations are also different. Therefore, the code for the input chip driver focuses only on the adaptation of differentiated APIs. The following sample code demonstrates the data parsing of GT911. */
+
+ static int32_t ChipDataHandle(ChipDevice *device)
+ {
+ ...
+ /* Read the status register before GT911 obtains coordinates. */
+ reg[0] = (GT_BUF_STATE_ADDR >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
+ reg[1] = GT_BUF_STATE_ADDR & ONE_BYTE_MASK;
+ ret = InputI2cRead(i2cClient, reg, GT_ADDR_LEN, &touchStatus, 1);
+ if (ret < 0 || touchStatus == GT_EVENT_INVALID) {
+ return HDF_FAILURE;
+ }
+ ...
+ /* Read data from the data register based on the value of the status register. */
+ reg[0] = (GT_X_LOW_BYTE_BASE >> ONE_BYTE_OFFSET) & ONE_BYTE_MASK;
+ reg[1] = GT_X_LOW_BYTE_BASE & ONE_BYTE_MASK;
+ pointNum = touchStatus & GT_FINGER_NUM_MASK;
+ if (pointNum == 0 || pointNum > MAX_SUPPORT_POINT) {
+ HDF_LOGE("%s: pointNum is invalid, %u", __func__, pointNum);
+ (void)ChipCleanBuffer(i2cClient);
+ OsalMutexUnlock(&device->driver->mutex);
+ return HDF_FAILURE;
+ }
+ frame->realPointNum = pointNum;
+ frame->definedEvent = TOUCH_DOWN;
+ (void)InputI2cRead(i2cClient, reg, GT_ADDR_LEN, buf, GT_POINT_SIZE * pointNum);
+ /* Parse the obtained data. */
+ ParsePointData(device, frame, buf, pointNum);
+ ...
+ }
+ static void ParsePointData(ChipDevice *device, FrameData *frame, uint8_t *buf, uint8_t pointNum)
+ {
+ ...
+ /* Each coordinate value consists of two bytes. Obtain the final coordinate value by combining the obtained single-byte data. */
+ for (i = 0; i < pointNum; i++) {
+ frame->fingers[i].trackId = buf[GT_POINT_SIZE * i + GT_TRACK_ID];
+ frame->fingers[i].y = (buf[GT_POINT_SIZE * i + GT_X_LOW] & ONE_BYTE_MASK) |
+ ((buf[GT_POINT_SIZE * i + GT_X_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
+ frame->fingers[i].x = (buf[GT_POINT_SIZE * i + GT_Y_LOW] & ONE_BYTE_MASK) |
+ ((buf[GT_POINT_SIZE * i + GT_Y_HIGH] & ONE_BYTE_MASK) << ONE_BYTE_OFFSET);
+ /* Print the parsed coordinate value. */
+ HDF_LOGD("%s: x = %d, y = %d", __func__, frame->fingers[i].x, frame->fingers[i].y);
+ }
+ }
+ ```
+
+2. Initialize the input chip driver and register the driver with the HDF.
+
+ You can obtain the sample code at **./drivers/framework/model/input/driver/touchscreen/touch\_gt911.c**.
+
+ ```
+ static int32_t HdfGoodixChipInit(struct HdfDeviceObject *device)
+ {
+ ...
+ /* Use the chipCfg structure to allocate memory, parse the configuration information, and mount the parsed data. */
+ chipCfg = ChipConfigInstance(device);
+ ...
+ /* Instantiate the touchscreen device. */
+ chipDev = ChipDeviceInstance();
+ ...
+ /* Mount touchscreen chip configuration and private operation data. */
+ chipDev->chipCfg = chipCfg;
+ chipDev->ops = &g_gt911ChipOps;
+ ...
+ /* Register the chip driver with the platform driver. */
+ RegisterChipDevice(chipDev);
+ ...
+ }
+ struct HdfDriverEntry g_touchGoodixChipEntry = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_TOUCH_GT911", // The value must match the moduleName field of the chip driver in the device_info.hcs file.
+ .Init = HdfGoodixChipInit, // Initialize the touchscreen chip driver.
+ };
+ HDF_INIT(g_touchGoodixChipEntry); // Register the touchscreen chip driver with the HDF.
+ ```
+
+ The private chip drivers present the major differentiations among chip vendors, such as hibernation and wakeup, data parsing, and firmware update.
+
+ Now, you have completed the adaptation for the touchscreen driver based on the HDF and input driver model.
+
+
+## Building Source Code and Burning Images
+
+1. Compile the Makefile.
+
+ Open the file at **./drivers/adapter/khdf/linux/model/input/Makefile**.
+
+ Add the following content:
+
+ ```
+ obj-$(CONFIG_DRIVERS_HDF_TP_5P5_GT911) += \
+ $(INPUT_ROOT_DIR)/touchscreen/touch_gt911.o
+ ```
+
+ **touch\_gt911.o** is the content added in this example.
+
+2. Build source code and burn images. For details, see the related sections in [Getting Started for Standard System](../nottoctopics/en-us_topic_0000001135402541.md#section375234715135).
+
+## Debugging and Verification
+
+The following is part of the startup log:
+
+```
+[I/HDF_INPUT_DRV] HdfInputManagerInit: enter // Initialize the input device manager.
+[I/HDF_INPUT_DRV] HdfInputManagerInit: exit succ // The initialization is successful.
+[I/osal_cdev] add cdev hdf_input_host success
+[I/HDF_LOG_TAG] HdfTouchDriverProbe: enter // Initialize the input common driver.
+[I/HDF_LOG_TAG] HdfTouchDriverProbe: main_touch exit succ // The initialization is successful.
+[I/osal_cdev] add cdev hdf_input_event1 success
+[I/HDF_INPUT_DRV] HdfGoodixChipInit: enter // Initialize the input chip driver.
+[I/HDF_INPUT_DRV] ChipDetect: IC FW version is 0x1060
+[I/HDF_INPUT_DRV] Product_ID: 911_1060, x_sol = 960, y_sol = 480
+[I/HDF_LOG_TAG] ChipDriverInit: chipDetect succ, ret = 0
+[I/HDF_LOG_TAG] InputDeviceInstance: inputDev->devName = main_touch
+[I/HDF_INPUT_DRV] HdfGoodixChipInit: exit succ, chipName = gt911 // The initialization is successful.
+```
+
+## Input Driver Model Workflow Analysis
+
+To help you get familiarized with the working process of the input driver model, the following sections will describe the key code loaded by the input driver model.
+
+> **NOTICE:**
+>You do not need to perform development related to the input driver model.
+
+### Parsing Private Configuration Data
+
+You can obtain the sample code at **./drivers/framework/model/input/driver/input\_config\_parser.c**.
+
+The configuration parsing functions provided by the OSAL can parse the fields in the **hcs** file. For details, see the implementation of each function in **input\_config\_parser.c**. If the provided template cannot meet business requirements, add required information to the **hcs** file and then develop parsing functions based on the added fields.
+
+```
+static int32_t ParseAttr(struct DeviceResourceIface *parser, const struct DeviceResourceNode *attrNode, BoardAttrCfg *attr)
+{
+ int32_t ret;
+ ret = parser->GetUint8(attrNode, "inputType", &attr->devType, 0); // Obtain the inputType field and save it in the BoardAttrCfg structure.
+ CHECK_PARSER_RET(ret, "GetUint8");
+ ...
+ return HDF_SUCCESS;
+}
+```
+
+### Initializing the Input Device Manager and Registering the Driver with the HDF
+
+You can obtain the sample code at **./drivers/framework/model/input/driver/hdf\_input\_device\_manager.c**.
+
+```
+static int32_t HdfInputManagerInit(struct HdfDeviceObject *device)
+{
+ /* Allocate memory to the device manager, which will store all input devices. */
+ g_inputManager = InputManagerInstance();
+ ...
+}
+struct HdfDriverEntry g_hdfInputEntry = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_INPUT_MANAGER",
+ .Bind = HdfInputManagerBind,
+ .Init = HdfInputManagerInit,
+ .Release = HdfInputManagerRelease,
+};
+
+HDF_INIT(g_hdfInputEntry); // Driver input entry
+```
+
+### Initializing the Input Common Driver and Registering the Driver with the HDF
+
+You can obtain the sample code at **./drivers/framework/model/input/driver/hdf\_touch.c**.
+
+```
+static int32_t HdfTouchDriverProbe(struct HdfDeviceObject *device)
+{
+ ...
+ /* Use the boardCfg structure to allocate memory and parse the configuration information obtained from the HCS. */
+ boardCfg = BoardConfigInstance(device);
+ ...
+ /* Allocate memory in the touchDriver structure. */
+ touchDriver = TouchDriverInstance();
+ ...
+ /* Initialize common resources based on the parsed board-level information, such as IIC initialization. */
+ ret = TouchDriverInit(touchDriver, boardCfg);
+ if (ret == HDF_SUCCESS) {
+ ...
+ /* Add the driver to the common driver management linked list, which is used to query the driver after it is bound to the device. */
+ AddTouchDriver(touchDriver);
+ ...
+ }
+ ...
+}
+struct HdfDriverEntry g_hdfTouchEntry = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_TOUCH",
+ .Bind = HdfTouchDriverBind,
+ .Init = HdfTouchDriverProbe,
+ .Release = HdfTouchDriverRelease,
+};
+
+ HDF_INIT(g_hdfTouchEntry); // Driver input entry
+```
+
+### Initializing the Input Chip Driver and Registering the Driver with the HDF
+
+For details, see related content in [Adapting to the Private Drivers of the Touchscreen](#section17127331595).
+
+### Function Invocation Logic
+
+The init function of the input device manager initializes the device management linked list, and the init function of the common driver allocates memory for related structures. The **RegisterChipDevice** function passes touchscreen chip driver information to the related structures of the input common driver and initializes hardware information \(for example, interrupt registration\). The **RegisterInputDevice** function registers **inputDev** \(binding the device and the driver\) with the device manager. The **RegisterInputDevice** function adds **inputDev** to the device management linked list. The function implementation is as follows:
+
+```
+// Code location: ./drivers/framework/model/input/driver/hdf_touch.c
+int32_t RegisterChipDevice(ChipDevice *chipDev)
+{
+ ...
+ /* Bind the device to the driver and create an inputDev instance using InputDeviceInstance. */
+ DeviceBindDriver(chipDev);
+ ...
+ /* Implement the interrupt registration and interrupt handling functions. The interrupt handling function contains the channel for reporting data to the user space. */
+ ChipDriverInit(chipDev);
+ ...
+ /* Allocate memory for instantiating inputDev. */
+ inputDev = InputDeviceInstance(chipDev);
+ ...
+ /* Register inputDev with the input device manager. */
+ RegisterInputDevice(inputDev);
+ ...
+}
+
+// Code location: ./drivers/framework/model/input/driver/hdf_input_device_manager.c
+int32_t RegisterInputDevice(InputDevice *inputDev)
+{
+ ...
+ /* Allocate a device ID, which is unique for each input device. */
+ ret = AllocDeviceID(inputDev);
+ ...
+ /* This function contains special processing for hid devices but does nothing for the touchscreen driver. */
+ CreateDeviceNode(inputDev);
+ /* Apply for the buffer for the IOService capability, which is required to transmit kernel-space data to the user space. */
+ AllocPackageBuffer(inputDev);
+ /* Add the input device to the global device management linked list. */
+ AddInputDevice(inputDev);
+ ...
+}
+```
+
diff --git a/en/device-dev/guide/device-wifi-led-outcontrol.md b/en/device-dev/guide/device-wifi-led-outcontrol.md
new file mode 100644
index 0000000000000000000000000000000000000000..af9d86a4d2b7b3b514e02d41b2e0949fc386cc50
--- /dev/null
+++ b/en/device-dev/guide/device-wifi-led-outcontrol.md
@@ -0,0 +1,110 @@
+# LED Peripheral Control
+
+- [Overview](#section14639174516337)
+- [Development](#section13857170163412)
+- [Verification](#section1949121910344)
+
+## Overview
+
+Based on the Hi3861 platform, the OpenHarmony WLAN module provides abundant peripheral operation capabilities, including the I2C, I2S, ADC, UART, SPI, SDIO, GPIO, PWM, and flash memory. This document describes how to control GPIO pins by calling the OpenHarmony native development kit \(NDK\) interface to implement LED blinking. For details about how to control other IoT peripherals, see the API guide.
+
+## Development
+
+1. Complete the operations described in [Getting Started with Hi3861](../quick-start/quickstart-lite-introduction-hi3861.md#section19352114194115).
+
+ LED control examples are stored in the file **applications/sample/wifi-iot/app/iothardware/led\_example.c**.
+
+2. Understand the cable connections by referring to the schematic diagram. You can learn that LED of hispark pegasus is connected to pin 9 of the chip.
+
+ ```
+ #define LED_TEST_GPIO 9
+ ```
+
+ > **NOTE:**
+ >For details about the schematic diagram of the development board, contact the Hi3861 customer service personnel.
+
+3. Initialize the GPIO pin, specify the pin usage, and create a task to turn on or off the LED periodically so that the LED blinks.
+
+ ```
+ static void LedExampleEntry(void)
+ {
+ osThreadAttr_t attr;
+
+ /* Initialize the GPIO pin. */
+ IoTGpioInit(LED_TEST_GPIO);
+ /* Set pin 9 as the output direction. */
+ IoTGpioSetDir(LED_TEST_GPIO, IOT_GPIO_DIR_OUT);
+
+ attr.name = "LedTask";
+ attr.attr_bits = 0U;
+ attr.cb_mem = NULL;
+ attr.cb_size = 0U;
+ attr.stack_mem = NULL;
+ attr.stack_size = LED_TASK_STACK_SIZE;
+ attr.priority = LED_TASK_PRIO;
+
+ /* Start the task. */
+ if (osThreadNew((osThreadFunc_t)LedTask, NULL, &attr) == NULL) {
+ printf("[LedExample] Failed to create LedTask!\n");
+ }
+ }
+ ```
+
+4. Use a cyclic task in which the LED periodically turns on and off to implement LED blinking.
+
+ ```
+ static void *LedTask(const char *arg)
+ {
+ (void)arg;
+ while (1) {
+ switch (g_ledState) {
+ case LED_ON:
+ IoTGpioSetOutputVal(LED_TEST_GPIO, 1);
+ usleep(LED_INTERVAL_TIME_US);
+ break;
+ case LED_OFF:
+ IoTGpioSetOutputVal(LED_TEST_GPIO, 0);
+ usleep(LED_INTERVAL_TIME_US);
+ break;
+ case LED_SPARK:
+ IoTGpioSetOutputVal(LED_TEST_GPIO, 0);
+ usleep(LED_INTERVAL_TIME_US);
+ IoTGpioSetOutputVal(LED_TEST_GPIO, 1);
+ usleep(LED_INTERVAL_TIME_US);
+ break;
+ default:
+ usleep(LED_INTERVAL_TIME_US);
+ break;
+ }
+ }
+ return NULL;
+ }
+ ```
+
+5. Call **SYS\_RUN\(\)** of OpenHarmony to start the service. \(**SYS\_RUN** is defined in the **ohos\_init.h** file.\)
+
+ ```
+ SYS_RUN(LedExampleEntry);
+ ```
+
+6. Change the **applications/sample/wifi-iot/app/BUILD.gn** file to enable **led\_example.c** to participate in compilation.
+
+ ```
+ import("//build/lite/config/component/lite_component.gni")
+ lite_component("app") {
+ features = [
+ "iothardware:led_example"
+ ]
+ }
+ ```
+
+
+## Verification
+
+For details about the compilation and burning processes, see [Building Source Code](../quick-start/quickstart-lite-steps-board3861-connection.md#section191121332125319) and [Burning Images](../quick-start/quickstart-lite-steps-board3861-connection.md#section19458165166) in the _Getting Started with Hi3861_.
+
+After the preceding two steps are complete, press the **RST** button to reset the module. If the LED blinks periodically as expected, the verification is passed.
+
+**Figure 1** LED blinking
+
+
diff --git a/en/device-dev/guide/device-wifi-sdk.md b/en/device-dev/guide/device-wifi-sdk.md
new file mode 100644
index 0000000000000000000000000000000000000000..dee530d9b864c0a98ddcde0288576294c69769f5
--- /dev/null
+++ b/en/device-dev/guide/device-wifi-sdk.md
@@ -0,0 +1,325 @@
+# Third-Party SDK Integration
+
+- [Planning a Directory Structure](#section1736472718351)
+- [Building the Service libs](#section442815485351)
+- [Compiling Adaptation Code](#section3984721113613)
+- [Compiling Code](#section830417531286)
+- [Compiling a Script](#section13500201173710)
+- [Compiling Service Code](#section8754114803918)
+- [Runtime](#section7737749184012)
+- [End](#section153301392411)
+
+To build a more open and complete Internet of Things \(IoT\) ecosystem, OpenHarmony has opened up a group of directories to integrate SDKs provided by different vendors. This guide describes how to integrate SDKs into OpenHarmony based on the Hi3861 board.
+
+## Planning a Directory Structure
+
+A third-party SDK consists of a static library and the adaption code. The SDK service logic is compiled to obtain the static library **libs** through the hardware module tool chain. Each module has its corresponding **libs**. The southbound APIs of the SDK are different from the APIs of OpenHarmony. The difference can be shielded by using the adaptation code **adapter**. Different modules can share the same **adapter**.
+
+Based on the preceding features, third-party SDK directories can be divided as follows in the OpenHarmony directory structure:
+
+- domains/iot/link/: The **adapter** is stored in this directory and is decoupled from the module.
+- device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/: The service library **libs** is stored in this directory and is bound to the module.
+
+You must perform the following steps before adaptation. The following uses the demolink SDK as an example.
+
+1. Create vendor directories, **domains/iot/link/demolink/** and **device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/demolink/**, to isolate different vendors.
+2. Create the **domains/iot/link/demolink/BUILD.gn** file to build the adaptation code.
+3. Create the **device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/demolink/libs/** directory to store the service library **libs**.
+
+```
+.
+├── domains
+│ └── iot
+│ └── link
+│ ├── demolink
+│ │ └── BUILD.gn
+│ ├── libbuild
+│ │ └── BUILD.gn
+│ └── BUILD.gn
+└── device
+ └── hisilicon
+ └── hispark_pegasus
+ └── sdk_liteos
+ └── 3rd_sdk
+ └── demolink
+ └── libs
+```
+
+## Building the Service **libs**
+
+Generally, the platform SDK service is provided as a static library. After obtaining the OpenHarmony code, the platform vendor needs to compile the service library **libs** based on the corresponding hardware module vendor and save the compilation result to the **device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/demolink/libs/** directory. The following describes how to build the service library **libs**.
+
+OpenHarmony has planned the **domains/iot/link/libbuild/** directory for compiling the service library **libs**. This directory contains the **domains/iot/link/libbuild/BUILD.gn** and **domains/iot/link/BUILD.gn** files. The directory structure is as follows:
+
+```
+.
+└── domains
+ └── iot
+ └── link
+ ├── demolink
+ │ └── BUILD.gn
+ ├── libbuild
+ │ └── BUILD.gn
+ └── BUILD.gn
+```
+
+Before building **libs**, you must perform the following steps:
+
+1. Place the service source code files \(including **.c** and **.h** files\) in the **domains/iot/link/libbuild/** directory.
+
+ ```
+ .
+ └── domains
+ └── iot
+ └── link
+ ├── demolink
+ │ ├── demosdk_adapter.c
+ │ ├── demosdk_adapter.h
+ │ └── BUILD.gn
+ ├── libbuild
+ │ ├── demosdk.c
+ │ ├── demosdk.h
+ │ └── BUILD.gn
+ └── BUILD.gn
+ ```
+
+2. Adapt to the **domains/iot/link/libbuild/BUILD.gn** file and restore the file after the compilation is complete.
+
+ In the **BUILD.gn** file, **sources** specifies the source file to build and **include\_dirs** specifies the path of the dependent header file so that the target build result is the static library **libdemosdk.a**.
+
+ ```
+ static_library("demosdk") {
+ sources = [
+ "demosdk.c"
+ ]
+ include_dirs = [
+ "//domains/iot/link/libbuild",
+ "//domains/iot/link/demolink"
+ ]
+ }
+ ```
+
+3. Adapt to the **domains/iot/link/BUILD.gn** file and restore the file after the compilation is complete.
+
+ The **BUILD.gn** file is used to specify build entries. You need to enter all static library entries to be compiled in **features** so that the **domains/iot/link/libbuild/BUILD.gn** file is used in the build.
+
+ ```
+ import("//build/lite/config/subsystem/lite_subsystem.gni")
+ import("//build/lite/config/component/lite_component.gni")
+ lite_subsystem("iot") {
+ subsystem_components = [
+ ":link"
+ ]
+ }
+ lite_component("link") {
+ features = [
+ "libbuild:demosdk"
+ ]
+ }
+ ```
+
+
+After the preceding operations are complete, run the **hb build -T //domains/iot/link:iot** command in the root directory of the code and then check whether the target library file is generated in the **out/hispark\_pegasus/wifiiot\_hispark\_pegasus/libs/** directory.
+
+
+
+Copy the library file to the **device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/demolink/libs/** directory and delete the **.c** and **.h** files from the **domains/iot/link/libbuild/** directory.
+
+## Compiling Adaptation Code
+
+## Compiling Code
+
+The APIs used in the platform SDK are different from the OpenHarmony APIs and cannot be directly used. Therefore, the adaptation code **adapter** is required for intermediate conversion. This section uses **DemoSdkCreateTask** in **domains/iot/link/demolink/demosdk\_adapter.c** as an example to describe how to compile adaptation code on OpenHarmony.
+
+1. Check the description, parameters, and return values of the **DemoSdkCreateTask** API to adapt.
+
+ ```
+ struct TaskPara {
+ char *name;
+ void *(*func)(char* arg);
+ void *arg;
+ unsigned char prio;
+ unsigned int size;
+ };
+
+ /*
+ * Create a thread for the IoT OS.
+ * Returns 0 if the operation is successful; returns a non-zero value otherwise.
+ */
+ int DemoSdkCreateTask(unsigned int *handle, const struct TaskPara *para);
+ ```
+
+2. Check the OpenHarmony API document, select an API with similar features, and compare the parameters and usage. This guide uses **osThreadNew** as an example. By comparing this API with **DemoSdkCreateTask**, you can find that the parameters on which the two APIs depend are basically the same, but the structures to which the parameters belong are different.
+
+ ```
+ typedef struct {
+ const char *name; ///< name of the thread
+ uint32_t attr_bits; ///< attribute bits
+ void *cb_mem; ///< memory for control block
+ uint32_t cb_size; ///< size of provided memory for control block
+ void *stack_mem; ///< memory for stack
+ uint32_t stack_size; ///< size of stack
+ osPriority_t priority; ///< initial thread priority (default: osPriorityNormal)
+ TZ_ModuleId_t tz_module; ///< TrustZone module identifier
+ uint32_t reserved; ///< reserved (must be 0)
+ } osThreadAttr_t;
+
+ /// Create a thread and add it to Active Threads.
+ /// \param[in] func thread function.
+ /// \param[in] argument pointer that is passed to the thread function as start argument.
+ /// \param[in] attr thread attributes; NULL: default values.
+ /// \return thread ID for reference by other functions or NULL in case of error.
+ osThreadId_t osThreadNew (osThreadFunc_t func, void *argument, const osThreadAttr_t *attr);
+ ```
+
+3. Perform code adaptation to shield the difference.
+
+ ```
+ int DemoSdkCreateTask(unsigned int *handle, const struct TaskPara *para)
+ {
+ osThreadAttr_t attr = {0};
+ osThreadId_t threadId;
+ if (handle == 0 || para == 0) {
+ return DEMOSDK_ERR;
+ }
+ if (para->func == 0) {
+ return DEMOSDK_ERR;
+ }
+ if (para->name == 0) {
+ return DEMOSDK_ERR;
+ }
+ attr.name = para->name;
+ attr.priority = para->prio;
+ attr.stack_size = para->size;
+ threadId = osThreadNew((osThreadFunc_t)para->func, para->arg, &attr);
+ if (threadId == 0) {
+ printf("osThreadNew fail\n");
+ return DEMOSDK_ERR;
+ }
+ *(unsigned int *)handle = (unsigned int)threadId;
+ return DEMOSDK_OK;
+ }
+ ```
+
+
+## Compiling a Script
+
+After completing code adaptation, create the **BUILD.gn** file in the directory where the **adapter** is located. This file can be used to compile the adaptation code into a static library and link the static library to the **bin** package during the entire package build. In the **domains/iot/link/demolink/BUILD.gn** file, **sources** specifies the source files to be used in the build and **include\_dirs** specifies the path of the dependent header file so that the target build result is the static library **libdemolinkadapter.a**.
+
+```
+import("//build/lite/config/component/lite_component.gni")
+static_library("demolinkadapter") {
+ sources = [
+ "demosdk_adapter.c"
+ ]
+ include_dirs = [
+ "//kernel/liteos-m/kal/cmsis",
+ "//domains/iot/link/demolink"
+ ]
+}
+```
+
+Modify the **domains/iot/link/BUILD.gn** file so that the **domain/iot/hilink/BUILD.gn** file is used in the build.
+
+```
+import("//build/lite/config/subsystem/lite_subsystem.gni")
+import("//build/lite/config/component/lite_component.gni")
+lite_subsystem("iot") {
+ subsystem_components = [
+ ":link"
+ ]
+}
+lite_component("link") {
+ features = [
+ "demolink:demolinkadapter"
+ ]
+}
+```
+
+## Compiling Service Code
+
+After the service library **libs** and adaptation code are ready, compile the service entry function to call the service entry of the third-party SDK.
+
+The following uses **demolink** as an example to describe how to compile code in **applications/sample/wifi-iot/app/** to call the **demosdk** entry function.
+
+1. Create a directory.
+
+ Before compiling a service, you must create a directory \(or a directory structure\) in **applications/sample/wifi-iot/app/** to store service source code files.
+
+ For example, add the service directory **demolink** to the app, and create the service entry code **helloworld.c** and compile the **BUILD.gn** file.
+
+ ```
+ .
+ └── applications
+ └── sample
+ └── wifi-iot
+ └── app
+ │── demolink
+ │ │── helloworld.c
+ │ └── BUILD.gn
+ └── BUILD.gn
+ ```
+
+2. Compile service code.
+
+ Compile the service entry function **DemoSdkMain** in the **helloworld.c** file, call the service entry **DemoSdkEntry** of **demolink**, and call the entry function through **SYS\_RUN\(\)** to start the service.
+
+ ```
+ #include "hos_init.h"
+ #include "demosdk.h"
+
+ void DemoSdkMain(void)
+ {
+ DemoSdkEntry();
+ }
+
+ SYS_RUN(DemoSdkMain);
+ ```
+
+3. Compile build scripts.
+
+ Add the **applications/sample/wifi-iot/app/demolink/BUILD.gn** file, specify the paths of the source code and header file, and compile the static library file **libexample\_demolink.a**.
+
+ ```
+ static_library("example_demolink") {
+ sources = [
+ "helloworld.c"
+ ]
+ include_dirs = [
+ "//utils/native/lite/include",
+ "//domains/iot/link/libbuild"
+ ]
+ }
+ ```
+
+ Modify the **applications/sample/wifi-iot/app/BUILD.gn** file so that **demolink** is used in compilation.
+
+ ```
+ import("//build/lite/config/component/lite_component.gni")
+ lite_component("app") {
+ features = [
+ "demolink:example_demolink"
+ ]
+ }
+ ```
+
+
+## Runtime
+
+Run the **hb build** command in the root directory of the code to compile and output the version package. Start **demolink**. The following shows the running result, which is consistent with the expected result of **demolink**.
+
+```
+ready to OS start
+sdk ver:Hi3861V100R001C00SPC024 2020-08-05 16:30:00
+formatting spiffs...
+FileSystem mount ok.
+wifi init success!
+it is demosdk entry.
+it is demo biz: hello world.
+it is demo biz: hello world.
+```
+
+## End
+
+The third-party SDK integration is complete.
+
diff --git a/en/device-dev/guide/device-wifi.md b/en/device-dev/guide/device-wifi.md
new file mode 100644
index 0000000000000000000000000000000000000000..73a5fc8cae7ea60dd1612b47fe8f8352688876db
--- /dev/null
+++ b/en/device-dev/guide/device-wifi.md
@@ -0,0 +1,7 @@
+# WLAN-connected Products
+
+- **[LED Peripheral Control](device-wifi-led-outcontrol.md)**
+
+- **[Third-Party SDK Integration](device-wifi-sdk.md)**
+
+
diff --git a/en/device-dev/guide/device.md b/en/device-dev/guide/device.md
new file mode 100644
index 0000000000000000000000000000000000000000..80fbb7796e3401f070d3c92b83cf7d806743dbc1
--- /dev/null
+++ b/en/device-dev/guide/device.md
@@ -0,0 +1,15 @@
+# Device Development Guidelines
+
+- **[WLAN-connected Products](device-wifi.md)**
+
+- **[Cameras Without a Screen](device-iotcamera.md)**
+
+- **[Cameras with a Screen](device-camera.md)**
+
+- **[Development Guidelines on Clock Apps](oem_device_clockapp_des.md)**
+
+- **[Development Example for Platform Drivers](device-drive-demo.md)**
+
+- **[Development Example for Peripheral Drivers](device-outerdrive-demo.md)**
+
+
diff --git a/en/device-dev/guide/faqs-10.md b/en/device-dev/guide/faqs-10.md
deleted file mode 100644
index b9828da1546f7dc0a067b0dc0a684bd33cc30e57..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/faqs-10.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# FAQs
-
-- [hdc\_std Fails to Connect to a Device](#section1221016541119)
-- [hdc\_std Fails to Run](#section219185710311)
-
-## hdc\_std Fails to Connect to a Device
-
-- **Symptom**
-
- **\[Empty\]** is displayed in the output after the **hdc\_std list targets** command is run.
-
-- **Possible Causes and Solutions**
- 1. The device cannot be identified.
-
- Check whether **HDC Device** exists in the universal serial bus device of the device manager. If **HDC Device** does not exist, the device cannot be connected. In this case, remove and then insert the device or burn the latest image for the device.
-
- 2. hdc\_std works improperly.
-
- Run the **hdc kill** or **hdc start -r** command to kill or restart the hdc service, and then run the **hdc list targets** command to check whether device information is obtained.
-
- If no device information is obtained, check whether the adb process exists in the task manager. If the adb process exists, kill this process because it may affect the hdc service. After that, run **hdc kill** or **hdc start -r** and then **hdc list targets** again.
-
- 3. hdc\_std does not match the device.
-
- If the latest image is burnt for the device, hdc\_std must also be of the latest version. As hdc\_std is updated continuously, obtain hdc\_std of the latest version from the **developtools\_hdc\_standard** repository in the **prebuilt** directory.
-
-
-
-## hdc\_std Fails to Run
-
-- **Symptom**
-
- The **hdc\_std.exe** file does not run after being clicked.
-
-- **Possible Causes and Solutions**
-
- **hdc\_std.exe** requires no installation and can be directly used on a disk. It can also be added to environment variables. Open the cmd window and run the **hdc\_std** command to use **hdc\_std.exe**.
-
-
diff --git a/en/device-dev/guide/figures/adding-a-page.png b/en/device-dev/guide/figure/adding-a-page.png
similarity index 100%
rename from en/device-dev/guide/figures/adding-a-page.png
rename to en/device-dev/guide/figure/adding-a-page.png
diff --git a/en/device-dev/guide/figures/clock.png b/en/device-dev/guide/figure/clock.png
similarity index 100%
rename from en/device-dev/guide/figures/clock.png
rename to en/device-dev/guide/figure/clock.png
diff --git a/en/device-dev/guide/figures/complete-project-directory.png b/en/device-dev/guide/figure/complete-project-directory.png
similarity index 100%
rename from en/device-dev/guide/figures/complete-project-directory.png
rename to en/device-dev/guide/figure/complete-project-directory.png
diff --git a/en/device-dev/guide/figures/en-us_image_0000001078563230.png b/en/device-dev/guide/figure/en-us_image_0000001078563230.png
similarity index 100%
rename from en/device-dev/guide/figures/en-us_image_0000001078563230.png
rename to en/device-dev/guide/figure/en-us_image_0000001078563230.png
diff --git a/en/device-dev/guide/figures/en-us_image_0000001082434703.png b/en/device-dev/guide/figure/en-us_image_0000001082434703.png
similarity index 100%
rename from en/device-dev/guide/figures/en-us_image_0000001082434703.png
rename to en/device-dev/guide/figure/en-us_image_0000001082434703.png
diff --git a/en/device-dev/guide/figures/en-us_image_0000001161922745.png b/en/device-dev/guide/figure/en-us_image_0000001169991055.png
similarity index 100%
rename from en/device-dev/guide/figures/en-us_image_0000001161922745.png
rename to en/device-dev/guide/figure/en-us_image_0000001169991055.png
diff --git a/en/device-dev/guide/figures/entering-the-page-name.png b/en/device-dev/guide/figure/entering-the-page-name.png
similarity index 100%
rename from en/device-dev/guide/figures/entering-the-page-name.png
rename to en/device-dev/guide/figure/entering-the-page-name.png
diff --git a/en/device-dev/guide/figures/home-screen.png b/en/device-dev/guide/figure/home-screen.png
similarity index 100%
rename from en/device-dev/guide/figures/home-screen.png
rename to en/device-dev/guide/figure/home-screen.png
diff --git a/en/device-dev/guide/figures/indicator-bar.png b/en/device-dev/guide/figure/indicator-bar.png
similarity index 100%
rename from en/device-dev/guide/figures/indicator-bar.png
rename to en/device-dev/guide/figure/indicator-bar.png
diff --git a/en/device-dev/guide/figures/led-blinking.gif b/en/device-dev/guide/figure/led-blinking.gif
similarity index 100%
rename from en/device-dev/guide/figures/led-blinking.gif
rename to en/device-dev/guide/figure/led-blinking.gif
diff --git a/en/device-dev/guide/figures/preview-effect.jpg b/en/device-dev/guide/figure/preview-effect.jpg
similarity index 100%
rename from en/device-dev/guide/figures/preview-effect.jpg
rename to en/device-dev/guide/figure/preview-effect.jpg
diff --git a/en/device-dev/guide/figures/project-directory.png b/en/device-dev/guide/figure/project-directory.png
similarity index 100%
rename from en/device-dev/guide/figures/project-directory.png
rename to en/device-dev/guide/figure/project-directory.png
diff --git a/en/device-dev/guide/figures/saved-files.png b/en/device-dev/guide/figure/saved-files.png
similarity index 100%
rename from en/device-dev/guide/figures/saved-files.png
rename to en/device-dev/guide/figure/saved-files.png
diff --git a/en/device-dev/guide/figures/serial-port-logs-displayed-after-the-exit-command-is-executed.png b/en/device-dev/guide/figure/serial-port-logs-displayed-after-the-exit-command-is-executed.png
similarity index 100%
rename from en/device-dev/guide/figures/serial-port-logs-displayed-after-the-exit-command-is-executed.png
rename to en/device-dev/guide/figure/serial-port-logs-displayed-after-the-exit-command-is-executed.png
diff --git a/en/device-dev/guide/figures/serial-port-logs-displayed-after-the-photographing-command-is-executed.png b/en/device-dev/guide/figure/serial-port-logs-displayed-after-the-photographing-command-is-executed.png
similarity index 100%
rename from en/device-dev/guide/figures/serial-port-logs-displayed-after-the-photographing-command-is-executed.png
rename to en/device-dev/guide/figure/serial-port-logs-displayed-after-the-photographing-command-is-executed.png
diff --git a/en/device-dev/guide/figures/serial-port-logs-displayed-after-the-preview-command-is-executed.png b/en/device-dev/guide/figure/serial-port-logs-displayed-after-the-preview-command-is-executed.png
similarity index 100%
rename from en/device-dev/guide/figures/serial-port-logs-displayed-after-the-preview-command-is-executed.png
rename to en/device-dev/guide/figure/serial-port-logs-displayed-after-the-preview-command-is-executed.png
diff --git a/en/device-dev/guide/figures/serial-port-logs-displayed-after-the-recording-command-is-executed.png b/en/device-dev/guide/figure/serial-port-logs-displayed-after-the-recording-command-is-executed.png
similarity index 100%
rename from en/device-dev/guide/figures/serial-port-logs-displayed-after-the-recording-command-is-executed.png
rename to en/device-dev/guide/figure/serial-port-logs-displayed-after-the-recording-command-is-executed.png
diff --git a/en/device-dev/guide/figures/starting-camera_sample.png b/en/device-dev/guide/figure/starting-camera_sample.png
similarity index 100%
rename from en/device-dev/guide/figures/starting-camera_sample.png
rename to en/device-dev/guide/figure/starting-camera_sample.png
diff --git a/en/device-dev/guide/figures/title-bar-and-information-bar.png b/en/device-dev/guide/figure/title-bar-and-information-bar.png
similarity index 100%
rename from en/device-dev/guide/figures/title-bar-and-information-bar.png
rename to en/device-dev/guide/figure/title-bar-and-information-bar.png
diff --git a/en/device-dev/guide/figures/title-bar.png b/en/device-dev/guide/figure/title-bar.png
similarity index 100%
rename from en/device-dev/guide/figures/title-bar.png
rename to en/device-dev/guide/figure/title-bar.png
diff --git a/en/device-dev/guide/figures/video_2020-07-25_173141.gif b/en/device-dev/guide/figure/video_2020-07-25_173141.gif
similarity index 100%
rename from en/device-dev/guide/figures/video_2020-07-25_173141.gif
rename to en/device-dev/guide/figure/video_2020-07-25_173141.gif
diff --git "a/en/device-dev/guide/figures/\347\273\230\345\233\2761.png" "b/en/device-dev/guide/figure/\347\273\230\345\233\2761.png"
similarity index 100%
rename from "en/device-dev/guide/figures/\347\273\230\345\233\2761.png"
rename to "en/device-dev/guide/figure/\347\273\230\345\233\2761.png"
diff --git a/en/device-dev/guide/function-invocation-logic.md b/en/device-dev/guide/function-invocation-logic.md
deleted file mode 100644
index 8f633c3a85a43be32973b50af8729acfeb0ea5ba..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/function-invocation-logic.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Function Invocation Logic
-
-The init function of the input device manager initializes the device management linked list, and the init function of the common driver allocates memory for related structures. The **RegisterChipDevice** function passes touchscreen chip driver information to the related structures of the input common driver and initializes hardware information \(for example, interrupt registration\). The **RegisterInputDevice** function registers **inputDev** \(binding the device and the driver\) with the device manager. The **RegisterInputDevice** function adds **inputDev** to the device management linked list. The function implementation is as follows:
-
-```
-// Code location: ./drivers/framework/model/input/driver/hdf_touch.c
-int32_t RegisterChipDevice(ChipDevice *chipDev)
-{
- ...
- /* Bind the device to the driver and create an inputDev instance using InputDeviceInstance. */
- DeviceBindDriver(chipDev);
- ...
- /* Implement the interrupt registration and interrupt handling functions. The interrupt handling function contains the channel for reporting data to the user space. */
- ChipDriverInit(chipDev);
- ...
- /* Allocate memory for instantiating inputDev. */
- inputDev = InputDeviceInstance(chipDev);
- ...
- /* Register inputDev with the input device manager. */
- RegisterInputDevice(inputDev);
- ...
-}
-
-// Code location: ./drivers/framework/model/input/driver/hdf_input_device_manager.c
-int32_t RegisterInputDevice(InputDevice *inputDev)
-{
- ...
- /* Allocate a device ID, which is unique for each input device. */
- ret = AllocDeviceID(inputDev);
- ...
- /* This function contains special processing for hid devices but does nothing for the touchscreen driver. */
- CreateDeviceNode(inputDev);
- /* Apply for the buffer for the IOService capability, which is required to transmit kernel-space data to the user space. */
- AllocPackageBuffer(inputDev);
- /* Add the input device to the global device management linked list. */
- AddInputDevice(inputDev);
- ...
-}
-```
-
diff --git a/en/device-dev/guide/hardware-resources.md b/en/device-dev/guide/hardware-resources.md
deleted file mode 100644
index 5e93297911c69fdcd9ebaa6cb383c4761e5715b1..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/hardware-resources.md
+++ /dev/null
@@ -1,6 +0,0 @@
-# Hardware Resources
-
-The touchscreen integrated circuit \(IC\) provided by the Hi3516D V300 development board is GT911, which uses the standard inter-integrated circuit \(I2C\) to communicate with the development board and connects to the main board through the 6-pin flexible flat cable. The following figure shows the distribution of the 6 pins and their connection.
-
-
-
diff --git a/en/device-dev/guide/how-to-develop.md b/en/device-dev/guide/how-to-develop.md
deleted file mode 100644
index 28b0a31d6c892bf82adf85b0bc86f2312812ad4b..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/how-to-develop.md
+++ /dev/null
@@ -1,230 +0,0 @@
-# How to Develop
-
-The Clock app displays the current time through a clock face and numbers.
-
-As shown in [Figure 1 Clock display effect](overview-7.md#fig7763172132019), the page 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.
-
-To build such an app, we can create a page that has a flexible layout with two rows vertically arranged. The development procedure is as follows:
-
-1. Add a root **** to the **.hml** file. Note that each **.hml** file can contain only one root component. The example code is as follows:
-
- ```
-
-
- ```
-
- **class="container"** indicates the style used by the component. The **container** is a style class defined in the **index.css** file.
-
- ```
- .container {
- flex-direction: column;
- justify-content: center;
- align-items: center;
- width: 100%;
- height: 100%;
- }
- ```
-
- The height and width of the root component **** are set in the style class. Note that the height and width must be explicitly specified \(except for some components, such as ****\). Otherwise, the component may fail to display. In the **container** style class, the **flex-direction** attribute is set to **column**, which means that child components of **** are vertically arranged from top to bottom for implementing the flexible page layout.
-
-2. Implement clock hand rotation using the **** component. The **** component provides a stack container where child components are successively stacked and the latter one overwrites the previous one.
-
- Add a stack container to the root component. The example code is as follows:
-
- ```
-
-
-
-
-
-
-
-
- ```
-
- **style="transform: rotate\(\{\{ second \* 6 \}\}deg\)** sets the rotation event of a component. **transform** translates, rotates, or scales an element. **rotate** rotates an element. You can set the element to rotate around its x-axis or y-axis.
-
- Set attributes, such as the height, width, and position, of the component in the CSS file. The example code is as follows:
-
- ```
- .stack {
- flex-direction: column;
- justify-content: center;
- align-items: center;
- width: 100%;
- height: 50%;
- }
- ```
-
- Set attributes, such as the height and width, of the component in the CSS file. The example code is as follows:
-
- ```
- .clock-bg {
- width: 80%;
- height: 80%;
- object-fit: scale-down;
- }
- ```
-
- Set attributes, such as the height and width of the hour, minute, and second hands, of the component in the CSS file. The example code is as follows:
-
- ```
- .clock-hand {
- width: 25%;
- height: 65%;
- object-fit: contain;
- }
- ```
-
- Add a timer in the **index.js** file to update the hour, minute, and second variables in real time so that time can be automatically updated on the app UI. The example code is as follows:
-
- ```
- export default {
- timer: undefined,
- // Define parameters.
- data: {
- hour: 0, // Define hours.
- minute: 0, // Define minutes.
- second: 0 // Define seconds.
- },
- onInit () {
- this.updateTime();
- this.timer = setInterval(this.updateTime, 1000)// Set the update time of the timer to 1 second.
- },
- updateTime: function () {
- var nowTime = new Date()
- this.hour = nowTime.getHours()
- this.minute = nowTime.getMinutes()
- this.second = nowTime.getSeconds()
- if (this.hour < 10) {
- this.hour = '0' + this.hour
- }
- if (this.minute < 10) {
- this.minute = '0' + this.minute
- }
- if (this.second < 10) {
- this.second = '0' + this.second
- }
- },
- }
- ```
-
-3. Display the current time in digital form under the analog clock. Add the **** component at the end of the root layout. The following example shows the page structure:
-
- ```
- {{ hour }}:{{ minute }}:{{ second }}
- ```
-
- **class="digit-clock"** sets the height, width, and font size of the component. The example code is as follows:
-
- ```
- .digit-clock {
- font-size: 58px;
- width: 100%;
- margin-top: 0px;
- text-align: center;
- }
- ```
-
-4. Set the style, animation effect, and dynamic data binding for all components. The complete example code is as follows:
-
- - **index.hml**
-
- ```
-
- ```
-
- - **index.css**
-
- ```
- .container {
- flex-direction: column;
- justify-content: center;
- align-items: center;
- width: 100%;
- height: 100%;
- }
-
- .stack {
- flex-direction: column;
- justify-content: center;
- align-items: center;
- width: 100%;
- height: 50%;
- }
-
- .digit-clock {
- font-size: 58px;
- width: 100%;
- margin-top: 0px;
- text-align: center;
- }
-
- .clock-bg {
- width: 80%;
- height: 80%;
- object-fit: scale-down;
- }
-
- .clock-hand {
- width: 25%;
- height: 65%;
- object-fit: contain;
- }
- ```
-
- - **index.js**
-
- A **.js** file is used to implement interaction logic of your app. In the **.js** file of the page, implement the function of periodically obtaining the system time.
-
- ```
- export default {
- timer: undefined,
- data: {
- hour: 0,
- minute: 0,
- second: 0
- },
- onInit() {
- this.updateTime()
- this.timer = setInterval(this.updateTime, 1000)
- },
- updateTime: function () {
- var nowTime = new Date()
- this.hour = nowTime.getHours()
- this.minute = nowTime.getMinutes()
- this.second = nowTime.getSeconds()
- if (this.hour < 10) {
- this.hour = '0' + this.hour
- }
- if (this.minute < 10) {
- this.minute = '0' + this.minute
- }
- if (this.second < 10) {
- this.second = '0' + this.second
- }
- },
- onDestroy() {
- clearInterval(this.timer);
- }
- }
- ```
-
-
diff --git a/en/device-dev/guide/initializing-the-input-chip-driver-and-registering-the-driver-with-the-hdf.md b/en/device-dev/guide/initializing-the-input-chip-driver-and-registering-the-driver-with-the-hdf.md
deleted file mode 100644
index 80abf74934cd632f99e0bf8dbd87f6097158b9a0..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/initializing-the-input-chip-driver-and-registering-the-driver-with-the-hdf.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Initializing the Input Chip Driver and Registering the Driver with the HDF
-
-For details, see step [Initialize the input chip driver and register the driver with the HDF](adapting-to-the-private-drivers-of-the-touchscreen.md).
-
diff --git a/en/device-dev/guide/initializing-the-input-common-driver-and-registering-the-driver-with-the-hdf.md b/en/device-dev/guide/initializing-the-input-common-driver-and-registering-the-driver-with-the-hdf.md
deleted file mode 100644
index cf43752893cfad241dd78633c42c2957f6122d86..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/initializing-the-input-common-driver-and-registering-the-driver-with-the-hdf.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Initializing the Input Common Driver and Registering the Driver with the HDF
-
-You can obtain the sample code at **./drivers/framework/model/input/driver/hdf\_touch.c**.
-
-```
-static int32_t HdfTouchDriverProbe(struct HdfDeviceObject *device)
-{
- ...
- /* Use the boardCfg structure to allocate memory and parse the configuration information obtained from the HCS. */
- boardCfg = BoardConfigInstance(device);
- ...
- /* Allocate memory in the touchDriver structure. */
- touchDriver = TouchDriverInstance();
- ...
- /* Initialize common resources based on the parsed board-level information, such as IIC initialization. */
- ret = TouchDriverInit(touchDriver, boardCfg);
- if (ret == HDF_SUCCESS) {
- ...
- /* Add the driver to the common driver management linked list, which is used to query the driver after it is bound to the device. */
- AddTouchDriver(touchDriver);
- ...
- }
- ...
-}
-struct HdfDriverEntry g_hdfTouchEntry = {
- .moduleVersion = 1,
- .moduleName = "HDF_TOUCH",
- .Bind = HdfTouchDriverBind,
- .Init = HdfTouchDriverProbe,
- .Release = HdfTouchDriverRelease,
-};
-
- HDF_INIT(g_hdfTouchEntry); // Driver registration entry
-```
-
diff --git a/en/device-dev/guide/initializing-the-input-device-manager-and-registering-the-driver-with-the-hdf.md b/en/device-dev/guide/initializing-the-input-device-manager-and-registering-the-driver-with-the-hdf.md
deleted file mode 100644
index a8ebbf4a5de71f905ff090114d5541a7d46afbe3..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/initializing-the-input-device-manager-and-registering-the-driver-with-the-hdf.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# Initializing the Input Device Manager and Registering the Driver with the HDF
-
-You can obtain the sample code at **./drivers/framework/model/input/driver/hdf\_input\_device\_manager.c**.
-
-```
-static int32_t HdfInputManagerInit(struct HdfDeviceObject *device)
-{
- /* Allocate memory to the device manager, which will store all input devices. */
- g_inputManager = InputManagerInstance();
- ...
-}
-struct HdfDriverEntry g_hdfInputEntry = {
- .moduleVersion = 1,
- .moduleName = "HDF_INPUT_MANAGER",
- .Bind = HdfInputManagerBind,
- .Init = HdfInputManagerInit,
- .Release = HdfInputManagerRelease,
-};
-
-HDF_INIT(g_hdfInputEntry); // Driver registration entry
-```
-
diff --git a/en/device-dev/guide/input-driver-model-workflow-analysis.md b/en/device-dev/guide/input-driver-model-workflow-analysis.md
deleted file mode 100644
index c99c0617eaa8da4150494580902e215567c2dee2..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/input-driver-model-workflow-analysis.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# Input Driver Model Workflow Analysis
-
-To help you get familiarized with the working process of the input driver model, the following sections will describe the key code loaded by the input driver model.
-
-> **NOTICE:**
->You do not need to perform development related to the input driver model.
-
-- **[Parsing Private Configuration Data](parsing-private-configuration-data.md)**
-
-- **[Initializing the Input Device Manager and Registering the Driver with the HDF](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](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](initializing-the-input-chip-driver-and-registering-the-driver-with-the-hdf.md)**
-
-- **[Function Invocation Logic](function-invocation-logic.md)**
-
-
diff --git a/en/device-dev/guide/input-driver-model.md b/en/device-dev/guide/input-driver-model.md
deleted file mode 100644
index a4f2cdb3720235bcf0fd941caf6ae05c68792bd8..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/input-driver-model.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Input Driver Model
-
-The input driver model mainly consists of the device manager, common drivers, and chip drivers.
-
-- Input device manager: provides various input device drivers with the APIs for registering or unregistering input devices and manages the input device list.
-- Input common driver: provides common drivers for initializing the board-level hardware, processing hardware interrupts, and registering input devices with the input device manager.
-- Input chip driver: calls differentiated APIs reserved by the input platform driver to minimize the workload for input chip driver development.
-
-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](https://device.harmonyos.com/en/docs/develop/drive/oem_drive_touch_des-0000001052857350)[Touchscreen Overview](../driver/touchscreenoverview.md).
-
diff --git a/en/device-dev/guide/led-peripheral-control.md b/en/device-dev/guide/led-peripheral-control.md
deleted file mode 100644
index abe05cea370b4b7743e120ce2207aa54834de1b1..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/led-peripheral-control.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# LED Peripheral Control
-
-- **[Overview](overview.md)**
-
-- **[Development](development.md)**
-
-- **[Verification](verification.md)**
-
-
diff --git a/en/device-dev/guide/oem_device_clockapp_des.md b/en/device-dev/guide/oem_device_clockapp_des.md
new file mode 100644
index 0000000000000000000000000000000000000000..5a7836cea35b322fb0bc27c81d4f7b371a97482f
--- /dev/null
+++ b/en/device-dev/guide/oem_device_clockapp_des.md
@@ -0,0 +1,332 @@
+# Development Guidelines on Clock Apps
+
+- [Overview](#section11522349121115)
+- [Preparations](#section6592121861218)
+- [How to Develop](#section19901741111312)
+- [Signing and Packaging](#section10601181101516)
+- [Running on the Real Device](#section092721731511)
+- [FAQs](#section1122413460153)
+ - [hdc\_std Fails to Connect to a Device](#section1922725151614)
+ - [hdc\_std Fails to Run](#section15657547131615)
+
+
+## Overview
+
+This document describes how to quickly set up a development environment \(using the Hi3516D V300 development board\) and develop a clock app running on OpenHarmony. You can click [here](https://gitee.com/openharmony/app_samples/tree/master/common/Clock) to obtain the sample code.
+
+The clock app displays the current time, as shown in the following figure.
+
+**Figure 1** Clock display effect
+
+
+
+
+## Preparations
+
+Download and install DevEco Studio. For details, see the [HUAWEI DevEco Studio User Guide](../../application-dev/quick-start/deveco-studio-(openharmony)-user-guide.md).
+
+## How to Develop
+
+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:
+
+- Clock face area: displays a dynamic analog clock whose hands rotate accurately.
+- Digital time area: displays the current time in numerals.
+
+To build such an app, we can create a page that has a flexible layout with two rows vertically arranged. The development procedure is as follows:
+
+1. Add a root component **** to the **.hml** file. Note that each **.hml** file can contain only one root component. The sample code is as follows:
+
+ ```
+
+
+ ```
+
+ **class="container"** indicates the style used by the component. The **container** is a style class defined in the **index.css** file.
+
+ ```
+ .container {
+ flex-direction: column;
+ justify-content: center;
+ align-items: center;
+ width: 100%;
+ height: 100%;
+ }
+ ```
+
+ The height and width of the root component **** are set in the style class. Note that the height and width must be explicitly specified \(except for some components, such as ****\). Otherwise, the component may fail to display. In the **container** style class, the **flex-direction** attribute is set to **column**, which means that child components of **** are vertically arranged from top to bottom for implementing the flexible page layout.
+
+2. Implement clock hand rotation using the **** component. The **** component provides a stack container where child components are successively stacked and the latter one overwrites the previous one.
+
+ Add a stack container to the root component. The sample code is as follows:
+
+ ```
+
+
+
+
+
+
+
+
+ ```
+
+ **style="transform: rotate\(\{\{ second \* 6 \}\}deg\)** sets the rotation event of a component. **transform** translates, rotates, or scales an image. **rotate** rotates an image. You can set an image to rotate around its x-axis or y-axis.
+
+ Set attributes, such as the height, width, and position, of the stack component in the CSS file. The sample code is as follows:
+
+ ```
+ .stack {
+ flex-direction: column;
+ justify-content: center;
+ align-items: center;
+ width: 100%;
+ height: 50%;
+ }
+ ```
+
+ Set attributes, such as the height and width, of the clock-bg component in the CSS file. The sample code is as follows:
+
+ ```
+ .clock-bg {
+ width: 80%;
+ height: 80%;
+ object-fit: scale-down;
+ }
+ ```
+
+ Set attributes, such as the height and width of the hour, minute, and second hands, of the clock-hand component in the CSS file. The sample code is as follows:
+
+ ```
+ .clock-hand {
+ width: 25%;
+ height: 65%;
+ object-fit: contain;
+ }
+ ```
+
+ Add a timer in the **index.js** file to update the hour, minute, and second variables in real time so that the time can be automatically updated on the app UI. The sample code is as follows:
+
+ ```
+ export default {
+ timer: undefined,
+ // Define parameters.
+ data: {
+ hour: 0, // Define hours.
+ minute: 0, // Define minutes.
+ second: 0 // Define seconds.
+ },
+ onInit () {
+ this.updateTime();
+ this.timer = setInterval(this.updateTime, 1000)// Set the timer to 1 second.
+ },
+ updateTime: function () {
+ var nowTime = new Date()
+ this.hour = nowTime.getHours()
+ this.minute = nowTime.getMinutes()
+ this.second = nowTime.getSeconds()
+ if (this.hour < 10) {
+ this.hour = '0' + this.hour
+ }
+ if (this.minute < 10) {
+ this.minute = '0' + this.minute
+ }
+ if (this.second < 10) {
+ this.second = '0' + this.second
+ }
+ },
+ }
+ ```
+
+3. Display the current time in numerals under the analog clock. Add the text component at the end of the root layout. The following example shows the UI structure:
+
+ ```
+ {{ hour }}:{{ minute }}:{{ second }}
+ ```
+
+ class=**"digit-clock"** sets the height, width, and font size of the component. The sample code is as follows:
+
+ ```
+ .digit-clock {
+ font-size: 58px;
+ width: 100%;
+ margin-top: 0px;
+ text-align: center;
+ }
+ ```
+
+4. Set the style, animation effect, and dynamic data binding for all components. The complete sample code is as follows:
+ - **index.hml**
+
+ ```
+
+ ```
+
+
+ - **index.css**
+
+ ```
+ .container {
+ flex-direction: column;
+ justify-content: center;
+ align-items: center;
+ width: 100%;
+ height: 100%;
+ }
+
+ .stack {
+ flex-direction: column;
+ justify-content: center;
+ align-items: center;
+ width: 100%;
+ height: 50%;
+ }
+
+ .digit-clock {
+ font-size: 58px;
+ width: 100%;
+ margin-top: 0px;
+ text-align: center;
+ }
+
+ .clock-bg {
+ width: 80%;
+ height: 80%;
+ object-fit: scale-down;
+ }
+
+ .clock-hand {
+ width: 25%;
+ height: 65%;
+ object-fit: contain;
+ }
+ ```
+
+
+ - **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,
+ data: {
+ hour: 0,
+ minute: 0,
+ second: 0
+ },
+ onInit() {
+ this.updateTime()
+ this.timer = setInterval(this.updateTime, 1000)
+ },
+ updateTime: function () {
+ var nowTime = new Date()
+ this.hour = nowTime.getHours()
+ this.minute = nowTime.getMinutes()
+ this.second = nowTime.getSeconds()
+ if (this.hour < 10) {
+ this.hour = '0' + this.hour
+ }
+ if (this.minute < 10) {
+ this.minute = '0' + this.minute
+ }
+ if (this.second < 10) {
+ this.second = '0' + this.second
+ }
+ },
+ onDestroy() {
+ clearInterval(this.timer);
+ }
+ }
+ ```
+
+
+
+## Signing and Packaging
+
+After finishing writing the app code, you need to sign and package the app before running it on a real device. For details, see [Signing and Packaging Guide](../../application-dev/quick-start/configuring-the-openharmony-app-signature.md).
+
+## 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:
+
+1. Obtain the HDC client from the following path:
+
+ ```
+ developtools/hdc_standard/prebuilt/windows/hdc_std.exe
+ ```
+
+ Change the HDC client name to **hdc.exe** and add the path above to the system environment variable **path**.
+
+2. Open the **cmd** window, and run the following commands to push the HAP file to the device directory, and install it:
+
+ ```
+ hdc smode
+ hdc target mount
+ hdc file send clock.hap /data/clock.hap
+ hdc shell chmod 666 /data/clock.hap
+ hdc shell bm install -p /data/clock.hap
+ ```
+
+3. Run the following command to start the app. **ohos.samples.clock** indicates the app package name, and **MainAbility** indicates the ability started by the app.
+
+ ```
+ hdc shell aa start -d 123 -a ohos.samples.clock.MainAbility -b ohos.samples.clock
+ ```
+
+4. \(Optional\) Run the following command to uninstall the app. **ohos.samples.clock** indicates the app package name.
+
+ ```
+ hdc shell bm uninstall -n ohos.samples.clock
+ ```
+
+
+## FAQs
+
+### hdc\_std Fails to Connect to a Device
+
+- **Symptom**
+
+ **\[Empty\]** is displayed in the output after the **hdc\_std list targets** command is run.
+
+- **Possible Causes and Solutions**
+ 1. The device fails to be identified.
+
+ Check whether **HDC Device** exists in the universal serial bus device of the device manager. If **HDC Device** does not exist, the device cannot be connected. In this case, remove and then insert the device or burn the latest image for the device.
+
+ 2. hdc\_std works improperly.
+
+ Run the **hdc kill** or **hdc start -r** command to kill or restart the HDC service, and then run the **hdc list targets** command to check whether device information is obtained.
+
+ 3. hdc\_std does not match the device.
+
+ If the latest image is burnt for the device, hdc\_std must also be of the latest version. As hdc\_std is updated continuously, obtain hdc\_std of the latest version from the **developtools\_hdc\_standard** repository in the **prebuilt** directory.
+
+
+
+### hdc\_std Fails to Run
+
+- **Symptom**
+
+ The **hdc\_std.exe** file does not run after being clicked.
+
+- **Possible Causes and Solutions**
+
+ **hdc\_std.exe** requires no installation and can be directly used on a disk. It can also be added to environment variables. Open the **cmd** window and run the **hdc\_std** command to use **hdc\_std.exe**.
+
+
diff --git a/en/device-dev/guide/overview-0.md b/en/device-dev/guide/overview-0.md
deleted file mode 100644
index 39a2eba2ffd3e70fa55b95840b2ff05f0893243c..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/overview-0.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# Overview
-
-This document describes how to use the IoT camera development board and the built-in camera of the development kit to implement photographing and video recording.
-
-You can perform operations provided in [Use Case](use-case.md) to learn more about development board peripheral control and then develop devices such as cameras.
-
-If you want to view the sample effect first, see [Use Case](use-case.md). To customize application behavior, modify the sample code by referring to APIs described in the next section.
-
-For details about basic concepts for camera development, see the [camera development overview](../subsystems/overview.md).
-
diff --git a/en/device-dev/guide/overview-1.md b/en/device-dev/guide/overview-1.md
deleted file mode 100644
index fb22f918ac419c6783e78bca66a00fb332b9bcad..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/overview-1.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# Overview
-
-This document describes how to use the IoT camera development board \(Hi3516D V300\) and its camera and screen to implement photographing, video recording, and video preview.
-
-This document helps you take a deep dive into OpenHarmony camera control. With this reference, you can develop devices, such as peephole cameras, smart rear-view mirrors, and smart displays.
-
-If you want to view the running effect first, see [Use Case](use-case-5.md). To customize application behavior, modify the sample code by referring to APIs described in the "Development Guidelines" section.
-
-For basic concepts of camera development, see [Camera Development Overview](../subsystems/overview.md).
-
diff --git a/en/device-dev/guide/overview-10.md b/en/device-dev/guide/overview-10.md
deleted file mode 100644
index f2936c824fa1dc1ddee20998e9501f350f205651..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/overview-10.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Overview
-
-- [When to Use](#section191543223549)
-
-This document uses the I2C driver as an example to describe how to develop platform drivers based on the hardware driver foundation \(HDF\).
-
-> **CAUTION:**
->The sample code in this document is for reference only and cannot be directly used for commercial integration.
-
-## When to Use
-
-The HDF provides a standard driver framework for common peripherals. To use the APIs provided by the HDF to perform operations on peripherals, you only need to adapt the specific driver to the HDF.
-
-In this example, an I2C driver is used. [Figure 1](#fig148041484161) shows the sequence diagram of the I2C driver.
-
-**Figure 1** I2C driver sequence diagram
-
-
-
-
-- User Business: business-triggered driver
-- i2cManagerEntry: entry to the I2C manager, which is used to register the I2C manager with the HDF
-- I2cManager: I2C manager, which manages the I2C controller
-- I2cCntlr: I2C controller
-- i2cDriverEntry: entry to the I2C controller, which is used to register the I2C controller with the HDF
-
diff --git a/en/device-dev/guide/overview-13.md b/en/device-dev/guide/overview-13.md
deleted file mode 100644
index 608d2272089797a51ae741056816d32d5028c113..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/overview-13.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# 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.
-
-- **[Hardware Resources](hardware-resources.md)**
-
-- **[Input Driver Model](input-driver-model.md)**
-
-
diff --git a/en/device-dev/guide/overview-6.md b/en/device-dev/guide/overview-6.md
deleted file mode 100644
index 13a514937591a52c53f35897110ab7d949505d7a..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/overview-6.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Overview
-
-- [Display Effects](#section3997224182313)
-
-This document describes how to quickly set up an application development environment \(using the Hi3516DV300 development board\) for event data recorders running on OpenHarmony. An air quality monitoring application, AirQuality, is used as an example to describe how to create, develop, and debug your application.
-
-## Display Effects
-
-AirQuality displays information about the urban air quality on two pages, the home page and details page. The following GIF shows AirQuality on the DevEco Studio simulator.
-
-**Figure 1** Display effects of the AirQuality
-
-
-
-
diff --git a/en/device-dev/guide/overview-7.md b/en/device-dev/guide/overview-7.md
deleted file mode 100644
index a1d94bca1274c243b4046785121ecacd56a0a93b..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/overview-7.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Overview
-
-- [Display Effect](#section3997224182313)
-
-This document describes how to quickly set up a development environment \(using the Hi3516D V300 development board\) and develop a clock app running on OpenHarmony. You can click [here](https://gitee.com/openharmony/app_samples/tree/master/common/Clock) to obtain the sample code.
-
-## Display Effect
-
-The Clock app displays the current time, as shown in the following figure.
-
-**Figure 1** Clock display effect
-
-
-
-
diff --git a/en/device-dev/guide/overview.md b/en/device-dev/guide/overview.md
deleted file mode 100644
index 598fa8d3b918f7e9f37ec53fd3ff80c81b26254f..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/overview.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Overview
-
-Based on the Hi3861 platform, the OpenHarmony WLAN module provides abundant peripheral operation capabilities, including the I2C, I2S, ADC, UART, SPI, SDIO, GPIO, PWM, and flash memory. This document describes how to control GPIO pins by calling the OpenHarmony native development kit \(NDK\) interface to implement LED blinking. For details about how to control other IoT peripherals, see the API guide.
-
diff --git a/en/device-dev/guide/parsing-private-configuration-data.md b/en/device-dev/guide/parsing-private-configuration-data.md
deleted file mode 100644
index a66a1a0f634b3ceee01ba8ab6ad13a6a929abdaf..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/parsing-private-configuration-data.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Parsing Private Configuration Data
-
-You can obtain the sample code at **./drivers/framework/model/input/driver/input\_config\_parser.c**.
-
-The configuration parsing functions provided by the OSAL can parse the fields in the **hcs** file. For details, see the implementation of each function in **input\_config\_parser.c**. If the provided template cannot meet business requirements, you need to add required information to the **hcs** file and then develop parsing functions based on the added fields.
-
-```
-static int32_t ParseAttr(struct DeviceResourceIface *parser, const struct DeviceResourceNode *attrNode, BoardAttrCfg *attr)
-{
- int32_t ret;
- ret = parser->GetUint8(attrNode, "inputType", &attr->devType, 0); // Obtain the inputType field and save it in the BoardAttrCfg structure.
- CHECK_PARSER_RET(ret, "GetUint8");
- ...
- return HDF_SUCCESS;
-}
-```
-
diff --git a/en/device-dev/guide/photographing-3.md b/en/device-dev/guide/photographing-3.md
deleted file mode 100644
index 7d6450e761f1a0d4823c683ae95546de5a0a18fb..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/photographing-3.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# Photographing
-
-- [When to Use](#en-us_topic_0000001052170554_section1963312376119)
-- [Available APIs](#en-us_topic_0000001052170554_section56549532016)
-- [Limitations and Constraints](#en-us_topic_0000001052170554_section1165911177314)
-- [How to Develop](#en-us_topic_0000001052170554_section138543918214)
-
-## When to Use
-
-Use the camera module APIs to capture frames \(photographing\).
-
-## Available APIs
-
-**Table 1** APIs for photographing
-
-
-
-
-## Limitations and Constraints
-
-None
-
-## How to Develop
-
-1. Extend the **CameraDeviceCallback** class and call **OnCameraStatus** to customize operations when the camera device changes, for example, when a camera becomes available or unavailable.
-
- ```
- class SampleCameraDeviceCallback : public CameraDeviceCallback {
- void OnCameraStatus(std::string cameraId, int32_t status) override
- {
- // Do something when camera is available or unavailable.
- }
- };
- ```
-
-2. Extend the **FrameStateCallback** class. After obtaining the frame data, save the data as a file.
-
- ```
- static void SampleSaveCapture(const char *p, uint32_t size)
- {
- cout << "Start saving picture" << endl;
- struct timeval tv;
- gettimeofday(&tv, NULL);
- struct tm *ltm = localtime(&tv.tv_sec);
- if (ltm != nullptr) {
- ostringstream ss("Capture_");
- ss << "Capture" << ltm->tm_hour << "-" << ltm->tm_min << "-" << ltm->tm_sec << ".jpg";
-
- ofstream pic("/sdcard/" + ss.str(), ofstream::out | ofstream::trunc);
- cout << "write " << size << " bytes" << endl;
- pic.write(p, size);
- cout << "Saving picture end" << endl;
- }
- }
-
- class TestFrameStateCallback : public FrameStateCallback {
- void OnFrameFinished(Camera &camera, FrameConfig &fc, FrameResult &result) override
- {
- cout << "Receive frame complete inform." << endl;
- if (fc.GetFrameConfigType() == FRAME_CONFIG_CAPTURE) {
- cout << "Capture frame received." << endl;
- list surfaceList = fc.GetSurfaces();
- for (Surface *surface : surfaceList) {
- SurfaceBuffer *buffer = surface->AcquireBuffer();
- if (buffer != nullptr) {
- char *virtAddr = static_cast(buffer->GetVirAddr());
- if (virtAddr != nullptr) {
- SampleSaveCapture(virtAddr, buffer->GetSize());
- }
- surface->ReleaseBuffer(buffer);
- }
- delete surface;
- }
- delete &fc;
- }
- }
- };
- ```
-
-3. Extend the **CameraStateCallback** class and customize operations when the camera state changes \(configuration successful or failed, and creation successful or failed\).
-
- ```
- class SampleCameraStateMng : public CameraStateCallback {
- public:
- SampleCameraStateMng() = delete;
- SampleCameraStateMng(EventHandler &eventHdlr) : eventHdlr_(eventHdlr) {}
- ~SampleCameraStateMng()
- {
- if (recordFd_ != -1) {
- close(recordFd_);
- }
- }
- void OnCreated(Camera &c) override
- {
- cout << "Sample recv OnCreate camera." << endl;
- auto config = CameraConfig::CreateCameraConfig();
- config->SetFrameStateCallback(&fsCb_, &eventHdlr_);
- c.Configure(*config);
- cam_ = &c;
- }
- void OnCreateFailed(const std::string cameraId, int32_t errorCode) override {}
- void OnReleased(Camera &c) override {}
- };
- ```
-
-4. Create a **CameraKit** instance to set and obtain camera information.
-
- ```
- CameraKit *camKit = CameraKit::GetInstance();
- list camList = camKit->GetCameraIds();
- string camId;
- for (auto &cam : camList) {
- cout << "camera name:" << cam << endl;
- const CameraAbility *ability = camKit->GetCameraAbility(cam);
- /* Find the camera that fits your ability. */
- list sizeList = ability->GetSupportedSizes(0);
- if (find(sizeList.begin(), sizeList.end(), CAM_PIC_1080P) != sizeList.end()) {
- camId = cam;
- break;
- }
- }
- ```
-
-5. Create a **Camera** instance.
-
- ```
- EventHandler eventHdlr; // Create a thread to handle callback events.
- SampleCameraStateMng CamStateMng(eventHdlr);
-
- camKit->CreateCamera(camId, CamStateMng, eventHdlr);
- ```
-
-6. In the main process, synchronize configurations set by callback functions implemented in [step 1](#en-us_topic_0000001052170554_li378084192111), [step 2](#en-us_topic_0000001052170554_li8716104682913), and [step 3](#en-us_topic_0000001052170554_li6671035102514).
-
- ```
- void OnCreated(Camera &c) override
- {
- cout << "Sample recv OnCreate camera." << endl;
- auto config = CameraConfig::CreateCameraConfig();
- config->SetFrameStateCallback(&fsCb_, &eventHdlr_);
- c.Configure(*config);
- cam_ = &c;
- }
-
- void Capture()
- {
- if (cam_ == nullptr) {
- cout << "Camera is not ready." << endl;
- return;
- }
- FrameConfig *fc = new FrameConfig(FRAME_CONFIG_CAPTURE);
- Surface *surface = Surface::CreateSurface();
- if (surface == nullptr) {
- delete fc;
- }
- surface->SetWidthAndHeight(1920, 1080); /* 1920:width,1080:height */
- fc->AddSurface(*surface);
- cam_->TriggerSingleCapture(*fc);
- }
- ```
-
-
diff --git a/en/device-dev/guide/preparations-11.md b/en/device-dev/guide/preparations-11.md
deleted file mode 100644
index 50badfb8ff63a2f6fc2a5ee80fe58b0fa8a4221b..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/preparations-11.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Preparations
-
-Set up the environment by referring to [Setting Up a Standard OpenHarmony Environment](../quick-start/standard-system.md).
-
-> **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/preparations-8.md b/en/device-dev/guide/preparations-8.md
deleted file mode 100644
index e56d1485fdb5dfd7833cec5df4d23159168ca493..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/preparations-8.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# Preparations
-
-- [Setting Up the Development Environment and Creating a Project](#section1912530122716)
-
-## Setting Up the Development Environment and Creating a Project
-
-Download and install DevEco Studio. For details, see the [HUAWEI DevEco Studio User Guide](../../application-dev/quick-start/deveco-studio-(openharmony)-user-guide.md).
-
diff --git a/en/device-dev/guide/preparations.md b/en/device-dev/guide/preparations.md
deleted file mode 100644
index 9b4572fc68620f830d040b4537fecb852b9fc9dd..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/preparations.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Preparations
-
-- [Setting Up the Development Environment](#section1912530122716)
-- [Creating a Project](#section1456035192720)
-
-## Setting Up the Development Environment
-
-Download and install DevEco Studio. For details, see the [HUAWEI DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/software_install-0000001053582415).
-
-## Creating a Project
-
-1. Open the project wizard using either of the following methods:
- - If no project is open, select **Create HarmonyOS Project** on the welcome page.
- - If a project is already open, go to **File** \> **New** \> **New Project** on the menu bar.
-
-2. Choose the **Smart Vision** for **Device** and **Empty Feature Ability** for **Template**.
-
- 
-
-3. Click **Next** and configure the project.
- - **Project Name**: project name.
- - **Package Name**: software package name. By default, this name will also be used as your application ID. Your application must have a unique ID to be released.
- - **Save Location**: path for storing project files. The path cannot contain Chinese characters or spaces.
- - **Compatible API Version**: compatible API version.
-
-4. Click **Finish**. DevEco Studio will automatically generate the sample code and resources that match your project type. Wait until the project is created.
-
diff --git a/en/device-dev/guide/public_sys-resources/icon-caution.gif b/en/device-dev/guide/public_sys-resources/icon-caution.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/guide/public_sys-resources/icon-caution.gif and /dev/null differ
diff --git a/en/device-dev/guide/public_sys-resources/icon-danger.gif b/en/device-dev/guide/public_sys-resources/icon-danger.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/guide/public_sys-resources/icon-danger.gif and /dev/null differ
diff --git a/en/device-dev/guide/public_sys-resources/icon-note.gif b/en/device-dev/guide/public_sys-resources/icon-note.gif
deleted file mode 100644
index 6314297e45c1de184204098efd4814d6dc8b1cda..0000000000000000000000000000000000000000
Binary files a/en/device-dev/guide/public_sys-resources/icon-note.gif and /dev/null differ
diff --git a/en/device-dev/guide/public_sys-resources/icon-notice.gif b/en/device-dev/guide/public_sys-resources/icon-notice.gif
deleted file mode 100644
index 86024f61b691400bea99e5b1f506d9d9aef36e27..0000000000000000000000000000000000000000
Binary files a/en/device-dev/guide/public_sys-resources/icon-notice.gif and /dev/null differ
diff --git a/en/device-dev/guide/public_sys-resources/icon-tip.gif b/en/device-dev/guide/public_sys-resources/icon-tip.gif
deleted file mode 100644
index 93aa72053b510e456b149f36a0972703ea9999b7..0000000000000000000000000000000000000000
Binary files a/en/device-dev/guide/public_sys-resources/icon-tip.gif and /dev/null differ
diff --git a/en/device-dev/guide/public_sys-resources/icon-warning.gif b/en/device-dev/guide/public_sys-resources/icon-warning.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/guide/public_sys-resources/icon-warning.gif and /dev/null differ
diff --git a/en/device-dev/guide/running-on-the-device-9.md b/en/device-dev/guide/running-on-the-device-9.md
deleted file mode 100644
index 72fdad2eca6863415f1db8890939a18f49d09103..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/running-on-the-device-9.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Running on the 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/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 [Getting Started with Hi3516](../quick-start/standard-system.md). 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:
-
- ```
- developtools/hdc_standard/prebuilt/windows/hdc_std.exe
- ```
-
- Change the HDC client name to **hdc.exe** and add the path above to the system environment variable **path**.
-
-2. Open the **cmd** window, and run the following commands to push the HAP file to the device directory, and install it:
-
- ```
- hdc smode
- hdc target mount
- hdc file send clock.hap /data/clock.hap
- hdc shell chmod 666 /data/clock.hap
- hdc shell bm install -p /data/clock.hap
- ```
-
-3. Run the following command to start the app. **ohos.samples.clock** indicates the app package name, and **MainAbility** indicates the ability started by the app.
-
- ```
- hdc shell aa start -d 123 -a ohos.samples.clock.MainAbility -b ohos.samples.clock
- ```
-
-4. \(Optional\) Run the following command to uninstall the app. **ohos.samples.clock** indicates the app package name.
-
- ```
- hdc shell bm uninstall -n ohos.samples.clock
- ```
-
-
diff --git a/en/device-dev/guide/running-on-the-device.md b/en/device-dev/guide/running-on-the-device.md
deleted file mode 100644
index 79167a2934ce10c5e799b2c59d09830ac68e7ac4..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/running-on-the-device.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Running on the Device
-
-Before you install the application 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 compile, burn, and run an image, see the [Getting Started with Hi3516](../quick-start/hi3516-development-board.md). After the image is running normally and the system is started properly, perform the following steps to install or uninstall the application:
-
-1. Store the compiled unsigned application installation package and installation tool in an SD card and insert the SD card into the development board slot. The installation tool is in **idev\_tools** of the directory where the image file is generated.
-2. Run the following command to disable signature verification, which is enabled by default for application installation:
-
- ```
- ./sdcard/dev_tools/bin/bm set -s disable
- ```
-
-3. Run the following command to install the application:
-
- ```
- ./sdcard/dev_tools/bin/bm install -p /sdcard/airquality.hap
- ```
-
- The **dev\_tools** directory stores the installation tool, and **airquality.hap** is the application installation package. Replace it with actual the package name.
-
-4. After the application is installed, touch the application icon on the home screen to enter the application.
-
- **Figure 1** Home screen
- 
-
-5. \(Optional\) Uninstall the application.
-
- Touch and hold the application icon on the home screen, and touch the uninstall button in the displayed menu.
-
-
diff --git a/en/device-dev/guide/screen-and-camera-control.md b/en/device-dev/guide/screen-and-camera-control.md
deleted file mode 100644
index e017e08b1bcec34edc084d41bbc1fd0f1773461f..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/screen-and-camera-control.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Screen and Camera Control
-
-- **[Overview](overview-1.md)**
-
-- **[Development Guidelines](development-guidelines-2.md)**
-
-- **[Use Case](use-case-5.md)**
-
-
diff --git a/en/device-dev/guide/setting-up-the-environment.md b/en/device-dev/guide/setting-up-the-environment.md
deleted file mode 100644
index 9c2593432e6ebf03654d188c35e1a1953fe3e5f0..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/setting-up-the-environment.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Setting Up the Environment
-
-Set up the environment by referring to [Setting Up a Standard OpenHarmony Environment](../quick-start/standard-system.md).
-
-> **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/signing-and-packaging.md b/en/device-dev/guide/signing-and-packaging.md
deleted file mode 100644
index 80e390ea1a19510c5efeca200abe14e667f36b46..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/signing-and-packaging.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Signing and Packaging
-
-After finishing writing the app code, you need to sign and package the app before running it on a real device. For details, see [Signing and Packaging Guide](../../application-dev/quick-start/configuring-the-openharmony-app-signature.md).
-
diff --git a/en/device-dev/guide/startup-log-analysis.md b/en/device-dev/guide/startup-log-analysis.md
deleted file mode 100644
index 967f333237e42aea6541c8377786360b6f9ce7c8..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/startup-log-analysis.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Startup Log Analysis
-
-The following is part of the startup log:
-
-```
-[I/HDF_INPUT_DRV] HdfInputManagerInit: enter // Initialize the input device manager.
-[I/HDF_INPUT_DRV] HdfInputManagerInit: exit succ // The initialization is successful.
-[I/osal_cdev] add cdev hdf_input_host success
-[I/HDF_LOG_TAG] HdfTouchDriverProbe: enter // Initialize the input common driver.
-[I/HDF_LOG_TAG] HdfTouchDriverProbe: main_touch exit succ // The initialization is successful.
-[I/osal_cdev] add cdev hdf_input_event1 success
-[I/HDF_INPUT_DRV] HdfGoodixChipInit: enter // Initialize the input chip driver.
-[I/HDF_INPUT_DRV] ChipDetect: IC FW version is 0x1060
-[I/HDF_INPUT_DRV] Product_ID: 911_1060, x_sol = 960, y_sol = 480
-[I/HDF_LOG_TAG] ChipDriverInit: chipDetect succ, ret = 0
-[I/HDF_LOG_TAG] InputDeviceInstance: inputDev->devName = main_touch
-[I/HDF_INPUT_DRV] HdfGoodixChipInit: exit succ, chipName = gt911 // The initialization is successful.
-```
-
diff --git a/en/device-dev/guide/third-party-sdk-integration.md b/en/device-dev/guide/third-party-sdk-integration.md
deleted file mode 100644
index db6388833d5fc135ad5dc7dd8f9109f9c57d139b..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/third-party-sdk-integration.md
+++ /dev/null
@@ -1,325 +0,0 @@
-# Third-Party SDK Integration
-
-- [Planning a Directory Structure](#section1736472718351)
-- [Building the Service libs](#section442815485351)
-- [Compiling Adaptation Code](#section3984721113613)
-- [Compiling Code](#section830417531286)
-- [Compiling a Script](#section13500201173710)
-- [Compiling Service Code](#section8754114803918)
-- [Runtime](#section7737749184012)
-- [End](#section153301392411)
-
-To build a more open and complete Internet of Things \(IoT\) ecosystem, OpenHarmony has opened up a group of directories to integrate SDKs provided by different vendors. This guide describes how to integrate SDKs into OpenHarmony based on the Hi3861 board.
-
-## Planning a Directory Structure
-
-A third-party SDK consists of a static library and the adaption code. The SDK service logic is compiled to obtain the static library **libs** through the hardware module tool chain. Each module has its corresponding **libs**. The southbound APIs of the SDK are different from the APIs of OpenHarmony. The difference can be shielded by using the adaptation code **adapter**. Different modules can share the same **adapter**.
-
-Based on the preceding features, third-party SDK directories can be divided as follows in the OpenHarmony directory structure:
-
-- domains/iot/link/: The **adapter** is stored in this directory and is decoupled from the module.
-- device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/: The service library **libs** is stored in this directory and is bound to the module.
-
-You must perform the following steps before adaptation. The following uses the demolink SDK as an example.
-
-1. Create vendor directories, **domains/iot/link/demolink/** and **device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/demolink/**, to isolate different vendors.
-2. Create the **domains/iot/link/demolink/BUILD.gn** file to build the adaptation code.
-3. Create the **device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/demolink/libs/** directory to store the service library **libs**.
-
-```
-.
-├── domains
-│ └── iot
-│ └── link
-│ ├── demolink
-│ │ └── BUILD.gn
-│ ├── libbuild
-│ │ └── BUILD.gn
-│ └── BUILD.gn
-└── device
- └── hisilicon
- └── hispark_pegasus
- └── sdk_liteos
- └── 3rd_sdk
- └── demolink
- └── libs
-```
-
-## Building the Service **libs**
-
-Generally, the platform SDK service is provided as a static library. After obtaining the OpenHarmony code, the platform vendor needs to compile the service library **libs** based on the corresponding hardware module vendor and save the compilation result to the **device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/demolink/libs/** directory. The following describes how to build the service library **libs**.
-
-OpenHarmony has planned the **domains/iot/link/libbuild/** directory for compiling the service library **libs**. This directory contains the **domains/iot/link/libbuild/BUILD.gn** and **domains/iot/link/BUILD.gn** files. The directory structure is as follows:
-
-```
-.
-└── domains
- └── iot
- └── link
- ├── demolink
- │ └── BUILD.gn
- ├── libbuild
- │ └── BUILD.gn
- └── BUILD.gn
-```
-
-Before building **libs**, you must perform the following steps:
-
-1. Place the service source code files \(including **.c** and **.h** files\) in the **domains/iot/link/libbuild/** directory.
-
- ```
- .
- └── domains
- └── iot
- └── link
- ├── demolink
- │ ├── demosdk_adapter.c
- │ ├── demosdk_adapter.h
- │ └── BUILD.gn
- ├── libbuild
- │ ├── demosdk.c
- │ ├── demosdk.h
- │ └── BUILD.gn
- └── BUILD.gn
- ```
-
-2. Adapt to the **domains/iot/link/libbuild/BUILD.gn** file and restore the file after the compilation is complete.
-
- In the **BUILD.gn** file, **sources** specifies the source file to build and **include\_dirs** specifies the path of the dependent header file so that the target build result is the static library **libdemosdk.a**.
-
- ```
- static_library("demosdk") {
- sources = [
- "demosdk.c"
- ]
- include_dirs = [
- "//domains/iot/link/libbuild",
- "//domains/iot/link/demolink"
- ]
- }
- ```
-
-3. Adapt to the **domains/iot/link/BUILD.gn** file and restore the file after the compilation is complete.
-
- The **BUILD.gn** file is used to specify build entries. You need to enter all static library entries to be compiled in **features** so that the **domains/iot/link/libbuild/BUILD.gn** file is used in the build.
-
- ```
- import("//build/lite/config/subsystem/lite_subsystem.gni")
- import("//build/lite/config/component/lite_component.gni")
- lite_subsystem("iot") {
- subsystem_components = [
- ":link"
- ]
- }
- lite_component("link") {
- features = [
- "libbuild:demosdk"
- ]
- }
- ```
-
-
-After the preceding operations are complete, run the **hb build -T //domains/iot/link:iot** command in the root directory of the code and then check whether the target library file is generated in the **out/hispark\_pegasus/wifiiot\_hispark\_pegasus/libs/** directory.
-
-
-
-Copy the library file to the **device/hisilicon/hispark\_pegasus/sdk\_liteos/3rd\_sdk/demolink/libs/** directory and delete the **.c** and **.h** files from the **domains/iot/link/libbuild/** directory.
-
-## Compiling Adaptation Code
-
-## Compiling Code
-
-The APIs used in the platform SDK are different from the OpenHarmony APIs and cannot be directly used. Therefore, the adaptation code **adapter** is required for intermediate conversion. This section uses **DemoSdkCreateTask** in **domains/iot/link/demolink/demosdk\_adapter.c** as an example to describe how to compile adaptation code on OpenHarmony.
-
-1. Check the description, parameters, and return values of the **DemoSdkCreateTask** API to adapt.
-
- ```
- struct TaskPara {
- char *name;
- void *(*func)(char* arg);
- void *arg;
- unsigned char prio;
- unsigned int size;
- };
-
- /*
- * Create a thread for the IoT OS.
- * Return 0 if the operation is successful; return a non-zero value otherwise.
- */
- int DemoSdkCreateTask(unsigned int *handle, const struct TaskPara *para);
- ```
-
-2. Check the OpenHarmony API document, select an API with similar features, and compare the parameters and usage. This guide uses **osThreadNew** as an example. By comparing this API with **DemoSdkCreateTask**, you can find that the parameters on which the two APIs depend are basically the same, but the structures to which the parameters belong are different.
-
- ```
- typedef struct {
- const char *name; ///< name of the thread
- uint32_t attr_bits; ///< attribute bits
- void *cb_mem; ///< memory for control block
- uint32_t cb_size; ///< size of provided memory for control block
- void *stack_mem; ///< memory for stack
- uint32_t stack_size; ///< size of stack
- osPriority_t priority; ///< initial thread priority (default: osPriorityNormal)
- TZ_ModuleId_t tz_module; ///< TrustZone module identifier
- uint32_t reserved; ///< reserved (must be 0)
- } osThreadAttr_t;
-
- /// Create a thread and add it to Active Threads.
- /// \param[in] func thread function.
- /// \param[in] argument pointer that is passed to the thread function as start argument.
- /// \param[in] attr thread attributes; NULL: default values.
- /// \return thread ID for reference by other functions or NULL in case of error.
- osThreadId_t osThreadNew (osThreadFunc_t func, void *argument, const osThreadAttr_t *attr);
- ```
-
-3. Perform code adaptation to shield the difference.
-
- ```
- int DemoSdkCreateTask(unsigned int *handle, const struct TaskPara *para)
- {
- osThreadAttr_t attr = {0};
- osThreadId_t threadId;
- if (handle == 0 || para == 0) {
- return DEMOSDK_ERR;
- }
- if (para->func == 0) {
- return DEMOSDK_ERR;
- }
- if (para->name == 0) {
- return DEMOSDK_ERR;
- }
- attr.name = para->name;
- attr.priority = para->prio;
- attr.stack_size = para->size;
- threadId = osThreadNew((osThreadFunc_t)para->func, para->arg, &attr);
- if (threadId == 0) {
- printf("osThreadNew fail\n");
- return DEMOSDK_ERR;
- }
- *(unsigned int *)handle = (unsigned int)threadId;
- return DEMOSDK_OK;
- }
- ```
-
-
-## Compiling a Script
-
-After completing code adaptation, create the **BUILD.gn** file in the directory where the **adapter** is located. This file can be used to compile the adaptation code into a static library and link the static library to the **bin** package during the entire package build. In the **domains/iot/link/demolink/BUILD.gn** file, **sources** specifies the source files to be used in the build and **include\_dirs** specifies the path of the dependent header file so that the target build result is the static library **libdemolinkadapter.a**.
-
-```
-import("//build/lite/config/component/lite_component.gni")
-static_library("demolinkadapter") {
- sources = [
- "demosdk_adapter.c"
- ]
- include_dirs = [
- "//kernel/liteos-m/kal/cmsis",
- "//domains/iot/link/demolink"
- ]
-}
-```
-
-Modify the **domains/iot/link/BUILD.gn** file so that the **domain/iot/hilink/BUILD.gn** file is used in the build.
-
-```
-import("//build/lite/config/subsystem/lite_subsystem.gni")
-import("//build/lite/config/component/lite_component.gni")
-lite_subsystem("iot") {
- subsystem_components = [
- ":link"
- ]
-}
-lite_component("link") {
- features = [
- "demolink:demolinkadapter"
- ]
-}
-```
-
-## Compiling Service Code
-
-After the service library **libs** and adaptation code are ready, compile the service entry function to call the service entry of the third-party SDK.
-
-The following uses **demolink** as an example to describe how to compile code in **applications/sample/wifi-iot/app/** to call the **demosdk** entry function.
-
-1. Create a directory.
-
- Before compiling a service, you must create a directory \(or a directory structure\) in **applications/sample/wifi-iot/app/** to store service source code files.
-
- For example, add the service directory **demolink** to the app, and create the service entry code **helloworld.c** and compile the **BUILD.gn** file.
-
- ```
- .
- └── applications
- └── sample
- └── wifi-iot
- └── app
- │── demolink
- │ │── helloworld.c
- │ └── BUILD.gn
- └── BUILD.gn
- ```
-
-2. Compile service code.
-
- Compile the service entry function **DemoSdkMain** in the **helloworld.c** file, call the service entry **DemoSdkEntry** of **demolink**, and call the entry function through **SYS\_RUN\(\)** to start the service.
-
- ```
- #include "hos_init.h"
- #include "demosdk.h"
-
- void DemoSdkMain(void)
- {
- DemoSdkEntry();
- }
-
- SYS_RUN(DemoSdkMain);
- ```
-
-3. Compile build scripts.
-
- Add the **applications/sample/wifi-iot/app/demolink/BUILD.gn** file, specify the paths of the source code and header file, and compile the static library file **libexample\_demolink.a**.
-
- ```
- static_library("example_demolink") {
- sources = [
- "helloworld.c"
- ]
- include_dirs = [
- "//utils/native/lite/include",
- "//domains/iot/link/libbuild"
- ]
- }
- ```
-
- Modify the **applications/sample/wifi-iot/app/BUILD.gn** file so that **demolink** is used in compilation.
-
- ```
- import("//build/lite/config/component/lite_component.gni")
- lite_component("app") {
- features = [
- "demolink:example_demolink"
- ]
- }
- ```
-
-
-## Runtime
-
-Run the **hb build** command in the root directory of the code to compile and output the version package. Start **demolink**. The following shows the running result, which is consistent with the expected result of **demolink**.
-
-```
-ready to OS start
-sdk ver:Hi3861V100R001C00SPC024 2020-08-05 16:30:00
-formatting spiffs...
-FileSystem mount ok.
-wifi init success!
-it is demosdk entry.
-it is demo biz: hello world.
-it is demo biz: hello world.
-```
-
-## End
-
-The third-party SDK integration is complete.
-
diff --git a/en/device-dev/guide/use-case-5.md b/en/device-dev/guide/use-case-5.md
deleted file mode 100644
index f4e481e1cef8c4815def24a9aa9c604df9b01680..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/use-case-5.md
+++ /dev/null
@@ -1,64 +0,0 @@
-# Use Case
-
-This use case takes **camera\_sample** \(contained in the source code\) as an example for photographing, recording, and previewing on the development board.
-
-- You can obtain source code of the sample from **applications/sample/camera/media/camera\_sample.cpp**.
-- Before running the sample camera, you need to compile, burn, and run the image. For details, see [Getting Started with Hi3516](../quick-start/hi3516-development-board.md).
-
- > **NOTE:**
- >After the development board is started, the home screen is loaded and displayed above the media layer by default. To prevent covering **camera\_sample**, you should remove the home screen during compilation or packaging.
- >How to Remove: In **build/lite/components/applications.json**, comment out or delete the **//applications/sample/camera/launcher:launcher\_hap** line from the **target** field of **camera\_sample\_app**.
-
-- The compilation result of the sample code is stored in **out/hi3516dv300/ipcamera\_hi3516dv300\_liteos/dev\_tools/bin**. To ensure that the code can be executed on the development board, you can copy the file to a TF card through a card reader, or modify the compilation script of **camera\_sample** to copy the compilation result to **rootfs.img**.
-
- Modify the first **output\_dir** in the source code path **applications/sample/camera/media/BUILD.gn**.
-
- - Before: **output\_dir = "$root\_out\_dir/dev\_ools"**
- - After: **output\_dir = "$root\_out\_dir/"**
-
- Recompile the source code repository and burn the code into the development board. Then you can find the **camera\_sample** file in the **bin** directory of the board.
-
- > **NOTICE:**
- >You should insert a TF card \(up to 128 GB supported\) for photographing and video recording before system startup. This way, the TF card will be automatically mounted to the **/sdcard** directory. If you insert the TF card after the system is started, you have to manually mount the TF card.
- >To view the photos and videos in the TF card, copy them to a computer. If you just want to preview photos and videos, you do not need to insert a TF card.
-
-- Perform the following steps to run the sample:
-
-1. Run the **cd** command to go to the end path of the executable program and start **camera\_sample** by running the command in the following figure.
-
- **Figure 1** Starting camera\_sample
- 
-
- The control commands are displayed as shown in the preceding figure. Press **S** to stop the current operation \(including video recording and preview\), and press **Q** to exit the program.
-
-2. Press **1** to take a photo in JPG format. The photo is saved in the **/sdcard** directory and named **Capture\***.
-
- **Figure 2** Serial port logs displayed after the photographing command is executed
- 
-
- To view the saved file, exit the program and enter the file system. To start the program again, return to the previous step.
-
- **Figure 3** Saved files
- 
-
-3. Press **2** to start recording. The video file is in MP4 format and saved in the **/sdcard** directory with the name **Record\***. Press **S** to stop recording.
-
- **Figure 4** Serial port logs displayed after the recording command is executed
- 
-
-4. Press **3** to start preview. The preview is displayed on the screen. Press **S** to stop preview.
-
- **Figure 5** Serial port logs displayed after the preview command is executed
- 
-
- The following figure shows the preview.
-
- **Figure 6** Preview effect
- 
-
-5. Press **Q** to exit.
-
- **Figure 7** Serial port logs displayed after the exit command is executed
- 
-
-
diff --git a/en/device-dev/guide/use-case.md b/en/device-dev/guide/use-case.md
deleted file mode 100644
index 274e2d375df15cf35285544f1c48c37f6b8e3c94..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/use-case.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Use Case
-
-- For details about the development board, compilation, burning, and image running, see [Getting Started with Hi3518](../quick-start/hi3518-development-board.md). A compilation result file of sample code is stored in **out/ipcamera\_hi3518ev300/dev\_tools/bin/camera\_sample**. You can copy the file to a TF card, or modify the compilation script of **camera\_sample** to copy the result to **rootfs.img**.
-
- Modify **output\_dir** in **applications/sample/camera/media/BUILD.gn**.
-
- - Before: **output\_dir = "$root\_out\_dir/dev\_tools"**
- - After: **output\_dir = "$root\_out\_dir/"**
-
- Recompile the source code repository and burn the code into the development board. Then you can find the **camera\_sample** file in the **bin** directory of the board.
-
-- The sample code for camera development is stored in **applications/sample/camera/media/camera\_sample.cpp**.
-
- > **NOTICE:**
- >You should insert a TF card \(maximum capacity: 128 GB\) for photographing and video recording functions. After the system is started, the TF card is automatically mounted to the **/sdcard** directory. If the TF card is inserted after the system is started, you have to manually mount the TF card. To view the photos and videos in the TF card, copy the content to a computer. The preview function does not require a TF card.
-
-
-1. Run the **cd** command to go to the end path of the executable program and start **camera\_sample** by running the command in the following figure.
-
- **Figure 1** Starting camera\_sample
- 
-
- The control commands are displayed as shown in the preceding figure. Press **S** to stop the current operation \(including video recording and preview\), and press **Q** to exit the program.
-
-2. Press **1** to take a photo in JPG format. The photo is saved in the **/sdcard** directory and named **Capture\***.
-
- **Figure 2** Serial port logs displayed after the photographing command is executed
- 
-
- To view the saved file, exit the program and enter the file system. To start the program again, return to the previous step.
-
- **Figure 3** Saved files
- 
-
-3. Press **2** to start recording. The video file is in MP4 format and saved in the **/sdcard** directory with the name **Record\***. Press **S** to stop recording.
-
- **Figure 4** Serial port logs displayed after the recording command is executed
- 
-
-4. Press **Q** to exit.
-
- **Figure 5** Serial port logs displayed after the exit command is executed
- 
-
-
diff --git a/en/device-dev/guide/verification.md b/en/device-dev/guide/verification.md
deleted file mode 100644
index 55254e77cd032307a97cc73ffa3b45169789be56..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/verification.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Verification
-
-For details about the compilation and burning processes, see [Modifying Source Code](../quick-start/running-a-hello-world-program.md) and [Burning Images](../quick-start/wlan-connection.md) in _Getting Started with Hi3861_.
-
-After the preceding two steps are complete, press the **RST** button to reset the module. The LED blinks periodically, which meets the expectation. The verification is complete.
-
-**Figure 1** LED blinking
-
-
diff --git a/en/device-dev/guide/visual-application-development.md b/en/device-dev/guide/visual-application-development.md
deleted file mode 100644
index b13654cffb462ca5fa2919848035a3e8b5f9a6ac..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/visual-application-development.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Visual Application Development
-
-- **[Overview](overview-6.md)**
-
-- **[Preparations](preparations.md)**
-
-- **[Adding Pages](adding-pages.md)**
-
-- **[Building the Home Page](building-the-home-page.md)**
-
-- **[Building the Details Page](building-the-details-page.md)**
-
-- **[Debugging and Packaging](debugging-and-packaging.md)**
-
-- **[Running on the Device](running-on-the-device.md)**
-
-- **[FAQs](faqs.md)**
-
-
diff --git a/en/device-dev/guide/wlan-connected-products.md b/en/device-dev/guide/wlan-connected-products.md
deleted file mode 100644
index 184f46eb0e144c6d086c2b35264557825fe5bb8e..0000000000000000000000000000000000000000
--- a/en/device-dev/guide/wlan-connected-products.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# WLAN-connected Products
-
-- **[LED Peripheral Control](led-peripheral-control.md)**
-
-
diff --git a/en/device-dev/kernel/Readme-EN.md b/en/device-dev/kernel/Readme-EN.md
index 2ec9f17abde6255b6bfb7b20df50fac5357972ea..b00926f092b5c5a566464d21458e1d6c589e8f71 100644
--- a/en/device-dev/kernel/Readme-EN.md
+++ b/en/device-dev/kernel/Readme-EN.md
@@ -1,93 +1,87 @@
-# Kernel
-
-- [Lite Kernel](lite-kernel.md)
- - [OpenHarmony Lite Kernel Basic Functions](openharmony-lite-kernel-basic-functions.md)
- - [Process](process.md)
- - [Thread](thread.md)
- - [Memory](memory.md)
- - [Network](network.md)
-
- - [OpenHarmony Lite Kernel File System](openharmony-lite-kernel-file-system.md)
- - [VFS](vfs.md)
- - [NFS](nfs.md)
- - [RAMFS](ramfs.md)
- - [FAT](fat.md)
- - [JFFS2](jffs2.md)
-
- - [Standard Library](standard-library.md)
- - [Standard Library](standard-library-0.md)
- - [Differences from the Linux Standard Library](differences-from-the-linux-standard-library.md)
-
- - [Commissioning](commissioning.md)
- - [Introduction to the Shell](introduction-to-the-shell.md)
- - [Shell Command Development Guidelines](shell-command-development-guidelines.md)
- - [Shell Command Programming Example](shell-command-programming-example.md)
- - [Shell Command Reference](shell-command-reference.md)
- - [System Commands](system-commands.md)
- - [cpup](cpup.md)
- - [date](date.md)
- - [dmesg](dmesg.md)
- - [exec](exec.md)
- - [free](free.md)
- - [help](help.md)
- - [hwi](hwi.md)
- - [kill](kill.md)
- - [log](log.md)
- - [memcheck](memcheck.md)
- - [oom](oom.md)
- - [pmm](pmm.md)
- - [reset](reset.md)
- - [sem](sem.md)
- - [stack](stack.md)
- - [su](su.md)
- - [swtmr](swtmr.md)
- - [systeminfo](systeminfo.md)
- - [task](task.md)
- - [uname](uname.md)
- - [vmm](vmm.md)
- - [watch](watch.md)
-
- - [File Commands](file-commands.md)
- - [cat](cat.md)
- - [cd](cd.md)
- - [chgrp](chgrp.md)
- - [chmod](chmod.md)
- - [chown](chown.md)
- - [cp](cp.md)
- - [format](format.md)
- - [ls](ls.md)
- - [lsfd](lsfd.md)
- - [mkdir](mkdir.md)
- - [mount](mount.md)
- - [partinfo](partinfo.md)
- - [partition](partition.md)
- - [pwd](pwd.md)
- - [rm](rm.md)
- - [rmdir](rmdir.md)
- - [statfs](statfs.md)
- - [sync](sync.md)
- - [touch](touch.md)
- - [writeproc](writeproc.md)
- - [umount](umount.md)
-
- - [Network Commands](network-commands.md)
- - [arp](arp.md)
- - [dhclient](dhclient.md)
- - [dns](dns.md)
- - [ifconfig](ifconfig.md)
- - [ipdebug](ipdebug.md)
- - [netstat](netstat.md)
- - [ntpdate](ntpdate.md)
- - [ping](ping.md)
- - [ping6](ping6.md)
- - [telnet](telnet.md)
- - [tftp](tftp.md)
-
- - [Magic Key Usage](magic-key-usage.md)
- - [User-Space Exception Information](user-space-exception-information.md)
-
-- [Linux Kernel](linux-kernel.md)
- - [Linux Kernel Overview](linux-kernel-overview.md)
- - [Guidelines for Using Patches on OpenHarmony Development Boards](guidelines-for-using-patches-on-openharmony-development-boards.md)
- - [Guidelines for Compiling and Building the Linux Kernel](guidelines-for-compiling-and-building-the-linux-kernel.md)
+# Kernel
+- [Kernel for Mini and Small Systems](kernel-lite.md)
+ - [Kernel for Mini Systems](kernel-lite-mini.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 for Standard Systems](kernel-standard.md)
+ - [Linux Kernel Overview](kernel-standard-des.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/arp.md b/en/device-dev/kernel/arp.md
deleted file mode 100644
index 0589669289c590d43958472e8a660866098dd165..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/arp.md
+++ /dev/null
@@ -1,114 +0,0 @@
-# arp
-
-- [Command Function](#section201149459368)
-- [Syntax](#section579813484364)
-- [Parameter Description](#section168065311366)
-- [Usage](#section19190125723612)
-- [Example](#section10383416372)
-
-## Command Function
-
-On an Ethernet, hosts communicate with each other using MAC addresses \(non-IP addresses\). Therefore, IP addresses must be converted into MAC addresses so that hosts can communicate with each other on a LAN \(Ethernet\). To resolve this issue, the host stores a table containing the mapping between IP addresses and MAC addresses, that is, the ARP cache table. When the host needs to send an IP packet to the destination IP address on a LAN, the host can query the destination MAC address from the ARP cache table. The ARP cache table is maintained by the TCP/IP protocol stack. You can run the **arp** command to view and modify the ARP cache table.
-
-## Syntax
-
-arp
-
-arp \[_-i IF_\] -s _IPADDR HWADDR_
-
-arp \[_-i IF_\] -d _IPADDR_
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
No parameter
-
-
Prints the content of the entire ARP cache table.
-
-
N/A
-
-
-
-i IF
-
-
Indicates the network interface. This parameter is optional.
-
-
N/A
-
-
-
-s IPADDR
-
HWADDR
-
-
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
-
-
Deletes an ARP entry.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- The **arp** command is used to query and modify the ARP cache table of the TCP/IP protocol stack. If ARP entries for IP addresses on different subnets are added, the protocol stack returns a failure message.
-- This command can be used only after the TCP/IP protocol stack is enabled.
-
-## Example
-
-Example:
-
-1. Enter **arp**.
-
- **Figure 1** Printing the entire ARP cache table
-
-
- 
-
- **Table 2** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
Address
-
-
Indicates the IPv4 address of a network device.
-
-
-
HWaddress
-
-
Indicates the MAC address of a network device.
-
-
-
Iface
-
-
Indicates the name of the interface used by the ARP entry.
-
-
-
Type
-
-
Indicates whether the ARP entry is dynamic or static. A dynamic ARP entry is automatically created by the protocol stack, and a static ARP entry is added by the user.
-
-
-
-
-
-
diff --git a/en/device-dev/kernel/cat.md b/en/device-dev/kernel/cat.md
deleted file mode 100644
index b6cbfd94caeb9d9e14769da53b3e7ae69df1f4eb..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/cat.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# cat
-
-- [Command Function](#section16710153391315)
-- [Syntax](#section1699392313158)
-- [Parameter Description](#section1677217374136)
-- [Usage](#section186772414131)
-- [Example](#section12158131814561)
-- [Output](#section183926225561)
-
-## Command Function
-
-This command is used to display the content of a text file.
-
-## Syntax
-
-cat \[_pathname_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
pathname
-
-
Indicates the file path.
-
-
An existing file
-
-
-
-
-
-## Usage
-
-Run the **cat** \[_pathname_\] command to display the content of a text file.
-
-## Example
-
-Enter **cat hello-harmony.txt**.
-
-## Output
-
-**Figure 1** Viewing content of the **hello-harmony.txt** file
-
-
diff --git a/en/device-dev/kernel/cd.md b/en/device-dev/kernel/cd.md
deleted file mode 100644
index 52825654be515c883babb87db3131038d7285492..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/cd.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# cd
-
-- [Command Function](#section11690184921316)
-- [Syntax](#section75695409569)
-- [Parameter Description](#section71961353181311)
-- [Usage](#section3629759111317)
-- [Example](#section211620301412)
-- [Output](#section1968117214577)
-
-## Command Function
-
-This command is used to change the current working directory.
-
-## Syntax
-
-cd \[_path_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
path
-
-
Indicates the file path.
-
-
The user must have the execution (search) permission for the specified directory.
-
-
-
-
-
-## Usage
-
-- If the **path** parameter is not specified, the system switches to the root directory.
-- If the **path** parameter is specified, the system switches to the specified path.
-- The **path** value starting with a slash \(/\) represents the root directory.
-- The **path** value starting with a dot \(.\) represents the current directory.
-- The **path** value starting with two dots \(..\) represents the parent directory.
-
-## Example
-
-Enter **cd ..**.
-
-## Output
-
-**Figure 1** Directory switching result
-
-
diff --git a/en/device-dev/kernel/chgrp.md b/en/device-dev/kernel/chgrp.md
deleted file mode 100644
index bca849032f2c618bf837b6a5b052edf7a1d4a384..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/chgrp.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# chgrp
-
-- [Command Function](#section6103119161418)
-- [Syntax](#section186958132141)
-- [Parameter Description](#section81796174141)
-- [Usage](#section14330152417140)
-- [Example](#section951823119149)
-- [Output](#section14271133125715)
-
-## Command Function
-
-This command is used to change a file group.
-
-## Syntax
-
-chgrp \[_group_\] \[_pathname_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
group
-
-
Indicates the file group.
-
-
[0, 0xFFFFFFFF]
-
-
-
pathname
-
-
Indicates the file path.
-
-
An existing file
-
-
-
-
-
-## Usage
-
-By specifying a file group before the file name in this command, you can change the group to which the file belongs.
-
-## Example
-
-Enter **chgrp 100 hello-harmony.txt**.
-
-## Output
-
-**Figure 1** Changing the group of the **hello-harmony.txt** file to **100**
-
-
diff --git a/en/device-dev/kernel/chmod.md b/en/device-dev/kernel/chmod.md
deleted file mode 100644
index 0645a96d31a8c52cd6c39b11213154c2bdf36025..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/chmod.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# chmod
-
-- [Command Function](#section13992936121418)
-- [Syntax](#section63342439147)
-- [Parameter Description](#section894414671411)
-- [Usage](#section182415221419)
-- [Example](#section8518195718147)
-- [Output](#section127391818158)
-
-## Command Function
-
-This command is used to change the file operation permission.
-
-## Syntax
-
-chmod \[_mode_\] \[_pathname_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
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).
-
-
[0, 777]
-
-
-
pathname
-
-
Indicates the file path.
-
-
An existing file
-
-
-
-
-
-## Usage
-
-By specifying the **mode** parameter before the file name, you can change the permission for this file.
-
-## Example
-
-Enter **chmod 666 hello-harmony.txt**.
-
-## Output
-
-**Figure 1** Changing the permission on the **hello-harmony.txt** file to **666**
-
-
diff --git a/en/device-dev/kernel/chown.md b/en/device-dev/kernel/chown.md
deleted file mode 100644
index 39b3ed6e04da7941af5a86e6023766f319e8de94..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/chown.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# chown
-
-- [Command Function](#section247414691513)
-- [Syntax](#section14773151018159)
-- [Parameter Description](#section598731391517)
-- [Usage](#section16524152071510)
-- [Example](#section17901152561510)
-- [Output](#section15513163115816)
-
-## Command Function
-
-This command is used to change the owner and group of a specified file.
-
-## Syntax
-
-chown \[_owner_\] \[_group_\] \[_pathname_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
owner
-
-
Indicates the file owner.
-
-
[0, 0xFFFFFFFF]
-
-
-
group
-
-
Indicates the file group.
-
-
Left blank
[0, 0xFFFFFFFF]
-
-
-
pathname
-
-
Indicates the file path.
-
-
An existing file
-
-
-
-
-
-## 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.
-- The **group** parameter can be left blank.
-
-## Example
-
-Enter **chown 100 200 hello-harmony.txt**.
-
-## Output
-
-**Figure 1** Changing the owner and group of the hello-harmony.txt file to 100 and 200 respectively
-
-
diff --git a/en/device-dev/kernel/commissioning.md b/en/device-dev/kernel/commissioning.md
deleted file mode 100644
index f7be69f45389758ac2eb5493f63b52140cb0ffcc..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/commissioning.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Commissioning
-
-- **[Introduction to the Shell](introduction-to-the-shell.md)**
-
-- **[Shell Command Development Guidelines](shell-command-development-guidelines.md)**
-
-- **[Shell Command Programming Example](shell-command-programming-example.md)**
-
-- **[Shell Command Reference](shell-command-reference.md)**
-
-- **[Magic Key Usage](magic-key-usage.md)**
-
-- **[User-Space Exception Information](user-space-exception-information.md)**
-
-
diff --git a/en/device-dev/kernel/cp.md b/en/device-dev/kernel/cp.md
deleted file mode 100644
index e5c6d12695b650a2268fa6defe5371a2a78dd7bd..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/cp.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# cp
-
-- [Command Function](#section6841203041513)
-- [Syntax](#section24286359150)
-- [Parameter Description](#section558617385152)
-- [Usage](#section16128156162)
-- [Example](#section19354171211618)
-- [Output](#section16754183195914)
-
-## Command Function
-
-This command is used to create a copy for a file.
-
-## Syntax
-
-cp \[_SOURCEFILE_\] \[_DESTFILE_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
SOURCEFILE
-
-
Indicates the path to the source file.
-
-
Currently, only files are supported. Directories are not supported.
-
-
-
DESTFILE
-
-
Indicates the path to the destination file.
-
-
Both directories and files are supported.
-
-
-
-
-
-## Usage
-
-- 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.
-- 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.
-- If the destination file does not exist, a new file is created. If the destination file already exists, the existing file is overwritten.
-
-When important system resources are copied, unexpected results such as a system breakdown may occur. For example, when the **/dev/uartdev-0** file is copied, the system may stop responding.
-
-## Example
-
-Enter **cp hello-harmony.txt ./tmp/**.
-
-## Output
-
-**Figure 1** File copying result
-
-
diff --git a/en/device-dev/kernel/cpup.md b/en/device-dev/kernel/cpup.md
deleted file mode 100644
index 0eb2985b3f8b471862be7f0a17350dce9cebf200..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/cpup.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# cpup
-
-- [Command Function](#section1842161614217)
-- [Syntax](#section5629527427)
-- [Parameter Description](#section133651361023)
-- [Usage](#section156611948521)
-- [Example](#section68501605319)
-- [Output](#section19871522144219)
-
-## Command Function
-
-This command is used to query the CPU usage of the system.
-
-## Syntax
-
-cpup \[_mode_\] \[_taskID_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
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.
-
-
[0, 0xFFFFFFFF]
-
-
-
taskID
-
-
Indicates the task ID.
-
-
[0, 0xFFFFFFFF]
-
-
-
-
-
-## Usage
-
-- If the parameters are not specified, the CPU usage within the last 10 seconds is displayed.
-- If only the **mode** parameter is specified, the CPU usage within the specified period is displayed.
-- If both the **mode** and **taskID** parameters are specified, the CPU usage of the specified task within the given period is displayed.
-
-## Example
-
-Enter **cpup 1 5**.
-
-## Output
-
-**Figure 1** CPU usage
-
-
diff --git a/en/device-dev/kernel/date.md b/en/device-dev/kernel/date.md
deleted file mode 100644
index f9e52b6c1cd360f4fd263340730bebf5c60eae56..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/date.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# date
-
-- [Command Function](#section56472016338)
-- [Syntax](#section16635112512316)
-- [Parameter Description](#section15896030039)
-- [Usage](#section116361036636)
-- [Example](#section021711411237)
-- [Output](#section17950184414312)
-
-## Command Function
-
-This command is used to query and set the system date and time.
-
-## Syntax
-
-date
-
-date --help
-
-date +\[_Format_\]
-
-date -s_ _\[_YY/MM/DD_\]
-
-date_ _-s_ _\[_hh:mm:ss_\]__
-
-date -r \[_Filename_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
--help
-
-
Uses the help.
-
-
N/A
-
-
-
+Format
-
-
Prints the date and time based on Format.
-
-
Placeholders listed in --help.
-
-
-
-s YY/MM/DD
-
-
Sets the system date and separates the year, month, and day by slashes (/).
-
-
>= 1970/01/01
-
-
-
-s hh:mm:ss
-
-
Sets the system time and separates the hour, minute, and second by colons (:).
-
-
N/A
-
-
-
-r Filename
-
-
Queries the modification time of the Filename file.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- If the **date** parameter is not specified, the current system date and time are displayed by default.
-- The **--help**, **+Format**, **-s**, and **-r** parameters are mutually exclusive.
-
-## Example
-
-Enter **date +%Y--%m--%d**.
-
-## Output
-
-**Figure 1** System date printed based on the specified format
-
-
diff --git a/en/device-dev/kernel/dhclient.md b/en/device-dev/kernel/dhclient.md
deleted file mode 100644
index ab3f5ba9984951888a488e883d602f852d61d50c..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/dhclient.md
+++ /dev/null
@@ -1,138 +0,0 @@
-# dhclient
-
-- [Command Function](#section366714216619)
-- [Syntax](#section8833164614615)
-- [Parameter Description](#section12809111019453)
-- [Usage](#section15935131220717)
-- [Example](#section79281818476)
-- [Output](#section12742311179)
-
-## Command Function
-
-This command is used to set and view **dhclient** parameters.
-
-## Syntax
-
-dhclient <_netif name_\>
-
-dhclient -x <_netif name_\>
-
-dhclient -gb <_netif name_\>
-
-dhclient -sv <_vendor_\>
-
-dhclient -gv
-
-dhclient -gd <_index_\>
-
-dhclient -sd <_dns\_ip_\>
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
<netif name>
-
-
Starts the DHCP request of the network interface card (NIC).
-
-
NIC name, eth0
-
-
-
-x <netif name>
-
-
Disables the DHCP function for the NIC.
-
-
NIC name, eth0
-
-
-
-gb <netif name>
-
-
Checks whether the DHCP request of the NIC is complete.
-
-
NIC name, eth0
-
-
-
-sv <vendor>
-
-
Sets the vendor information of a DHCP request.
-
-
Vendor information (The value is a string of 32 characters.)
-
-
-
-gv
-
-
Displays the vendor information in a DHCP request.
-
-
N/A
-
-
-
-gd <index>
-
-
Obtains information about the DNS server at the specified index.
-
-
Index, 0 or 1
-
-
-
-sd <dns_ip>
-
-
Indicates the IP address of the active DNS server.
Indicates that 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.
-
-
-
-
-
diff --git a/en/device-dev/kernel/dmesg.md b/en/device-dev/kernel/dmesg.md
deleted file mode 100644
index 4890f812707b7308504c214a5157a751b4a3d665..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/dmesg.md
+++ /dev/null
@@ -1,111 +0,0 @@
-# dmesg
-
-- [Command Function](#section4643204919313)
-- [Syntax](#section6553153635)
-- [Parameter Description](#section208971157532)
-- [Usage](#section213115219413)
-- [Example](#section13736564418)
-- [Output](#section194005101413)
-
-## Command Function
-
-This command is used to control the dmesg buffer of the kernel.
-
-## Syntax
-
-dmesg
-
-dmesg \[_-c/-C/-D/-E/-L/-U_\]
-
-dmesg -s \[_size_\]
-
-dmesg -l \[_level_\]
-
-dmesg \> \[_fileA_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
-c
-
-
Prints content in the buffer and clears the buffer.
-
-
N/A
-
-
-
-C
-
-
Clears the buffer.
-
-
N/A
-
-
-
-D/-E
-
-
Enables or disables printing to the console.
-
-
N/A
-
-
-
-L/-U
-
-
Enables or disables printing via the serial port.
-
-
N/A
-
-
-
-s size
-
-
Sets the size of the buffer.
-
-
N/A
-
-
-
-l level
-
-
Sets the buffering level.
-
-
0 - 5
-
-
-
> fileA
-
-
Writes the content in the buffer to a file.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- This command depends on **LOSCFG\_SHELL\_DMESG**. Before running this command, enable the **Enable Shell dmesg** configuration item using **menuconfig**.
-
- Debug ---\> Enable a Debug Version ---\> Enable Shell ---\> Enable Shell dmesg
-
-- If the parameters are not specified, all content in the buffer is printed.
-- The parameters followed by hyphens \(-\) are mutually exclusive.
- 1. Before writing content to a file, ensure that the file system has been mounted.
- 2. Disabling the serial port printing will adversely affect the shell. You are advised to set up a connection using Telnet before disabling the serial port.
-
-
-## Example
-
-Enter **dmesg \> /usr/dmesg.log**.
-
-## Output
-
-**Figure 1** Writing dmesg content to a file
-
-
diff --git a/en/device-dev/kernel/exec.md b/en/device-dev/kernel/exec.md
deleted file mode 100644
index 3db30ca0a4ee351d499fea9431203c046b9f5202..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/exec.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# exec
-
-- [Command Function](#section4643204919313)
-- [Syntax](#section6553153635)
-- [Parameter Description](#section208971157532)
-- [Usage](#section213115219413)
-- [Example](#section13736564418)
-- [Output](#section194005101413)
-
-## Command Function
-
-This command is a built-in shell command used to execute user-space programs.
-
-## Syntax
-
-exec <_executable-file_\>
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
executable-file
-
-
Indicates a valid executable file.
-
-
N/A
-
-
-
-
-
-## Usage
-
-Currently, this command supports only valid binary programs. The programs are successfully executed and then run in the background by default. However, the programs share the same device with the shell. As a result, the output of the programs and the shell may be interlaced.
-
-## Example
-
-Enter **exec helloworld**.
-
-## Output
-
-```
-OHOS # exec helloworld
-OHOS # hello world!
-```
-
-> **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.
-
diff --git a/en/device-dev/kernel/figures/changing-the-group-of-the-hello-harmony-txt-file-to-100.png b/en/device-dev/kernel/figure/changing-the-group-of-the-hello-harmony-txt-file-to-100.png
similarity index 100%
rename from en/device-dev/kernel/figures/changing-the-group-of-the-hello-harmony-txt-file-to-100.png
rename to en/device-dev/kernel/figure/changing-the-group-of-the-hello-harmony-txt-file-to-100.png
diff --git a/en/device-dev/kernel/figures/changing-the-owner-and-group-of-the-hello-harmony-txt-file-to-100-and-200-respectively.png b/en/device-dev/kernel/figure/changing-the-owner-and-group-of-the-hello-harmony-txt-file-to-100-and-200-respectively.png
similarity index 100%
rename from en/device-dev/kernel/figures/changing-the-owner-and-group-of-the-hello-harmony-txt-file-to-100-and-200-respectively.png
rename to en/device-dev/kernel/figure/changing-the-owner-and-group-of-the-hello-harmony-txt-file-to-100-and-200-respectively.png
diff --git a/en/device-dev/kernel/figures/changing-the-permission-on-the-hello-harmony-txt-file-to-666.png b/en/device-dev/kernel/figure/changing-the-permission-on-the-hello-harmony-txt-file-to-666.png
similarity index 100%
rename from en/device-dev/kernel/figures/changing-the-permission-on-the-hello-harmony-txt-file-to-666.png
rename to en/device-dev/kernel/figure/changing-the-permission-on-the-hello-harmony-txt-file-to-666.png
diff --git a/en/device-dev/kernel/figures/command-output-0.png b/en/device-dev/kernel/figure/command-output-19.png
similarity index 100%
rename from en/device-dev/kernel/figures/command-output-0.png
rename to en/device-dev/kernel/figure/command-output-19.png
diff --git a/en/device-dev/kernel/figures/command-output.png b/en/device-dev/kernel/figure/command-output.png
similarity index 100%
rename from en/device-dev/kernel/figures/command-output.png
rename to en/device-dev/kernel/figure/command-output.png
diff --git a/en/device-dev/kernel/figures/cpu-usage.png b/en/device-dev/kernel/figure/cpu-usage.png
similarity index 100%
rename from en/device-dev/kernel/figures/cpu-usage.png
rename to en/device-dev/kernel/figure/cpu-usage.png
diff --git a/en/device-dev/kernel/figures/creating-file-c.png b/en/device-dev/kernel/figure/creating-file-c.png
similarity index 100%
rename from en/device-dev/kernel/figures/creating-file-c.png
rename to en/device-dev/kernel/figure/creating-file-c.png
diff --git a/en/device-dev/kernel/figures/creating-the-share-directory.png b/en/device-dev/kernel/figure/creating-the-share-directory.png
similarity index 100%
rename from en/device-dev/kernel/figures/creating-the-share-directory.png
rename to en/device-dev/kernel/figure/creating-the-share-directory.png
diff --git a/en/device-dev/kernel/figures/deleting-directory-dir.png b/en/device-dev/kernel/figure/deleting-directory-dir.png
similarity index 100%
rename from en/device-dev/kernel/figures/deleting-directory-dir.png
rename to en/device-dev/kernel/figure/deleting-directory-dir.png
diff --git a/en/device-dev/kernel/figures/deleting-the-log1-txt-file.png b/en/device-dev/kernel/figure/deleting-the-log1-txt-file.png
similarity index 100%
rename from en/device-dev/kernel/figures/deleting-the-log1-txt-file.png
rename to en/device-dev/kernel/figure/deleting-the-log1-txt-file.png
diff --git a/en/device-dev/kernel/figures/deleting-the-sd-directory.png b/en/device-dev/kernel/figure/deleting-the-sd-directory.png
similarity index 100%
rename from en/device-dev/kernel/figures/deleting-the-sd-directory.png
rename to en/device-dev/kernel/figure/deleting-the-sd-directory.png
diff --git a/en/device-dev/kernel/figures/directory-switching-result.png b/en/device-dev/kernel/figure/directory-switching-result.png
similarity index 100%
rename from en/device-dev/kernel/figures/directory-switching-result.png
rename to en/device-dev/kernel/figure/directory-switching-result.png
diff --git a/en/device-dev/kernel/figures/displaying-the-memory-usage-in-three-units.png b/en/device-dev/kernel/figure/displaying-the-memory-usage-in-three-units.png
similarity index 100%
rename from en/device-dev/kernel/figures/displaying-the-memory-usage-in-three-units.png
rename to en/device-dev/kernel/figure/displaying-the-memory-usage-in-three-units.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001051690323.png b/en/device-dev/kernel/figure/en-us_image_0000001051690323.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001051690323.png
rename to en/device-dev/kernel/figure/en-us_image_0000001051690323.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001052370303.png b/en/device-dev/kernel/figure/en-us_image_0000001052370303.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001052370303.png
rename to en/device-dev/kernel/figure/en-us_image_0000001052370303.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001052370305.png b/en/device-dev/kernel/figure/en-us_image_0000001052370305.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001052370305.png
rename to en/device-dev/kernel/figure/en-us_image_0000001052370305.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001052370307.png b/en/device-dev/kernel/figure/en-us_image_0000001052370307.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001052370307.png
rename to en/device-dev/kernel/figure/en-us_image_0000001052370307.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001052530298.png b/en/device-dev/kernel/figure/en-us_image_0000001052530298.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001052530298.png
rename to en/device-dev/kernel/figure/en-us_image_0000001052530298.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001052810300.png b/en/device-dev/kernel/figure/en-us_image_0000001052810300.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001052810300.png
rename to en/device-dev/kernel/figure/en-us_image_0000001052810300.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001052810304.png b/en/device-dev/kernel/figure/en-us_image_0000001052810304.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001052810304.png
rename to en/device-dev/kernel/figure/en-us_image_0000001052810304.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001053224218.png b/en/device-dev/kernel/figure/en-us_image_0000001053224218.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001053224218.png
rename to en/device-dev/kernel/figure/en-us_image_0000001053224218.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001053710680.png b/en/device-dev/kernel/figure/en-us_image_0000001053710680.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001053710680.png
rename to en/device-dev/kernel/figure/en-us_image_0000001053710680.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001053826366.png b/en/device-dev/kernel/figure/en-us_image_0000001053826366.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001053826366.png
rename to en/device-dev/kernel/figure/en-us_image_0000001053826366.png
diff --git a/en/device-dev/kernel/figures/en-us_image_0000001054624363.png b/en/device-dev/kernel/figure/en-us_image_0000001054624363.png
similarity index 100%
rename from en/device-dev/kernel/figures/en-us_image_0000001054624363.png
rename to en/device-dev/kernel/figure/en-us_image_0000001054624363.png
diff --git a/en/device-dev/kernel/figures/file-copying-result.png b/en/device-dev/kernel/figure/file-copying-result.png
similarity index 100%
rename from en/device-dev/kernel/figures/file-copying-result.png
rename to en/device-dev/kernel/figure/file-copying-result.png
diff --git a/en/device-dev/kernel/figures/no-out-of-bounds-memory-access.png b/en/device-dev/kernel/figure/no-out-of-bounds-memory-access.png
similarity index 100%
rename from en/device-dev/kernel/figures/no-out-of-bounds-memory-access.png
rename to en/device-dev/kernel/figure/no-out-of-bounds-memory-access.png
diff --git a/en/device-dev/kernel/figures/out-of-bounds-memory-access.png b/en/device-dev/kernel/figure/out-of-bounds-memory-access.png
similarity index 100%
rename from en/device-dev/kernel/figures/out-of-bounds-memory-access.png
rename to en/device-dev/kernel/figure/out-of-bounds-memory-access.png
diff --git a/en/device-dev/kernel/figures/output-of-telnet-on.png b/en/device-dev/kernel/figure/output-of-telnet-on.png
similarity index 100%
rename from en/device-dev/kernel/figures/output-of-telnet-on.png
rename to en/device-dev/kernel/figure/output-of-telnet-on.png
diff --git a/en/device-dev/kernel/figures/output-of-the-statfs-command.png b/en/device-dev/kernel/figure/output-of-the-statfs-command.png
similarity index 100%
rename from en/device-dev/kernel/figures/output-of-the-statfs-command.png
rename to en/device-dev/kernel/figure/output-of-the-statfs-command.png
diff --git a/en/device-dev/kernel/figures/posix-framework.png b/en/device-dev/kernel/figure/posix-framework.png
similarity index 100%
rename from en/device-dev/kernel/figures/posix-framework.png
rename to en/device-dev/kernel/figure/posix-framework.png
diff --git a/en/device-dev/kernel/figures/querying-information-about-a-specified-software-timer.png b/en/device-dev/kernel/figure/querying-information-about-a-specified-software-timer.png
similarity index 100%
rename from en/device-dev/kernel/figures/querying-information-about-a-specified-software-timer.png
rename to en/device-dev/kernel/figure/querying-information-about-a-specified-software-timer.png
diff --git a/en/device-dev/kernel/figures/querying-information-about-all-semaphores-in-use.png b/en/device-dev/kernel/figure/querying-information-about-all-semaphores-in-use.png
similarity index 100%
rename from en/device-dev/kernel/figures/querying-information-about-all-semaphores-in-use.png
rename to en/device-dev/kernel/figure/querying-information-about-all-semaphores-in-use.png
diff --git a/en/device-dev/kernel/figures/querying-information-about-all-software-timers.png b/en/device-dev/kernel/figure/querying-information-about-all-software-timers.png
similarity index 100%
rename from en/device-dev/kernel/figures/querying-information-about-all-software-timers.png
rename to en/device-dev/kernel/figure/querying-information-about-all-software-timers.png
diff --git a/en/device-dev/kernel/figures/querying-partial-task-information.png b/en/device-dev/kernel/figure/querying-partial-task-information.png
similarity index 100%
rename from en/device-dev/kernel/figures/querying-partial-task-information.png
rename to en/device-dev/kernel/figure/querying-partial-task-information.png
diff --git a/en/device-dev/kernel/figures/querying-pids.png b/en/device-dev/kernel/figure/querying-pids.png
similarity index 100%
rename from en/device-dev/kernel/figures/querying-pids.png
rename to en/device-dev/kernel/figure/querying-pids.png
diff --git a/en/device-dev/kernel/figures/querying-the-current-path.png b/en/device-dev/kernel/figure/querying-the-current-path.png
similarity index 100%
rename from en/device-dev/kernel/figures/querying-the-current-path.png
rename to en/device-dev/kernel/figure/querying-the-current-path.png
diff --git a/en/device-dev/kernel/figures/relationship-between-the-vfs-and-file-systems.png b/en/device-dev/kernel/figure/relationship-between-the-vfs-and-file-systems.png
similarity index 100%
rename from en/device-dev/kernel/figures/relationship-between-the-vfs-and-file-systems.png
rename to en/device-dev/kernel/figure/relationship-between-the-vfs-and-file-systems.png
diff --git a/en/device-dev/kernel/figures/sending-a-signal-to-a-specified-process.png b/en/device-dev/kernel/figure/sending-a-signal-to-a-specified-process.png
similarity index 100%
rename from en/device-dev/kernel/figures/sending-a-signal-to-a-specified-process.png
rename to en/device-dev/kernel/figure/sending-a-signal-to-a-specified-process.png
diff --git a/en/device-dev/kernel/figures/signal-sending-failure.png b/en/device-dev/kernel/figure/signal-sending-failure.png
similarity index 100%
rename from en/device-dev/kernel/figures/signal-sending-failure.png
rename to en/device-dev/kernel/figure/signal-sending-failure.png
diff --git a/en/device-dev/kernel/figures/snipaste_2021-01-26_10-38-58-1.png b/en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-20.png
similarity index 100%
rename from en/device-dev/kernel/figures/snipaste_2021-01-26_10-38-58-1.png
rename to en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-20.png
diff --git a/en/device-dev/kernel/figures/snipaste_2021-01-26_10-38-58-2.png b/en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-21.png
similarity index 100%
rename from en/device-dev/kernel/figures/snipaste_2021-01-26_10-38-58-2.png
rename to en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58-21.png
diff --git a/en/device-dev/kernel/figures/snipaste_2021-01-26_10-38-58.png b/en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58.png
similarity index 100%
rename from en/device-dev/kernel/figures/snipaste_2021-01-26_10-38-58.png
rename to en/device-dev/kernel/figure/snipaste_2021-01-26_10-38-58.png
diff --git a/en/device-dev/kernel/figures/state-transition-of-a-process.png b/en/device-dev/kernel/figure/state-transition-of-a-process.png
similarity index 100%
rename from en/device-dev/kernel/figures/state-transition-of-a-process.png
rename to en/device-dev/kernel/figure/state-transition-of-a-process.png
diff --git a/en/device-dev/kernel/figures/state-transition-of-a-thread.png b/en/device-dev/kernel/figure/state-transition-of-a-thread.png
similarity index 100%
rename from en/device-dev/kernel/figures/state-transition-of-a-thread.png
rename to en/device-dev/kernel/figure/state-transition-of-a-thread.png
diff --git a/en/device-dev/kernel/figures/switching-to-the-user-whose-uid-and-gid-are-both-1000.png b/en/device-dev/kernel/figure/switching-to-the-user-whose-uid-and-gid-are-both-1000.png
similarity index 100%
rename from en/device-dev/kernel/figures/switching-to-the-user-whose-uid-and-gid-are-both-1000.png
rename to en/device-dev/kernel/figure/switching-to-the-user-whose-uid-and-gid-are-both-1000.png
diff --git a/en/device-dev/kernel/figures/system-date-printed-based-on-the-specified-format.png b/en/device-dev/kernel/figure/system-date-printed-based-on-the-specified-format.png
similarity index 100%
rename from en/device-dev/kernel/figures/system-date-printed-based-on-the-specified-format.png
rename to en/device-dev/kernel/figure/system-date-printed-based-on-the-specified-format.png
diff --git a/en/device-dev/kernel/figures/task-command-monitoring-result.png b/en/device-dev/kernel/figure/task-command-monitoring-result.png
similarity index 100%
rename from en/device-dev/kernel/figures/task-command-monitoring-result.png
rename to en/device-dev/kernel/figure/task-command-monitoring-result.png
diff --git a/en/device-dev/kernel/figures/tree-structure-of-the-file-system.png b/en/device-dev/kernel/figure/tree-structure-of-the-file-system.png
similarity index 100%
rename from en/device-dev/kernel/figures/tree-structure-of-the-file-system.png
rename to en/device-dev/kernel/figure/tree-structure-of-the-file-system.png
diff --git a/en/device-dev/kernel/figures/unmounting-result.png b/en/device-dev/kernel/figure/unmounting-result.png
similarity index 100%
rename from en/device-dev/kernel/figures/unmounting-result.png
rename to en/device-dev/kernel/figure/unmounting-result.png
diff --git a/en/device-dev/kernel/figures/usage-of-system-resources.png b/en/device-dev/kernel/figure/usage-of-system-resources.png
similarity index 100%
rename from en/device-dev/kernel/figures/usage-of-system-resources.png
rename to en/device-dev/kernel/figure/usage-of-system-resources.png
diff --git a/en/device-dev/kernel/figures/viewing-content-of-the-current-directory.png b/en/device-dev/kernel/figure/viewing-content-of-the-current-directory.png
similarity index 100%
rename from en/device-dev/kernel/figures/viewing-content-of-the-current-directory.png
rename to en/device-dev/kernel/figure/viewing-content-of-the-current-directory.png
diff --git a/en/device-dev/kernel/figures/viewing-content-of-the-hello-harmony-txt-file.png b/en/device-dev/kernel/figure/viewing-content-of-the-hello-harmony-txt-file.png
similarity index 100%
rename from en/device-dev/kernel/figures/viewing-content-of-the-hello-harmony-txt-file.png
rename to en/device-dev/kernel/figure/viewing-content-of-the-hello-harmony-txt-file.png
diff --git a/en/device-dev/kernel/figures/viewing-the-usage-of-physical-pages.png b/en/device-dev/kernel/figure/viewing-the-usage-of-physical-pages.png
similarity index 100%
rename from en/device-dev/kernel/figures/viewing-the-usage-of-physical-pages.png
rename to en/device-dev/kernel/figure/viewing-the-usage-of-physical-pages.png
diff --git a/en/device-dev/kernel/figures/virtual-memory-usage-of-the-process-with-pid-3.png b/en/device-dev/kernel/figure/virtual-memory-usage-of-the-process-with-pid-3.png
similarity index 100%
rename from en/device-dev/kernel/figures/virtual-memory-usage-of-the-process-with-pid-3.png
rename to en/device-dev/kernel/figure/virtual-memory-usage-of-the-process-with-pid-3.png
diff --git a/en/device-dev/kernel/figures/writing-dmesg-content-to-a-file.png b/en/device-dev/kernel/figure/writing-dmesg-content-to-a-file.png
similarity index 100%
rename from en/device-dev/kernel/figures/writing-dmesg-content-to-a-file.png
rename to en/device-dev/kernel/figure/writing-dmesg-content-to-a-file.png
diff --git a/en/device-dev/kernel/file-commands.md b/en/device-dev/kernel/file-commands.md
deleted file mode 100644
index b75130d6cdb08de238a18e95a0b03e811f9c0f28..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/file-commands.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# File Commands
-
-- **[cat](cat.md)**
-
-- **[cd](cd.md)**
-
-- **[chgrp](chgrp.md)**
-
-- **[chmod](chmod.md)**
-
-- **[chown](chown.md)**
-
-- **[cp](cp.md)**
-
-- **[format](format.md)**
-
-- **[ls](ls.md)**
-
-- **[lsfd](lsfd.md)**
-
-- **[mkdir](mkdir.md)**
-
-- **[mount](mount.md)**
-
-- **[partinfo](partinfo.md)**
-
-- **[partition](partition.md)**
-
-- **[pwd](pwd.md)**
-
-- **[rm](rm.md)**
-
-- **[rmdir](rmdir.md)**
-
-- **[statfs](statfs.md)**
-
-- **[sync](sync.md)**
-
-- **[touch](touch.md)**
-
-- **[writeproc](writeproc.md)**
-
-- **[umount](umount.md)**
-
-
diff --git a/en/device-dev/kernel/format.md b/en/device-dev/kernel/format.md
deleted file mode 100644
index 11336955c0987b66e83d272edda4b12e36a52b30..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/format.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# format
-
-- [Command Function](#section1922331919169)
-- [Syntax](#section249226169)
-- [Parameter Description](#section985173416177)
-- [Usage](#section1510162714162)
-- [Example](#section25691431161611)
-- [Output](#section17368112365920)
-
-## Command Function
-
-This command is used to format a disk.
-
-## Syntax
-
-format <_dev\_inodename_\> <_sectors_\> <_option_\> \[_label_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
-
-
dev_inodename
-
-
Indicates 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.)
-
-
-
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)
-
-
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.
-
-
-
-
-
-## Usage
-
-- The **format** command is used to format a disk. You can find the device name in the **dev** directory. A storage card must be installed before the formatting.
-- This command can be used to format only the USB flash drive, SD card, and MMC, but not the NAND flash and NOR flash.
-- The **sectors** parameter must be set to a valid value. An invalid value may cause exceptions.
-
-## Example
-
-Enter **format /dev/mmcblk0 128 2**.
-
-## Output
-
-Formatting result
-
-
-
diff --git a/en/device-dev/kernel/free.md b/en/device-dev/kernel/free.md
deleted file mode 100644
index 640004a9f60ae70c204fde9d9d11de93ce085aed..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/free.md
+++ /dev/null
@@ -1,119 +0,0 @@
-# free
-
-- [Command Function](#section175151514841)
-- [Syntax](#section8488721749)
-- [Parameter Description](#section27272181949)
-- [Usage](#section148661259410)
-- [Example](#section68081530242)
-- [Output](#section171235517543)
-
-## Command Function
-
-This command is used to display the system memory usage and the sizes of the **text**, **data**, **rodata**, and **bss** segments.
-
-## Syntax
-
-free \[_-k | -m_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
No parameter
-
-
Displays the size in the unit of byte.
-
-
N/A
-
-
-
-k
-
-
Displays the size in the unit of KB.
-
-
N/A
-
-
-
-m
-
-
Displays the size in the unit of MB.
-
-
N/A
-
-
-
-
-
-## Usage
-
-None
-
-## Example
-
-Enter **free**, **free -k**, and **free -m**, respectively.
-
-## Output
-
-**Figure 1** Displaying the memory usage in three units
-
-
-**Table 2** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
total
-
-
Indicates the total size of the dynamic memory pool.
-
-
-
used
-
-
Indicates the size of the used memory.
-
-
-
free
-
-
Indicates the size of the unallocated memory.
-
-
-
heap
-
-
Indicates the size of the allocated heap.
-
-
-
text
-
-
Indicates the size of a code segment.
-
-
-
data
-
-
Indicates the size of a data segment.
-
-
-
rodata
-
-
Indicates the size of a read-only data segment.
-
-
-
bss
-
-
Indicates the size of the memory occupied by uninitialized global variables.
-
-
-
-
-
diff --git a/en/device-dev/kernel/guidelines-for-compiling-and-building-the-linux-kernel.md b/en/device-dev/kernel/guidelines-for-compiling-and-building-the-linux-kernel.md
deleted file mode 100644
index a310e530bfb4368baaca86b1095c384d20f02912..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/guidelines-for-compiling-and-building-the-linux-kernel.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Guidelines for Compiling and Building the Linux Kernel
-
-- [Example of Development Using the Hi3516D V300 Board and Ubuntu x86 Server](#section19369206113115)
- - [Scenario 1: building the native kernel at the version level](#section1025111193220)
- - [Scenario 2: building the modified kernel separately](#section17446652173211)
-
-
-## Example of Development Using the Hi3516D V300 Board and Ubuntu x86 Server
-
-### Scenario 1: building the native kernel at the version level
-
-Perform a full build for the project to generate the **uImage** kernel image.
-
-```
-./build.sh --product-name Hi3516DV300 # Build the uImage kernel image of the Hi3516D V300 board.
-```
-
-### Scenario 2: building the modified kernel separately
-
-1. Set up the build environment.
-
- 1. Merge the required patch by referring to [guidelines for using patches on development boards](guidelines-for-using-patches-on-openharmony-development-boards.md).
- 2. Prepare for the build environment. You can use the Arm Clang or GCC compiler.
-
- Enter the root directory of the project and configure environment variables:
-
- ```
- export PATH=`pwd`/prebuilts/clang/host/linux-x86/clang-r353983c/bin:`pwd`/prebuilts/gcc/linux-x86/arm/gcc-linaro-7.5.0-arm-linux-gnueabi/bin/:$PATH # Configure the build environment.
- MAKE_OPTIONES="ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CC=clang HOSTCC=clang" # Use Clang provided by the project.
- ```
-
-2. Modify the kernel code or kernel configuration \(**defconfig** file provided by OpenHarmony can be used for reference\).
-3. Create a build directory and generate the **.config** file of the kernel.
-
- ```
- make ${MAKE_OPTIONES} hi3516dv300_emmc_smp_hos_l2_defconfig # Use the defconfig file to build the kernel.
- ```
-
-4. Build the kernel image.
-
- ```
- make ${MAKE_OPTIONES} -j32 uImage # Build the uImage kernel image.
- ```
-
-
diff --git a/en/device-dev/kernel/guidelines-for-using-patches-on-openharmony-development-boards.md b/en/device-dev/kernel/guidelines-for-using-patches-on-openharmony-development-boards.md
deleted file mode 100644
index 6b05e850113e75cf1f21dc6a68a3a0a836552f51..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/guidelines-for-using-patches-on-openharmony-development-boards.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Guidelines for Using Patches on OpenHarmony Development Boards
-
-The patch files are stored in the **kernel/linux/patches/linux-4.19** source code path of the project. You can obtain the driver patch of a specific chip architecture from this directory.
-
-To use the patch of a specific chip platform driver, you need to merge the required kernel patch into the kernel code.
-
-Merge the corresponding patches for different chip platforms.
-
-The following uses Hi3516D V300 as an example:
-
-```
-patch -p1 < device/hisilicon/hi3516dv300/sdk_linux/open_source/linux/hisi_linux-4.19_hos_l2.patch
-```
-
-> **NOTICE:**
->Because patches are applied after the code environment of **kernel/linux-4.19** is copied during compilation and building of the OpenHarmony project, you must retain the original code environment of **kernel/linux-4.19** before running the OpenHarmony version-level build command.
-
diff --git a/en/device-dev/kernel/hwi.md b/en/device-dev/kernel/hwi.md
deleted file mode 100644
index 72d7bd3f10e5f63e42cb4989259c76e187a9d4a6..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/hwi.md
+++ /dev/null
@@ -1,94 +0,0 @@
-# hwi
-
-- [Command Function](#section445335110416)
-- [Syntax](#section1795712553416)
-- [Parameter Description](#section92544592410)
-- [Usage](#section104151141252)
-- [Example](#section11545171957)
-- [Output](#section075617368542)
-
-## Command Function
-
-This command is used to query information about the current interrupts.
-
-## Syntax
-
-hwi
-
-## Parameter Description
-
-None
-
-## Usage
-
-- Enter **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
-
-Enter **hwi**.
-
-## Output
-
-1. Interrupt information \(with **LOSCFG\_CPUP\_INCLUDE\_IRQ** disabled\)
-
- 
-
-2. Interrupt information \(with **LOSCFG\_CPUP\_INCLUDE\_IRQ** enabled\)
-
- 
-
- **Table 1** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
InterruptNo
-
-
Indicates the interrupt ID.
-
-
-
Count
-
-
Indicates the count of interrupts.
-
-
-
Name
-
-
Indicates the registered interrupt name.
-
-
-
CYCLECOST
-
-
Indicates the interrupt processing time (cycles).
-
-
-
CPUUSE
-
-
Indicates the CPU usage.
-
-
-
CPUUSE10s
-
-
Indicates CPU usage within the last 10 seconds.
-
-
-
CPUUSE1s
-
-
Indicates CPU usage within the last 1 second.
-
-
-
mode
-
-
Indicates the interrupt mode.
-
normal: non-shared interrupt.
shared: shared interrupt.
-
-
-
-
-
-
diff --git a/en/device-dev/kernel/introduction-to-the-shell.md b/en/device-dev/kernel/introduction-to-the-shell.md
deleted file mode 100644
index 497aade9dff0b3e08f776b7f97d4ca0544b39ab3..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/introduction-to-the-shell.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# 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.
-
-- System-related commands: querying information about system tasks, kernel semaphores, system software timers, CPU usage, and current interrupts
-
-- File-related commands: basic functions 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
-
- For details about the process of adding commands, see [Shell Command Development Guidelines](shell-command-development-guidelines.md) and [Shell Command Programming Example](shell-command-programming-example.md).
-
-
-## Important Notes
-
-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.
-
-- 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.
-
-- The shell working directory is separated from the system working directory. You can run commands such as **cd** and **pwd** on the shell to perform operations on the shell working directory, and run commands such as **chdir** and **getcwd** to perform operations on the system working directory. Pay special attention when an input parameter in a file system operation command is a relative path.
-
-- Before using network shell commands, you need to call the **tcpip\_init** function to initialize the network and set up the Telnet connection. By default, the kernel does not call **tcpip\_init**.
-
-- 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.
-
- > **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**\).
-
-
diff --git a/en/device-dev/kernel/kernel-lite-mini.md b/en/device-dev/kernel/kernel-lite-mini.md
new file mode 100644
index 0000000000000000000000000000000000000000..f87451dcc80d174191386a4112bd676fe6a9ab4b
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-mini.md
@@ -0,0 +1,2 @@
+# Kernel for Mini Systems
+
diff --git a/en/device-dev/kernel/kernel-lite-small-basic.md b/en/device-dev/kernel/kernel-lite-small-basic.md
new file mode 100644
index 0000000000000000000000000000000000000000..d373831984d8fa1e3dd10572af268edf6444f4c1
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-basic.md
@@ -0,0 +1,11 @@
+# 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/fat.md b/en/device-dev/kernel/kernel-lite-small-file-fat.md
similarity index 100%
rename from en/device-dev/kernel/fat.md
rename to en/device-dev/kernel/kernel-lite-small-file-fat.md
diff --git a/en/device-dev/kernel/jffs2.md b/en/device-dev/kernel/kernel-lite-small-file-jffs.md
similarity index 100%
rename from en/device-dev/kernel/jffs2.md
rename to en/device-dev/kernel/kernel-lite-small-file-jffs.md
diff --git a/en/device-dev/kernel/kernel-lite-small-file-nfs.md b/en/device-dev/kernel/kernel-lite-small-file-nfs.md
new file mode 100644
index 0000000000000000000000000000000000000000..7b93df28d139c1347f291481370518c7ccb3bbb1
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-file-nfs.md
@@ -0,0 +1,163 @@
+# 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.
+
+ > **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/ramfs.md b/en/device-dev/kernel/kernel-lite-small-file-ramfs.md
similarity index 100%
rename from en/device-dev/kernel/ramfs.md
rename to en/device-dev/kernel/kernel-lite-small-file-ramfs.md
diff --git a/en/device-dev/kernel/kernel-lite-small-file-vfs.md b/en/device-dev/kernel/kernel-lite-small-file-vfs.md
new file mode 100644
index 0000000000000000000000000000000000000000..8634d9cf6c751e8ef23ce6a2b304c36f40fe9e35
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-file-vfs.md
@@ -0,0 +1,171 @@
+# 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
+
+
+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
+
+
+## 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
+
+> **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
new file mode 100644
index 0000000000000000000000000000000000000000..4a1e2be2e6b70eb7d6e18e123e6678de49b0ef30
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-file.md
@@ -0,0 +1,54 @@
+# 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/differences-from-the-linux-standard-library.md b/en/device-dev/kernel/kernel-lite-small-lib-differ.md
similarity index 100%
rename from en/device-dev/kernel/differences-from-the-linux-standard-library.md
rename to en/device-dev/kernel/kernel-lite-small-lib-differ.md
diff --git a/en/device-dev/kernel/kernel-lite-small-lib-standard.md b/en/device-dev/kernel/kernel-lite-small-lib-standard.md
new file mode 100644
index 0000000000000000000000000000000000000000..c617ebcef2bccda9d515a7e88a5a39cd1605cfac
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-lib-standard.md
@@ -0,0 +1,197 @@
+# 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
+
+
+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
new file mode 100644
index 0000000000000000000000000000000000000000..7b82773508bebc7f6f2b519897411f9a26df1bc4
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-lib.md
@@ -0,0 +1,7 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..7e5191df7b4d967ad5d879522e4a9c372f2a9e2f
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-memory.md
@@ -0,0 +1,353 @@
+# 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)
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.
+
+
+
+
+
+ > **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
new file mode 100644
index 0000000000000000000000000000000000000000..0f542fa52928ae3748dc0a6f51bb24a028dda547
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-net.md
@@ -0,0 +1,303 @@
+# 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.
+
+> **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.
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
new file mode 100644
index 0000000000000000000000000000000000000000..4ce3abc48b9d4c97f222aa495ec7167a00974567
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-process.md
@@ -0,0 +1,301 @@
+# 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
+
+
+**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/user-space-exception-information.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-abn.md
similarity index 100%
rename from en/device-dev/kernel/user-space-exception-information.md
rename to en/device-dev/kernel/kernel-lite-small-shell-cmd-abn.md
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cat.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cat.md
new file mode 100644
index 0000000000000000000000000000000000000000..db3798fee685ae6eff096a156023177358810019
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cat.md
@@ -0,0 +1,53 @@
+# cat
+
+- [Command Function](#section16710153391315)
+- [Syntax](#section1699392313158)
+- [Parameter Description](#section1677217374136)
+- [Usage](#section186772414131)
+- [Example](#section12158131814561)
+- [Output](#section183926225561)
+
+## Command Function
+
+This command is used to display the content of a text file.
+
+## Syntax
+
+cat \[_pathname_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
pathname
+
+
Indicates the file path.
+
+
An existing file
+
+
+
+
+
+## Usage
+
+Run the **cat** \[_pathname_\] command to display the content of a text file.
+
+## Example
+
+Enter **cat hello-harmony.txt**.
+
+## Output
+
+**Figure 1** Viewing content of the **hello-harmony.txt** file
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cd.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cd.md
new file mode 100644
index 0000000000000000000000000000000000000000..e901db1567ec14955417acda2be585f1b2ecdaf5
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cd.md
@@ -0,0 +1,57 @@
+# cd
+
+- [Command Function](#section11690184921316)
+- [Syntax](#section75695409569)
+- [Parameter Description](#section71961353181311)
+- [Usage](#section3629759111317)
+- [Example](#section211620301412)
+- [Output](#section1968117214577)
+
+## Command Function
+
+This command is used to change the current working directory.
+
+## Syntax
+
+cd \[_path_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
path
+
+
Indicates the file path.
+
+
The user must have the execution (search) permission for the specified directory.
+
+
+
+
+
+## Usage
+
+- If the **path** parameter is not specified, the system switches to the root directory.
+- If the **path** parameter is specified, the system switches to the specified path.
+- The **path** value starting with a slash \(/\) represents the root directory.
+- The **path** value starting with a dot \(.\) represents the current directory.
+- The **path** value starting with two dots \(..\) represents the parent directory.
+
+## Example
+
+Enter **cd ..**.
+
+## Output
+
+**Figure 1** Directory switching result
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chgrp.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chgrp.md
new file mode 100644
index 0000000000000000000000000000000000000000..b9fdfe09c32a883f3fdec32d4f421c0975f1b4f5
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chgrp.md
@@ -0,0 +1,60 @@
+# chgrp
+
+- [Command Function](#section6103119161418)
+- [Syntax](#section186958132141)
+- [Parameter Description](#section81796174141)
+- [Usage](#section14330152417140)
+- [Example](#section951823119149)
+- [Output](#section14271133125715)
+
+## Command Function
+
+This command is used to change a file group.
+
+## Syntax
+
+chgrp \[_group_\] \[_pathname_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
group
+
+
Indicates the file group.
+
+
[0, 0xFFFFFFFF]
+
+
+
pathname
+
+
Indicates the file path.
+
+
An existing file
+
+
+
+
+
+## Usage
+
+By specifying a file group before the file name in this command, you can change the group to which the file belongs.
+
+## Example
+
+Enter **chgrp 100 hello-harmony.txt**.
+
+## Output
+
+**Figure 1** Changing the group of the **hello-harmony.txt** file to **100**
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chmod.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chmod.md
new file mode 100644
index 0000000000000000000000000000000000000000..734b648c4f321c31da9dad7fad892444a5acd8df
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chmod.md
@@ -0,0 +1,60 @@
+# chmod
+
+- [Command Function](#section13992936121418)
+- [Syntax](#section63342439147)
+- [Parameter Description](#section894414671411)
+- [Usage](#section182415221419)
+- [Example](#section8518195718147)
+- [Output](#section127391818158)
+
+## Command Function
+
+This command is used to change the file operation permission.
+
+## Syntax
+
+chmod \[_mode_\] \[_pathname_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
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).
+
+
[0, 777]
+
+
+
pathname
+
+
Indicates the file path.
+
+
An existing file
+
+
+
+
+
+## Usage
+
+By specifying the **mode** parameter before the file name, you can change the permission for this file.
+
+## Example
+
+Enter **chmod 666 hello-harmony.txt**.
+
+## Output
+
+**Figure 1** Changing the permission on 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-lite-small-shell-cmd-file-chown.md
new file mode 100644
index 0000000000000000000000000000000000000000..62683b53615c8e753ec9db80e00b72693ae9f96a
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-chown.md
@@ -0,0 +1,69 @@
+# chown
+
+- [Command Function](#section247414691513)
+- [Syntax](#section14773151018159)
+- [Parameter Description](#section598731391517)
+- [Usage](#section16524152071510)
+- [Example](#section17901152561510)
+- [Output](#section15513163115816)
+
+## Command Function
+
+This command is used to change the owner and group of a specified file.
+
+## Syntax
+
+chown \[_owner_\] \[_group_\] \[_pathname_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
owner
+
+
Indicates the file owner.
+
+
[0, 0xFFFFFFFF]
+
+
+
group
+
+
Indicates the file group.
+
+
Left blank
[0, 0xFFFFFFFF]
+
+
+
pathname
+
+
Indicates the file path.
+
+
An existing file
+
+
+
+
+
+## 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.
+- The **group** parameter can be left blank.
+
+## Example
+
+Enter **chown 100 200 hello-harmony.txt**.
+
+## Output
+
+**Figure 1** Changing the owner and group of the hello-harmony.txt file to 100 and 200 respectively
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cp.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cp.md
new file mode 100644
index 0000000000000000000000000000000000000000..d654bd86f5da5f1dad144220e3955fc67e4a7599
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-cp.md
@@ -0,0 +1,68 @@
+# cp
+
+- [Command Function](#section6841203041513)
+- [Syntax](#section24286359150)
+- [Parameter Description](#section558617385152)
+- [Usage](#section16128156162)
+- [Example](#section19354171211618)
+- [Output](#section16754183195914)
+
+## Command Function
+
+This command is used to create a copy for a file.
+
+## Syntax
+
+cp \[_SOURCEFILE_\] \[_DESTFILE_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
SOURCEFILE
+
+
Indicates the path to the source file.
+
+
Currently, only files are supported. Directories are not supported.
+
+
+
DESTFILE
+
+
Indicates the path to the destination file.
+
+
Both directories and files are supported.
+
+
+
+
+
+## Usage
+
+- 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.
+- 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.
+- If the destination file does not exist, a new file is created. If the destination file already exists, the existing file is overwritten.
+
+When important system resources are copied, unexpected results such as a system breakdown may occur. For example, when the **/dev/uartdev-0** file is copied, the system may stop responding.
+
+## Example
+
+Enter **cp hello-harmony.txt ./tmp/**.
+
+## Output
+
+**Figure 1** File copying result
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-format.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-format.md
new file mode 100644
index 0000000000000000000000000000000000000000..06ff11d299af0cae40e548e8da3263cc7aaed5ed
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-format.md
@@ -0,0 +1,69 @@
+# format
+
+- [Command Function](#section1922331919169)
+- [Syntax](#section249226169)
+- [Parameter Description](#section985173416177)
+- [Usage](#section1510162714162)
+- [Example](#section25691431161611)
+- [Output](#section17368112365920)
+
+## Command Function
+
+This command is used to format a disk.
+
+## Syntax
+
+format <_dev\_inodename_\> <_sectors_\> <_option_\> \[_label_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
+
+
dev_inodename
+
+
Indicates 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.)
+
+
+
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)
+
+
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.
+
+
+
+
+
+## Usage
+
+- The **format** command is used to format a disk. You can find the device name in the **dev** directory. A storage card must be installed before the formatting.
+- This command can be used to format only the USB flash drive, SD card, and MMC, but not the NAND flash and NOR flash.
+- The **sectors** parameter must be set to a valid value. An invalid value may cause exceptions.
+
+## Example
+
+Enter **format /dev/mmcblk0 128 2**.
+
+## Output
+
+Formatting result
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-is.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-is.md
new file mode 100644
index 0000000000000000000000000000000000000000..20a95c9dcf2ffd4804a13d1d2a9f7d30b1e1b962
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-is.md
@@ -0,0 +1,58 @@
+# ls
+
+- [Command Function](#section6538163771614)
+- [Syntax](#section45881743111616)
+- [Parameter Description](#section17528148171617)
+- [Usage](#section041212533166)
+- [Example](#section986105716167)
+- [Output](#section2036124918592)
+
+## Command Function
+
+This command is used to display the content of a specified directory.
+
+## Syntax
+
+ls \[_path_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
path
+
+
If path is left blank, the content of the current directory is displayed.
+
If the path value is an invalid file name, the following failure message is displayed:
+
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
+
+
+
+
+
+## Usage
+
+- 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.
+
+## Example
+
+Enter **ls**.
+
+## Output
+
+**Figure 1** Viewing 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-lite-small-shell-cmd-file-isfd.md
new file mode 100644
index 0000000000000000000000000000000000000000..02962165e1e8998171905ffdcc3fea368c973eb6
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-isfd.md
@@ -0,0 +1,29 @@
+# lsfd
+
+- [Command Function](#section2053406181716)
+- [Syntax](#section523771017172)
+- [Usage](#section27241213201719)
+- [Example](#section442617197173)
+- [Output](#section42491639151813)
+
+## Command Function
+
+This command is used to display the file descriptors and names of currently opened files.
+
+## Syntax
+
+lsfd
+
+## Usage
+
+Run the **lsfd** command to view file descriptors and names of the opened files.
+
+## Example
+
+Enter **lsfd**.
+
+## Output
+
+**Figure 1** Command output
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mkdir.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mkdir.md
new file mode 100644
index 0000000000000000000000000000000000000000..77106a85f0ff8cea82322cafbaf3a62fd5051f1a
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mkdir.md
@@ -0,0 +1,54 @@
+# mkdir
+
+- [Command Function](#section1083613274175)
+- [Syntax](#section820913118178)
+- [Parameter Description](#section1256834121718)
+- [Usage](#section1294234115172)
+- [Example](#section1113345211713)
+- [Output](#section10142201012)
+
+## Command Function
+
+This command is used to create a directory.
+
+## Syntax
+
+mkdir \[_directory_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
directory
+
+
Indicates the directory to be created.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- If the **mkdir** command is followed by the name of the directory to be created, the directory is created in the current directory.
+- If the **mkdir** command is followed by a path and the name of the directory to be created, the directory is created in the specified path.
+
+## Example
+
+Enter **mkdir share**.
+
+## Output
+
+**Figure 1** Creating the share directory
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mount.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mount.md
new file mode 100644
index 0000000000000000000000000000000000000000..37feb309a276cdc1d5ccb7c8c339c219141b2507
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-mount.md
@@ -0,0 +1,78 @@
+# mount
+
+- [Command Function](#section11631837182)
+- [Syntax](#section1697638111820)
+- [Parameter Description](#section1650151221819)
+- [Usage](#section124541520171912)
+- [Example](#section7424625171917)
+- [Output](#section14757018116)
+
+## Command Function
+
+This command is used to mount a device to a specified directory.
+
+## Syntax
+
+mount <_device_\> <_path_\> <_name_\> \[_uid gid_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
device
+
+
Indicates 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.
+
+
N/A
+
+
+
name
+
+
Indicates the file system type.
+
+
vfat, yaffs, jffs, ramfs, nfs, procfs, romfs
+
+
+
uid gid
+
+
uid indicates the user ID.
+
gid indicates the group ID.
+
This parameter is optional. The default values are uid:0 and gid:0.
+
+
N/A
+
+
+
+
+
+## Usage
+
+By specifying the device to be mounted, directory, and file system format in the **mount** command, you can successfully mount the file system to the specified directory.
+
+## Example
+
+Enter **mount /dev/mmcblk0p0 /bin1/vs/sd vfat**.
+
+## Output
+
+Mounting **/dev/mmcblk0p0** to the **/bin1/vs/sd** directory
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-part.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-part.md
new file mode 100644
index 0000000000000000000000000000000000000000..da5b18b5bdd5e36f0fe08c425ded9138dddb6df5
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-part.md
@@ -0,0 +1,52 @@
+# partinfo
+
+- [Command Function](#section1777503617199)
+- [Syntax](#section185501447132114)
+- [Parameter Description](#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.
+
+## Syntax
+
+partinfo <_dev\_inodename_\>
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
dev_inodename
+
+
Indicates the name of the partition to be queried.
Displays information about the NAND flash partition.
+
+
N/A
+
+
+
spinor
+
+
Displays information about the spinor flash partition.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- The **partition** command is used to query flash partition information.
+- The NAND flash partition information can be viewed only when the YAFFS file system is enabled. The spinor flash partition information can be viewed only when the JFFS or ROMFS file system is enabled.
+
+## Example
+
+Enter **partition spinor**.
+
+## Output
+
+Viewing spinor flash partition information
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-pwd.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-pwd.md
new file mode 100644
index 0000000000000000000000000000000000000000..9f7182efd733fd05cad0f0a4c8d78f60ac50b074
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-pwd.md
@@ -0,0 +1,34 @@
+# pwd
+
+- [Command Function](#section197737712267)
+- [Syntax](#section1544061016267)
+- [Parameter Description](#section599112120262)
+- [Usage](#section66901116152615)
+- [Example](#section7427181922612)
+- [Output](#section116313389418)
+
+## Command Function
+
+This command is used to display the current path.
+
+## Syntax
+
+pwd
+
+## Parameter Description
+
+None
+
+## Usage
+
+The **pwd** command writes the full path name of the current directory \(from the root directory\) to the standard output. All directories are separated by slashes \(/\). The directory following the first slash \(/\) indicates the root directory, and the last directory is the current directory.
+
+## Example
+
+Enter **pwd**.
+
+## Output
+
+**Figure 1** Querying the current path
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rm.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rm.md
new file mode 100644
index 0000000000000000000000000000000000000000..072bb443e543c0309a97877e7f6a571387b5095f
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rm.md
@@ -0,0 +1,67 @@
+# rm
+
+- [Command Function](#section181141523142613)
+- [Syntax](#section8800926132619)
+- [Parameter Description](#section15476229152617)
+- [Usage](#section10578163215262)
+- [Example](#section18548133511263)
+- [Output](#section1565323814265)
+
+## Command Function
+
+This command is used to delete a file or folder.
+
+## Syntax
+
+rm \[_-r_\] \[_dirname / filename_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
-r
+
+
Deletes a directory. This parameter is optional. It is required if a directory is to be deleted.
+
+
N/A
+
+
+
dirname/filename
+
+
Indicates the name of the file or directory to be deleted. The value can be a path.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- The **rm** command deletes only one file or directory at a time.
+- The **rm -r** command can be used to delete a non-empty directory.
+
+## Example
+
+Example:
+
+1. Enter **rm log1.txt**.
+2. Enter **rm -r sd**.
+
+## Output
+
+**Figure 1** Deleting the **log1.txt** file
+
+
+**Figure 2** Deleting the **sd** directory
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rmdir.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rmdir.md
new file mode 100644
index 0000000000000000000000000000000000000000..78b7459cd91a8b17f9a7dcc2770362f6599ca5ec
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-rmdir.md
@@ -0,0 +1,55 @@
+# rmdir
+
+- [Command Function](#section1839611420266)
+- [Syntax](#section329574512266)
+- [Parameter Description](#section15865747102620)
+- [Usage](#section107857508261)
+- [Example](#section11196165315262)
+- [Output](#section1073811415613)
+
+## Command Function
+
+This command is used to delete a directory.
+
+## Syntax
+
+rmdir \[_dir_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
dir
+
+
Indicates the name of the directory to be deleted. The directory must be empty. You can enter a path for this parameter.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- The **rmdir** command can only be used to delete directories.
+- The **rmdir** command can delete only one directory at a time.
+- The **rmdir** command can delete only empty directories.
+
+## Example
+
+Enter **rmdir dir**.
+
+## Output
+
+**Figure 1** Deleting directory **dir**
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sta.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sta.md
new file mode 100644
index 0000000000000000000000000000000000000000..d2dc901d2cd4c7bc8907b3a9dff3a4812ea099ea
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sta.md
@@ -0,0 +1,52 @@
+# statfs
+
+- [Command Function](#section153921657152613)
+- [Syntax](#section135391102717)
+- [Parameter Description](#section074312314279)
+- [Usage](#section133816772712)
+- [Example](#section526149182717)
+
+## Command Function
+
+This command is used to print information about a file system, such as the type, total size, and available size.
+
+## Syntax
+
+statfs \[_directory_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
directory
+
+
Indicates 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.
+
+
+
+
+
+## Usage
+
+The printed information varies depending on the file system.
+
+## Example
+
+The following uses the NFS file system as an example:
+
+Enter **statfs /nfs**.
+
+**Figure 1** Output of the statfs command
+
+
diff --git a/en/device-dev/kernel/sync.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sync.md
similarity index 100%
rename from en/device-dev/kernel/sync.md
rename to en/device-dev/kernel/kernel-lite-small-shell-cmd-file-sync.md
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-touch.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-touch.md
new file mode 100644
index 0000000000000000000000000000000000000000..eef1d51cfac06ed388294a2cf896960faf4510ed
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-touch.md
@@ -0,0 +1,59 @@
+# touch
+
+- [Command Function](#section17541924112716)
+- [Syntax](#section866182711274)
+- [Parameter Description](#section268912296270)
+- [Usage](#section412093332714)
+- [Example](#section414434814354)
+- [Output](#section1028419515711)
+
+## Command Function
+
+- This command is used to create an empty file in a specified directory.
+- If this command is executed to create an existing file, the execution will be successful but the timestamp will not be updated.
+
+## Syntax
+
+touch \[_filename_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
filename
+
+
Indicates the name of the file to be created.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- The **touch** command creates a read-write empty file.
+- The **touch** command creates only one file at a time.
+
+ > **NOTICE:**
+ >If you run the **touch** command to create a file in a path storing important system resources, unexpected results such as a system breakdown may occur. For example, if you run the **touch uartdev-0** command in the **/dev** path, the system may stop responding.
+
+
+## Example
+
+Enter **touch file.c**.
+
+## Output
+
+**Figure 1** Creating **file.c**
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-umount.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-umount.md
new file mode 100644
index 0000000000000000000000000000000000000000..ad2e4575a2e6bc658144afb407ae1a27fd95e468
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-umount.md
@@ -0,0 +1,55 @@
+# umount
+
+- [Command Function](#section365125133520)
+- [Syntax](#section9615254123512)
+- [Parameter Description](#section63446577355)
+- [Usage](#section92931509368)
+- [Example](#section144311323616)
+- [Output](#section360525113611)
+
+## Command Function
+
+This command is used to unmount a specified file system.
+
+## Syntax
+
+umount \[_dir_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
dir
+
+
Indicates the directory from which the file system is to be unmounted.
+
+
Directory to which the file system has been mounted
+
+
+
+
+
+## Usage
+
+By specifying the **dir** parameter in the **unmount** command, you can unmount the specified file system from the directory.
+
+## Example
+
+Enter **umount /bin1/vs/sd**.
+
+## Output
+
+Unmounting the file system from **/bin1/vs/sd**
+
+**Figure 1** Unmounting result
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-write.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-write.md
new file mode 100644
index 0000000000000000000000000000000000000000..5bffaf6a19ae64f27475d646b8982f31c8012d36
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file-write.md
@@ -0,0 +1,69 @@
+# writeproc
+
+- [Command Function](#section366714216619)
+- [Syntax](#section8833164614615)
+- [Parameter Description](#section12809111019453)
+- [Usage](#section15935131220717)
+- [Example](#section79281818476)
+- [Output](#section12742311179)
+
+## Command Function
+
+This command is used to write data to a specified proc file system. The proc file system supports the input of string parameters. Each file needs to implement its own method.
+
+## Syntax
+
+writeproc <_data_\> \>\> /proc/<_filename_\>
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
data
+
+
Indicates 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.
+
+
N/A
+
+
+
+
+
+## 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.
+
+> **NOTE:**
+>The proc file system does not support multi-thread access.
+
+## Example
+
+Enter **writeproc test \>\> /proc/uptime**.
+
+## Output
+
+OHOS \# writeproc test \>\> /proc/uptime
+
+\[INFO\]write buf is: test
+
+test \>\> /proc/uptime
+
+> **NOTE:**
+>The uptime proc file temporarily implements the **write** command. The **INFO** log is generated by the implemented **test** command.
+
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
new file mode 100644
index 0000000000000000000000000000000000000000..b47f48fbebd91c9f0edb883f48aa53b360100b46
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-file.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..9bcfa88de03da750fda2be03b4ef15505a27c91f
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-mag.md
@@ -0,0 +1,40 @@
+# 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.
+
+> **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!".
+
+
+> **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-arp.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-arp.md
new file mode 100644
index 0000000000000000000000000000000000000000..b0267af58de2fbc692cabe60efe2f02ba0c367ad
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-arp.md
@@ -0,0 +1,114 @@
+# arp
+
+- [Command Function](#section201149459368)
+- [Syntax](#section579813484364)
+- [Parameter Description](#section168065311366)
+- [Usage](#section19190125723612)
+- [Example](#section10383416372)
+
+## Command Function
+
+On an Ethernet, hosts communicate with each other using MAC addresses \(non-IP addresses\). Therefore, IP addresses must be converted into MAC addresses so that hosts can communicate with each other on a LAN \(Ethernet\). To resolve this issue, the host stores a table containing the mapping between IP addresses and MAC addresses, that is, the ARP cache table. When the host needs to send an IP packet to the destination IP address on a LAN, the host can query the destination MAC address from the ARP cache table. The ARP cache table is maintained by the TCP/IP protocol stack. You can run the **arp** command to view and modify the ARP cache table.
+
+## Syntax
+
+arp
+
+arp \[_-i IF_\] -s _IPADDR HWADDR_
+
+arp \[_-i IF_\] -d _IPADDR_
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
No parameter
+
+
Prints the content of the entire ARP cache table.
+
+
N/A
+
+
+
-i IF
+
+
Indicates the network interface. This parameter is optional.
+
+
N/A
+
+
+
-s IPADDR
+
HWADDR
+
+
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
+
+
Deletes an ARP entry.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- The **arp** command is used to query and modify the ARP cache table of the TCP/IP protocol stack. If ARP entries for IP addresses on different subnets are added, the protocol stack returns a failure message.
+- This command can be used only after the TCP/IP protocol stack is enabled.
+
+## Example
+
+Example:
+
+1. Enter **arp**.
+
+ **Figure 1** Printing the entire ARP cache table
+
+
+ 
+
+ **Table 2** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
Address
+
+
Indicates the IPv4 address of a network device.
+
+
+
HWaddress
+
+
Indicates the MAC address of a network device.
+
+
+
Iface
+
+
Indicates the name of the interface used by the ARP entry.
+
+
+
Type
+
+
Indicates whether the ARP entry is dynamic or static. A dynamic ARP entry is automatically created by the protocol stack, and a static ARP entry is added by the user.
Indicates that 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.
+
+
+
+
+
diff --git a/en/device-dev/kernel/dns.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-dns.md
similarity index 100%
rename from en/device-dev/kernel/dns.md
rename to en/device-dev/kernel/kernel-lite-small-shell-cmd-net-dns.md
diff --git a/en/device-dev/kernel/ifconfig.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipc.md
similarity index 100%
rename from en/device-dev/kernel/ifconfig.md
rename to en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipc.md
diff --git a/en/device-dev/kernel/ipdebug.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipd.md
similarity index 100%
rename from en/device-dev/kernel/ipdebug.md
rename to en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ipd.md
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-net.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-net.md
new file mode 100644
index 0000000000000000000000000000000000000000..362fa9a4301ca48b86cab9e2732fcfdfd9a89c4e
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-net.md
@@ -0,0 +1,83 @@
+# netstat
+
+- [Command Function](#section13469162113816)
+- [Syntax](#section795712373812)
+- [Parameter Description](#section17629431193817)
+- [Usage](#section5277153519380)
+- [Example](#section108141437163820)
+- [Output](#section1357015107117)
+
+## Command Function
+
+The **netstat** command is a console command and is used for monitoring the TCP/IP network. It can display the actual network connections and the status of each network interface device. It is used to display the statistics related to the TCP and UDP protocols and check the network connection to each port on the device \(board\).
+
+## Syntax
+
+netstat
+
+## Parameter Description
+
+None
+
+## Usage
+
+Run the command directly.
+
+## Example
+
+Enter **netstat**.
+
+**Figure 1** Output information
+
+
+
+
+## Output
+
+**Table 1** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
Proto
+
+
Indicates the 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.
+
+
+
Send-Q
+
+
For a TCP connection, this value indicates the amount of data that has been sent but not acknowledged.
+
For a UDP connection, this value indicates the amount of data buffered before IP address resolution is complete.
+
+
+
Local Address
+
+
Indicates the local IP address and port number.
+
+
+
Foreign Address
+
+
Indicates the remote IP address and port number.
+
+
+
State
+
+
Indicates the TCP connection status. This parameter is meaningless for UDP.
+
+
+
+
+
+> **NOTE:**
+>The command output like "========== total sockets 32 ====== unused sockets 22 BootTime 27 s ==========" indicates that there are 32 sockets in total, 22 sockets are not used, and it has been 27 seconds since the system starts.
+
diff --git a/en/device-dev/kernel/ntpdate.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ntp.md
similarity index 100%
rename from en/device-dev/kernel/ntpdate.md
rename to en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ntp.md
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping.md
new file mode 100644
index 0000000000000000000000000000000000000000..0d83722cacc365360530ae1ea7d9e141cb86155c
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping.md
@@ -0,0 +1,98 @@
+# ping
+
+- [Command Function](#section119672573385)
+- [Syntax](#section869419010390)
+- [Parameter Description](#section9877183173918)
+- [Usage](#section1097046193914)
+- [Example](#section14564129113911)
+- [Output](#section1621732891215)
+
+## Command Function
+
+This command is used to test whether the network connection is normal.
+
+## Syntax
+
+ping_ _\[_-n cnt_\] \[_-w interval_\] \[_-l data\_len_\]_ _
+
+ping \[_-t_\] \[_-w interval_\] __
+
+ping _-k_
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
IP
+
+
Indicates 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.
+
+
1-65535
+
+
+
-w interval
+
+
Indicates the interval between two ping packets, in ms.
+
+
>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.
+
+
0-65500
+
+
+
-t
+
+
Indicates a permanent ping thread, which will be killed until the ping -k command is executed.
+
+
N/A
+
+
+
-k
+
+
Kills the ping thread and stops the ping operation.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- Run the **ping** command by setting a destination IP address to check whether the network connection to the destination IP address is normal.
+- If the destination IP address is unreachable, the system displays a message indicating that the request times out.
+- If no route is available to the destination IP address, an error message is displayed.
+- This command can be used only after the TCP/IP protocol stack is enabled.
+
+## Example
+
+Enter **ping 192.168.1.10**.
+
+## Output
+
+**Figure 1** Output of pinging the IP address of the TFTP server
+
+
+
+
diff --git a/en/device-dev/kernel/ping6.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping6.md
similarity index 100%
rename from en/device-dev/kernel/ping6.md
rename to en/device-dev/kernel/kernel-lite-small-shell-cmd-net-ping6.md
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tel.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tel.md
new file mode 100644
index 0000000000000000000000000000000000000000..30c190696e0d3b2ef1a2ead7cc8d1e25997909b3
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tel.md
@@ -0,0 +1,65 @@
+# telnet
+
+- [Command Function](#section3551830123913)
+- [Syntax](#section14897133233918)
+- [Parameter Description](#section977718353392)
+- [Usage](#section134991538183916)
+- [Example](#section1097414426398)
+- [Output](#section11846624191310)
+
+## Command Function
+
+This command is used to enable or disable the Telnet server service.
+
+## Syntax
+
+telnet \[_on | off_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
on
+
+
Enables the Telnet server service.
+
+
N/A
+
+
+
off
+
+
Disables the Telnet server service.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- Before enabling Telnet, ensure that the network driver and network protocol stack have been initialized and the NIC of the board is in the **link up** state.
+- Currently, multiple clients \(Telnet + IP\) cannot connect to the development board at the same time.
+
+ > **NOTICE:**
+ >Telnet is under debugging and disabled by default. Do not use it in formal products.
+
+
+## Example
+
+Enter **telnet on**.
+
+## Output
+
+**Figure 1** Output of **telnet on**
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tftp.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tftp.md
new file mode 100644
index 0000000000000000000000000000000000000000..3da40ac274b26ac660065256ad5d8a99c9da8468
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net-tftp.md
@@ -0,0 +1,87 @@
+# tftp
+
+- [Command Function](#section15142134573911)
+- [Syntax](#section20958174917394)
+- [Parameter Description](#section576613532395)
+- [Usage](#section149795134408)
+- [Example](#section148921918114015)
+- [Output](#section7872155631313)
+
+## Command Function
+
+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.
+
+## Syntax
+
+./bin/tftp _<-g/-p\>_ _-l_ _\[FullPathLocalFile\] -r \[RemoteFile\] \[Host\]_
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
-g/-p
+
+
Indicates the file transfer direction.
+
-g: downloads files from the TFTP server.
-p: uploads files to the TFTP server.
+
+
N/A
+
+
+
-l FullPathLocalFile
+
+
Indicates the complete path of a local file.
+
+
N/A
+
+
+
-r RemoteFile
+
+
Indicates the file name on the server.
+
+
N/A
+
+
+
Host
+
+
Indicates the server IP address.
+
+
N/A
+
+
+
+
+
+## Usage
+
+1. Deploy a TFTP server on the server and configure the TFTP server correctly.
+2. Use the **tftp** command to upload and download files on the OpenHarmony board.
+3. The size of the file to be transferred cannot exceed 32 MB.
+
+ > **NOTICE:**
+ >TFTP is under debugging and disabled by default. Do not use it in formal products.
+
+
+## Example
+
+Download the **out** file from the server.
+
+## Output
+
+```
+OHOS # ./bin/tftp -g -l /nfs/out -r out 192.168.1.2
+TFTP transfer finish
+```
+
+After the **tftp** command is executed, **TFTP transfer finish** is displayed if the file transfer is complete. If the file transfer fails, other information is displayed to help locate the fault.
+
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
new file mode 100644
index 0000000000000000000000000000000000000000..68d76bf26eccdeef28fa67938389cdae428d81f4
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-net.md
@@ -0,0 +1,25 @@
+# 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-cpup.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-cpup.md
new file mode 100644
index 0000000000000000000000000000000000000000..fc8d35798807612cd32d68d78af1735edab736fc
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-cpup.md
@@ -0,0 +1,63 @@
+# cpup
+
+- [Command Function](#section1842161614217)
+- [Syntax](#section5629527427)
+- [Parameter Description](#section133651361023)
+- [Usage](#section156611948521)
+- [Example](#section68501605319)
+- [Output](#section19871522144219)
+
+## Command Function
+
+This command is used to query the CPU usage of the system.
+
+## Syntax
+
+cpup \[_mode_\] \[_taskID_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
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.
+
+
[0, 0xFFFFFFFF]
+
+
+
taskID
+
+
Indicates the task ID.
+
+
[0, 0xFFFFFFFF]
+
+
+
+
+
+## Usage
+
+- If the parameters are not specified, the CPU usage within the last 10 seconds is displayed.
+- If only the **mode** parameter is specified, the CPU usage within the specified period is displayed.
+- If both the **mode** and **taskID** parameters are specified, the CPU usage of the specified task within the given period is displayed.
+
+## Example
+
+Enter **cpup 1 5**.
+
+## Output
+
+**Figure 1** CPU usage
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-date.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-date.md
new file mode 100644
index 0000000000000000000000000000000000000000..ebd63e75d05e9f349275be20f465b3c3a15ca561
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-date.md
@@ -0,0 +1,92 @@
+# date
+
+- [Command Function](#section56472016338)
+- [Syntax](#section16635112512316)
+- [Parameter Description](#section15896030039)
+- [Usage](#section116361036636)
+- [Example](#section021711411237)
+- [Output](#section17950184414312)
+
+## Command Function
+
+This command is used to query and set the system date and time.
+
+## Syntax
+
+date
+
+date --help
+
+date +\[_Format_\]
+
+date -s_ _\[_YY/MM/DD_\]
+
+date_ _-s_ _\[_hh:mm:ss_\]__
+
+date -r \[_Filename_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
--help
+
+
Uses the help.
+
+
N/A
+
+
+
+Format
+
+
Prints the date and time based on Format.
+
+
Placeholders listed in --help.
+
+
+
-s YY/MM/DD
+
+
Sets the system date and separates the year, month, and day by slashes (/).
+
+
>= 1970/01/01
+
+
+
-s hh:mm:ss
+
+
Sets the system time and separates the hour, minute, and second by colons (:).
+
+
N/A
+
+
+
-r Filename
+
+
Queries the modification time of the Filename file.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- If the **date** parameter is not specified, the current system date and time are displayed by default.
+- The **--help**, **+Format**, **-s**, and **-r** parameters are mutually exclusive.
+
+## Example
+
+Enter **date +%Y--%m--%d**.
+
+## Output
+
+**Figure 1** System date printed based on the specified format
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-demsg.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-demsg.md
new file mode 100644
index 0000000000000000000000000000000000000000..d122787795603df26b1d319151fa094c4cd674fa
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-demsg.md
@@ -0,0 +1,111 @@
+# dmesg
+
+- [Command Function](#section4643204919313)
+- [Syntax](#section6553153635)
+- [Parameter Description](#section208971157532)
+- [Usage](#section213115219413)
+- [Example](#section13736564418)
+- [Output](#section194005101413)
+
+## Command Function
+
+This command is used to control the dmesg buffer of the kernel.
+
+## Syntax
+
+dmesg
+
+dmesg \[_-c/-C/-D/-E/-L/-U_\]
+
+dmesg -s \[_size_\]
+
+dmesg -l \[_level_\]
+
+dmesg \> \[_fileA_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
-c
+
+
Prints content in the buffer and clears the buffer.
+
+
N/A
+
+
+
-C
+
+
Clears the buffer.
+
+
N/A
+
+
+
-D/-E
+
+
Enables or disables printing to the console.
+
+
N/A
+
+
+
-L/-U
+
+
Enables or disables printing via the serial port.
+
+
N/A
+
+
+
-s size
+
+
Sets the size of the buffer.
+
+
N/A
+
+
+
-l level
+
+
Sets the buffering level.
+
+
0 - 5
+
+
+
> fileA
+
+
Writes the content in the buffer to a file.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- This command depends on **LOSCFG\_SHELL\_DMESG**. Before running this command, enable the **Enable Shell dmesg** configuration item using **menuconfig**.
+
+ Debug ---\> Enable a Debug Version ---\> Enable Shell ---\> Enable Shell dmesg
+
+- If the parameters are not specified, all content in the buffer is printed.
+- The parameters followed by hyphens \(-\) are mutually exclusive.
+ 1. Before writing content to a file, ensure that the file system has been mounted.
+ 2. Disabling the serial port printing will adversely affect the shell. You are advised to set up a connection using Telnet before disabling the serial port.
+
+
+## Example
+
+Enter **dmesg \> /usr/dmesg.log**.
+
+## Output
+
+**Figure 1** Writing dmesg content to a file
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-exec.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-exec.md
new file mode 100644
index 0000000000000000000000000000000000000000..e68a27f893b835538ac24e9ed38eacf4854d10ed
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-exec.md
@@ -0,0 +1,58 @@
+# exec
+
+- [Command Function](#section4643204919313)
+- [Syntax](#section6553153635)
+- [Parameter Description](#section208971157532)
+- [Usage](#section213115219413)
+- [Example](#section13736564418)
+- [Output](#section194005101413)
+
+## Command Function
+
+This command is a built-in shell command used to execute user-space programs.
+
+## Syntax
+
+exec <_executable-file_\>
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
executable-file
+
+
Indicates a valid executable file.
+
+
N/A
+
+
+
+
+
+## Usage
+
+Currently, this command supports only valid binary programs. The programs are successfully executed and then run in the background by default. However, the programs share the same device with the shell. As a result, the output of the programs and the shell may be interlaced.
+
+## Example
+
+Enter **exec helloworld**.
+
+## Output
+
+```
+OHOS # exec helloworld
+OHOS # hello world!
+```
+
+> **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.
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-free.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-free.md
new file mode 100644
index 0000000000000000000000000000000000000000..09e281e9f498c2673b1c71974cc80ab23cc4cce0
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-free.md
@@ -0,0 +1,119 @@
+# free
+
+- [Command Function](#section175151514841)
+- [Syntax](#section8488721749)
+- [Parameter Description](#section27272181949)
+- [Usage](#section148661259410)
+- [Example](#section68081530242)
+- [Output](#section171235517543)
+
+## Command Function
+
+This command is used to display the system memory usage and the sizes of the **text**, **data**, **rodata**, and **bss** segments.
+
+## Syntax
+
+free \[_-k | -m_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
No parameter
+
+
Displays the size in the unit of byte.
+
+
N/A
+
+
+
-k
+
+
Displays the size in the unit of KB.
+
+
N/A
+
+
+
-m
+
+
Displays the size in the unit of MB.
+
+
N/A
+
+
+
+
+
+## Usage
+
+None
+
+## Example
+
+Enter **free**, **free -k**, and **free -m**, respectively.
+
+## Output
+
+**Figure 1** Displaying the memory usage in three units
+
+
+**Table 2** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
total
+
+
Indicates the total size of the dynamic memory pool.
+
+
+
used
+
+
Indicates the size of the used memory.
+
+
+
free
+
+
Indicates the size of the unallocated memory.
+
+
+
heap
+
+
Indicates the size of the allocated heap.
+
+
+
text
+
+
Indicates the size of a code segment.
+
+
+
data
+
+
Indicates the size of a data segment.
+
+
+
rodata
+
+
Indicates the size of a read-only data segment.
+
+
+
bss
+
+
Indicates the size of the memory occupied by uninitialized global variables.
+
+
+
+
+
diff --git a/en/device-dev/kernel/help.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-help.md
similarity index 100%
rename from en/device-dev/kernel/help.md
rename to en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-help.md
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-hwi.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-hwi.md
new file mode 100644
index 0000000000000000000000000000000000000000..90027ac456a656ca1dd41d7451491df2caba5ba7
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-hwi.md
@@ -0,0 +1,94 @@
+# hwi
+
+- [Command Function](#section445335110416)
+- [Syntax](#section1795712553416)
+- [Parameter Description](#section92544592410)
+- [Usage](#section104151141252)
+- [Example](#section11545171957)
+- [Output](#section075617368542)
+
+## Command Function
+
+This command is used to query information about the current interrupts.
+
+## Syntax
+
+hwi
+
+## Parameter Description
+
+None
+
+## Usage
+
+- Enter **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
+
+Enter **hwi**.
+
+## Output
+
+1. Interrupt information \(with **LOSCFG\_CPUP\_INCLUDE\_IRQ** disabled\)
+
+ 
+
+2. Interrupt information \(with **LOSCFG\_CPUP\_INCLUDE\_IRQ** enabled\)
+
+ 
+
+ **Table 1** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
InterruptNo
+
+
Indicates the interrupt ID.
+
+
+
Count
+
+
Indicates the count of interrupts.
+
+
+
Name
+
+
Indicates the registered interrupt name.
+
+
+
CYCLECOST
+
+
Indicates the interrupt processing time (cycles).
+
+
+
CPUUSE
+
+
Indicates the CPU usage.
+
+
+
CPUUSE10s
+
+
Indicates CPU usage within the last 10 seconds.
+
+
+
CPUUSE1s
+
+
Indicates CPU usage within the last 1 second.
+
+
+
mode
+
+
Indicates the interrupt mode.
+
normal: non-shared interrupt.
shared: shared interrupt.
+
+
+
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-kill.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-kill.md
new file mode 100644
index 0000000000000000000000000000000000000000..3b69b6c8da73988cfbd00566587adffc425613b7
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-kill.md
@@ -0,0 +1,82 @@
+# kill
+
+- [Command Function](#section366714216619)
+- [Syntax](#section8833164614615)
+- [Parameter Description](#section12809111019453)
+- [Usage](#section15935131220717)
+- [Example](#section79281818476)
+- [Output](#section12742311179)
+
+## Command Function
+
+This command is used to send a specific signal to a specified process.
+
+## Syntax
+
+kill \[_signo_ | _-signo_\] \[_pid_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
signo
+
+
Indicates the signal ID.
+
+
[1, 30]
+
+
+
pid
+
+
Indicates the process ID.
+
+
[1, MAX_INT]
+
+
+
+
+
+> **NOTICE:**
+>The valid range of the **signo** value is \[0, 64\], and the recommended value range is \[1, 30\]. Other values in the valid range are reserved.
+
+## Usage
+
+The **signo** and **pid** parameters are mandatory.
+
+The **pid** value range varies depending on the system configuration. For example, if the maximum **pid** value supported by the system is **256**, this value range is \[1-256\].
+
+## Example
+
+1. Query the current process list and determine the PID \(7\) of the process to be killed.
+
+**Figure 1** Querying PIDs
+
+
+2. Run **kill 14 7** to send signal 14 \(the default behavior of **SIGALRM** is to terminate the process\) to process 7 **helloworld\_d** \(user-space\). Then query the current process list. Process 7 has been terminated. The result of the **kill 14 7** command is the same as that of the **kill -14 7** command.
+
+**Figure 2** Command output
+
+
+## Output
+
+The command output is as follows:
+
+**Figure 3** Sending a signal to a specified process
+
+
+The signal is successfully sent if no error is reported.
+
+**Figure 4** 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.
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-log.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-log.md
new file mode 100644
index 0000000000000000000000000000000000000000..ae7b0cde098849ed4a0762b59394ac75531c7fc7
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-log.md
@@ -0,0 +1,72 @@
+# log
+
+- [Command Function](#section128219131856)
+- [Syntax](#section3894181710519)
+- [Parameter Description](#section7693122310515)
+- [Usage](#section1982111281512)
+- [Example](#section176301333259)
+- [Output](#section14354765415)
+
+## Command Function
+
+This command is used to modify and query log configurations.
+
+## Syntax
+
+log level \[_levelNum_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
levelNum
+
+
Indicates the print level of configuration logs.
+
+
[0x0, 0x5]
+
+
+
+
+
+## Usage
+
+- This command depends on **LOSCFG\_SHELL\_LK**. Before running this command, enable the **Enable Shell lk** configuration item using **menuconfig**.
+
+ Debug ---\> Enable a Debug Version ---\> Enable Shell ---\> Enable Shell lK
+
+- The **log level** command is used to configure log levels, which can be:
+
+ TRACE\_EMG = 0,
+
+ TRACE\_COMMON = 1,
+
+ TRACE\_ERROR = 2,
+
+ TRACE\_WARN = 3,
+
+ TRACE\_INFO = 4,
+
+ TRACE\_DEBUG = 5
+
+ If the level is not within the valid range, a message is printed.
+
+- If the **\[levelNum\]** parameter is not specified, the current log level and its usage are printed by default.
+
+## Example
+
+Enter **log level 4**.
+
+## Output
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-mem.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-mem.md
new file mode 100644
index 0000000000000000000000000000000000000000..965a6eb17045482ecf59a9e19e0f4e8e5e7cfa77
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-mem.md
@@ -0,0 +1,38 @@
+# memcheck
+
+- [Command Function](#section191633812516)
+- [Syntax](#section428816435510)
+- [Parameter Description](#section1939943304411)
+- [Usage](#section228914491951)
+- [Example](#section17373205314515)
+- [Output](#section13406205385413)
+
+## Command Function
+
+This command is used to check whether the dynamically requested memory block is complete and whether nodes in the memory pool are damaged due to out-of-bounds memory access.
+
+## Syntax
+
+memcheck
+
+## Parameter Description
+
+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.
+
+## Example
+
+Enter **memcheck**.
+
+## Output
+
+**Figure 1** No out-of-bounds memory access
+
+
+**Figure 2** Out-of-bounds memory access
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-oom.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-oom.md
new file mode 100644
index 0000000000000000000000000000000000000000..7748844b3fc8ddc7d2a213b262481fc554aaa1be
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-oom.md
@@ -0,0 +1,120 @@
+# oom
+
+- [Command Function](#section366714216619)
+- [Syntax](#section8833164614615)
+- [Parameter Description](#section12809111019453)
+- [Usage](#section15935131220717)
+- [Example](#section79281818476)
+- [Output](#section12742311179)
+
+## Command Function
+
+This command is used to query and set the low memory threshold and the page cache reclaim threshold.
+
+## Syntax
+
+oom
+
+oom -i \[_interval_\]
+
+oom -m \[_mem byte_\]
+
+oom -r \[_mem byte_\]
+
+oom -h | --help
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
-i [interval]
+
+
Sets the interval for checking the Out Of Memory (OOM) thread task.
+
+
100 ms – 10000 ms
+
+
+
-m [mem byte]
+
+
Sets the low memory threshold.
+
+
0 MB (does not check for low memory) – 1 MB
+
+
+
-r [mem byte]
+
+
Sets the page cache reclaim threshold.
+
+
Ranging from the low memory threshold to the maximum available system memory
+
+
+
-h | --help
+
+
Uses the help.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- If no parameter is specified, the current configurations of the OOM function are displayed.
+
+## Example
+
+When the system memory is insufficient, the system displays a message indicating the insufficiency.
+
+## Output
+
+
+
+**Table 2** Output description
+
+
+
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.
+
+
+
[oom] candidate victim process UserProcess12 pid: 12, actual phy mem byte: 25951558
+
+
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.
+
+
+
excFrom: User!
+
+
When the system memory is low, the UserProcess12 process fails to apply for memory and exits as a result.
+
+
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-pmm.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-pmm.md
new file mode 100644
index 0000000000000000000000000000000000000000..34e2594d5d6d61d6cbb935b62986eb796334d5b5
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-pmm.md
@@ -0,0 +1,91 @@
+# pmm
+
+- [Command Function](#section445335110416)
+- [Syntax](#section1795712553416)
+- [Parameter Description](#section92544592410)
+- [Usage](#section104151141252)
+- [Example](#section11545171957)
+- [Output](#section075617368542)
+
+## Command Function
+
+This command is used to check the usage of the physical pages and page cache of the system memory.
+
+## Syntax
+
+pmm
+
+## Parameter Description
+
+None
+
+## Usage
+
+This command is available only in the **Debug** version.
+
+## Example
+
+Enter **pmm**.
+
+## Output
+
+**Figure 1** Viewing the usage of physical pages
+
+
+**Table 1** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
phys_seg
+
+
Indicates the address of the physical page control block.
+
+
+
base
+
+
Indicates the first physical page address, that is, start address of the physical page memory.
+
+
+
size
+
+
Indicates the size of the physical page memory.
+
+
+
free_pages
+
+
Indicates the number of idle physical pages.
+
+
+
active anon
+
+
Indicates the number of active anonymous pages in the page cache.
+
+
+
inactive anon
+
+
Indicates the number of inactive anonymous pages in the page cache.
+
+
+
active file
+
+
Indicates the number of active file pages in the page cache.
+
+
+
inactive file
+
+
Indicates the 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.
+
+
+
+
+
diff --git a/en/device-dev/kernel/reset.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-reset.md
similarity index 100%
rename from en/device-dev/kernel/reset.md
rename to en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-reset.md
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sem.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sem.md
new file mode 100644
index 0000000000000000000000000000000000000000..1941131dd0fcc3a410f4786a9491a2ee34d79547
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sem.md
@@ -0,0 +1,91 @@
+# sem
+
+- [Command Function](#section366714216619)
+- [Syntax](#section8833164614615)
+- [Parameter Description](#section12809111019453)
+- [Usage](#section15935131220717)
+- [Example](#section79281818476)
+- [Output](#section1975118519456)
+
+## Command Function
+
+This command is used to query information about kernel semaphores.
+
+## Syntax
+
+sem \[_ID__ / fulldata_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
ID
+
+
Indicates 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.
+
+
N/A
+
+
+
+
+
+## Usage
+
+- 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**.
+
+ Debug ---\> Enable a Debug Version ---\> Enable Debug LiteOS Kernel Resource ---\> Enable Semaphore Debugging
+
+
+## Example
+
+Example 1: Enter **sem fulldata**.
+
+## Output
+
+**Figure 1** Querying information about all semaphores in use
+
+
+**Table 2** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
SemID
+
+
Indicates the semaphore ID.
+
+
+
Count
+
+
Indicates the number of used semaphores.
+
+
+
+
+
+> **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.
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-stack.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-stack.md
new file mode 100644
index 0000000000000000000000000000000000000000..e9d5ab785c3dbca69d6245083c90e6522e3fd826
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-stack.md
@@ -0,0 +1,73 @@
+# stack
+
+- [Command Function](#section445335110416)
+- [Syntax](#section1795712553416)
+- [Parameter Description](#section92544592410)
+- [Usage](#section104151141252)
+- [Example](#section11545171957)
+- [Output](#section075617368542)
+
+## Command Function
+
+This command is used to check the usage of each stack in the system.
+
+## Syntax
+
+stack
+
+## Parameter Description
+
+None
+
+## Usage
+
+None
+
+## Example
+
+Enter **stack**.
+
+## Output
+
+**Figure 1** System stack usage
+
+
+
+
+**Table 1** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
stack name
+
+
Indicates the system stack name.
+
+
+
cpu id
+
+
Indicates the CPU ID.
+
+
+
stack addr
+
+
Indicates the stack address.
+
+
+
total size
+
+
Indicates the stack size.
+
+
+
used size
+
+
Indicates the used size of the stack.
+
+
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-su.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-su.md
new file mode 100644
index 0000000000000000000000000000000000000000..44f370e01867c0ac061f77598d178c93d71241fb
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-su.md
@@ -0,0 +1,62 @@
+# su
+
+- [Command Function](#section297810431676)
+- [Syntax](#section157131147876)
+- [Parameter Description](#section04145521671)
+- [Usage](#section14615155610719)
+- [Example](#section13338150985)
+- [Output](#section125021924194613)
+
+## Command Function
+
+This command is used to switch the user.
+
+## Syntax
+
+su \[_uid_\] \[_gid_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
uid
+
+
Indicates the ID of the target user.
+
+
Left blank
[0, 60000]
+
+
+
gid
+
+
Indicates the ID of the target user group.
+
+
Left blank
[0, 60000]
+
+
+
+
+
+## Usage
+
+- 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.
+
+## Example
+
+Enter **su 1000 1000**.
+
+## Output
+
+**Figure 1** Switching to the user whose **uid** and **gid** are both **1000**
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-swymr.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-swymr.md
new file mode 100644
index 0000000000000000000000000000000000000000..c69f0d3c071d618f595d4418f3763b05ebda77eb
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-swymr.md
@@ -0,0 +1,110 @@
+# swtmr
+
+- [Command Function](#section166171064814)
+- [Syntax](#section424011111682)
+- [Parameter Description](#section1268410459465)
+- [Usage](#section169806213815)
+- [Example](#section16676026389)
+- [Output](#section1541991614710)
+
+## Command Function
+
+This command is used to query information about system software timers.
+
+## Syntax
+
+swtmr \[_ID_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
ID
+
+
Indicates the ID of a software timer.
+
+
[0, 0xFFFFFFFF]
+
+
+
+
+
+## Usage
+
+- If the parameter is not 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**.
+
+## Output
+
+**Figure 1** Querying information about all software timers
+
+
+**Figure 2** Querying information about a specified software timer
+
+
+**Table 2** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
SwTmrID
+
+
Indicates the ID of the software timer.
+
+
+
State
+
+
Indicates the 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).
+
+
+
Interval
+
+
Indicates the number of ticks used by the software timer.
+
+
+
Count
+
+
Indicates the number of times that the software timer has been working.
+
+
+
Arg
+
+
Indicates the input parameter.
+
+
+
handlerAddr
+
+
Indicates the callback address.
+
+
+
+
+
+> **NOTE:**
+>- The **ID** value can be in decimal or hexadecimal format.
+>- If the **ID** value is within the range of \[0, _Number of current software timers - 1_\], the status of the specified software timer is returned. For other values, an error message is displayed.
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sys.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sys.md
new file mode 100644
index 0000000000000000000000000000000000000000..8868225020ea651976928fda71a42afe12fc715c
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-sys.md
@@ -0,0 +1,91 @@
+# systeminfo
+
+- [Command Function](#section863016434820)
+- [Syntax](#section139791817795)
+- [Parameter](#section19472339164813)
+- [Usage](#section285522592)
+- [Example](#section9471171015105)
+- [Output](#section1657011114915)
+
+## Command Function
+
+This command is used to display the resource usage of the current OS, including tasks, semaphores, mutexes, queues, and timers.
+
+## Syntax
+
+systeminfo
+
+## Parameter
+
+None
+
+## Usage
+
+None
+
+## Example
+
+Enter **systeminfo**.
+
+## Output
+
+**Figure 1** Usage of system resources
+
+
+**Table 1** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
Module
+
+
Indicates the module name.
+
+
+
Used
+
+
Indicates the quantity of currently used resources.
+
+
+
Total
+
+
Indicates the total quantity of available resources.
+
+
+
Enabled
+
+
Indicates whether the module is enabled.
+
+
+
Task
+
+
Indicates the task.
+
+
+
Sem
+
+
Indicates the semaphore.
+
+
+
Mutex
+
+
Indicates the mutex.
+
+
+
Queue
+
+
Indicates the queue.
+
+
+
SwTmr
+
+
Indicates the timer.
+
+
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-task.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-task.md
new file mode 100644
index 0000000000000000000000000000000000000000..bcef76f8b87049ab74a81be659756f7721caf3b0
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-task.md
@@ -0,0 +1,125 @@
+# task
+
+- [Command Function](#section0533181714106)
+- [Syntax](#section1014412308101)
+- [Parameter Description](#section116057158506)
+- [Usage](#section2053502951112)
+- [Example](#section12629113381116)
+- [Output](#section19299103465015)
+
+## Command Function
+
+This command is used to query information about processes and threads.
+
+## Syntax
+
+task/task -a
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
-a
+
+
Displays all information.
+
+
N/A
+
+
+
+
+
+## Usage
+
+If the parameter is not specified, partial task information is printed by default.
+
+## Example
+
+Enter **task**.
+
+## Output
+
+**Figure 1** Querying partial task information
+
+
+**Table 2** Output description
+
+
+
Parameter
+
+
Description
+
+
+
+
PID
+
+
Indicates the process ID.
+
+
+
PPID
+
+
Indicates the parent process ID.
+
+
+
PGID
+
+
Indicates the process group ID.
+
+
+
UID
+
+
Indicates the user ID.
+
+
+
Status
+
+
Indicates the current task status.
+
+
+
CPUUSE10s
+
+
Indicates the CPU usage within 10 seconds.
+
+
+
PName
+
+
Indicates the process name.
+
+
+
TID
+
+
Indicates the task ID.
+
+
+
StackSize
+
+
Indicates the size of the task stack.
+
+
+
WaterLine
+
+
Indicates the peak value used by the stack.
+
+
+
MEMUSE
+
+
Indicates the memory usage.
+
+
+
TaskName
+
+
Indicates the task name.
+
+
+
+
+
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
new file mode 100644
index 0000000000000000000000000000000000000000..7a9a79658247b8bbc3a97978aa945ed5182b4837
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-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
+
+
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
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-vmm.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-vmm.md
new file mode 100644
index 0000000000000000000000000000000000000000..920498ee8af7bb23537cd0225b4966645e35ab2f
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-vmm.md
@@ -0,0 +1,158 @@
+# vmm
+
+- [Command Function](#section445335110416)
+- [Syntax](#section1795712553416)
+- [Parameter Description](#section92544592410)
+- [Usage](#section104151141252)
+- [Example](#section11545171957)
+- [Output](#section075617368542)
+
+## Command Function
+
+This command is used to query the virtual memory usage of a process.
+
+## Syntax
+
+vmm \[_-a / -h / --help_\]
+
+vmm \[_pid_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Value Range
+
+
+
+
-a
+
+
Displays the virtual memory usage of all processes.
+
+
N/A
+
+
+
-h | --help
+
+
Displays the help information.
+
+
N/A
+
+
+
pid
+
+
Indicates the ID of the process to query.
+
+
[0, 63]
+
+
+
+
+
+## Usage
+
+By default, the virtual memory usage of all processes is displayed.
+
+## Example
+
+Enter **vmm 3**.
+
+## Output
+
+**Figure 1** Virtual memory usage of the process with PID 3
+
+
+**Table 2** Basic process information
+
+
+
Parameter
+
+
Description
+
+
+
+
PID
+
+
Indicates the process ID.
+
+
+
aspace
+
+
Indicates the address of the virtual memory control block.
+
+
+
name
+
+
Indicates the process name.
+
+
+
base
+
+
Indicates the start address of the virtual memory.
+
+
+
size
+
+
Indicates the size of virtual memory.
+
+
+
pages
+
+
Indicates the number of used physical pages.
+
+
+
+
+
+**Table 3** Virtual memory region information
+
+
+
Parameter
+
+
Description
+
+
+
+
region
+
+
Indicates the address of the control block in the virtual memory region.
+
+
+
name
+
+
Indicates the name of the virtual memory region.
+
+
+
base
+
+
Indicates the start address of the virtual memory region.
+
+
+
size
+
+
Indicates the size of the virtual memory region.
+
+
+
mmu_flags
+
+
Indicates the MMU mapping attribute of the virtual memory region.
+
+
+
pages
+
+
Indicates the number of used physical pages (including the shared memory).
+
+
+
pg/ref
+
+
Indicates the number of used physical pages.
+
+
+
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-watch.md b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-watch.md
new file mode 100644
index 0000000000000000000000000000000000000000..99eb40aabfed18d4a06fd2d9847fc2794b694607
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys-watch.md
@@ -0,0 +1,98 @@
+# watch
+
+- [Command Function](#section20643141481314)
+- [Syntax](#section1075441721316)
+- [Parameter Description](#section1472810220135)
+- [Usage](#section186772414131)
+- [Example](#section4764192791314)
+- [Output](#section5791253155517)
+
+## Command Function
+
+This command is used to periodically monitor the execution result of a command.
+
+## Syntax
+
+watch
+
+watch \[_-c/-n/-t/--count/--interval/-no-title/--over_\] \[_command_\]
+
+## Parameter Description
+
+**Table 1** Parameters
+
+
+
Parameter
+
+
Description
+
+
Default Value
+
+
Value Range
+
+
+
+
-c / --count
+
+
Indicates the number of times that the command is executed.
+
+
0xFFFFFF
+
+
(0, 0xFFFFFF]
+
+
+
-n / --interval
+
+
Indicates the interval for periodically running the command, in seconds.
+
+
1s
+
+
(0, 0xFFFFFF]
+
+
+
-t / -no-title
+
+
Disables time display on the top.
+
+
N/A
+
+
N/A
+
+
+
command
+
+
Indicates the command to be monitored.
+
+
N/A
+
+
N/A
+
+
+
--over
+
+
Stops the current command monitoring.
+
+
N/A
+
+
N/A
+
+
+
+
+
+## Usage
+
+You can run the **watch --over** command to stop the currently running command monitoring.
+
+## Example
+
+Enter **watch -n 2 -c 6 task**.
+
+## Output
+
+**Figure 1** **task** command monitoring result
+
+
+> **NOTE:**
+>In this example, the **task** command has been executed every 2 seconds for six times, and the preceding figure shows the output of the last execution.
+
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
new file mode 100644
index 0000000000000000000000000000000000000000..5549fe5c32bd6c2660afc196b0061d88cf8f8b70
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd-sys.md
@@ -0,0 +1,47 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..ca4697ae096f4b8bd08daaa2de56f60b00c77a59
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-cmd.md
@@ -0,0 +1,13 @@
+# 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-des.md b/en/device-dev/kernel/kernel-lite-small-shell-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..2bbbee37a67679fd6818ef68463549b4841ac47e
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-des.md
@@ -0,0 +1,36 @@
+# 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.
+
+- System-related commands: querying information about system tasks, kernel semaphores, system software timers, CPU usage, and current interrupts
+
+- File-related commands: basic functions 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
+
+ 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).
+
+
+## Important Notes
+
+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.
+
+- 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.
+
+- The shell working directory is separated from the system working directory. You can run commands such as **cd** and **pwd** on the shell to perform operations on the shell working directory, and run commands such as **chdir** and **getcwd** to perform operations on the system working directory. Pay special attention when an input parameter in a file system operation command is a relative path.
+
+- Before using network shell commands, you need to call the **tcpip\_init** function to initialize the network and set up the Telnet connection. By default, the kernel does not call **tcpip\_init**.
+
+- 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.
+
+ > **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**\).
+
+
diff --git a/en/device-dev/kernel/kernel-lite-small-shell-guide.md b/en/device-dev/kernel/kernel-lite-small-shell-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..9c984d76ba256de8a9ff82b1f4670c168a0ac19a
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell-guide.md
@@ -0,0 +1,167 @@
+# Shell Command Development Guidelines
+
+- [Development Guidelines](#section22071515161018)
+
+## Development Guidelines
+
+You can perform the following operations to add shell commands:
+
+1. Include the following header files:
+
+ ```
+ #include "shell.h"
+ #include "shcmd.h"
+ ```
+
+2. Register commands. You can register commands either statically or dynamically when the system is running. In most cases, static registration is widely used by common system commands, and dynamic registration is widely used by user commands.
+
+ 1. Static registration:
+
+ 1. Register a command using a macro.
+
+ The prototype of the macro is as follows:
+
+ ```
+ SHELLCMD_ENTRY(l, cmdType, cmdKey, paraNum, cmdHook)
+ ```
+
+ **Table 1** Parameters of the SHELLCMD\_ENTRY macro
+
+
+
Parameter
+
+
Description
+
+
+
+
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.
+
+
+
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.
+
+
+
+
cmdKey
+
+
Indicates 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.
+
+
+
cmdHook
+
+
Indicates the address of the execution function, that is, the function that is actually executed by the command.
+
+
+
+
+
+ For 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.
+
+ 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:
+
+ ```
+ UINT32 osCmdReg(CmdT ype cmdType, CHAR *cmdKey, UINT32 paraNum, CmdCallBackFunc cmdProc)
+ ```
+
+ **Table 2** Parameters of UINT32 osCmdReg
+
+
+
Parameter
+
+
Description
+
+
+
+
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.
+
+
+
+
cmdKey
+
+
Indicates 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).
+
+
+
cmdHook
+
+
Indicates the address of the execution function, that is, the function that is actually executed by the command.
+
+
+
+
+
+ For example:
+
+ ```
+ osCmdReg(CMD_TYPE_EX, "ls", XARGS, (CMD_CBK_FUNC)osShellCmdLs)
+ ```
+
+
+ > **NOTE:**
+ >The command keyword must be unique. Specifically, 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:
+
+ ```
+ UINT32 osShellCmdLs(UINT32 argc, CHAR **argv)
+ ```
+
+ **Table 3** Parameters of osShellCmdLs
+
+
+
Parameter
+
+
Description
+
+
+
+
argc
+
+
Indicates the number of parameters in the shell command.
+
+
+
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.
+
+
+
+
+
+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 the Telnet tool. For details, see [telnet](kernel-lite-small-shell-cmd-net-tel.md).
+
+
+
diff --git a/en/device-dev/kernel/shell-command-programming-example.md b/en/device-dev/kernel/kernel-lite-small-shell-sample.md
similarity index 100%
rename from en/device-dev/kernel/shell-command-programming-example.md
rename to en/device-dev/kernel/kernel-lite-small-shell-sample.md
diff --git a/en/device-dev/kernel/kernel-lite-small-shell.md b/en/device-dev/kernel/kernel-lite-small-shell.md
new file mode 100644
index 0000000000000000000000000000000000000000..e780951cf490b49819a1bdb13d33a3753a1f10cf
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-shell.md
@@ -0,0 +1,15 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..d1d04cc376ee7a85153d5bafadc003999109e932
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small-thread.md
@@ -0,0 +1,702 @@
+# 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
+
+
+**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
new file mode 100644
index 0000000000000000000000000000000000000000..7964a667d365b26721febc5fcb5e8cd169f1b73c
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite-small.md
@@ -0,0 +1,11 @@
+# Kernel for Small Systems
+
+- **[Basic Kernel](kernel-lite-small-basic.md)**
+
+- **[File System](kernel-lite-small-file.md)**
+
+- **[Standard Library](kernel-lite-small-lib.md)**
+
+- **[Commissioning](kernel-lite-small-shell.md)**
+
+
diff --git a/en/device-dev/kernel/kernel-lite.md b/en/device-dev/kernel/kernel-lite.md
new file mode 100644
index 0000000000000000000000000000000000000000..78ab36575118374840a0211296b1ebf9b6bf83e9
--- /dev/null
+++ b/en/device-dev/kernel/kernel-lite.md
@@ -0,0 +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-standard-build.md b/en/device-dev/kernel/kernel-standard-build.md
new file mode 100644
index 0000000000000000000000000000000000000000..5dd23ea67832db1fa75e6ec1ac6a70fdafd137fc
--- /dev/null
+++ b/en/device-dev/kernel/kernel-standard-build.md
@@ -0,0 +1,47 @@
+# Guidelines for Compiling and Building the Linux Kernel
+
+- [Example 1](#section19369206113115)
+ - [Scenario 1: Building the Native Kernel at the Version Level](#section1025111193220)
+ - [Scenario 2: Building the Modified Kernel Separately](#section17446652173211)
+
+
+## Example 1
+
+The following uses the Hi3516D V300 board and Ubuntu x86 server as an example.
+
+### Scenario 1: Building the Native Kernel at the Version Level
+
+Perform a full build for the project to generate the **uImage** kernel image.
+
+```
+./build.sh --product-name Hi3516DV300 # Build the uImage kernel image of the Hi3516D V300 board.
+```
+
+### Scenario 2: Building the Modified Kernel Separately
+
+1. Set up the build environment.
+
+ 1. Merge the required patch by referring to [guidelines for using patches on development boards](kernel-standard-patch.md).
+ 2. Prepare for the build environment. You can use the Arm Clang or GCC compiler.
+
+ Enter the root directory of the project and configure environment variables:
+
+ ```
+ export PATH=`pwd`/prebuilts/clang/host/linux-x86/clang-r353983c/bin:`pwd`/prebuilts/gcc/linux-x86/arm/gcc-linaro-7.5.0-arm-linux-gnueabi/bin/:$PATH # Configure the build environment.
+ MAKE_OPTIONES="ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CC=clang HOSTCC=clang" # Use Clang provided by the project.
+ ```
+
+2. Modify the kernel code or kernel configuration \(**defconfig** file provided by OpenHarmony can be used for reference\).
+3. Create a build directory and generate the **.config** file of the kernel.
+
+ ```
+ make ${MAKE_OPTIONES} hi3516dv300_emmc_smp_hos_l2_defconfig # Use the defconfig file to build the kernel.
+ ```
+
+4. Build the kernel image.
+
+ ```
+ make ${MAKE_OPTIONES} -j32 uImage # Build the uImage kernel image.
+ ```
+
+
diff --git a/en/device-dev/kernel/linux-kernel-overview.md b/en/device-dev/kernel/kernel-standard-des.md
similarity index 100%
rename from en/device-dev/kernel/linux-kernel-overview.md
rename to en/device-dev/kernel/kernel-standard-des.md
diff --git a/en/device-dev/kernel/kernel-standard-patch.md b/en/device-dev/kernel/kernel-standard-patch.md
new file mode 100644
index 0000000000000000000000000000000000000000..e1ecf1aad2a3ea5e004a9d55699738b2f7fade1e
--- /dev/null
+++ b/en/device-dev/kernel/kernel-standard-patch.md
@@ -0,0 +1,17 @@
+# Guidelines for Using Patches on OpenHarmony Development Boards
+
+The patch files are stored in the **kernel/linux/patches/linux-4.19** source code path of the project. You can obtain the driver patch of a specific chip architecture from this directory.
+
+To use the patch of a specific chip platform driver, you need to merge the required kernel patch into the kernel code.
+
+Merge the corresponding patches for different chip platforms.
+
+The following uses Hi3516D V300 as an example:
+
+```
+patch -p1 < device/hisilicon/hi3516dv300/sdk_linux/open_source/linux/hisi_linux-4.19_hos_l2.patch
+```
+
+> **NOTICE:**
+>Because patches are applied after the code environment of **kernel/linux-4.19** is copied during compilation and building of the OpenHarmony project, you must retain the original code environment of **kernel/linux-4.19** before running the OpenHarmony version-level build command.
+
diff --git a/en/device-dev/kernel/kernel-standard.md b/en/device-dev/kernel/kernel-standard.md
new file mode 100644
index 0000000000000000000000000000000000000000..cdbdf659c166ba32ea9b47e15b06e57184149032
--- /dev/null
+++ b/en/device-dev/kernel/kernel-standard.md
@@ -0,0 +1,9 @@
+# Kernel for Standard Systems
+
+- **[Linux Kernel Overview](kernel-standard-des.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)**
+
+
diff --git a/en/device-dev/kernel/kernel.md b/en/device-dev/kernel/kernel.md
new file mode 100644
index 0000000000000000000000000000000000000000..356b5d646277ab0bd61df5175f9292b5a4982831
--- /dev/null
+++ b/en/device-dev/kernel/kernel.md
@@ -0,0 +1,7 @@
+# Kernel
+
+- **[Kernel for Mini and Small Systems](kernel-lite.md)**
+
+- **[Kernel for Standard Systems](kernel-standard.md)**
+
+
diff --git a/en/device-dev/kernel/kill.md b/en/device-dev/kernel/kill.md
deleted file mode 100644
index 72a2a65937e17fba4e5dd277d6284126ffa04ee7..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/kill.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# kill
-
-- [Command Function](#section366714216619)
-- [Syntax](#section8833164614615)
-- [Parameter Description](#section12809111019453)
-- [Usage](#section15935131220717)
-- [Example](#section79281818476)
-- [Output](#section12742311179)
-
-## Command Function
-
-This command is used to send a specific signal to a specified process.
-
-## Syntax
-
-kill \[_signo_ | _-signo_\] \[_pid_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
signo
-
-
Indicates the signal ID.
-
-
[1, 30]
-
-
-
pid
-
-
Indicates the process ID.
-
-
[1, MAX_INT]
-
-
-
-
-
-> **NOTICE:**
->The valid range of the **signo** value is \[0, 64\], and the recommended value range is \[1, 30\]. Other values in the valid range are reserved.
-
-## Usage
-
-The **signo** and **pid** parameters are mandatory.
-
-The **pid** value range varies depending on the system configuration. For example, if the maximum **pid** value supported by the system is **256**, this value range is \[1-256\].
-
-## Example
-
-1. Query the current process list and determine the PID \(7\) of the process to be killed.
-
-**Figure 1** Querying PIDs
-
-
-2. Run **kill 14 7** to send signal 14 \(the default behavior of **SIGALRM** is to terminate the process\) to process 7 **helloworld\_d** \(user-space\). Then query the current process list. Process 7 has been terminated. The result of the **kill 14 7** command is the same as that of the **kill -14 7** command.
-
-**Figure 2** Command output
-
-
-## Output
-
-The command output is as follows:
-
-**Figure 3** Sending a signal to a specified process
-
-
-The signal is successfully sent if no error is reported.
-
-**Figure 4** 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.
-
diff --git a/en/device-dev/kernel/linux-kernel.md b/en/device-dev/kernel/linux-kernel.md
deleted file mode 100644
index 9391b466f5f056bda10b6cff24a0142cce6fef51..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/linux-kernel.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Linux Kernel
-
-- **[Linux Kernel Overview](linux-kernel-overview.md)**
-
-- **[Guidelines for Using Patches on OpenHarmony Development Boards](guidelines-for-using-patches-on-openharmony-development-boards.md)**
-
-- **[Guidelines for Compiling and Building the Linux Kernel](guidelines-for-compiling-and-building-the-linux-kernel.md)**
-
-
diff --git a/en/device-dev/kernel/lite-kernel.md b/en/device-dev/kernel/lite-kernel.md
deleted file mode 100644
index 3927b0fb506a8a301ca2b168f58e99170365406a..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/lite-kernel.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Lite Kernel
-
-- **[OpenHarmony Lite Kernel Basic Functions](openharmony-lite-kernel-basic-functions.md)**
-
-- **[OpenHarmony Lite Kernel File System](openharmony-lite-kernel-file-system.md)**
-
-- **[Standard Library](standard-library.md)**
-
-- **[Commissioning](commissioning.md)**
-
-
diff --git a/en/device-dev/kernel/log.md b/en/device-dev/kernel/log.md
deleted file mode 100644
index 7702a920dc8d7520de4f78100dcb4b5f39474b90..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/log.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# log
-
-- [Command Function](#section128219131856)
-- [Syntax](#section3894181710519)
-- [Parameter Description](#section7693122310515)
-- [Usage](#section1982111281512)
-- [Example](#section176301333259)
-- [Output](#section14354765415)
-
-## Command Function
-
-This command is used to modify and query log configurations.
-
-## Syntax
-
-log level \[_levelNum_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
levelNum
-
-
Indicates the print level of configuration logs.
-
-
[0x0, 0x5]
-
-
-
-
-
-## Usage
-
-- This command depends on **LOSCFG\_SHELL\_LK**. Before running this command, enable the **Enable Shell lk** configuration item using **menuconfig**.
-
- Debug ---\> Enable a Debug Version ---\> Enable Shell ---\> Enable Shell lK
-
-- The **log level** command is used to configure log levels, which can be:
-
- TRACE\_EMG = 0,
-
- TRACE\_COMMON = 1,
-
- TRACE\_ERROR = 2,
-
- TRACE\_WARN = 3,
-
- TRACE\_INFO = 4,
-
- TRACE\_DEBUG = 5
-
- If the level is not within the valid range, a message is printed.
-
-- If the **\[levelNum\]** parameter is not specified, the current log level and its usage are printed by default.
-
-## Example
-
-Enter **log level 4**.
-
-## Output
-
-
-
diff --git a/en/device-dev/kernel/ls.md b/en/device-dev/kernel/ls.md
deleted file mode 100644
index 24912f8546337540b7037276d62b1c531156f33c..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/ls.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# ls
-
-- [Command Function](#section6538163771614)
-- [Syntax](#section45881743111616)
-- [Parameter Description](#section17528148171617)
-- [Usage](#section041212533166)
-- [Example](#section986105716167)
-- [Output](#section2036124918592)
-
-## Command Function
-
-This command is used to display the content of a specified directory.
-
-## Syntax
-
-ls \[_path_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
path
-
-
If path is left blank, the content of the current directory is displayed.
-
If the path value is an invalid file name, the following failure message is displayed:
-
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
-
-
-
-
-
-## Usage
-
-- 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.
-
-## Example
-
-Enter **ls**.
-
-## Output
-
-**Figure 1** Viewing content of the current directory
-
-
diff --git a/en/device-dev/kernel/lsfd.md b/en/device-dev/kernel/lsfd.md
deleted file mode 100644
index 950cfda3a3dad5c6aae7292e1b23298a89d24ec0..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/lsfd.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# lsfd
-
-- [Command Function](#section2053406181716)
-- [Syntax](#section523771017172)
-- [Usage](#section27241213201719)
-- [Example](#section442617197173)
-- [Output](#section42491639151813)
-
-## Command Function
-
-This command is used to display the file descriptors and names of currently opened files.
-
-## Syntax
-
-lsfd
-
-## Usage
-
-Run the **lsfd** command to view file descriptors and names of the opened files.
-
-## Example
-
-Enter **lsfd**.
-
-## Output
-
-**Figure 1** Command output
-
-
diff --git a/en/device-dev/kernel/magic-key-usage.md b/en/device-dev/kernel/magic-key-usage.md
deleted file mode 100644
index 4beecc99310464737b92ebca1cf1d75d2ba898a4..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/magic-key-usage.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.
-
-> **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!".
-
-
-> **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/memcheck.md b/en/device-dev/kernel/memcheck.md
deleted file mode 100644
index 20e8bbccbf638aef8861aeabe4017c133aab7b1a..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/memcheck.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# memcheck
-
-- [Command Function](#section191633812516)
-- [Syntax](#section428816435510)
-- [Parameter Description](#section1939943304411)
-- [Usage](#section228914491951)
-- [Example](#section17373205314515)
-- [Output](#section13406205385413)
-
-## Command Function
-
-This command is used to check whether the dynamically requested memory block is complete and whether nodes in the memory pool are damaged due to out-of-bounds memory access.
-
-## Syntax
-
-memcheck
-
-## Parameter Description
-
-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.
-
-## Example
-
-Enter **memcheck**.
-
-## Output
-
-**Figure 1** No out-of-bounds memory access
-
-
-**Figure 2** Out-of-bounds memory access
-
-
diff --git a/en/device-dev/kernel/memory.md b/en/device-dev/kernel/memory.md
deleted file mode 100644
index f189a61be22662a5151caf30b45f8c8508487188..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/memory.md
+++ /dev/null
@@ -1,353 +0,0 @@
-# Memory
-
-- [Basic Concepts](#section1392116583424)
-- [When to Use](#section159581619194319)
-- [Available APIs](#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.
-
-## Available APIs
-
-**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)
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.
-
-
-
-
-
- > **NOTE:**
- >For details about the implementation differences between **mmap** and Linux function, see [Differences from the Linux Standard Library](differences-from-the-linux-standard-library.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/mkdir.md b/en/device-dev/kernel/mkdir.md
deleted file mode 100644
index 37e762b7f7c5f8d5bbe3e8ccaecaf863175adc73..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/mkdir.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# mkdir
-
-- [Command Function](#section1083613274175)
-- [Syntax](#section820913118178)
-- [Parameter Description](#section1256834121718)
-- [Usage](#section1294234115172)
-- [Example](#section1113345211713)
-- [Output](#section10142201012)
-
-## Command Function
-
-This command is used to create a directory.
-
-## Syntax
-
-mkdir \[_directory_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
directory
-
-
Indicates the directory to be created.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- If the **mkdir** command is followed by the name of the directory to be created, the directory is created in the current directory.
-- If the **mkdir** command is followed by a path and the name of the directory to be created, the directory is created in the specified path.
-
-## Example
-
-Enter **mkdir share**.
-
-## Output
-
-**Figure 1** Creating the share directory
-
-
diff --git a/en/device-dev/kernel/mount.md b/en/device-dev/kernel/mount.md
deleted file mode 100644
index 4ba01ec183a67d020cb1fd33e295f1dd104f4d20..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/mount.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# mount
-
-- [Command Function](#section11631837182)
-- [Syntax](#section1697638111820)
-- [Parameter Description](#section1650151221819)
-- [Usage](#section124541520171912)
-- [Example](#section7424625171917)
-- [Output](#section14757018116)
-
-## Command Function
-
-This command is used to mount a device to a specified directory.
-
-## Syntax
-
-mount <_device_\> <_path_\> <_name_\> \[_uid gid_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
device
-
-
Indicates 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.
-
-
N/A
-
-
-
name
-
-
Indicates the file system type.
-
-
vfat, yaffs, jffs, ramfs, nfs, procfs, romfs
-
-
-
uid gid
-
-
uid indicates the user ID.
-
gid indicates the group ID.
-
This parameter is optional. The default values are uid:0 and gid:0.
-
-
N/A
-
-
-
-
-
-## Usage
-
-By specifying the device to be mounted, directory, and file system format in the **mount** command, you can successfully mount the file system to the specified directory.
-
-## Example
-
-Enter **mount /dev/mmcblk0p0 /bin1/vs/sd vfat**.
-
-## Output
-
-Mounting **/dev/mmcblk0p0** to the **/bin1/vs/sd** directory
-
-
-
diff --git a/en/device-dev/kernel/netstat.md b/en/device-dev/kernel/netstat.md
deleted file mode 100644
index fe85534166fe35e43d60fb59c6e160340485df9f..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/netstat.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# netstat
-
-- [Command Function](#section13469162113816)
-- [Syntax](#section795712373812)
-- [Parameter Description](#section17629431193817)
-- [Usage](#section5277153519380)
-- [Example](#section108141437163820)
-- [Output](#section1357015107117)
-
-## Command Function
-
-The **netstat** command is a console command and is used for monitoring the TCP/IP network. It can display the actual network connections and the status of each network interface device. It is used to display the statistics related to the TCP and UDP protocols and check the network connection to each port on the device \(board\).
-
-## Syntax
-
-netstat
-
-## Parameter Description
-
-None
-
-## Usage
-
-Run the command directly.
-
-## Example
-
-Enter **netstat**.
-
-**Figure 1** Output information
-
-
-
-
-## Output
-
-**Table 1** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
Proto
-
-
Indicates the 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.
-
-
-
Send-Q
-
-
For a TCP connection, this value indicates the amount of data that has been sent but not acknowledged.
-
For a UDP connection, this value indicates the amount of data buffered before IP address resolution is complete.
-
-
-
Local Address
-
-
Indicates the local IP address and port number.
-
-
-
Foreign Address
-
-
Indicates the remote IP address and port number.
-
-
-
State
-
-
Indicates the TCP connection status. This parameter is meaningless for UDP.
-
-
-
-
-
-> **NOTE:**
->The command output like "========== total sockets 32 ====== unused sockets 22 BootTime 27 s ==========" indicates that there are 32 sockets in total, 22 sockets are not used, and it has been 27 seconds since the system starts.
-
diff --git a/en/device-dev/kernel/network-commands.md b/en/device-dev/kernel/network-commands.md
deleted file mode 100644
index 87571257010b07ad22d44be257458089c3f76b61..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/network-commands.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Network Commands
-
-- **[arp](arp.md)**
-
-- **[dhclient](dhclient.md)**
-
-- **[dns](dns.md)**
-
-- **[ifconfig](ifconfig.md)**
-
-- **[ipdebug](ipdebug.md)**
-
-- **[netstat](netstat.md)**
-
-- **[ntpdate](ntpdate.md)**
-
-- **[ping](ping.md)**
-
-- **[ping6](ping6.md)**
-
-- **[telnet](telnet.md)**
-
-- **[tftp](tftp.md)**
-
-
diff --git a/en/device-dev/kernel/network.md b/en/device-dev/kernel/network.md
deleted file mode 100644
index 9899f4ae3070ec6ebb1559337782c2d99303f760..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/network.md
+++ /dev/null
@@ -1,303 +0,0 @@
-# Network
-
-- [Basic Concepts](#section9840143083510)
-- [When to Use](#section1575885183516)
-- [Description](#section16351198193614)
-
-## Basic Concepts
-
-The network module implements basic functions of the TCP/IP protocol stack and provides the standard POSIX socket interfaces.
-
-> **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.
-
-## 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.
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/nfs.md b/en/device-dev/kernel/nfs.md
deleted file mode 100644
index 5953ad82e372bd6871d158c2ecd74c21e8efdef3..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/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.
-
- > **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/oom.md b/en/device-dev/kernel/oom.md
deleted file mode 100644
index f97c98347a567e251f5003483d9c214cb02b9351..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/oom.md
+++ /dev/null
@@ -1,120 +0,0 @@
-# oom
-
-- [Command Function](#section366714216619)
-- [Syntax](#section8833164614615)
-- [Parameter Description](#section12809111019453)
-- [Usage](#section15935131220717)
-- [Example](#section79281818476)
-- [Output](#section12742311179)
-
-## Command Function
-
-This command is used to query and set the low memory threshold and the page cache reclaim threshold.
-
-## Syntax
-
-oom
-
-oom -i \[_interval_\]
-
-oom -m \[_mem byte_\]
-
-oom -r \[_mem byte_\]
-
-oom -h | --help
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
-i [interval]
-
-
Sets the interval for checking the Out Of Memory (OOM) thread task.
-
-
100 ms – 10000 ms
-
-
-
-m [mem byte]
-
-
Sets the low memory threshold.
-
-
0 MB (does not check for low memory) – 1 MB
-
-
-
-r [mem byte]
-
-
Sets the page cache reclaim threshold.
-
-
Ranging from the low memory threshold to the maximum available system memory
-
-
-
-h | --help
-
-
Uses the help.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- If no parameter is specified, the current configurations of the OOM function are displayed.
-
-## Example
-
-When the system memory is insufficient, the system displays a message indicating the insufficiency.
-
-## Output
-
-
-
-**Table 2** Output description
-
-
-
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.
-
-
-
[oom] candidate victim process UserProcess12 pid: 12, actual phy mem byte: 25951558
-
-
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.
-
-
-
excFrom: User!
-
-
When the system memory is low, the UserProcess12 process fails to apply for memory and exits as a result.
-
-
-
-
-
diff --git a/en/device-dev/kernel/openharmony-lite-kernel-basic-functions.md b/en/device-dev/kernel/openharmony-lite-kernel-basic-functions.md
deleted file mode 100644
index 8e3d07b35fb20071a4799e33f88480253820194f..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/openharmony-lite-kernel-basic-functions.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# OpenHarmony Lite Kernel Basic Functions
-
-- **[Process](process.md)**
-
-- **[Thread](thread.md)**
-
-- **[Memory](memory.md)**
-
-- **[Network](network.md)**
-
-
diff --git a/en/device-dev/kernel/openharmony-lite-kernel-file-system.md b/en/device-dev/kernel/openharmony-lite-kernel-file-system.md
deleted file mode 100644
index 443fc42c437c4eb5b001c163b4ae4b56355186d5..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/openharmony-lite-kernel-file-system.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# OpenHarmony Lite Kernel 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](vfs.md)**
-
-- **[NFS](nfs.md)**
-
-- **[RAMFS](ramfs.md)**
-
-- **[FAT](fat.md)**
-
-- **[JFFS2](jffs2.md)**
-
-
diff --git a/en/device-dev/kernel/partinfo.md b/en/device-dev/kernel/partinfo.md
deleted file mode 100644
index 0de22f29a1033c0187ec9a97b384cbba7b3f12b1..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/partinfo.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# partinfo
-
-- [Command Function](#section1777503617199)
-- [Syntax](#section185501447132114)
-- [Parameter Description](#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.
-
-## Syntax
-
-partinfo <_dev\_inodename_\>
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
dev_inodename
-
-
Indicates the name of the partition to be queried.
Displays information about the NAND flash partition.
-
-
N/A
-
-
-
spinor
-
-
Displays information about the spinor flash partition.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- The **partition** command is used to query flash partition information.
-- The NAND flash partition information can be viewed only when the YAFFS file system is enabled. The spinor flash partition information can be viewed only when the JFFS or ROMFS file system is enabled.
-
-## Example
-
-Enter **partition spinor**.
-
-## Output
-
-Viewing spinor flash partition information
-
-
-
diff --git a/en/device-dev/kernel/ping.md b/en/device-dev/kernel/ping.md
deleted file mode 100644
index 8a829c7ee45729bd729c292bf7e52751f9a8e354..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/ping.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# ping
-
-- [Command Function](#section119672573385)
-- [Syntax](#section869419010390)
-- [Parameter Description](#section9877183173918)
-- [Usage](#section1097046193914)
-- [Example](#section14564129113911)
-- [Output](#section1621732891215)
-
-## Command Function
-
-This command is used to test whether the network connection is normal.
-
-## Syntax
-
-ping_ _\[_-n cnt_\] \[_-w interval_\] \[_-l data\_len_\]_ _
-
-ping \[_-t_\] \[_-w interval_\] __
-
-ping _-k_
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
IP
-
-
Indicates 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.
-
-
1-65535
-
-
-
-w interval
-
-
Indicates the interval between two ping packets, in ms.
-
-
>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.
-
-
0-65500
-
-
-
-t
-
-
Indicates a permanent ping thread, which will be killed until the ping -k command is executed.
-
-
N/A
-
-
-
-k
-
-
Kills the ping thread and stops the ping operation.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- Run the **ping** command by setting a destination IP address to check whether the network connection to the destination IP address is normal.
-- If the destination IP address is unreachable, the system displays a message indicating that the request times out.
-- If no route is available to the destination IP address, an error message is displayed.
-- This command can be used only after the TCP/IP protocol stack is enabled.
-
-## Example
-
-Enter **ping 192.168.1.10**.
-
-## Output
-
-**Figure 1** Output of pinging the IP address of the TFTP server
-
-
-
-
diff --git a/en/device-dev/kernel/pmm.md b/en/device-dev/kernel/pmm.md
deleted file mode 100644
index 6d44a3c6f051735afc8e97fbb3bcce8400c81526..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/pmm.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# pmm
-
-- [Command Function](#section445335110416)
-- [Syntax](#section1795712553416)
-- [Parameter Description](#section92544592410)
-- [Usage](#section104151141252)
-- [Example](#section11545171957)
-- [Output](#section075617368542)
-
-## Command Function
-
-This command is used to check the usage of the physical pages and page cache of the system memory.
-
-## Syntax
-
-pmm
-
-## Parameter Description
-
-None
-
-## Usage
-
-This command is available only in the **Debug** version.
-
-## Example
-
-Enter **pmm**.
-
-## Output
-
-**Figure 1** Viewing the usage of physical pages
-
-
-**Table 1** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
phys_seg
-
-
Indicates the address of the physical page control block.
-
-
-
base
-
-
Indicates the first physical page address, that is, start address of the physical page memory.
-
-
-
size
-
-
Indicates the size of the physical page memory.
-
-
-
free_pages
-
-
Indicates the number of idle physical pages.
-
-
-
active anon
-
-
Indicates the number of active anonymous pages in the page cache.
-
-
-
inactive anon
-
-
Indicates the number of inactive anonymous pages in the page cache.
-
-
-
active file
-
-
Indicates the number of active file pages in the page cache.
-
-
-
inactive file
-
-
Indicates the 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.
-
-
-
-
-
diff --git a/en/device-dev/kernel/process.md b/en/device-dev/kernel/process.md
deleted file mode 100644
index 6cb4b62be89c4981d339121017e13cf127d2ca83..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/process.md
+++ /dev/null
@@ -1,301 +0,0 @@
-# Process
-
-- [Basic Concepts](#section29197338383)
-- [When to Use](#section85513272398)
-- [Available APIs](#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
-
-
-**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.
-
-## Available APIs
-
-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/public_sys-resources/icon-caution.gif b/en/device-dev/kernel/public_sys-resources/icon-caution.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/kernel/public_sys-resources/icon-caution.gif and /dev/null differ
diff --git a/en/device-dev/kernel/public_sys-resources/icon-danger.gif b/en/device-dev/kernel/public_sys-resources/icon-danger.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/kernel/public_sys-resources/icon-danger.gif and /dev/null differ
diff --git a/en/device-dev/kernel/public_sys-resources/icon-note.gif b/en/device-dev/kernel/public_sys-resources/icon-note.gif
deleted file mode 100644
index 6314297e45c1de184204098efd4814d6dc8b1cda..0000000000000000000000000000000000000000
Binary files a/en/device-dev/kernel/public_sys-resources/icon-note.gif and /dev/null differ
diff --git a/en/device-dev/kernel/public_sys-resources/icon-notice.gif b/en/device-dev/kernel/public_sys-resources/icon-notice.gif
deleted file mode 100644
index 86024f61b691400bea99e5b1f506d9d9aef36e27..0000000000000000000000000000000000000000
Binary files a/en/device-dev/kernel/public_sys-resources/icon-notice.gif and /dev/null differ
diff --git a/en/device-dev/kernel/public_sys-resources/icon-tip.gif b/en/device-dev/kernel/public_sys-resources/icon-tip.gif
deleted file mode 100644
index 93aa72053b510e456b149f36a0972703ea9999b7..0000000000000000000000000000000000000000
Binary files a/en/device-dev/kernel/public_sys-resources/icon-tip.gif and /dev/null differ
diff --git a/en/device-dev/kernel/public_sys-resources/icon-warning.gif b/en/device-dev/kernel/public_sys-resources/icon-warning.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/kernel/public_sys-resources/icon-warning.gif and /dev/null differ
diff --git a/en/device-dev/kernel/pwd.md b/en/device-dev/kernel/pwd.md
deleted file mode 100644
index f277c5391ef0a704c51ab67b29126c8868b5a09c..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/pwd.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# pwd
-
-- [Command Function](#section197737712267)
-- [Syntax](#section1544061016267)
-- [Parameter Description](#section599112120262)
-- [Usage](#section66901116152615)
-- [Example](#section7427181922612)
-- [Output](#section116313389418)
-
-## Command Function
-
-This command is used to display the current path.
-
-## Syntax
-
-pwd
-
-## Parameter Description
-
-None
-
-## Usage
-
-The **pwd** command writes the full path name of the current directory \(from the root directory\) to the standard output. All directories are separated by slashes \(/\). The directory following the first slash \(/\) indicates the root directory, and the last directory is the current directory.
-
-## Example
-
-Enter **pwd**.
-
-## Output
-
-**Figure 1** Querying the current path
-
-
diff --git a/en/device-dev/kernel/rm.md b/en/device-dev/kernel/rm.md
deleted file mode 100644
index b828771a11901997a0efc0dc09fcd4d9c118b507..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/rm.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# rm
-
-- [Command Function](#section181141523142613)
-- [Syntax](#section8800926132619)
-- [Parameter Description](#section15476229152617)
-- [Usage](#section10578163215262)
-- [Example](#section18548133511263)
-- [Output](#section1565323814265)
-
-## Command Function
-
-This command is used to delete a file or folder.
-
-## Syntax
-
-rm \[_-r_\] \[_dirname / filename_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
-r
-
-
Deletes a directory. This parameter is optional. It is required if a directory is to be deleted.
-
-
N/A
-
-
-
dirname/filename
-
-
Indicates the name of the file or directory to be deleted. The value can be a path.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- The **rm** command deletes only one file or directory at a time.
-- The **rm -r** command can be used to delete a non-empty directory.
-
-## Example
-
-Example:
-
-1. Enter **rm log1.txt**.
-2. Enter **rm -r sd**.
-
-## Output
-
-**Figure 1** Deleting the **log1.txt** file
-
-
-**Figure 2** Deleting the **sd** directory
-
-
diff --git a/en/device-dev/kernel/rmdir.md b/en/device-dev/kernel/rmdir.md
deleted file mode 100644
index 9d35e2c1c866847aa54c83fc216df38bec50a791..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/rmdir.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# rmdir
-
-- [Command Function](#section1839611420266)
-- [Syntax](#section329574512266)
-- [Parameter Description](#section15865747102620)
-- [Usage](#section107857508261)
-- [Example](#section11196165315262)
-- [Output](#section1073811415613)
-
-## Command Function
-
-This command is used to delete a directory.
-
-## Syntax
-
-rmdir \[_dir_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
dir
-
-
Indicates the name of the directory to be deleted. The directory must be empty. You can enter a path for this parameter.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- The **rmdir** command can only be used to delete directories.
-- The **rmdir** command can delete only one directory at a time.
-- The **rmdir** command can delete only empty directories.
-
-## Example
-
-Enter **rmdir dir**.
-
-## Output
-
-**Figure 1** Deleting directory **dir**
-
-
diff --git a/en/device-dev/kernel/sem.md b/en/device-dev/kernel/sem.md
deleted file mode 100644
index 08e04352c5934a4fc38310df39c7c2133558fc61..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/sem.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# sem
-
-- [Command Function](#section366714216619)
-- [Syntax](#section8833164614615)
-- [Parameter Description](#section12809111019453)
-- [Usage](#section15935131220717)
-- [Example](#section79281818476)
-- [Output](#section1975118519456)
-
-## Command Function
-
-This command is used to query information about kernel semaphores.
-
-## Syntax
-
-sem \[_ID__ / fulldata_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
ID
-
-
Indicates 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.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- 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**.
-
- Debug ---\> Enable a Debug Version ---\> Enable Debug LiteOS Kernel Resource ---\> Enable Semaphore Debugging
-
-
-## Example
-
-Example 1: Enter **sem fulldata**.
-
-## Output
-
-**Figure 1** Querying information about all semaphores in use
-
-
-**Table 2** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
SemID
-
-
Indicates the semaphore ID.
-
-
-
Count
-
-
Indicates the number of used semaphores.
-
-
-
-
-
-> **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.
-
diff --git a/en/device-dev/kernel/shell-command-development-guidelines.md b/en/device-dev/kernel/shell-command-development-guidelines.md
deleted file mode 100644
index 766aff15ee4cfa14a45cfccd44e922d65f53f133..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/shell-command-development-guidelines.md
+++ /dev/null
@@ -1,167 +0,0 @@
-# Shell Command Development Guidelines
-
-- [Development Guidelines](#section22071515161018)
-
-## Development Guidelines
-
-You can perform the following operations to add shell commands:
-
-1. Include the following header files:
-
- ```
- #include "shell.h"
- #include "shcmd.h"
- ```
-
-2. Register commands. You can register commands either statically or dynamically when the system is running. In most cases, static registration is widely used by common system commands, and dynamic registration is widely used by user commands.
-
- 1. Static registration:
-
- 1. Register a command using a macro.
-
- The prototype of the macro is as follows:
-
- ```
- SHELLCMD_ENTRY(l, cmdType, cmdKey, paraNum, cmdHook)
- ```
-
- **Table 1** Parameters of the SHELLCMD\_ENTRY macro
-
-
-
Parameter
-
-
Description
-
-
-
-
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.
-
-
-
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.
-
-
-
-
cmdKey
-
-
Indicates 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.
-
-
-
cmdHook
-
-
Indicates the address of the execution function, that is, the function that is actually executed by the command.
-
-
-
-
-
- For 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.
-
- 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:
-
- ```
- UINT32 osCmdReg(CmdT ype cmdType, CHAR *cmdKey, UINT32 paraNum, CmdCallBackFunc cmdProc)
- ```
-
- **Table 2** Parameters of UINT32 osCmdReg
-
-
-
Parameter
-
-
Description
-
-
-
-
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.
-
-
-
-
cmdKey
-
-
Indicates 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).
-
-
-
cmdHook
-
-
Indicates the address of the execution function, that is, the function that is actually executed by the command.
-
-
-
-
-
- For example:
-
- ```
- osCmdReg(CMD_TYPE_EX, "ls", XARGS, (CMD_CBK_FUNC)osShellCmdLs)
- ```
-
-
- > **NOTE:**
- >The command keyword must be unique. Specifically, 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:
-
- ```
- UINT32 osShellCmdLs(UINT32 argc, CHAR **argv)
- ```
-
- **Table 3** Parameters of osShellCmdLs
-
-
-
Parameter
-
-
Description
-
-
-
-
argc
-
-
Indicates the number of parameters in the shell command.
-
-
-
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.
-
-
-
-
-
-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 the Telnet tool. For details, see [telnet](telnet.md).
-
-
-
diff --git a/en/device-dev/kernel/shell-command-reference.md b/en/device-dev/kernel/shell-command-reference.md
deleted file mode 100644
index 1c1df368f21fee6269b33805f9178611dfc956ed..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/shell-command-reference.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](help.md) command. You can also use the **-h | --help** option of a command to view the help information about the command.
-
-- **[System Commands](system-commands.md)**
-
-- **[File Commands](file-commands.md)**
-
-- **[Network Commands](network-commands.md)**
-
-
diff --git a/en/device-dev/kernel/stack.md b/en/device-dev/kernel/stack.md
deleted file mode 100644
index a3bf37a1c193ebe6f7c86b8bd9d2713452081a0e..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/stack.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# stack
-
-- [Command Function](#section445335110416)
-- [Syntax](#section1795712553416)
-- [Parameter Description](#section92544592410)
-- [Usage](#section104151141252)
-- [Example](#section11545171957)
-- [Output](#section075617368542)
-
-## Command Function
-
-This command is used to check the usage of each stack in the system.
-
-## Syntax
-
-stack
-
-## Parameter Description
-
-None
-
-## Usage
-
-None
-
-## Example
-
-Enter **stack**.
-
-## Output
-
-**Figure 1** System stack usage
-
-
-
-
-**Table 1** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
stack name
-
-
Indicates the system stack name.
-
-
-
cpu id
-
-
Indicates the CPU ID.
-
-
-
stack addr
-
-
Indicates the stack address.
-
-
-
total size
-
-
Indicates the stack size.
-
-
-
used size
-
-
Indicates the used size of the stack.
-
-
-
-
-
diff --git a/en/device-dev/kernel/standard-library-0.md b/en/device-dev/kernel/standard-library-0.md
deleted file mode 100644
index 5d885291e116ea56c42f6865b32e59ab20300950..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/standard-library-0.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
-
-
-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/standard-library.md b/en/device-dev/kernel/standard-library.md
deleted file mode 100644
index 558eeb7fd7862b35e585fd54f753b4a647a1947d..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/standard-library.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Standard Library
-
-- **[Standard Library](standard-library-0.md)**
-
-- **[Differences from the Linux Standard Library](differences-from-the-linux-standard-library.md)**
-
-
diff --git a/en/device-dev/kernel/statfs.md b/en/device-dev/kernel/statfs.md
deleted file mode 100644
index e823440c5929b4fc2e927264d44faf225dbdb6b6..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/statfs.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# statfs
-
-- [Command Function](#section153921657152613)
-- [Syntax](#section135391102717)
-- [Parameter Description](#section074312314279)
-- [Usage](#section133816772712)
-- [Example](#section526149182717)
-
-## Command Function
-
-This command is used to print information about a file system, such as the type, total size, and available size.
-
-## Syntax
-
-statfs \[_directory_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
directory
-
-
Indicates 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.
-
-
-
-
-
-## Usage
-
-The printed information varies depending on the file system.
-
-## Example
-
-The following uses the NFS file system as an example:
-
-Enter **statfs /nfs**.
-
-**Figure 1** Output of the statfs command
-
-
diff --git a/en/device-dev/kernel/su.md b/en/device-dev/kernel/su.md
deleted file mode 100644
index 77c7843aff7eae3a28492e61b375231d1ae01efb..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/su.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# su
-
-- [Command Function](#section297810431676)
-- [Syntax](#section157131147876)
-- [Parameter Description](#section04145521671)
-- [Usage](#section14615155610719)
-- [Example](#section13338150985)
-- [Output](#section125021924194613)
-
-## Command Function
-
-This command is used to switch the user.
-
-## Syntax
-
-su \[_uid_\] \[_gid_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
uid
-
-
Indicates the ID of the target user.
-
-
Left blank
[0, 60000]
-
-
-
gid
-
-
Indicates the ID of the target user group.
-
-
Left blank
[0, 60000]
-
-
-
-
-
-## Usage
-
-- 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.
-
-## Example
-
-Enter **su 1000 1000**.
-
-## Output
-
-**Figure 1** Switching to the user whose **uid** and **gid** are both **1000**
-
-
diff --git a/en/device-dev/kernel/swtmr.md b/en/device-dev/kernel/swtmr.md
deleted file mode 100644
index 69b4720d91e1e8a1a55141eb3350294de7e438e9..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/swtmr.md
+++ /dev/null
@@ -1,110 +0,0 @@
-# swtmr
-
-- [Command Function](#section166171064814)
-- [Syntax](#section424011111682)
-- [Parameter Description](#section1268410459465)
-- [Usage](#section169806213815)
-- [Example](#section16676026389)
-- [Output](#section1541991614710)
-
-## Command Function
-
-This command is used to query information about system software timers.
-
-## Syntax
-
-swtmr \[_ID_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
ID
-
-
Indicates the ID of a software timer.
-
-
[0, 0xFFFFFFFF]
-
-
-
-
-
-## Usage
-
-- If the parameter is not 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**.
-
-## Output
-
-**Figure 1** Querying information about all software timers
-
-
-**Figure 2** Querying information about a specified software timer
-
-
-**Table 2** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
SwTmrID
-
-
Indicates the ID of the software timer.
-
-
-
State
-
-
Indicates the 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).
-
-
-
Interval
-
-
Indicates the number of ticks used by the software timer.
-
-
-
Count
-
-
Indicates the number of times that the software timer has been working.
-
-
-
Arg
-
-
Indicates the input parameter.
-
-
-
handlerAddr
-
-
Indicates the callback address.
-
-
-
-
-
-> **NOTE:**
->- The **ID** value can be in decimal or hexadecimal format.
->- If the **ID** value is within the range of \[0, _Number of current software timers - 1_\], the status of the specified software timer is returned. For other values, an error message is displayed.
-
diff --git a/en/device-dev/kernel/system-commands.md b/en/device-dev/kernel/system-commands.md
deleted file mode 100644
index cb95770023d2c98f56f2a8068b38111e0c628fe6..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/system-commands.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# System Commands
-
-- **[cpup](cpup.md)**
-
-- **[date](date.md)**
-
-- **[dmesg](dmesg.md)**
-
-- **[exec](exec.md)**
-
-- **[free](free.md)**
-
-- **[help](help.md)**
-
-- **[hwi](hwi.md)**
-
-- **[kill](kill.md)**
-
-- **[log](log.md)**
-
-- **[memcheck](memcheck.md)**
-
-- **[oom](oom.md)**
-
-- **[pmm](pmm.md)**
-
-- **[reset](reset.md)**
-
-- **[sem](sem.md)**
-
-- **[stack](stack.md)**
-
-- **[su](su.md)**
-
-- **[swtmr](swtmr.md)**
-
-- **[systeminfo](systeminfo.md)**
-
-- **[task](task.md)**
-
-- **[uname](uname.md)**
-
-- **[vmm](vmm.md)**
-
-- **[watch](watch.md)**
-
-
diff --git a/en/device-dev/kernel/systeminfo.md b/en/device-dev/kernel/systeminfo.md
deleted file mode 100644
index 058d899cdf7b4d1213763e531237f2c518e91a9f..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/systeminfo.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# systeminfo
-
-- [Command Function](#section863016434820)
-- [Syntax](#section139791817795)
-- [Parameter](#section19472339164813)
-- [Usage](#section285522592)
-- [Example](#section9471171015105)
-- [Output](#section1657011114915)
-
-## Command Function
-
-This command is used to display the resource usage of the current OS, including tasks, semaphores, mutexes, queues, and timers.
-
-## Syntax
-
-systeminfo
-
-## Parameter
-
-None
-
-## Usage
-
-None
-
-## Example
-
-Enter **systeminfo**.
-
-## Output
-
-**Figure 1** Usage of system resources
-
-
-**Table 1** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
Module
-
-
Indicates the module name.
-
-
-
Used
-
-
Indicates the quantity of currently used resources.
-
-
-
Total
-
-
Indicates the total quantity of available resources.
-
-
-
Enabled
-
-
Indicates whether the module is enabled.
-
-
-
Task
-
-
Indicates the task.
-
-
-
Sem
-
-
Indicates the semaphore.
-
-
-
Mutex
-
-
Indicates the mutex.
-
-
-
Queue
-
-
Indicates the queue.
-
-
-
SwTmr
-
-
Indicates the timer.
-
-
-
-
-
diff --git a/en/device-dev/kernel/task.md b/en/device-dev/kernel/task.md
deleted file mode 100644
index 4bac34f5c9b33579900118efb6267edae157999d..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/task.md
+++ /dev/null
@@ -1,125 +0,0 @@
-# task
-
-- [Command Function](#section0533181714106)
-- [Syntax](#section1014412308101)
-- [Parameter Description](#section116057158506)
-- [Usage](#section2053502951112)
-- [Example](#section12629113381116)
-- [Output](#section19299103465015)
-
-## Command Function
-
-This command is used to query information about processes and threads.
-
-## Syntax
-
-task/task -a
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
-a
-
-
Displays all information.
-
-
N/A
-
-
-
-
-
-## Usage
-
-If the parameter is not specified, partial task information is printed by default.
-
-## Example
-
-Enter **task**.
-
-## Output
-
-**Figure 1** Querying partial task information
-
-
-**Table 2** Output description
-
-
-
Parameter
-
-
Description
-
-
-
-
PID
-
-
Indicates the process ID.
-
-
-
PPID
-
-
Indicates the parent process ID.
-
-
-
PGID
-
-
Indicates the process group ID.
-
-
-
UID
-
-
Indicates the user ID.
-
-
-
Status
-
-
Indicates the current task status.
-
-
-
CPUUSE10s
-
-
Indicates the CPU usage within 10 seconds.
-
-
-
PName
-
-
Indicates the process name.
-
-
-
TID
-
-
Indicates the task ID.
-
-
-
StackSize
-
-
Indicates the size of the task stack.
-
-
-
WaterLine
-
-
Indicates the peak value used by the stack.
-
-
-
MEMUSE
-
-
Indicates the memory usage.
-
-
-
TaskName
-
-
Indicates the task name.
-
-
-
-
-
diff --git a/en/device-dev/kernel/telnet.md b/en/device-dev/kernel/telnet.md
deleted file mode 100644
index d58498d777835091a5e536dd4db6549daa67e0f1..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/telnet.md
+++ /dev/null
@@ -1,65 +0,0 @@
-# telnet
-
-- [Command Function](#section3551830123913)
-- [Syntax](#section14897133233918)
-- [Parameter Description](#section977718353392)
-- [Usage](#section134991538183916)
-- [Example](#section1097414426398)
-- [Output](#section11846624191310)
-
-## Command Function
-
-This command is used to enable or disable the Telnet server service.
-
-## Syntax
-
-telnet \[_on | off_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
on
-
-
Enables the Telnet server service.
-
-
N/A
-
-
-
off
-
-
Disables the Telnet server service.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- Before enabling Telnet, ensure that the network driver and network protocol stack have been initialized and the NIC of the board is in the **link up** state.
-- Currently, multiple clients \(Telnet + IP\) cannot connect to the development board at the same time.
-
- > **NOTICE:**
- >Telnet is under debugging and disabled by default. Do not use it in formal products.
-
-
-## Example
-
-Enter **telnet on**.
-
-## Output
-
-**Figure 1** Output of **telnet on**
-
-
diff --git a/en/device-dev/kernel/tftp.md b/en/device-dev/kernel/tftp.md
deleted file mode 100644
index c1bbd2eba3924c83503b38a30e0a39d5cc14d20b..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/tftp.md
+++ /dev/null
@@ -1,87 +0,0 @@
-# tftp
-
-- [Command Function](#section15142134573911)
-- [Syntax](#section20958174917394)
-- [Parameter Description](#section576613532395)
-- [Usage](#section149795134408)
-- [Example](#section148921918114015)
-- [Output](#section7872155631313)
-
-## Command Function
-
-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.
-
-## Syntax
-
-./bin/tftp _<-g/-p\>_ _-l_ _\[FullPathLocalFile\] -r \[RemoteFile\] \[Host\]_
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
-g/-p
-
-
Indicates the file transfer direction.
-
-g: downloads files from the TFTP server.
-p: uploads files to the TFTP server.
-
-
N/A
-
-
-
-l FullPathLocalFile
-
-
Indicates the complete path of a local file.
-
-
N/A
-
-
-
-r RemoteFile
-
-
Indicates the file name on the server.
-
-
N/A
-
-
-
Host
-
-
Indicates the server IP address.
-
-
N/A
-
-
-
-
-
-## Usage
-
-1. Deploy a TFTP server on the server and configure the TFTP server correctly.
-2. Use the **tftp** command to upload and download files on the OpenHarmony board.
-3. The size of the file to be transferred cannot exceed 32 MB.
-
- > **NOTICE:**
- >TFTP is under debugging and disabled by default. Do not use it in formal products.
-
-
-## Example
-
-Download the **out** file from the server.
-
-## Output
-
-```
-OHOS # ./bin/tftp -g -l /nfs/out -r out 192.168.1.2
-TFTP transfer finish
-```
-
-After the **tftp** command is executed, **TFTP transfer finish** is displayed if the file transfer is complete. If the file transfer fails, other information is displayed to help locate the fault.
-
diff --git a/en/device-dev/kernel/thread.md b/en/device-dev/kernel/thread.md
deleted file mode 100644
index 6c6f3cc1c7a37a35c44f5d0414cffbabcfd6d42d..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/thread.md
+++ /dev/null
@@ -1,702 +0,0 @@
-# Thread
-
-- [Basic Concepts](#section1179311337405)
-- [When to Use](#section44877547404)
-- [Available APIs](#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
-
-
-**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.
-
-## Available APIs
-
-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/touch.md b/en/device-dev/kernel/touch.md
deleted file mode 100644
index 8b7b21b93d9b80b2511074ab59eadede0855aa7d..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/touch.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# touch
-
-- [Command Function](#section17541924112716)
-- [Syntax](#section866182711274)
-- [Parameter Description](#section268912296270)
-- [Usage](#section412093332714)
-- [Example](#section414434814354)
-- [Output](#section1028419515711)
-
-## Command Function
-
-- This command is used to create an empty file in a specified directory.
-- If this command is executed to create an existing file, the execution will be successful but the timestamp will not be updated.
-
-## Syntax
-
-touch \[_filename_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
filename
-
-
Indicates the name of the file to be created.
-
-
N/A
-
-
-
-
-
-## Usage
-
-- The **touch** command creates a read-write empty file.
-- The **touch** command creates only one file at a time.
-
- > **NOTICE:**
- >If you run the **touch** command to create a file in a path storing important system resources, unexpected results such as a system breakdown may occur. For example, if you run the **touch uartdev-0** command in the **/dev** path, the system may stop responding.
-
-
-## Example
-
-Enter **touch file.c**.
-
-## Output
-
-**Figure 1** Creating **file.c**
-
-
diff --git a/en/device-dev/kernel/umount.md b/en/device-dev/kernel/umount.md
deleted file mode 100644
index 931ab380dfe501594c0c3a0122b98254682d61df..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/umount.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# umount
-
-- [Command Function](#section365125133520)
-- [Syntax](#section9615254123512)
-- [Parameter Description](#section63446577355)
-- [Usage](#section92931509368)
-- [Example](#section144311323616)
-- [Output](#section360525113611)
-
-## Command Function
-
-This command is used to unmount a specified file system.
-
-## Syntax
-
-umount \[_dir_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
dir
-
-
Indicates the directory from which the file system is to be unmounted.
-
-
Directory to which the file system has been mounted
-
-
-
-
-
-## Usage
-
-By specifying the **dir** parameter in the **unmount** command, you can unmount the specified file system from the directory.
-
-## Example
-
-Enter **umount /bin1/vs/sd**.
-
-## Output
-
-Unmounting the file system from **/bin1/vs/sd**
-
-**Figure 1** Unmounting result
-
-
diff --git a/en/device-dev/kernel/uname.md b/en/device-dev/kernel/uname.md
deleted file mode 100644
index a66e69e5ca2a6c3b7f2cc700c1d89b7849beec30..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/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
-
-
-
diff --git a/en/device-dev/kernel/vfs.md b/en/device-dev/kernel/vfs.md
deleted file mode 100644
index 9b3ea51a6f5eee1b4e968b72ea87052eec067249..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/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
-
-
-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
-
-
-## 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
-
-> **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/vmm.md b/en/device-dev/kernel/vmm.md
deleted file mode 100644
index c5d73aaa832540c3323e3d65516a2fb8b32d603a..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/vmm.md
+++ /dev/null
@@ -1,158 +0,0 @@
-# vmm
-
-- [Command Function](#section445335110416)
-- [Syntax](#section1795712553416)
-- [Parameter Description](#section92544592410)
-- [Usage](#section104151141252)
-- [Example](#section11545171957)
-- [Output](#section075617368542)
-
-## Command Function
-
-This command is used to query the virtual memory usage of a process.
-
-## Syntax
-
-vmm \[_-a / -h / --help_\]
-
-vmm \[_pid_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
-a
-
-
Displays the virtual memory usage of all processes.
-
-
N/A
-
-
-
-h | --help
-
-
Displays the help information.
-
-
N/A
-
-
-
pid
-
-
Indicates the ID of the process to query.
-
-
[0, 63]
-
-
-
-
-
-## Usage
-
-By default, the virtual memory usage of all processes is displayed.
-
-## Example
-
-Enter **vmm 3**.
-
-## Output
-
-**Figure 1** Virtual memory usage of the process with PID 3
-
-
-**Table 2** Basic process information
-
-
-
Parameter
-
-
Description
-
-
-
-
PID
-
-
Indicates the process ID.
-
-
-
aspace
-
-
Indicates the address of the virtual memory control block.
-
-
-
name
-
-
Indicates the process name.
-
-
-
base
-
-
Indicates the start address of the virtual memory.
-
-
-
size
-
-
Indicates the size of virtual memory.
-
-
-
pages
-
-
Indicates the number of used physical pages.
-
-
-
-
-
-**Table 3** Virtual memory region information
-
-
-
Parameter
-
-
Description
-
-
-
-
region
-
-
Indicates the address of the control block in the virtual memory region.
-
-
-
name
-
-
Indicates the name of the virtual memory region.
-
-
-
base
-
-
Indicates the start address of the virtual memory region.
-
-
-
size
-
-
Indicates the size of the virtual memory region.
-
-
-
mmu_flags
-
-
Indicates the MMU mapping attribute of the virtual memory region.
-
-
-
pages
-
-
Indicates the number of used physical pages (including the shared memory).
-
-
-
pg/ref
-
-
Indicates the number of used physical pages.
-
-
-
-
-
diff --git a/en/device-dev/kernel/watch.md b/en/device-dev/kernel/watch.md
deleted file mode 100644
index 1e3211a4c14524d4bb972610b377caf5c21e9d8c..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/watch.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# watch
-
-- [Command Function](#section20643141481314)
-- [Syntax](#section1075441721316)
-- [Parameter Description](#section1472810220135)
-- [Usage](#section186772414131)
-- [Example](#section4764192791314)
-- [Output](#section5791253155517)
-
-## Command Function
-
-This command is used to periodically monitor the execution result of a command.
-
-## Syntax
-
-watch
-
-watch \[_-c/-n/-t/--count/--interval/-no-title/--over_\] \[_command_\]
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Default Value
-
-
Value Range
-
-
-
-
-c / --count
-
-
Indicates the number of times that the command is executed.
-
-
0xFFFFFF
-
-
(0, 0xFFFFFF]
-
-
-
-n / --interval
-
-
Indicates the interval for periodically running the command, in seconds.
-
-
1s
-
-
(0, 0xFFFFFF]
-
-
-
-t / -no-title
-
-
Disables time display on the top.
-
-
N/A
-
-
N/A
-
-
-
command
-
-
Indicates the command to be monitored.
-
-
N/A
-
-
N/A
-
-
-
--over
-
-
Stops the current command monitoring.
-
-
N/A
-
-
N/A
-
-
-
-
-
-## Usage
-
-You can run the **watch --over** command to stop the currently running command monitoring.
-
-## Example
-
-Enter **watch -n 2 -c 6 task**.
-
-## Output
-
-**Figure 1** **task** command monitoring result
-
-
-> **NOTE:**
->In this example, the **task** command has been executed every 2 seconds for six times, and the preceding figure shows the output of the last execution.
-
diff --git a/en/device-dev/kernel/writeproc.md b/en/device-dev/kernel/writeproc.md
deleted file mode 100644
index c7b4c69b6e8b7eac0963d68a62a85f665c5c9c37..0000000000000000000000000000000000000000
--- a/en/device-dev/kernel/writeproc.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# writeproc
-
-- [Command Function](#section366714216619)
-- [Syntax](#section8833164614615)
-- [Parameter Description](#section12809111019453)
-- [Usage](#section15935131220717)
-- [Example](#section79281818476)
-- [Output](#section12742311179)
-
-## Command Function
-
-This command is used to write data to a specified proc file system. The proc file system supports the input of string parameters. Each file needs to implement its own method.
-
-## Syntax
-
-writeproc <_data_\> \>\> /proc/<_filename_\>
-
-## Parameter Description
-
-**Table 1** Parameters
-
-
-
Parameter
-
-
Description
-
-
Value Range
-
-
-
-
data
-
-
Indicates 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.
-
-
N/A
-
-
-
-
-
-## 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.
-
-> **NOTE:**
->The proc file system does not support multi-thread access.
-
-## Example
-
-Enter **writeproc test \>\> /proc/uptime**.
-
-## Output
-
-OHOS \# writeproc test \>\> /proc/uptime
-
-\[INFO\]write buf is: test
-
-test \>\> /proc/uptime
-
-> **NOTE:**
->The uptime proc file temporarily implements the **write** command. The **INFO** log is generated by the implemented **test** command.
-
diff --git a/en/device-dev/overview.md b/en/device-dev/overview.md
index 4a5832db5a9e81baccd6d4cbb4bf500c0f5a06a3..48d154e9b82369651b2f5fadd10ae947b00699ac 100644
--- a/en/device-dev/overview.md
+++ b/en/device-dev/overview.md
@@ -55,42 +55,42 @@ In addition, OpenHarmony provides a series of optional system components that ca
diff --git a/en/device-dev/porting/Readme-EN.md b/en/device-dev/porting/Readme-EN.md
index b4f760b020e0cd05bae29470c24a27d49696bb63..aa4e507c0956dd1856217ca6a3569e805b4cf371 100644
--- a/en/device-dev/porting/Readme-EN.md
+++ b/en/device-dev/porting/Readme-EN.md
@@ -1,26 +1,33 @@
# Porting Guide
-- [Third-Party Library Porting Guide](third-party-library-porting-guide.md)
- - [Overview](overview.md)
- - [Porting a Library Built Using CMake](porting-a-library-built-using-cmake.md)
- - [Porting a Library Built Using Makefile](porting-a-library-built-using-makefile.md)
-
-- [Third-Party SoC Porting Guide](third-party-soc-porting-guide.md)
- - [Porting Preparations](porting-preparations.md)
- - [Before You Start](before-you-start.md)
- - [Building Adaptation Process](building-adaptation-process.md)
-
- - [Kernel Porting](kernel-porting.md)
- - [Overview](overview-0.md)
- - [Basic Kernel Adaptation](basic-kernel-adaptation.md)
- - [Kernel Porting Verification](kernel-porting-verification.md)
-
- - [Board-Level OS Porting](board-level-os-porting.md)
- - [Overview](overview-1.md)
- - [Board-Level Driver Adaptation](board-level-driver-adaptation.md)
- - [Implementation of APIs at the HAL](implementation-of-apis-at-the-hal.md)
- - [System Modules](system-modules.md)
- - [XTS](xts.md)
-
- - [FAQ](faq.md)
-
+- [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)
+ - [三方组件适配](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
diff --git a/en/device-dev/porting/basic-kernel-adaptation.md b/en/device-dev/porting/basic-kernel-adaptation.md
deleted file mode 100644
index 8713d4e6c026edc5ec6b37188011427478e5bcfd..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/basic-kernel-adaptation.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# Basic Kernel Adaptation
-
-- [Adaptation Process](#section14523241594)
-- [Feature Configuration](#section112994366592)
-
-The LiteOS Cortex-M kernel provides the system initialization process and customized configuration options required for system running. During kernel porting, you must pay attention to the functions related to hardware configuration in the initialization process and understand the kernel configuration options so that the minimum kernel that matches the board can be tailored.
-
-## Adaptation Process
-
-Basic adaptation consists of the following steps:
-
-1. Modify the code in the **startup.S** and corresponding link configuration files.
-2. Initialize the serial port and register the handler function for the tick interrupt response in the **main.c** file
-
-**Figure 1** Startup process
-
-
-
-
-In the **startup.S** file, you must ensure that the entry function \(for example, **reset\_vector**\) of the interrupt vector table is stored in the RAM start address specified by the link configuration files. The link configuration files of IAR, Keil, and GCC projects are **xxx.icf**, **xxx.sct**, and **xxx.ld**, respectively. The startup file provided by the vendor does not need to be modified if the **startup.S** file has initialized the system clock and returned to the **main** function. Otherwise, the preceding functions need to be implemented.
-
-In the **main.c** file, you need to register the UartInit function used for initializing the serial port and the handler function used for the system tick.
-
-- The UartInit function initializes the board serial port, and the function name can be defined based on the board. This function is optional. You can determine whether to call it based on whether the board supports the serial port. If the board supports the serial port, this function must enable TX and RX channels of the serial port and set the baud rate.
-- You can call **HalTickStart** to set the **OsTickHandler** function for the tick interrupt response.
-
-For the chip whose interrupt vector table cannot be redirected, you need to disable the **LOSCFG\_PLATFORM\_HWI** macro, and add the **OsTickHandler** function for the tick interrupt response in the **startup.S** file.
-
-## Feature Configuration
-
-The **los\_config.h** file defines both complete configuration and default configuration of **liteos\_m**. All configuration items in this file can be customized for different boards as required.
-
-You can define configuration items in the **device/xxxx/target\_config.h** file of the corresponding board. For other undefined configuration items, default values in the **los\_config.h** file will be used.
-
-The following table shows some typical configuration items:
-
-**Table 1** Typical configuration items
-
-
-
Item
-
-
Description
-
-
-
-
LOSCFG_BASE_CORE_SWTMR
-
-
Switch of the software timer. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
-
-
-
LOSCFG_BASE_CORE_SWTMR_ALIGN
-
-
Switch of the time alignment feature, which depends on the switch status of the software timer. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
-
-
-
LOSCFG_BASE_IPC_MUX
-
-
Switch of the mux feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
-
-
-
LOSCFG_BASE_IPC_QUEUE
-
-
Switch of the queue feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
-
-
-
LOSCFG_BASE_IPC_SEM
-
-
Switch of the semaphore feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
-
-
-
LOSCFG_PLATFORM_EXC
-
-
Switch of the exception feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
-
-
-
LOSCFG_KERNEL_PRINTF
-
-
Switch of the print feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
-
-
-
-
-
diff --git a/en/device-dev/porting/before-you-start.md b/en/device-dev/porting/before-you-start.md
deleted file mode 100644
index 3b25588a1b4e0804d58c6e0055e8165b9384b29b..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/before-you-start.md
+++ /dev/null
@@ -1,84 +0,0 @@
-# Before You Start
-
-- [Porting Directory](#section284217487490)
-- [Porting Process](#section639315306506)
-- [Porting Specifications](#section187870185219)
-
-This document provides basic guidance for OpenHarmony developers and system on a chip \(SoC\) or module vendors to port OpenHarmony to typical chip architectures, such as the cortex-M and RISC-V series. Currently, the Bluetooth service is not supported. Due to the complexity of the OpenHarmony project, this document is subject to update as the version and APIs change.
-
-This guide is intended for readers who have experience in developing embedded systems. Therefore, it mainly describes operations and key points during platform porting instead of basic introduction to the OS.
-
-## Porting Directory
-
-The implementation of the OpenHarmony project directories and functions relies on the OS itself. If no enhancement for a complex feature is involved, you only need to focus on the directories described in the following table.
-
-**Table 1** Key directories in the porting process
-
-
-
Directory
-
-
Description
-
-
-
-
/build/lite
-
-
Basic building framework for OpenHarmony
-
-
-
/kernel/liteos_m
-
-
Basic kernel. The implementation related to the chip architecture is in the arch directory.
-
-
-
/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.
-
-
-
/vendor
-
-
Product-level implementation, which is contributed by Huawei or product vendors.
-
-
-
-
-
-The **device** directory is in the internal structure of **device/\{Chip solution vendor\}/\{Development board\}**. The following uses Hisilicon **hispark\_taurus** as an example:
-
-```
-device
-└── hisilicon # Name of the chip solution vendor
- ├── common # Common part of the chip solution development board
- └── hispark_taurus # Name of the development board
- ├── BUILD.gn # Entry to building the development board
- ├── hals # OS hardware adaptation of the chip solution vendor
- ├── linux # Linux version
- │ └── config.gni # Configurations of the building toolchain and building options for the Linux version
- └── liteos_a # LiteOS Cortex-A version
- └── config.gni # Configurations of the building toolchain and building options for the LiteOS Cortex-A version
-```
-
-The **vendor** directory is in the internal structure of **vendor/\{Product solution vendor\}/\{Product name\}**. The following uses Huawei Wi-Fi IoT product as an example:
-
-```
-vendor # Product solution vendor
-└── huawei # Name of the product solution vendor
- └── wifiiot # Product name
- ├── hals # OS adaptation of the product solution vendor
- ├── BUILD.gn # Product building script
- └── config.json # Product configuration file
-```
-
-## Porting Process
-
-The **device** directory of OpenHarmony is the adaptation directory for the basic SoC. You can skip the porting process and directly develop system applications if complete SoC adaptation code is already available in the directory. If there is no corresponding SoC porting implementation in the directory, complete the porting process by following the instructions provided in this document. The following figure shows the process of porting OpenHarmony to a third-party SoC.
-
-**Figure 1** Key steps for SoC porting
-
-
-## 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](overview-0.md) and [Board-Level Directory Specifications](overview-1.md#section6204129143013).
-
diff --git a/en/device-dev/porting/board-level-os-porting.md b/en/device-dev/porting/board-level-os-porting.md
deleted file mode 100644
index e70229d4a090f88acacea19f58ff606e8395bc7b..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/board-level-os-porting.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Board-Level OS Porting
-
-- **[Overview](overview-1.md)**
-
-- **[Board-Level Driver Adaptation](board-level-driver-adaptation.md)**
-
-- **[Implementation of APIs at the HAL](implementation-of-apis-at-the-hal.md)**
-
-- **[System Modules](system-modules.md)**
-
-- **[XTS](xts.md)**
-
-
diff --git a/en/device-dev/porting/figures/en-us_image_0000001072304191.png b/en/device-dev/porting/figure/en-us_image_0000001072304191.png
similarity index 100%
rename from en/device-dev/porting/figures/en-us_image_0000001072304191.png
rename to en/device-dev/porting/figure/en-us_image_0000001072304191.png
diff --git a/en/device-dev/porting/figures/en-us_image_0000001073943511.png b/en/device-dev/porting/figure/en-us_image_0000001073943511.png
similarity index 100%
rename from en/device-dev/porting/figures/en-us_image_0000001073943511.png
rename to en/device-dev/porting/figure/en-us_image_0000001073943511.png
diff --git a/en/device-dev/porting/figure/en-us_image_0000001126198996.png b/en/device-dev/porting/figure/en-us_image_0000001126198996.png
new file mode 100644
index 0000000000000000000000000000000000000000..57e7e35c2eb4d0bcafecd07c32639ca0e8b17b6e
Binary files /dev/null and b/en/device-dev/porting/figure/en-us_image_0000001126198996.png differ
diff --git a/en/device-dev/porting/figure/en-us_image_0000001126354076.png b/en/device-dev/porting/figure/en-us_image_0000001126354076.png
new file mode 100644
index 0000000000000000000000000000000000000000..c6cae9cb23b2d1767b415ba1fa668349e329034b
Binary files /dev/null and b/en/device-dev/porting/figure/en-us_image_0000001126354076.png differ
diff --git a/en/device-dev/porting/figure/en-us_image_0000001126358814.png b/en/device-dev/porting/figure/en-us_image_0000001126358814.png
new file mode 100644
index 0000000000000000000000000000000000000000..39c6cb96611a7ced5e17bbeee96ac77ba5c1bf58
Binary files /dev/null and b/en/device-dev/porting/figure/en-us_image_0000001126358814.png differ
diff --git a/en/device-dev/porting/figure/en-us_image_0000001172273945.jpg b/en/device-dev/porting/figure/en-us_image_0000001172273945.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..a1e7f8b695bebf395ea6cfa0aed55495c4896118
Binary files /dev/null and b/en/device-dev/porting/figure/en-us_image_0000001172273945.jpg differ
diff --git a/en/device-dev/porting/figure/en-us_image_0000001172393865.jpg b/en/device-dev/porting/figure/en-us_image_0000001172393865.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..efb1e17b00d37b072a3032678144984e2e13b2d6
Binary files /dev/null and b/en/device-dev/porting/figure/en-us_image_0000001172393865.jpg differ
diff --git a/en/device-dev/porting/figure/hdf_wifi.png b/en/device-dev/porting/figure/hdf_wifi.png
new file mode 100644
index 0000000000000000000000000000000000000000..4a0441de4621bd558383ba1323d21c793bcf192a
Binary files /dev/null and b/en/device-dev/porting/figure/hdf_wifi.png differ
diff --git a/en/device-dev/porting/figure/kernel-startup-framework.jpg b/en/device-dev/porting/figure/kernel-startup-framework.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..8e99fdaa50fdcc1cd5eaf3023ba62cce2f6a8981
Binary files /dev/null and b/en/device-dev/porting/figure/kernel-startup-framework.jpg differ
diff --git a/en/device-dev/porting/figures/key-steps-for-soc-porting.png b/en/device-dev/porting/figure/key-steps-for-soc-porting.png
similarity index 100%
rename from en/device-dev/porting/figures/key-steps-for-soc-porting.png
rename to en/device-dev/porting/figure/key-steps-for-soc-porting.png
diff --git a/en/device-dev/porting/figures/process-for-board-level-driver-adaptation.png b/en/device-dev/porting/figure/process-for-board-level-driver-adaptation.png
similarity index 100%
rename from en/device-dev/porting/figures/process-for-board-level-driver-adaptation.png
rename to en/device-dev/porting/figure/process-for-board-level-driver-adaptation.png
diff --git a/en/device-dev/porting/figures/successful-startup-of-openharmony.png b/en/device-dev/porting/figure/successful-startup-of-openharmony.png
similarity index 100%
rename from en/device-dev/porting/figures/successful-startup-of-openharmony.png
rename to en/device-dev/porting/figure/successful-startup-of-openharmony.png
diff --git "a/en/device-dev/porting/figure/\345\210\206\347\261\273.png" "b/en/device-dev/porting/figure/\345\210\206\347\261\273.png"
new file mode 100644
index 0000000000000000000000000000000000000000..7edac54ec2fcd1fc93330d47acb2d44fceef2710
Binary files /dev/null and "b/en/device-dev/porting/figure/\345\210\206\347\261\273.png" differ
diff --git a/en/device-dev/porting/kernel-porting-verification.md b/en/device-dev/porting/kernel-porting-verification.md
deleted file mode 100644
index b00b1cb1556201cb15da99b87cf559a9cda798f3..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/kernel-porting-verification.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Kernel Porting Verification
-
-Add the sample program file **main.c** to the **device** directory of the project and compile the file. After LOS\_KernelInit is complete, this sample program will create two tasks that loop the **LOS\_TaskDelay** function and print the log information cyclically. In this way, you can check whether system scheduling and the clock work properly.
-
-```
-VOID TaskSampleEntry2(VOID) // Entry function of task 2
-{
- while(1) {
- LOS_TaskDelay(10000);
- printf("taskSampleEntry2 running...\n");
- }
-}
-
-VOID TaskSampleEntry1(VOID) // Entry function of task 1
-{
- while(1) {
- LOS_TaskDelay(2000);
- printf("taskSampleEntry1 running...\n");
- }
-}
-
-UINT32 TaskSample(VOID)
-{
- UINT32 uwRet;
- UINT32 taskID1,taskID2;
- TSK_INIT_PARAM_S stTask1={0};
- stTask1.pfnTaskEntry = (TSK_ENTRY_FUNC)TaskSampleEntry1;
- stTask1.uwStackSize = 0X1000;
- stTask1.pcName = "taskSampleEntry1";
- stTask1.usTaskPrio = 6; // Set the priority of stTask1, which is different from that of stTask2.
- uwRet = LOS_TaskCreate(&taskID1, &stTask1);
-
- stTask1.pfnTaskEntry = (TSK_ENTRY_FUNC)TaskSampleEntry2;
- stTask1.uwStackSize = 0X1000;
- stTask1.pcName = "taskSampleEntry2";
- stTask1.usTaskPrio = 7;
- uwRet = LOS_TaskCreate(&taskID2, &stTask1);
-
- return LOS_OK;
-}
-
-LITE_OS_SEC_TEXT_INIT int main(void)
-{
- UINT32 ret;
- UartInit(); // Configure the hardware serial port and output the debug log over this serial port. The actual function name varies with the board.
- printf("\n\rhello world!!\n\r");
- ret = LOS_KernelInit();
- TaskSample();
- if (ret == LOS_OK) {
- LOS_Start(); // Start system scheduling, execute stTask1/stTask2 cyclically, and output task logs over the serial port.
- }
- while (1) {
- __asm volatile("wfi");
- }
-}
-```
-
-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](xts.md).
-
diff --git a/en/device-dev/porting/kernel-porting.md b/en/device-dev/porting/kernel-porting.md
deleted file mode 100644
index ce6f9d8c039b649b86657569141b682be86533b4..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/kernel-porting.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Kernel Porting
-
-- **[Overview](overview-0.md)**
-
-- **[Basic Kernel Adaptation](basic-kernel-adaptation.md)**
-
-- **[Kernel Porting Verification](kernel-porting-verification.md)**
-
-
diff --git a/en/device-dev/porting/overview-0.md b/en/device-dev/porting/overview-0.md
deleted file mode 100644
index 46e8c9491f46f61dcce2ac50e2c627349976e12d..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/overview-0.md
+++ /dev/null
@@ -1,64 +0,0 @@
-# Overview
-
-- [Porting Scenario](#section93781277367)
-- [Directory Specifications](#section18127744153119)
-- [Chip Architecture Adaptation](#section137431650339)
-
-## Porting Scenario
-
-The chip architecture adaptation process is optional. If the particular chip architecture is supported in the **liteos\_m/kernel/arch** directory, you can directly implement the board adaptation. Otherwise, chip architecture porting is required.
-
-## Directory Specifications
-
-The kernel used by module chips is LiteOS Cortex-M, which consists of four modules, namely kernel abstraction layer \(KAL\), components, kernel, and utils.
-
-- **KAL**: provides APIs exposed externally and depends on the components and kernel modules.
-- **Components**: is pluggable and relies on the kernel module.
-
-- **Kernel**: stores hardware-related code in the **arch** directory and other code. The implementation of kernel function sets \(such as task and sem\), for example, task context switching and atomic operations, depends on the hardware-related code in the **arch** directory.
-- **Utils**: functions as a basic code block where other modules rely.
-
-**Figure 1** Architecture of the LiteOS Cortex-M kernel
-
-
-
-
-The directory structure of the kernel is described as follows:
-
-```
-.
-├── components --- Components available for porting and header files exposed externally
-├── kal --- APIs exposed externally, including CMSIS APIs and part of POSIX APIs
-├── kernel --- Code for defining the minimum kernel function set
-│ ├── arch --- Code of the kernel instruction architecture layer
-│ │ ├── arm --- Code of the ARM32 architecture
-│ │ │ ├── cortex-m3 --- Code of the Cortex-M3 architecture
-│ │ │ │ ├── iar --- Implementation of the IAR toolchain
-│ │ │ │ ├── keil --- Implementation of the Keil toolchain
-│ │ │ │ └── xxx --- Implementation of the particular toolchain
-│ │ │ └── cortex-m4 --- Code of the Cortex-M4 architecture
-│ │ │ ├── iar --- Implementation of the IAR toolchain
-│ │ │ ├── keil --- Implementation of the Keil toolchain
-│ │ │ └── xxx --- Implementation of the particular toolchain
-│ │ ├── include --- Header files that declare the APIs required, kernel-independent
-│ │ └── risc-v --- RISK_V architecture
-│ │ └── gcc --- Implementation of the IAR toolchain
-│ ├── include --- Code for defining the minimum kernel function set
-│ └── src --- Code for implementing the minimum kernel function set
-└──utils --- Basic code
-```
-
-## Chip Architecture Adaptation
-
-As shown in the [Directory Specifications](#section18127744153119), the **arch/include** directory defines the functions that need to be implemented on the common chip architecture. The code related to the chip architecture contains assembly code, which varies based on building toolchains. Therefore, the code for adapting to different toolchains \(for example, IAR, Keil, GCC, etc.\) must be implemented in a specific chip architecture.
-
-The **arch/include** directory defines common files and functions. All functions in this directory need to be implemented to adapt to a newly added architecture. For details, refer to the following header files.
-
-```
-los_arch.h --- Defines the functions required for initializing the chip architecture.
-los_atomic.h --- Defines the atomic operation functions required by the chip architecture.
-los_context.h --- Defines the context functions required by the chip architecture.
-los_interrupt.h --- Defines the interrupt and exception functions required by the chip architecture.
-los_timer.h --- Defines the timer functions required by the chip architecture.
-```
-
diff --git a/en/device-dev/porting/overview-1.md b/en/device-dev/porting/overview-1.md
deleted file mode 100644
index a7332baa3775232b85193c40ab6984c32aa54b96..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/overview-1.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# Overview
-
-- [Porting Process](#section1283115812294)
-- [Board-Level Directory Specifications](#section6204129143013)
-
-## Porting Process
-
-After the minimum system is ported, you can port the board-level system by:
-
-1. Implementing the board-level driver adaptation
-2. Completing the implementation at the HAL
-3. Implementing the XTS
-4. Verifying service functions
-
-**Figure 1** Process for board-level driver adaptation
-
-
-## Board-Level Directory Specifications
-
-For details about board-level system building adaptation, see [Compilation and Building Subsystem](building-adaptation-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:
-
-```
-.
-├── device --- Sample board
-│ └── xxx ---
-│ └── xxx --- . This directory contains the demo of the LiteOS Cortex-M kernel, which can run properly.
-│ ├── BUILD.gn --- Building configuration file of the board
-│ ├── board --- Specific implementation of the board (Optional. If a product-level demo is provided, implementation at the application layer is stored in this directory.)
-│ ├── liteos_m --- LiteOS Cortex-M kernel to use based on the kernel_type in the BUILD.gn file
-│ │ └── config.gni --- Building options
-│ ├── libraries --- Board-level SDK
-│ │ └── include --- SDK-provided header files that are exposed externally
-│ │ └── ... --- binary or source files
-│ ├── main.c --- main function entry (Product level configuration is used if the same definition exists at the product level.)
-│ ├── target_config.h --- Board-level kernel configuration
-│ ├── project --- Board-level project configuration file (Product-level configuration is used if the same definition exists at the product level.)
-│ └── adapter --- HAL interfaces (Optional)
-│ └── hals
-│ ├── communication
-│ │ └── wifi_lite
-│ │ ├── ...
-│ └── iot_hardware
-│ ├── upgrade
-│ ├── utils
-│ └── wifiiot_lite
-├── vendor --- End-to-end feature product sample of OpenHarmony
-│ └── huawei --- Vendor name
-│ └── wifiiot --- Feature product
-│ ├── app
-│ │ └── main.c --- main function entry of the product
-│ ├── project --- Project configuration file
-│ ├── BUILD.gn --- Project building entry
-│ └── config.json --- Building configuration file of the product and components used for product configuration
-└── out --- Output directory during the building
- ├── ... --- .bin files generated during board/product building
-```
-
diff --git a/en/device-dev/porting/porting-a-library-built-using-cmake.md b/en/device-dev/porting/porting-a-library-built-using-cmake.md
deleted file mode 100644
index a7d399c983a5841878aa59c6c4bd01dec39d4135..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/porting-a-library-built-using-cmake.md
+++ /dev/null
@@ -1,435 +0,0 @@
-# Porting a Library Built Using CMake
-
-- [Source Code Acquisition](#section1771132116245)
-- [Porting Guidelines](#section9737174410328)
-- [Cross-Compilation](#section38205577332)
- - [Compilation Reference](#section1088111263418)
- - [Cross-Compilation Settings](#section8168182883515)
-
-- [Library Test](#section6686144293611)
-- [Adding the Compiled double-conversion Library to the OpenHarmony Project](#section1651053153715)
-
-The following shows how to port the double-conversion library.
-
-## Source Code Acquisition
-
-Acquire the source code of double-conversion from [https://github.com/google/double-conversion](https://github.com/google/double-conversion). The following table lists the directory structure.
-
-**Table 1** Directory structure of the source code
-
-
-
Directory
-
-
Description
-
-
-
-
double-conversion/cmake/
-
-
Template used for building with CMake
-
-
-
double-conversion/double-conversion/
-
-
Directory of source files
-
-
-
double-conversion/msvc/
-
-
-
-
-
-
double-conversion/test/
-
-
Source files of the test cases
-
-
-
double-conversion/.gitignore
-
-
-
-
-
-
double-conversion/AUTHORS
-
-
-
-
-
-
double-conversion/BUILD
-
-
-
-
-
-
double-conversion/CMakeLists.txt
-
-
Top-level file used for building with CMake
-
-
-
double-conversion/COPYING
-
-
-
-
-
-
double-conversion/Changelog
-
-
-
-
-
-
double-conversion/LICENSE
-
-
-
-
-
-
double-conversion/Makefile
-
-
-
-
-
-
double-conversion/README.md
-
-
-
-
-
-
double-conversion/SConstruct
-
-
-
-
-
-
double-conversion/WORKSPACE
-
-
-
-
-
-
-
-
-## Porting Guidelines
-
-Cross-compile the double-conversion library by modifying the toolchain to generate executable files for the OpenHarmony platform and then add these files to the OpenHarmony project by invoking CMake via GN.
-
-## Cross-Compilation
-
-### Compilation Reference
-
-The [README.md](https://github.com/google/double-conversion/blob/master/README.md) file in the code repository details the procedures for compiling the double-conversion library using CMake as well as the testing methods. This document focuses on the building, compilation, and testing of the library. If you have any questions during library porting, refer to the **README.md** file. For porting of other third-party libraries that can be independently built with CMake, you can refer to the compilation guides provided by the libraries.
-
-### Cross-Compilation Settings
-
-The following steps show how to configure and modify the toolchains for cross-compiling the libraries built using CMake to compile executable files for the OpenHarmony platform.
-
-1. Configure the toolchains.
-
- Add configuration of the clang toolchains to the top-level file **CMakeLists.txt** listed in [Table 1](#table824211132418).
-
- ```
- set(CMAKE_CROSSCOMPILING TRUE)
- set(CMAKE_SYSTEM_NAME Generic)
- set(CMAKE_CXX_COMPILER_ID Clang)
- set(CMAKE_TOOLCHAIN_PREFIX llvm-)
- # Specify the C compiler (ensure that the path of the toolchain has been added to the PATH environment variable) and its flags. To perform cross-compilation using clang, the --target flag must be specified.
- set(CMAKE_C_COMPILER clang)
- set(CMAKE_C_FLAGS "--target=arm-liteos -D__clang__ -march=armv7-a -w")
- # Specify the C++ compiler (ensure that the path of the toolchain has been added to the PATH environment variable) and its flags. To perform cross-compilation, the --target flag must be specified.
- set(CMAKE_CXX_COMPILER clang++)
- set(CMAKE_CXX_FLAGS "--target=arm-liteos -D__clang__ -march=armv7-a -w")
- # Specify the linker and its flags. --target and --sysroot must be specified. You can specify OHOS_ROOT_PATH via the suffix parameter of the cmake command.
- set(MY_LINK_FLAGS "--target=arm-liteos --sysroot=${OHOS_SYSROOT_PATH}")
- 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 ")
- # Specify the path for searching chained libraries.
- set(CMAKE_SYSROOT ${OHOS_SYSROOT_PATH})
- ```
-
-2. Perform the compilation.
-
- Run a Linux command to enter the directory \(listed in [Table 1](#table824211132418)\) for storing double-conversion source files and then run the following commands:
-
- ```
- mkdir build && cd build
- cmake .. -DBUILD_TESTING=ON -DOHOS_SYSROOT_PATH="..."
- make -j
- ```
-
- **OHOS\_SYSROOT\_PATH** specifies the absolute path where **sysroot** is located. Taking OpenHarmony for example, set **OHOS\_SYSROOT\_PATH** to the absolute path of **openHarmony/prebuilts/lite/sysroot**.
-
-3. View the result.
-
- After step 2 is complete, a static library file and test cases are generated in the **build** directory.
-
- **Table 2** Directory structure of compiled files
-
-
-
Directory
-
-
Description
-
-
-
-
double-conversion/build/libdouble-conversion.a
-
-
Static library file
-
-
-
double-conversion/build/test/
-
-
Test cases and CMake cache files
-
-
-
double-conversion/build/CMakeCache.txt
-
-
Cache files during CMake building
-
-
-
double-conversion/build/CMakeFiles/
-
-
-
-
-
-
double-conversion/build/cmake_install.cmake
-
-
-
-
-
-
double-conversion/build/CTestTestfile.cmake
-
-
-
-
-
-
double-conversion/build/DartConfiguration.tcl
-
-
-
-
-
-
double-conversion/build/generated/
-
-
-
-
-
-
double-conversion/build/Makefile
-
-
-
-
-
-
double-conversion/build/Testing/
-
-
-
-
-
-
-
-
-
-## Library Test
-
-1. Set up the OpenHarmony environment.
-
- Using Hi3518EV300 as an example, compile the OpenHarmony image and burn it to the development board. For details, see [Developing the First Example Program Running on Hi3518](https://gitee.com/openharmony/docs/blob/master/docs-en/quick-start/developing-the-first-example-program-running-on-hi3518.md).
-
- The following screen is displayed after a successful login to the OS.
-
- **Figure 1** Successful startup of OpenHarmony
- 
-
-2. Mount the **nfs** directory and put the executable file **cctest** into the **test** directory \(listed in [Table 2](#table1452412391911)\) to the **nfs** directory.
-3. Perform the test cases.
-
- If the double-conversion library is not cross-compiled, you can execute the test cases by running the **make test** command and obtain the result via CMake. However, this command is not applicable to the library after cross-compilation. This way, you can perform the test cases by executing the generated test case files.
-
- - After the **nfs** directory is successfully mounted, run the following command to list all items in the test cases:
-
- ```
- cd nfs
- ./cctest --list
- ```
-
- Some items are as follows:
-
- ```
- test-bignum/Assign<
- test-bignum/ShiftLeft<
- test-bignum/AddUInt64<
- test-bignum/AddBignum<
- test-bignum/SubtractBignum<
- test-bignum/MultiplyUInt32<
- test-bignum/MultiplyUInt64<
- test-bignum/MultiplyPowerOfTen<
- test-bignum/DivideModuloIntBignum<
- test-bignum/Compare<
- test-bignum/PlusCompare<
- test-bignum/Square<
- test-bignum/AssignPowerUInt16<
- test-bignum-dtoa/BignumDtoaVariousDoubles<
- test-bignum-dtoa/BignumDtoaShortestVariousFloats<
- test-bignum-dtoa/BignumDtoaGayShortest<
- test-bignum-dtoa/BignumDtoaGayShortestSingle<
- test-bignum-dtoa/BignumDtoaGayFixed<
- test-bignum-dtoa/BignumDtoaGayPrecision<
- test-conversions/DoubleToShortest<
- test-conversions/DoubleToShortestSingle<
- ...
- ```
-
- - Run the following command to test **test-bignum**:
-
- ```
- ./cctest test-bignum
- ```
-
- The test is passed if the following information is displayed:
-
- ```
- Ran 13 tests.
- ```
-
-
-## Adding the Compiled double-conversion Library to the OpenHarmony Project
-
-1. Copy the double-conversion library to the OpenHarmony project.
-
- Copy this library that can be cross-compiled to the **third\_party** directory of OpenHarmony. To avoid modifying the **BUILD.gn** file in the directory of the third-party library to be ported, add a directory to store adaptation files, including **BUILD.gn**, **build\_thirdparty.py**, and **config.gni**, for converting GN to CMake building.
-
- **Table 3** Directory structure of the ported library
-
-
-
-
-2. Add the GN file to the CMake adaptation file.
-
- - The following shows the implementation for building using the newly added **BUILD.gn** file. For other third-party libraries that can be independently compiled using CMake, you only need to change the target paths when porting them to OpenHarmony.
-
- ```
- import("config.gni")
- group("double-conversion") {
- if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
- deps = [":make"]
- }
- }
- if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
- action("make") {
- script = "//third_party/double-conversion/build_thirdparty.py"
- outputs = ["$root_out_dir/log_dc.txt"]
- exec_path = rebase_path(rebase_path("./build", ohos_third_party_dir))
- command = "rm * .* -rf && $CMAKE_TOOLS_PATH/cmake .. $CMAKE_FLAG $CMAKE_TOOLCHAIN_FLAG && make -j"
- args = [
- "--path=$exec_path",
- "--command=${command}"
- ]
- }
- }
- ```
-
- - The newly added **config.gni** file is used to configure the library in the following example implementation. For other third-party libraries that can be independently compiled using CMake, you only need to change the configuration of **CMAKE\_FLAG** when porting them to OpenHarmony.
-
- ```
- #CMAKE_FLAG: config compile feature
- CMAKE_FLAG = "-DBUILD_TESTING=ON -DCMAKE_CXX_STANDARD=11"
-
- #toolchain: follow up-layer, depend on $ohos_build_compiler
- if (ohos_build_compiler == "clang") {
- CMAKE_TOOLCHAIN_FLAG = "-DOHOS_SYSROOT_PATH=${ohos_root_path}prebuilts/lite/sysroot/"
- } else {
- CMAKE_TOOLCHAIN_FLAG = ""
- }
-
- #CMake tools path,no need setting if this path already joined to $PATH.
- CMAKE_TOOLS_PATH = "setting CMake tools path..."
- ```
-
- - The following shows the implementation of the newly added **build\_thirdparty.py** file. For other third-party libraries that can be independently compiled using CMake, you can port them to OpenHarmony without modifications.
-
- ```
- import os
- import sys
- from subprocess import Popen
- import argparse
- import shlex
-
- def cmd_exec(command):
- cmd = shlex.split(command)
- proc = Popen(cmd)
- proc.wait()
- ret_code = proc.returncode
- if ret_code != 0:
- raise Exception("{} failed, return code is {}".format(cmd, ret_code))
-
- def main():
- parser = argparse.ArgumentParser()
- parser.add_argument('--path', help='Build path.')
- parser.add_argument('--command', help='Build command.')
- parser.add_argument('--enable', help='enable python.', nargs='*')
- args = parser.parse_args()
-
- if args.enable:
- if args.enable[0] == 'false':
- return
-
- if args.path:
- curr_dir = os.getcwd()
- os.chdir(args.path)
- if args.command:
- if '&&' in args.command:
- command = args.command.split('&&')
- for data in command:
- cmd_exec(data)
- else:
- cmd_exec(args.command)
- os.chdir(curr_dir)
-
- if __name__ == '__main__':
- sys.exit(main())
- ```
-
- - Add a configuration item in the configuration file to control compiling of the library. By default, library compilation is disabled.
-
- For example, add the following configuration to the **//build/lite/ohos\_var.gni** file:
-
- ```
- declare_args() {
- ohos_build_thirdparty_migrated_from_fuchisa = true
- }
- ```
-
-3. Build the library.
-
- - Manual building
-
- Execute the following command:
-
- ```
- hb build -T //third_party/double-conversion:double-conversion
- ```
-
- If the compilation is successful, a static library file and test cases will be generated in the [build](#li15717101715249) directory.
-
-
diff --git a/en/device-dev/porting/porting-a-library-built-using-makefile.md b/en/device-dev/porting/porting-a-library-built-using-makefile.md
deleted file mode 100644
index ed7a88af264885f96282dd63ae5827083dfc8a49..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/porting-a-library-built-using-makefile.md
+++ /dev/null
@@ -1,309 +0,0 @@
-# Porting a Library Built Using Makefile
-
-- [Source Code Acquisition](#section114115321416)
-- [Cross-Compilation Settings](#section81263255384)
-- [Library Test](#section1830015913391)
-- [Adding the Compiled yxml Library to the OpenHarmony Project](#section1898016213406)
-
-The following shows how to port the yxml library.
-
-## Source Code Acquisition
-
-Acquire the source code of yxml from [the open-source repository](https://github.com/getdnsapi/yxml). The following table lists the directory structure.
-
-**Table 1** Directory structure of the source code
-
-
-
Directory
-
-
Description
-
-
-
-
yxml/bench/
-
-
Benchmark-related code
-
-
-
yxml/test/
-
-
Input and output files as well as scripts of the test cases
-
-
-
yxml/Makefile
-
-
File for organizing compilation
-
-
-
yxml/.gitattributes
-
-
-
-
-
-
yxml/.gitignore
-
-
-
-
-
-
yxml/COPYING
-
-
-
-
-
-
yxml/yxml.c
-
-
-
-
-
-
yxml/yxml.c.in
-
-
-
-
-
-
yxml/yxml-gen.pl
-
-
-
-
-
-
yxml/yxml.h
-
-
-
-
-
-
yxml/yxml.md
-
-
-
-
-
-
yxml/yxml-states
-
-
-
-
-
-
-
-
-## Cross-Compilation Settings
-
-The following steps show how to configure and modify the toolchains for cross-compiling the libraries built using CMake to compile executable files for the OpenHarmony platform.
-
-1. Configure the toolchains.
-
- Replace the original configuration of MakeFile \(listed in [Table 1](#table16520154171813)\) in the root directory of the yxml library with the following clang toolchains configuration.
-
- clang toolchains configuration:
-
- ```
- # Set the cross-compilation toolchain and ensure that the path of the toolchain has been added to the PATH environment variable.
- CC:=clang
- AR:=llvm-ar
- # The --target and --sysroot flags must be specified.
- CFLAGS:=-Wall -Wextra -Wno-unused-parameter -O2 -g --target=arm-liteos -march=armv7-a --sysroot=$(OHOS_ROOT_PATH)prebuilts/lite/sysroot
- ```
-
- Original configuration:
-
- ```
- CC:=gcc
- AR:=ar
- CFLAGS:=-Wall -Wextra -Wno-unused-parameter -O2 -g
- ```
-
-2. Perform the compilation.
-
- Run a Linux command to enter the directory \(listed in [Table 1](#table16520154171813)\) for storing yxml source files and then run the following command:
-
- ```
- make test OHOS_SYSROOT_PATH=...
- ```
-
- **OHOS\_SYSROOT\_PATH** specifies the absolute path of the directory where **sysroot** is located. Taking OpenHarmony for example, set **OHOS\_SYSROOT\_PATH** to the absolute path of **prebuilts/lite/sysroot/**.
-
-3. View the result.
-
- After step 2 is complete, a static library file and test case are generated in the **out** directory of the yxml library.
-
- **Table 2** Directory structure of compiled files
-
-
-
Directory
-
-
Description
-
-
-
-
openHarmony/third_party/yxml/yxml/out/lib/
-
-
Static library file
-
-
-
openHarmony/third_party/yxml/yxml/out/test/
-
-
Test cases as well as the input and output files
-
-
-
-
-
-
-## 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](porting-a-library-built-using-cmake.md#section6686144293611). The following describes how to use the test cases of the yxml library.
-
-**Table 3** Directory structure of the test directory
-
-
-
Automatic test script, which cannot be used because OpenHarmony does not support automatic script execution. However, you can refer to this script to conduct a manual test.
-
-
-
openHarmony/third_party/yxml/yxml/out/test/test
-
-
Executable file for testing.
-
-
-
openHarmony/third_party/yxml/yxml/out/test/*.xml
-
-
Input test file.
-
-
-
openHarmony/third_party/yxml/yxml/out/test/*.out
-
-
Expected output file.
-
-
-
-
-
-The content of the **test.sh** file is as follows:
-
-```
-#!/bin/sh
-for i in *.xml; do
- b=`basename $i .xml`
- o=${b}.out
- t=${b}.test
- ./test <$i >$t
- if [ -n "`diff -q $o $t`" ]; then
- echo "Test failed for $i:"
- diff -u $o $t
- exit 1
- fi
-done
-echo "All tests completed successfully."
-```
-
-The shell of OpenHarmony does not support input and output redirection symbols \(< and \>\). During the test, you need to copy the content in the **_\*_.xml** file to the shell and press **Enter**. The output content is displayed in the shell screen.
-
-The following operations are performed based on the assumption that the OpenHarmony environment has been set up and the **nfs** directory has been mounted and accessed.
-
-1. Execute the following command:
-
- ```
- ./test
- ```
-
-2. Copy the content in the **_\*_.xml** file to shell.
-
- Taking the **pi01.xml** file in the [test](#table115941423164318) directory as an example, copy the following content to shell and press **Enter**:
-
- ```
-
- ```
-
-3. Check whether the output in the shell is the same as that of the **_\*_.out** file in the [test](#table115941423164318) directory.
-
- The output is as follows:
-
- ```
- pistart SomePI
- picontent abc
- piend
- elemstart a
- elemend
- ok
- ```
-
- The output is the same as the **pi01.out** file in the [test](#table115941423164318) directory. The test is passed.
-
-
-## 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](porting-a-library-built-using-cmake.md#section1651053153715).
-
-- The implementation of the newly added **BUILD.gn** file in the yxml library is as follows:
-
-```
-import("config.gni")
-group("yxml") {
- if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
- deps = [":make"]
- }
-}
-if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
- action("make") {
- script = "//third_party/yxml/build_thirdparty.py"
- outputs = ["$target_out_dir/log_yxml.txt"]
- exec_path = rebase_path(rebase_path("./yxml", root_build_dir))
- command = "make clean && $MAKE_COMMAND"
- args = [
- "--path=$exec_path",
- "--command=${command}"
- ]
- }
-}
-```
-
-- The configuration of the newly added **config.gni** file in the yxml library is as follows:
-
-```
-TEST_ENABLE = "YES"
-
-if (TEST_ENABLE == "YES") {
- MAKE_COMMAND = "make test OHOS_SYSROOT_PATH=${ohos_root_path}prebuilts/lite/sysroot/"
-} else {
- MAKE_COMMAND = "make OHOS_SYSROOT_PATH=${ohos_root_path}prebuilts/lite/sysroot/"
-}
-```
-
-- The following table lists the directory structure of the OpenHarmony project.
-
-**Table 4** Directory structure of the ported library
-
-
-
Directory
-
-
Description
-
-
-
-
openHarmony/third_party/yxml/BUILD.gn
-
-
GN file for adding the third-party library to the OpenHarmony project
-
-
-
openHarmony/third_party/yxml/build_thirdpaty.py
-
-
Script file for GN to call the shell command to convert compilation from GN to Makefile.
-
-
-
openHarmony/third_party/yxml/config.gni
-
-
Third-party library compilation configuration file, which can be modified to determine whether the test cases will be used during the building
-
-
-
openHarmony/third_party/yxml/yxml/
-
-
Directory of the third-party library to be ported
-
-
-
-
-
diff --git a/en/device-dev/porting/porting-preparations.md b/en/device-dev/porting/porting-preparations.md
deleted file mode 100644
index 0e0f02a7044a9c634e2f101918e9c12747056bde..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/porting-preparations.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Porting Preparations
-
-- **[Before You Start](before-you-start.md)**
-
-- **[Building Adaptation Process](building-adaptation-process.md)**
-
-
diff --git a/en/device-dev/porting/public_sys-resources/icon-caution.gif b/en/device-dev/porting/public_sys-resources/icon-caution.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/porting/public_sys-resources/icon-caution.gif and /dev/null differ
diff --git a/en/device-dev/porting/public_sys-resources/icon-danger.gif b/en/device-dev/porting/public_sys-resources/icon-danger.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/porting/public_sys-resources/icon-danger.gif and /dev/null differ
diff --git a/en/device-dev/porting/public_sys-resources/icon-note.gif b/en/device-dev/porting/public_sys-resources/icon-note.gif
deleted file mode 100644
index 6314297e45c1de184204098efd4814d6dc8b1cda..0000000000000000000000000000000000000000
Binary files a/en/device-dev/porting/public_sys-resources/icon-note.gif and /dev/null differ
diff --git a/en/device-dev/porting/public_sys-resources/icon-notice.gif b/en/device-dev/porting/public_sys-resources/icon-notice.gif
deleted file mode 100644
index 86024f61b691400bea99e5b1f506d9d9aef36e27..0000000000000000000000000000000000000000
Binary files a/en/device-dev/porting/public_sys-resources/icon-notice.gif and /dev/null differ
diff --git a/en/device-dev/porting/public_sys-resources/icon-tip.gif b/en/device-dev/porting/public_sys-resources/icon-tip.gif
deleted file mode 100644
index 93aa72053b510e456b149f36a0972703ea9999b7..0000000000000000000000000000000000000000
Binary files a/en/device-dev/porting/public_sys-resources/icon-tip.gif and /dev/null differ
diff --git a/en/device-dev/porting/public_sys-resources/icon-warning.gif b/en/device-dev/porting/public_sys-resources/icon-warning.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/porting/public_sys-resources/icon-warning.gif and /dev/null differ
diff --git a/en/device-dev/porting/system-modules.md b/en/device-dev/porting/system-modules.md
deleted file mode 100644
index 686ea0751d80679d063a624cf1eceb04c415fbd0..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/system-modules.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# System Modules
-
-- [SAMGR](#section105874301910)
-- [DFX](#section20064420420)
-
-System modules, such as the system ability manager \(SAMGR\) and DFX subsystem, provide basic capabilities for upper-layer applications. During board-level system porting, you can directly select the system modules as required without any adaptation.
-
-## SAMGR
-
-**Introduction**
-
-This service-oriented framework enables you to develop services, features, and external APIs, and implement multi-service process sharing and service invocation for inter-process communication \(IPC\).
-
-> **NOTICE:**
->This module must be used during board-level system porting. Otherwise, other service modules cannot run properly.
-
-For details about how to use SAMGR, see [samgr\_lite](https://gitee.com/openharmony/distributedschedule_samgr_lite/blob/master/README.md).
-
-## DFX
-
-**Introduction**
-
-The design for X \(DFX\) subsystem mainly includes design for reliability \(DFR\) and design for testability \(DFT\), providing code maintenance and testing.
-
-For details, see [dfx](../subsystems/dfx.md).
-
diff --git a/en/device-dev/porting/third-party-library-porting-guide.md b/en/device-dev/porting/third-party-library-porting-guide.md
deleted file mode 100644
index 2f5cbcb9396ab5f55bf6f7ae956a5a2edfd1a833..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/third-party-library-porting-guide.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Third-Party Library Porting Guide
-
-- **[Overview](overview.md)**
-
-- **[Porting a Library Built Using CMake](porting-a-library-built-using-cmake.md)**
-
-- **[Porting a Library Built Using Makefile](porting-a-library-built-using-makefile.md)**
-
-
diff --git a/en/device-dev/porting/third-party-soc-porting-guide.md b/en/device-dev/porting/third-party-soc-porting-guide.md
deleted file mode 100644
index 19cd7887dee6cc3d7002e6173d3a01b181e19cdb..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/third-party-soc-porting-guide.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Third-Party SoC Porting Guide
-
-- **[Porting Preparations](porting-preparations.md)**
-
-- **[Kernel Porting](kernel-porting.md)**
-
-- **[Board-Level OS Porting](board-level-os-porting.md)**
-
-- **[FAQ](faq.md)**
-
-
diff --git a/en/device-dev/porting/transplant-chip-board-bundle.md b/en/device-dev/porting/transplant-chip-board-bundle.md
new file mode 100644
index 0000000000000000000000000000000000000000..d6c185df8b3dbb61bfc6bd9da2d5bd94181e1bfd
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-board-bundle.md
@@ -0,0 +1,57 @@
+# 三方组件适配
+
+如果需要使用third\_party目录下与产品相关的三方组件，可能需要对三方组件进行适配，下面以比较常用的mbedtls为例，介绍下适配步骤，注意本小节中仅介绍如何将适配的代码与OpenHarmony的编译框架融合，不会详细介绍mbedtls本身的原理和适配代码的具体逻辑，这些内容请参考mbedtls官方网站上的适配指南。
+
+1. 编写适配层代码
+
+ 根据mbedtls官网的适配指南，编写需要的适配层代码，以适配硬件随机数举例，下面的路径都是相对third\_party/mbedtls的路径：
+
+ 1. 拷贝include/mbedtls/config.h到ports目录下，并修改打开MBEDTLS\_ENTROPY\_HARDWARE\_ALT开关。
+ 2. 在ports目录下创建entropy\_poll\_alt.c文件include并实现entropy\_poll.h中的硬件随机数接口
+ 3. 在BUILD.gn中的mbedtls\_sources中增加刚才适配的entropy\_poll\_alt.c的路径
+ 4. 在BIULD.gn中的lite\_library\("mbedtls\_static"\)中增加一行MBEDTLS\_CONFIG\_FILE指定新配置文件的位置
+
+ ```
+ lite_library("mbedtks_static") {
+ ...
+ defines += ["MBEDTLS_CONFIG_FILE=<../port/config.h>"]
+ ...
+ }
+ ```
+
+
+ 注意，上面的修改最好都新建一个config或者新建一个xxx\_alt.c文件来修改，不要直接在原先的代码中修改，侵入式的修改会导致后续版本升级出现大量零散冲突，增加升级维护成本。
+
+2. 制作patch
+
+ 由于上面的适配是硬件相关的，上库代码时，不能直接放到通用的third\_party/mbedtls目录中，因此需要将上面的修改制作成patch，在编译之前通过打patch的方式注入到代码中。
+
+ 1. 首先增加设备的patch配置文件device///patch.yml
+ 2. 编辑device///patch.yml，增加要打的patch的信息：
+
+ ```
+ # 需要打patch的路径，路径均为相对代码根目录的路径
+ third_party/mbedtls:
+ # 该路径下需要打的patch存放路径
+ - device///third_party/mbedtls/adapter.patch
+ third_party/wpa_supplicant:
+ # 当一个路径下有多个patch的时候会依次执行patch
+ - device///third_party/wpa_supplicant/xxxxx.patch
+ - device///third_party/wpa_supplicant/yyyyy.patch
+ ...
+ ```
+
+ 3. 制作上述**步骤1**修改的patch并放到对应的目录即可
+
+3. 使用带patch的编译
+
+ 想要在编译的时候带上patch，其他步骤不变，仅需要在触发编译的时候加上 --patch，例如全编译的命令编程
+
+ ```
+ hb build -f --patch
+ ```
+
+ > **CAUTION:**
+ >最后一次打patch的产品信息会被记录，在进行下一次编译操作时，会对上一次的patch进行回退（即执行\`patch -p1 -R < xxx\`），回退patch失败或新增patch失败均会终止编译过程，请解决patch冲突后再次尝试编译。
+
+
diff --git a/en/device-dev/porting/transplant-chip-board-component.md b/en/device-dev/porting/transplant-chip-board-component.md
new file mode 100644
index 0000000000000000000000000000000000000000..2e29bb3150ed0a0e6de9b827f4799df05577be2c
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-board-component.md
@@ -0,0 +1,26 @@
+# System Modules
+
+- [SAMGR](#section105874301910)
+- [DFX](#section20064420420)
+
+System modules, such as the system ability manager \(SAMGR\) and DFX subsystem, provide basic capabilities for upper-layer applications. During board-level system porting, you can directly select the system modules as required without any adaptation.
+
+## SAMGR
+
+**Introduction**
+
+This service-oriented framework enables you to develop services, features, and external APIs, and implement multi-service process sharing and service invocation for inter-process communication \(IPC\).
+
+> **NOTICE:**
+>This module must be used during board-level system porting. Otherwise, other service modules cannot run properly.
+
+For details about how to use SAMGR, see [samgr\_lite](https://gitee.com/openharmony/distributedschedule_samgr_lite/blob/master/README.md).
+
+## DFX
+
+**Introduction**
+
+The design for X \(DFX\) subsystem mainly includes design for reliability \(DFR\) and design for testability \(DFT\), providing code maintenance and testing.
+
+For details about how to use the DFX subsystem, see [DFX](../subsystems/subsys-dfx-overview.md).
+
diff --git a/en/device-dev/porting/board-level-driver-adaptation.md b/en/device-dev/porting/transplant-chip-board-drive.md
similarity index 100%
rename from en/device-dev/porting/board-level-driver-adaptation.md
rename to en/device-dev/porting/transplant-chip-board-drive.md
diff --git a/en/device-dev/porting/implementation-of-apis-at-the-hal.md b/en/device-dev/porting/transplant-chip-board-hal.md
similarity index 100%
rename from en/device-dev/porting/implementation-of-apis-at-the-hal.md
rename to en/device-dev/porting/transplant-chip-board-hal.md
diff --git a/en/device-dev/porting/transplant-chip-board-overview.md b/en/device-dev/porting/transplant-chip-board-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..036de7066aee8df287fba20aec2d8f6c83b2a440
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-board-overview.md
@@ -0,0 +1,57 @@
+# Overview
+
+- [Porting Process](#section1283115812294)
+- [Board-Level Directory Specifications](#section6204129143013)
+
+## Porting Process
+
+After the minimum system is ported, you can port the board-level system by:
+
+1. Implementing the board-level driver adaptation
+2. Completing the implementation at the HAL
+3. Implementing the XTS
+4. Verifying service functions
+
+**Figure 1** Process for board-level driver adaptation
+
+
+## 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:
+
+```
+.
+├── device --- Sample board
+│ └── xxx ---
+│ └── xxx --- . This directory contains the demo of the LiteOS Cortex-M kernel, which can run properly.
+│ ├── BUILD.gn --- Building configuration file of the board
+│ ├── board --- Specific implementation of the board (Optional. If a product-level demo is provided, implementation at the application layer is stored in this directory.)
+│ ├── liteos_m --- LiteOS Cortex-M kernel to use based on the kernel_type in the BUILD.gn file
+│ │ └── config.gni --- Building options
+│ ├── libraries --- Board-level SDK
+│ │ └── include --- SDK-provided header files that are exposed externally
+│ │ └── ... --- binary or source files
+│ ├── main.c --- main function entry (Product level configuration is used if the same definition exists at the product level.)
+│ ├── target_config.h --- Board-level kernel configuration
+│ ├── project --- Board-level project configuration file (Product-level configuration is used if the same definition exists at the product level.)
+│ └── adapter --- HAL interfaces (Optional)
+│ └── hals
+│ ├── communication
+│ │ └── wifi_lite
+│ │ ├── ...
+│ └── iot_hardware
+│ ├── upgrade
+│ ├── utils
+│ └── wifiiot_lite
+├── vendor --- End-to-end feature product sample of OpenHarmony
+│ └── huawei --- Vendor name
+│ └── wifiiot --- Feature product
+│ ├── app
+│ │ └── main.c --- main function entry of the product
+│ ├── project --- Project configuration file
+│ ├── BUILD.gn --- Project building entry
+│ └── config.json --- Building configuration file of the product and components used for product configuration
+└── out --- Output directory during the building
+ ├── ... --- .bin files generated during board/product building
+```
+
diff --git a/en/device-dev/porting/transplant-chip-board-xts.md b/en/device-dev/porting/transplant-chip-board-xts.md
new file mode 100644
index 0000000000000000000000000000000000000000..35c40e9dc60e204096d5f5d136350087555790d5
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-board-xts.md
@@ -0,0 +1,63 @@
+# XTS
+
+- [Introduction](#section6725155811454)
+ - [Adding the XTS Subsystem to the Building Component](#section46981118105417)
+ - [Executing ACTS Cases for the IoTLink Module](#section9489122319819)
+
+
+## Introduction
+
+X Test Suite \(XTS\) is a set of OpenHarmony certification test suites. Currently, the application compatibility test suite \(ACTS\) is supported. The **test/xts** repository contains the **acts** directory and **tools** software package.
+
+- The **acts** directory stores the source code and configuration files of ACTS test cases. The ACTS helps device vendors detect the software incompatibility as early as possible and ensures that the software is compatible with OpenHarmony during the entire development process.
+- The **tools** software package stores the test case development framework related to **acts**.
+
+> **NOTE:**
+>The startup of the XTS depends on the SAMGR module.
+
+The XTS adaptation consists of the following steps:
+
+1. Add the XTS subsystem to the building component.
+2. Execute ACTS cases for the IoTLink module.
+
+### Adding the XTS Subsystem to the Building Component
+
+The following example shows how to add the XTS subsystem to the building component **hispark\_aries**:
+
+1. Add the definition of the XTS subsystem to the **vendor/hisilicon/hispark\_aries/config.json** file.
+
+ ```
+ {
+ "subsystem": "test",
+ "components": [
+ { "component": "xts_acts", "features":[] },
+ { "component": "xts_tools", "features":[] }
+ ]
+ },
+ ```
+
+2. Set the building type to the debug version so that the XTS subsystem can be built.
+
+### Executing ACTS Cases for the IoTLink Module
+
+The following example shows how to execute ACTS cases for the IoTLink module of **hispark\_aries**:
+
+1. Obtain the built image.
+
+ Obtain the image from the **out/hispark\_pegasus/wifiiot\_hispark\_pegasus/** directory.
+
+ > **NOTE:**
+ >To check whether the ACTS is integrated into the current image, check whether the corresponding **.a** file is compiled.
+
+2. Burn the image into the development board.
+3. Execute the test by performing the following steps.
+ - Use a serial port tool to log in to the development board and save information about the serial port.
+
+ - Restart the device and view serial port logs.
+
+4. Analyze the test result.
+ - View the serial port logs, whose format is as follows:
+
+ - The log for each test suite starts with **Start to run test suite:** and ends with **xx Tests xx Failures xx Ignored**.
+
+
diff --git a/en/device-dev/porting/transplant-chip-board.md b/en/device-dev/porting/transplant-chip-board.md
new file mode 100644
index 0000000000000000000000000000000000000000..c674dd27e2d16f5fb50991b9bf1a4e592807dc23
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-board.md
@@ -0,0 +1,15 @@
+# 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)**
+
+- **[三方组件适配](transplant-chip-board-bundle.md)**
+
+- **[XTS](transplant-chip-board-xts.md)**
+
+
diff --git a/en/device-dev/porting/faq.md b/en/device-dev/porting/transplant-chip-faqs.md
similarity index 100%
rename from en/device-dev/porting/faq.md
rename to en/device-dev/porting/transplant-chip-faqs.md
diff --git a/en/device-dev/porting/transplant-chip-kernel-adjustment.md b/en/device-dev/porting/transplant-chip-kernel-adjustment.md
new file mode 100644
index 0000000000000000000000000000000000000000..88acd2d145496f7650d96d56b25c49af3b76462c
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-kernel-adjustment.md
@@ -0,0 +1,83 @@
+# Basic Kernel Adaptation
+
+- [Adaptation Process](#section14523241594)
+- [Feature Configuration](#section112994366592)
+
+The LiteOS Cortex-M kernel provides the system initialization process and customized configuration options required for system running. During kernel porting, you must pay attention to the functions related to hardware configuration in the initialization process and understand the kernel configuration options so that the minimum kernel that matches the board can be tailored.
+
+## Adaptation Process
+
+Basic adaptation consists of the following steps:
+
+1. Modify the code in the **startup.S** and corresponding link configuration files.
+2. Initialize the serial port and register the handler function for the tick interrupt response in the **main.c** file
+
+**Figure 1** Startup process
+
+
+
+
+In the **startup.S** file, you must ensure that the entry function \(for example, **reset\_vector**\) of the interrupt vector table is stored in the RAM start address specified by the link configuration files. The link configuration files of IAR, Keil, and GCC projects are **xxx.icf**, **xxx.sct**, and **xxx.ld**, respectively. The startup file provided by the vendor does not need to be modified if the **startup.S** file has initialized the system clock and returned to the **main** function. Otherwise, the preceding functions need to be implemented.
+
+In the **main.c** file, you need to register the UartInit function used for initializing the serial port and the handler function used for the system tick.
+
+- The UartInit function initializes the board serial port, and the function name can be defined based on the board. This function is optional. You can determine whether to call it based on whether the board supports the serial port. If the board supports the serial port, this function must enable TX and RX channels of the serial port and set the baud rate.
+- You can call **HalTickStart** to set the **OsTickHandler** function for the tick interrupt response.
+
+For the chip whose interrupt vector table cannot be redirected, you need to disable the **LOSCFG\_PLATFORM\_HWI** macro, and add the **OsTickHandler** function for the tick interrupt response in the **startup.S** file.
+
+## Feature Configuration
+
+The **los\_config.h** file defines both complete configuration and default configuration of **liteos\_m**. All configuration items in this file can be customized for different boards as required.
+
+You can define configuration items in the **device/xxxx/target\_config.h** file of the corresponding board. For other undefined configuration items, default values in the **los\_config.h** file will be used.
+
+The following table shows some typical configuration items:
+
+**Table 1** Typical configuration items
+
+
+
Item
+
+
Description
+
+
+
+
LOSCFG_BASE_CORE_SWTMR
+
+
Switch of the software timer. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
+
+
+
LOSCFG_BASE_CORE_SWTMR_ALIGN
+
+
Switch of the time alignment feature, which depends on the switch status of the software timer. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
+
+
+
LOSCFG_BASE_IPC_MUX
+
+
Switch of the mux feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
+
+
+
LOSCFG_BASE_IPC_QUEUE
+
+
Switch of the queue feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
+
+
+
LOSCFG_BASE_IPC_SEM
+
+
Switch of the semaphore feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
+
+
+
LOSCFG_PLATFORM_EXC
+
+
Switch of the exception feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
+
+
+
LOSCFG_KERNEL_PRINTF
+
+
Switch of the print feature. The values 1 and 0 indicate that the switch is turned on and turned off, respectively.
+
+
+
+
+
diff --git a/en/device-dev/porting/transplant-chip-kernel-overview.md b/en/device-dev/porting/transplant-chip-kernel-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..48634e90d7b415d3998cb1d2df615a466aaa9eb7
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-kernel-overview.md
@@ -0,0 +1,64 @@
+# Overview
+
+- [Porting Scenario](#section93781277367)
+- [Directory Specifications](#section18127744153119)
+- [Chip Architecture Adaptation](#section137431650339)
+
+## Porting Scenario
+
+The chip architecture adaptation process is optional. If the particular chip architecture is supported in the **liteos\_m/kernel/arch** directory, you can directly implement the board adaptation. Otherwise, chip architecture porting is required.
+
+## Directory Specifications
+
+The kernel used by module chips is LiteOS Cortex-M, which consists of four modules, namely kernel abstraction layer \(KAL\), components, kernel, and utils.
+
+- **KAL**: provides APIs exposed externally and depends on the components and kernel modules.
+- **Components**: is pluggable and relies on the kernel module.
+
+- **Kernel**: stores hardware-related code in the **arch** directory and other code. The implementation of kernel function sets \(such as task and sem\), for example, task context switching and atomic operations, depends on the hardware-related code in the **arch** directory.
+- **Utils**: functions as a basic code block where other modules rely.
+
+**Figure 1** Architecture of the LiteOS Cortex-M kernel
+
+
+
+
+The directory structure of the kernel is described as follows:
+
+```
+.
+├── components --- Components available for porting and header files exposed externally
+├── kal --- APIs exposed externally, including CMSIS APIs and part of POSIX APIs
+├── kernel --- Code for defining the minimum kernel function set
+│ ├── arch --- Code of the kernel instruction architecture layer
+│ │ ├── arm --- Code of the ARM32 architecture
+│ │ │ ├── cortex-m3 --- Code of the Cortex-M3 architecture
+│ │ │ │ ├── iar --- Implementation of the IAR toolchain
+│ │ │ │ ├── keil --- Implementation of the Keil toolchain
+│ │ │ │ └── xxx --- Implementation of the particular toolchain
+│ │ │ └── cortex-m4 --- Code of the Cortex-M4 architecture
+│ │ │ ├── iar --- Implementation of the IAR toolchain
+│ │ │ ├── keil --- Implementation of the Keil toolchain
+│ │ │ └── xxx --- Implementation of the particular toolchain
+│ │ ├── include --- Header files that declare the APIs required, kernel-independent
+│ │ └── risc-v --- RISK_V architecture
+│ │ └── gcc --- Implementation of the IAR toolchain
+│ ├── include --- Code for defining the minimum kernel function set
+│ └── src --- Code for implementing the minimum kernel function set
+└──utils --- Basic code
+```
+
+## Chip Architecture Adaptation
+
+As shown in the [Directory Specifications](#section18127744153119), the **arch/include** directory defines the functions that need to be implemented on the common chip architecture. The code related to the chip architecture contains assembly code, which varies based on building toolchains. Therefore, the code for adapting to different toolchains \(for example, IAR, Keil, GCC, etc.\) must be implemented in a specific chip architecture.
+
+The **arch/include** directory defines common files and functions. All functions in this directory need to be implemented to adapt to a newly added architecture. For details, refer to the following header files.
+
+```
+los_arch.h --- Defines the functions required for initializing the chip architecture.
+los_atomic.h --- Defines the atomic operation functions required by the chip architecture.
+los_context.h --- Defines the context functions required by the chip architecture.
+los_interrupt.h --- Defines the interrupt and exception functions required by the chip architecture.
+los_timer.h --- Defines the timer functions required by the chip architecture.
+```
+
diff --git a/en/device-dev/porting/transplant-chip-kernel-verify.md b/en/device-dev/porting/transplant-chip-kernel-verify.md
new file mode 100644
index 0000000000000000000000000000000000000000..56aa1d19d06af1d3a2c994a64b898045e0270484
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-kernel-verify.md
@@ -0,0 +1,59 @@
+# Kernel Porting Verification
+
+Add the sample program file **main.c** to the **device** directory of the project and compile the file. After LOS\_KernelInit is complete, this sample program will create two tasks that loop the **LOS\_TaskDelay** function and print the log information cyclically. In this way, you can check whether system scheduling and the clock work properly.
+
+```
+VOID TaskSampleEntry2(VOID) // Entry function of task 2
+{
+ while(1) {
+ LOS_TaskDelay(10000);
+ printf("taskSampleEntry2 running...\n");
+ }
+}
+
+VOID TaskSampleEntry1(VOID) // Entry function of task 1
+{
+ while(1) {
+ LOS_TaskDelay(2000);
+ printf("taskSampleEntry1 running...\n");
+ }
+}
+
+UINT32 TaskSample(VOID)
+{
+ UINT32 uwRet;
+ UINT32 taskID1,taskID2;
+ TSK_INIT_PARAM_S stTask1={0};
+ stTask1.pfnTaskEntry = (TSK_ENTRY_FUNC)TaskSampleEntry1;
+ stTask1.uwStackSize = 0X1000;
+ stTask1.pcName = "taskSampleEntry1";
+ stTask1.usTaskPrio = 6; // Set the priority of stTask1, which is different from that of stTask2.
+ uwRet = LOS_TaskCreate(&taskID1, &stTask1);
+
+ stTask1.pfnTaskEntry = (TSK_ENTRY_FUNC)TaskSampleEntry2;
+ stTask1.uwStackSize = 0X1000;
+ stTask1.pcName = "taskSampleEntry2";
+ stTask1.usTaskPrio = 7;
+ uwRet = LOS_TaskCreate(&taskID2, &stTask1);
+
+ return LOS_OK;
+}
+
+LITE_OS_SEC_TEXT_INIT int main(void)
+{
+ UINT32 ret;
+ UartInit(); // Configure the hardware serial port and output the debug log over this serial port. The actual function name varies with the board.
+ printf("\n\rhello world!!\n\r");
+ ret = LOS_KernelInit();
+ TaskSample();
+ if (ret == LOS_OK) {
+ LOS_Start(); // Start system scheduling, execute stTask1/stTask2 cyclically, and output task logs over the serial port.
+ }
+ while (1) {
+ __asm volatile("wfi");
+ }
+}
+```
+
+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).
+
diff --git a/en/device-dev/porting/transplant-chip-kernel.md b/en/device-dev/porting/transplant-chip-kernel.md
new file mode 100644
index 0000000000000000000000000000000000000000..7f9366086a58c40a65915482a8891469bdc1b12c
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-kernel.md
@@ -0,0 +1,9 @@
+# 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-knows.md b/en/device-dev/porting/transplant-chip-prepare-knows.md
new file mode 100644
index 0000000000000000000000000000000000000000..731df255c420f947b4be298bca7b9ce89b6b5215
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-prepare-knows.md
@@ -0,0 +1,84 @@
+# Before You Start
+
+- [Porting Directory](#section284217487490)
+- [Porting Process](#section639315306506)
+- [Porting Specifications](#section187870185219)
+
+This document provides basic guidance for OpenHarmony developers and system on a chip \(SoC\) or module vendors to port OpenHarmony to typical chip architectures, such as the cortex-M and RISC-V series. Currently, the Bluetooth service is not supported. Due to the complexity of the OpenHarmony project, this document is subject to update as the version and APIs change.
+
+This guide is intended for readers who have experience in developing embedded systems. Therefore, it mainly describes operations and key points during platform porting instead of basic introduction to the OS.
+
+## Porting Directory
+
+The implementation of the OpenHarmony project directories and functions relies on the OS itself. If no enhancement for a complex feature is involved, you only need to focus on the directories described in the following table.
+
+**Table 1** Key directories in the porting process
+
+
+
Directory
+
+
Description
+
+
+
+
/build/lite
+
+
Basic building framework for OpenHarmony
+
+
+
/kernel/liteos_m
+
+
Basic kernel. The implementation related to the chip architecture is in the arch directory.
+
+
+
/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.
+
+
+
/vendor
+
+
Product-level implementation, which is contributed by Huawei or product vendors.
+
+
+
+
+
+The **device** directory is in the internal structure of **device/\{Chip solution vendor\}/\{Development board\}**. The following uses HiSilicon **hispark\_taurus** as an example:
+
+```
+device
+└── hisilicon # Name of the chip solution vendor
+ ├── common # Common part of the chip solution development board
+ └── hispark_taurus # Name of the development board
+ ├── BUILD.gn # Entry to building the development board
+ ├── hals # OS hardware adaptation of the chip solution vendor
+ ├── linux # Linux version
+ │ └── config.gni # Configurations of the building toolchain and building options for the Linux version
+ └── liteos_a # LiteOS Cortex-A version
+ └── config.gni # Configurations of the building toolchain and building options for the LiteOS Cortex-A version
+```
+
+The **vendor** directory is in the internal structure of **vendor/\{Product solution vendor\}/\{Product name\}**. The following uses Huawei Wi-Fi IoT product as an example:
+
+```
+vendor # Product solution vendor
+└── huawei # Name of the product solution vendor
+ └── wifiiot # Product name
+ ├── hals # OS adaptation of the product solution vendor
+ ├── BUILD.gn # Product building script
+ └── config.json # Product configuration file
+```
+
+## Porting Process
+
+The **device** directory of OpenHarmony is the adaptation directory for the basic SoC. You can skip the porting process and directly develop system applications if complete SoC adaptation code is already available in the directory. If there is no corresponding SoC porting implementation in the directory, complete the porting process by following the instructions provided in this document. The following figure shows the process of porting OpenHarmony to a third-party SoC.
+
+**Figure 1** Key steps for SoC porting
+
+
+## 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).
+
diff --git a/en/device-dev/porting/building-adaptation-process.md b/en/device-dev/porting/transplant-chip-prepare-process.md
similarity index 100%
rename from en/device-dev/porting/building-adaptation-process.md
rename to en/device-dev/porting/transplant-chip-prepare-process.md
diff --git a/en/device-dev/porting/transplant-chip-prepare.md b/en/device-dev/porting/transplant-chip-prepare.md
new file mode 100644
index 0000000000000000000000000000000000000000..f981ad0f6d0e48e56db1e5673c30b86ee3e5808f
--- /dev/null
+++ b/en/device-dev/porting/transplant-chip-prepare.md
@@ -0,0 +1,7 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..38a8e78dc15a0880b33aa775c6b13056f4aecc7c
--- /dev/null
+++ b/en/device-dev/porting/transplant-minichip.md
@@ -0,0 +1,11 @@
+# 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-des.md b/en/device-dev/porting/transplant-smallchip-drive-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..8608a1fff83b61f76c81b9642f79e87d069d7c55
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-drive-des.md
@@ -0,0 +1,11 @@
+# Overview
+
+Drivers can be classified as platform drivers or device drivers. The platform drivers are generally in the SoC, such as the GPIO, I2C, and SPI drivers. The device drivers are typically ouside of the SoC, such as the LCD, TP, and WLAN drivers.
+
+**Figure 1** OpenHarmony driver classification
+
+
+
+
+The HDF driver is designed to be used across OSs. The HDF driver framework provides strong support for the driver to achieve this goal. During HDF driver development, you are advised to use only the APIs provided by the HDF driver framework. Otherwise, the driver cannot be used across OSs. Before driver development, familiarize yourself with the [HDF](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/hdf.md).
+
diff --git a/en/device-dev/porting/transplant-smallchip-drive-oom.md b/en/device-dev/porting/transplant-smallchip-drive-oom.md
new file mode 100644
index 0000000000000000000000000000000000000000..6ca81d10be22559cac932f867a8e3681c1e819a0
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-drive-oom.md
@@ -0,0 +1,390 @@
+# Device Driver Porting
+
+- [LCD Driver Porting](#section1574513454119)
+- [Touchscreen Driver Porting](#section20284142116422)
+- [WLAN Driver Porting](#section0969448164217)
+
+This section describes how to port device drivers.
+
+## LCD Driver Porting
+
+To port an LCD driver, write the driver, create an instance of the corresponding model in the driver, and complete the registration.
+
+The LCD drivers are stored in **//drivers/framework/model/display/driver/panel**.
+
+1. Create a panel driver.
+
+ Create an HDF driver and call the **RegisterPanel** method to register a model instance during driver initialization.
+
+ ```
+ int32_t LCDxxEntryInit(struct HdfDeviceObject *object)
+ {
+ struct PanelData *panel = CreateYourPanel();
+ // Register a 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 = LCDxxEntryInit,
+ };
+
+ HDF_INIT(g_xxxxDevEntry);
+ ```
+
+2. Configure and load the panel driver.
+
+ Modify the source code file **//vendor/vendor\_name/product\_name/config/device\_info/device\_info.hcs**. Add configurations for the device named **device\_lcd** for the display host.
+
+ > **CAUTION:**
+ >Make sure the value of **moduleName** is the same as that of **moduleName** in the panel driver.
+
+ ```
+ root {
+ ...
+ display :: host {
+ device_lcd :: device {
+ deviceN :: deviceNode {
+ policy = 0;
+ priority = 100;
+ preload = 2;
+ moduleName = "LCD_XXXX";
+ }
+ }
+ }
+ }
+ ```
+
+
+## Touchscreen Driver Porting
+
+This section describes how to port a touchscreen driver. The touchscreen drivers are stored in the source code directory **//drivers/framework/model/input/driver/touchscreen**. To port a touchscreen driver, register a **ChipDevice** model instance with the system.
+
+For details about how to develop a touchscreen driver, see [Touchscreen Development Guidelines](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/touchscreen.md).
+
+1. Create a touchscreen driver.
+
+ Create the **touch\_ic\_name.c** file in the **touchscreen** directory. Write the following content:
+
+ ```
+ #include "hdf_touch.h"
+
+ static int32_t HdfXXXXChipInit(struct HdfDeviceObject *device)
+ {
+ ChipDevice *tpImpl = CreateXXXXTpImpl();
+ if(RegisterChipDevice(tpImpl) != HDF_SUCCESS) {// Register the ChipDevice model instance.
+ ReleaseXXXXTpImpl(tpImpl);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+ }
+
+ struct HdfDriverEntry g_touchXXXXChipEntry = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_TOUCH_XXXX", // Make sure the value is the same as that in the subsequent configuration.
+ .Init = HdfXXXXChipInit,
+ };
+
+ HDF_INIT(g_touchXXXXChipEntry);
+ ```
+
+ The following methods need to be implemented in **ChipDevice**:
+
+
+
Method
+
+
Description
+
+
+
+
int32_t (*Init)(ChipDevice *device)
+
+
Initializes the device.
+
+
+
int32_t (*Detect)(ChipDevice *device)
+
+
Detects the device.
+
+
+
int32_t (*Suspend)(ChipDevice *device)
+
+
Places the device in sleep mode.
+
+
+
int32_t (*Resume)(ChipDevice *device)
+
+
Wakes up the device.
+
+
+
int32_t (*DataHandle)(ChipDevice *device)
+
+
Reads data from the device and writes touch point data to device > driver > frameData.
+
+
+
int32_t (*UpdateFirmware)(ChipDevice *device)
+
+
Updates the firmware.
+
+
+
+
+
+2. Configure the product and load the driver.
+
+ All device information of the product is defined in the source code file **//vendor/vendor\_name/product\_name/config/device\_info/device\_info.hcs**. Modify the file and add configurations to the **device** named **device\_touch\_chip** in the **host** of the **input** command.
+
+ > **NOTE:**
+ >Make sure the value of **moduleName** is the same as that of **moduleName** in the touchscreen driver.
+
+ ```
+ deviceN :: deviceNode {
+ policy = 0;
+ priority = 130;
+ preload = 0;
+ permission = 0660;
+ moduleName = "HDF_TOUCH_XXXX";
+ deviceMatchAttr = "touch_XXXX_configs";
+ }
+ ```
+
+
+## WLAN Driver Porting
+
+The WLAN driver is divided into two parts. One of the parts manages WLAN devices, and the other part manages WLAN traffic.
+
+**Figure 1** OpenHarmony WLAN driver architecture
+
+
+
+
+As shown in [Figure 1](#fig155920160203), the left part manages Wi-Fi devices, and the right part manages WLAN traffic. The HDF WLAN framework abstracts these two parts. The porting process of the driver can be considered as the implementation of the APIs required by the two parts. These APIs are described as follows:
+
+
+
Factory of the ChipDriver, which is used to support multiple WLAN ports of a chip.
+
+
+
HdfChipDriver
+
+
drivers\framework\include\wifi\wifi_module.h
+
+
Manages a specific WLAN port.
+
+
+
NetDeviceInterFace
+
+
drivers\framework\include\wifi\net_device.h
+
+
Communicates with the protocol stack, such as sending data and setting the status of network ports.
+
+
+
+
+
+> **NOTE:**
+>For details about the API development, see [WLAN Development Guidelines](https://gitee.com/openharmony/docs/blob/master/en/device-dev/driver/wlan.md).
+
+The porting procedure is as follows:
+
+1. Create a WLAN chip driver.
+
+ Create the **hdf\_wlan\_chip\_name.c** file in **/device/vendor\_name/peripheral/wifi/chip\_name/**. The sample code is as follows:
+
+ ```
+ static int32_t HdfWlanHisiChipDriverInit(struct HdfDeviceObject *device) {
+ static struct HdfChipDriverFactory factory = CreateChipDriverFactory(); // Implement the method.
+ struct HdfChipDriverManager *driverMgr = HdfWlanGetChipDriverMgr();
+ if (driverMgr->RegChipDriver(&factory) != HDF_SUCCESS) {// Register the driver factory.
+ 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" // Make sure the name is the same as the configured one.
+ };
+
+ HDF_INIT(g_hdfXXXChipEntry);
+ ```
+
+ In the **CreateChipDriverFactory** method, create an object of the **HdfChipDriverFactory** type. This object provides the following methods:
+
+
+
Creates an HdfChipDriver. In the input parameters, device indicates the device information, and ifIndex indicates the sequence number of this interface in the chip.
Obtains the maximum number of interfaces supported by the current chip.
+
+
+
+
+
+ The **Build** method creates an **HdfChipDriver** object that manages the specified network interface. This object needs to provide the following methods:
+
+
+
Provides the interface set required for supporting the STA mode.
+
+
+
struct HdfMac80211APOps *apOps
+
+
Provides the interface set required for supporting the AP mode.
+
+
+
+
+
+2. Compile a configuration file to describe the chips supported by the driver.
+
+ Create a chip configuration file in the product configuration directory and save it to the source code path **//vendor/vendor\_name/product\_name/config/wifi/wlan\_chip\_chip\_name.hcs**.
+
+ The following is the file template:
+
+ ```
+ root {
+ wlan_config {
+ chip_name :& chipList {
+ chip_name :: chipInst {
+ match_attr = "hdf_wlan_chips_chip_name"; /* Indicates the configuration matching attribute, which is used to provide the configuration root of the driver.*/
+ driverName = "driverName"; /* Indicates the driver name, which must be the same as that of driverName in HdfChipDriverFactory.*/
+ sdio {
+ vendorId = 0xXXXX; /* your vendor id */
+ deviceId = [0xXXXX]; /*your supported devices */
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ > **NOTE:**
+ >Replace the values of **vendor\_name**, **product\_name**, and **chip\_name** in the path and file with the actual names.
+ >Set **vendorId** and **deviceId** to the actual vendor ID and chip ID, respectively.
+
+3. Compile the configuration file and load the driver.
+
+ All device information of the product is defined in the source code file **//vendor/vendor\_name/product\_name/config/device\_info/device\_info.hcs**. Modify the file and add configurations to the **device** named **device\_wlan\_chips** in the **host** of the **network** command. The sample code is as follows:
+
+ ```
+ deviceN :: deviceNode {
+ policy = 0;
+ preload = 2;
+ moduleName = "HDF_WLAN_CHIPS";
+ deviceMatchAttr = "hdf_wlan_chips_chip_name";
+ serviceName = "driverName";
+ }
+ ```
+
+ > **NOTE:**
+ >Make sure the value of **moduleName** is the same as that of **moduleName** in the WLAN driver.
+
+4. Modify the **Kconfig** file to make the ported WLAN driver appear in the kernel configuration.
+
+ Add configurations to **device/vendor\_name/drivers/Kconfig**. The sample code is as follows:
+
+ ```
+ config DRIVERS_HDF_WIFI_chip_name
+ bool "Enable chip_name Host driver"
+ default n
+ depends on DRIVERS_HDF_WLAN help
+ Answer Y to enable chip_name Host driver.
+ ```
+
+ > **NOTE:**
+ >Replace **chip\_name** with the actual chip name.
+
+5. Modify the build script to enable the driver to participate in the kernel build.
+
+ Add the following content to the end of the source code file **//device/vendor\_name/drivers/lite.mk**:
+
+ ```
+ ifeq ($(LOSCFG_DRIVERS_HDF_WIFI_chip_name), y)
+ # After the build is complete, an object named hdf_wlan_chipdriver_chip_name needs to be linked. You are advised to use this name to prevent conflicts.
+ LITEOS_BASELIB += -lhdf_wlan_chipdriver_chip_name
+ # Add the build directory gpio.
+ LIB_SUBDIRS += ../peripheral/wifi/chip_name
+ endif
+ ```
+
+ > **NOTE:**
+ >Replace **chip\_name** with the actual chip name.
+
+
diff --git a/en/device-dev/porting/transplant-smallchip-drive-plat.md b/en/device-dev/porting/transplant-smallchip-drive-plat.md
new file mode 100644
index 0000000000000000000000000000000000000000..e09e0856c25e83d8342db5d0acf1cfc44662e469
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-drive-plat.md
@@ -0,0 +1,165 @@
+# Platform Driver Porting
+
+Create a platform driver in the source code directory **//device/vendor\_name/soc\_name/drivers**. If there is no repository for the vendor of your SoC, contact [sig-devboard](https://gitee.com/openharmony/community/blob/master/sig/sig-devboard/sig_devboard.md) to create one.
+
+The recommended directory structure is as follows:
+
+```
+device
+├── vendor_name
+│ ├── drivers
+│ │ │ ├── common
+│ │ │ ├── Kconfig # Entry of the vendor driver kernel menu
+│ │ │ └── lite.mk # Build entry
+│ ├── soc_name
+│ │ ├── drivers
+│ │ │ ├── dmac
+│ │ │ ├── gpio
+│ │ │ ├── i2c
+│ │ │ ├── LICENSE
+│ │ │ ├── mipi_dsi
+│ │ │ ├── mmc
+│ │ │ ├── pwm
+│ │ │ ├── README.md # docs Add documentation information as needed.
+│ │ │ ├── README_zh.md
+│ │ │ ├── rtc
+│ │ │ ├── spi
+│ │ │ ├── uart
+│ │ │ └── watchdog
+│ ├── board_name
+```
+
+The HDF creates driver models for all platform drivers. The main task of porting platform drivers is to inject instances into the models. You can find the definitions of these models in the source code directory **//drivers/framework/support/platform/include**.
+
+This section uses the GPIO as an example to describe how to port the platform driver. The porting procedure is as follows:
+
+1. Creating a GPIO driver.
+
+ Create the **soc\_name\_gpio.c** file in the source code directory **//device/vendor\_name/soc\_name/drivers/gpio**. The sample code is as follows:
+
+ ```
+ #include "gpio_core.h"
+
+ // Define the GPIO structure if necessary.
+ struct SocNameGpioCntlr {
+ struct GpioCntlr cntlr; // Structure required by the HDF GPIO driver framework.
+ int myData; // The following information is required by the current driver.
+ };
+
+ // The Bind method is mainly used to release services in the HDF driver. As this method is not needed here, simply return a success message.
+ static int32_t GpioBind(struct HdfDeviceObject *device)
+ {
+ (void)device;
+ return HDF_SUCCESS;
+ }
+
+ // Entry for initializing the driver when the Init method is used. You need to register the model instance in the Init method.
+ static int32_t GpioInit(struct HdfDeviceObject *device)
+ {
+ SocNameGpioCntlr *impl = CreateGpio(); // Implement the CreateGpio method.
+ ret = GpioCntlrAdd(&impl->cntlr); // Register a GPIO model instance.
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: err add controller:%d", __func__, ret);
+ return ret;
+ }
+ return HDF_SUCCESS;
+ }
+
+ // The Release method is called when the driver is uninstalled to reclaim resources.
+ static void GpioRelease(struct HdfDeviceObject *device)
+ {
+ // The GpioCntlrFromDevice method obtains the model instance registered in the init method from the abstract device object.
+ struct GpioCntlr *cntlr = GpioCntlrFromDevice(device);
+ // Destroy allocations.
+ }
+
+ struct HdfDriverEntry g_gpioDriverEntry = {
+ .moduleVersion = 1,
+ .Bind = GpioBind,
+ .Init = GpioInit,
+ .Release = GpioRelease,
+ .moduleName = "SOC_NAME_gpio_driver", // Name to be used in the configuration file to load the driver.
+ };
+ HDF_INIT(g_gpioDriverEntry); // Register a GPIO driver entry.
+ ```
+
+2. Create a build entry for the vendor driver.
+
+ As described above, **device/vendor\_name/drivers/lite.mk** is the entry for building vendor drivers. We need to start from this entry to build.
+
+ ```
+ # File: device/vendor_name/drivers/lite.mk
+
+ SOC_VENDOR_NAME := $(subst $/",,$(LOSCFG_DEVICE_COMPANY))
+ SOC_NAME := $(subst $/",,$(LOSCFG_PLATFORM))
+ BOARD_NAME := $(subst $/",,$(LOSCFG_PRODUCT_NAME))
+
+ # Specify the SoC for building.
+ LIB_SUBDIRS += $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/
+ ```
+
+3. Create a build Entry for the SoC driver.
+
+ ```
+ # File: device/vendor_name/soc_name/drivers/lite.mk
+
+ SOC_DRIVER_ROOT := $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/
+
+ # Check whether the kernel compilation switch of the GPIO is enabled.
+ ifeq ($(LOSCFG_DRIVERS_HDF_PLATFORM_GPIO), y)
+ # After the construction is complete, an object named hdf_gpio needs to be linked.
+ LITEOS_BASELIB += -lhdf_gpio
+ # Add the build directory gpio.
+ LIB_SUBDIRS += $(SOC_DRIVER_ROOT)/gpio
+ endif
+
+ # Add other drivers here.
+ ```
+
+4. Create a build entry for the GPIO driver.
+
+ ```
+ include $(LITEOSTOPDIR)/config.mk
+ include $(LITEOSTOPDIR)/../../drivers/adapter/khdf/liteos/lite.mk
+
+ # Specify the name of the output object. Ensure that the name is the same as LITEOS_BASELIB in the SoC driver build entry.
+ MODULE_NAME := hdf_gpio
+
+ # Add the INCLUDE of the HDF framework.
+ LOCAL_CFLAGS += $(HDF_INCLUDE)
+
+ # Specify the file to be compiled.
+ LOCAL_SRCS += soc_name_gpio.c
+
+ # Build parameters
+ LOCAL_CFLAGS += -fstack-protector-strong -Wextra -Wall -Werror -fsigned-char -fno-strict-aliasing -fno-common
+
+ include $(HDF_DRIVER)
+ ```
+
+5. Configure the product loading driver.
+
+ All device information of the product is defined in the source code file **//vendor/vendor\_name/product\_name/config/device\_info/device\_info.hcs**.
+
+ Add the platform driver to the host of the platform.
+
+ > **NOTE:**
+ >The value of **moduleName** must be the same as that defined in the driver.
+
+ ```
+ root {
+ ...
+ platform :: host {
+ device_gpio :: device {
+ device0 :: deviceNode {
+ policy = 0;
+ priority = 10;
+ permission = 0644;
+ moduleName = "SOC_NAME_gpio_driver";
+ }
+ }
+ }
+ }
+ ```
+
+
diff --git a/en/device-dev/porting/transplant-smallchip-drive.md b/en/device-dev/porting/transplant-smallchip-drive.md
new file mode 100644
index 0000000000000000000000000000000000000000..a79db8073393aeffdbaf19445f95dee3cefb9218
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-drive.md
@@ -0,0 +1,9 @@
+# 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-a.md b/en/device-dev/porting/transplant-smallchip-kernel-a.md
new file mode 100644
index 0000000000000000000000000000000000000000..f64a0e832b18161a3cfd6339962f21b7776f45a8
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-kernel-a.md
@@ -0,0 +1,263 @@
+# LiteOS Cortex-A
+
+- [Overview](#section14876256185510)
+ - [Porting Scenario](#section1986014410569)
+ - [Directory Specifications](#section10916181716564)
+
+- [Adaptation Process](#section814974018565)
+ - [Programming Example](#section10854481825)
+
+- [Verification](#section646410453212)
+
+## Overview
+
+### Porting Scenario
+
+LiteOS Cortex-A supports the ARMv7-a instruction set architecture. If you are porting the kernel to a chipset that uses ARMv7-a, you can directly perform basic adaptation. Otherwise, you need to add support for the architecture used by the chipset. This process is complex and not covered in this document.
+
+### Directory Specifications
+
+For details about the LiteOS Cortex-A directory specifications, see [LiteOS Cortex-A Overview](https://gitee.com/openharmony/kernel_liteos_a).
+
+## Adaptation Process
+
+LiteOS Cortex-A provides the system initialization process and custom configuration options required for system running. During porting, pay attention to the functions related to hardware configuration in the initialization process.
+
+The LiteOS Cortex-A initialization process consists of five steps:
+
+1. Add the **target\_config.h** file and compile the macros **DDR\_MEM\_ADDR** and **DDR\_MEM\_SIZE**, which indicate the start address and length of the board memory, respectively. The prelinker script **board.ld.S** creates the linker script **board.ld** based on the two macros.
+2. The kernel creates a kernel image based on the linker script **board.ld**.
+3. Operations such as initialization of the interrupt vector table and MMU page table are performed in the assembly files: **reset\_vector\_up.S** and **reset\_vector\_mp.S**, from which a single-core CPU and a multi-core CPU start, respectively.
+4. The assembly code in **reset\_vector.S** jumps to the **main** function of the C programming language to initialize the hardware clock, software timer, memory, and tasks. This process depends on the feature macro configuration in **target\_config.h** . The **SystemInit** task to be implemented in the board code is then created, and **OsSchedStart\(\)** is enabled for task scheduling.
+5. The **DeviceManagerStart** function is called to initialize the HDF driver. This process is implemented by calling the driver configuration file **hdf.hcs** and driver source code in the board code.
+
+Below is the overall initialization process.
+
+**Figure 1** Overall initialization process
+
+
+
+
+As can be seen from preceding figure, kernel basic adaptation involves the following parts:
+
+- Adding the **target\_config.h** file, which contains board hardware parameters and feature parameters described in the following table:
+
+ **Table 1** Parameters in the target\_config.h file
+
+
+
Parameter
+
+
Description
+
+
+
+
OS_SYS_CLOCK
+
+
System cycle frequency
+
+
+
DDR_MEM_ADDR
+
+
Start address of the system memory
+
+
+
DDR_MEM_SIZE
+
+
Size of the system memory
+
+
+
PERIPH_PMM_BASE
+
+
Base address of the peripheral register
+
+
+
PERIPH_PMM_SIZE
+
+
Size of the peripheral register
+
+
+
OS_HWI_MIN
+
+
Minimum number of system interrupts
+
+
+
OS_HWI_MAX
+
+
Maximum number of system interrupts
+
+
+
NUM_HAL_INTERRUPT_UART0
+
+
UART0 interrupt ID
+
+
+
UART0_REG_BASE
+
+
UART0 register base address
+
+
+
GIC_BASE_ADDR
+
+
Base address of the GIC interrupt register
+
+
+
GICD_OFFSET
+
+
Offset address of the GICD relative to the GIC base address
+
+
+
GICC_OFFSET
+
+
Offset address of the GICC relative to the GIC base address
+
+
+
+
+
+- Implementing the **SystemInit** function to initialize services in the user space. Figure 2 shows a typical initialization scenario.
+
+ **Figure 1** Service startup process
+
+
+ 
+
+- Implementing the **main** function for basic kernel initialization and initialization of services in the board kernel space. Figure 3 shows the initialization process, where the kernel startup framework takes the lead in the initialization process. The light blue part in the figure indicates the phase in which external modules can be registered and started in the startup framework.
+
+ > **CAUTION:**
+ >Modules at the same layer cannot depend on each other.
+
+ **Figure 2** Kernel startup framework
+ 
+
+ **Table 2** Startup framework layers
+
+
+
Level
+
+
Description
+
+
+
+
LOS_INIT_LEVEL_EARLIEST
+
+
Earliest initialization.
+
This layer does not depend on the architecture. The board and subsequent modules, such as the Trace module, will initialize the software-only modules on which they depend.
+
+
+
LOS_INIT_LEVEL_ARCH_EARLY
+
+
Early initialization of the architecture.
+
This layer depends on the architecture. Subsequent modules will initialize the modules on which they depend. It is recommended that functions not required for startup be placed at the LOS_INIT_LEVEL_ARCH layer.
+
+
+
LOS_INIT_LEVEL_PLATFORM_EARLY
+
+
Early initialization of the platform.
+
This layer depends on the board platform and drivers. Subsequent modules will initialize the modules on which they depend. It is recommended that functions required for startup be placed at the LOS_INIT_LEVEL_PLATFORM layer.
+
Example: UART module
+
+
+
LOS_INIT_LEVEL_KMOD_PREVM
+
+
Kernel module initialization before memory initialization.
+
This layer involves initialization of the modules that need to be enabled before memory initialization.
+
+
+
LOS_INIT_LEVEL_VM_COMPLETE
+
+
Initialization after the basic memory is ready.
+
This layer involves initialization of the modules that need to be enabled and do not depend on the inter-process communication mechanism and system processes.
+
Example: shared memory function
+
+
+
LOS_INIT_LEVEL_ARCH
+
+
Late initialization of the architecture.
+
This layer depends on the architecture extension function. Subsequent modules will initialize the modules on which they depend.
+
+
+
LOS_INIT_LEVEL_PLATFORM
+
+
Late initialization of the platform.
+
This layer depends on the board platform and drivers. Subsequent modules will 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.
+
This layer is used to 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.
+
This layer is used to initialize the extended modules that can be detached from the kernel.
+
Example: system call initialization, ProcFS initialization, Futex initialization, HiLog initialization, HiEvent initialization, and LiteIPC initialization
+
+
+
LOS_INIT_LEVEL_KMOD_TASK
+
+
Kernel task creation
+
This layer can be used to create kernel tasks (kernel thread and software timer tasks).
+
Example: creation of the resident resource reclaiming task, SystemInit task, and CPU usage statistics task.
+
+
+
+
+
+ Adaptation for board porting. Focus on layers between **LOS\_INIT\_LEVEL\_ARCH** and **LOS\_INIT\_LEVEL\_KMOD\_TASK** and try to divide the initialization process into as many phases as possible for refined registration.
+
+ > **NOTE:**
+ >Modules at the same layer 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.
+
+
+### Programming Example
+
+In the board SDK file:
+
+```
+/* 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 layer 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 preceding information displayed during the system startup, the kernel calls the initialization function of the registered module during the startup to initialize the module.
+
+The system enters the kernel-space shell and the task commands can be properly executed.
+
+```
+OHOS # help
+*******************shell commands:*************************
+
+arp cat cd chgrp chmod chown cp cpup
+date dhclient dmesg dns format free help hwi
+ifconfig ipdebug kill log ls lsfd memcheck mkdir
+mount netstat oom partinfo partition ping ping6 pmm
+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/transplant-smallchip-kernel-linux.md
new file mode 100644
index 0000000000000000000000000000000000000000..3296d239e64311a2712ab66746be2f2e86c0fed2
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-kernel-linux.md
@@ -0,0 +1,125 @@
+# Linux Kernel
+
+- [Overview](#section6282121355111)
+ - [Basic Information](#section19589322515)
+ - [Bootloader](#section19062510518)
+
+- [Adaptation, Building, Burning, and Startup](#section11112101695215)
+- [Verification](#section17318153325311)
+
+## Overview
+
+Linux kernel porting involves basic kernel compilation, building, and verification after third-party chipset patches are installed based on the Linux kernel baseline.
+
+### Basic Information
+
+The current Linux kernel baseline evolves based on the Linux LTS version 4.19 and incorporates the CVE and bugfix patches. For details, see the [code library](https://gitee.com/openharmony/kernel_linux). The code path for the **repo** project is **kernel/linux-4.19**.
+
+### Bootloader
+
+You can use the Bootloader provided by the chipset vendor or open-source U-Boot to load the kernel image. For example, you can use [U-Boot](https://gitee.com/openharmony/device_hisilicon_third_party_uboot) for the Hi3516D V300 development board.
+
+## Adaptation, Building, Burning, and Startup
+
+1. Prepare the kernel configuration files, especially the chipset-related configuration files.
+
+ Source code directory of the configuration files: **kernel/linux/config/**
+
+ Create a **<_YOUR\_CHIP_\>\_small\_defconfig** file, such as **hi3516dv300\_small\_defconfig**, in the **linux-4.19/arch/arm/configs/** directory. The configuration file can be created by combining the general-purpose **small\_common\_defconfig** file and chipset-specific configurations.
+
+2. Prepare the chipset patches.
+
+ Source code directory of the patch files: **kernel/linux/patches/linux-4.19**
+
+ Create a **<_YOUR\_CHIP_\>\_patch** directory by referring to the existing patch directory **hi3516dv300\_small\_patch**, and place the related chipset patches, such as **hdf.patch** \(recommended\), in this directory.
+
+3. Build the code.
+
+ In the project directory **kernel/linux/patches/**, after version-level build commands are passed to the **kernel\_module\_build.sh** and **kernel.mk** files, adapt the **patch** and **defconfig** configuration file paths, compiler, chipset architecture, and kernel image format.
+
+ Adjust the patches based on build error logs. Typical error scenarios are as follows:
+
+ \(1\) A conflict occurs in installing a patch. In this case, context adaptation is required.
+
+ \(2\) The build fails due to kernel version mismatch. In this case, kernel adaptation is required, including function implementation adjustment.
+
+ > **CAUTION:**
+ >- As in the **kernel.mk** file, patches are applied after the code environment of **kernel/linux-4.19** is copied during compilation and building of the OpenHarmony project. Retain the original code environment of **kernel/linux-4.19** before running the OpenHarmony version-level build command.
+ >- You can modify the patches in **out/<\*\*\*\>/kernel/linux-4.19**, to which the code environment is copied.
+
+4. Burn images and start the development board.
+
+ The burning mode varies according to the development board of the chipset. Pay attention to the size of each burnt image and the configuration of the boot parameters. Below is the U-Boot parameter settings of Hi3516D V300:
+
+ ```
+ setenv bootargs 'mem=128M console=ttyAMA0,115200 root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait blkdevparts=mmcblk0:1M(boot),9M(kernel),50M(rootfs),50M(userfs)'
+ ```
+
+
+## Verification
+
+Debug the **init** process, start shell, and run a simple program in the user space to check whether the kernel porting is successful. Below is the OS image structure of the OpenHarmony [small system](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des-0000001105598722) and the Linux user-space program startup process.
+
+**Figure 1** OS image structure and user-space program startup process based on the Linux kernel
+
+
+
+
+Based on the preceding process, the recommended verification procedure is as follows:
+
+1. Create a root file system image.
+
+ Create a root file system image **rootfs.img** by following instructions in [Adding a Chipset Solution and a Product Solution](https://device.harmonyos.com/en/docs/develop/subsystems/oem_subsys_build_guide-0000001060378721). As shown in the preceding figure, the startup process is closely related to the product configuration. You need to complete the following configuration when creating **rootfs.img**:
+
+ - Component configuration
+
+ In the product component configuration file **_vendor_/\{_company_\}/\{_product_\}/config.json**, configure the **init\_lite** component of the startup subsystem and the **linux\_4\_1\_9** component of the kernel subsystem.
+
+ - System service configuration
+
+ Modify the system service configuration file **_vendor_/\{_company_\}/\{_product_\}/init\_configs/init\_xxx.cfg** to start the shell service.
+
+ - File system configuration
+
+ In the file system configuration file **_vendor_/\{_company_\}/\{_product_\}/fs.yml**, create the **/bin/sh -\> mksh** and **/lib/ld-musl-arm.so.1 -\> libc.so** soft links. These two files are the shell executable program and the c library on which the executable program depends, respectively.
+
+ - Startup configuration
+
+ 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.
+
+ Burn **rootfs.img** and debug the init process and shell. The burning tools and processes vary according to the development board. Follow the instructions provided by the chipset solution vendor. Before burning **rootfs.img**, ensure that the bootloader and Linux kernel are started properly. When **rootfs.img** is properly mounted by the kernel, the **/bin/init** program is executed, indicating the start of the user space.
+
+ The init process calls the **/etc/init.d/rcS** script. The **rcS** script runs the first command **/bin/mount -a** to load the **fstab** file. After the commands in this file are executed, **rcS** calls the **S_xxx_** scripts in sequence to create and scan for device nodes and configure file permissions.
+
+ Then the init process reads the **init.cfg** system service configuration file and starts the shell as configured. If the preceding process is executed properly, the system enters the shell.
+
+ If the init startup log contains the version number, the init program is started properly:
+
+ **Figure 2** Log indicating that the init process is started properly
+
+
+ 
+
+ After entering the shell, run the **ls** command. The following figure shows the information printed over the serial port.
+
+ **Figure 3** Information printed after the ls command is executed in the shell
+
+
+ 
+
+3. Configure the NFS.
+
+ After the init process and shell are started, run the following command in the root directory to enable the NFS service. In this example, the server IP address is 192.168.1.22 and the client IP address is 192.168.1.4.
+
+ ```
+ ifconfig eth0 192.168.1.4 netmask 255.255.255.0
+ mkdir -p /storgage/nfs
+ mount -t nfs -o nolock,addr=192.168.1.22 192.168.1.22:/nfs /storage/nfs
+ ```
+
+
diff --git a/en/device-dev/porting/transplant-smallchip-kernel.md b/en/device-dev/porting/transplant-smallchip-kernel.md
new file mode 100644
index 0000000000000000000000000000000000000000..cd252f8b951795654a29ecdc06cc83f1a9342c5b
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-kernel.md
@@ -0,0 +1,7 @@
+# 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-building.md b/en/device-dev/porting/transplant-smallchip-prepare-building.md
new file mode 100644
index 0000000000000000000000000000000000000000..b386a049feca70e65d61c8b234b6c4988b426b60
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-prepare-building.md
@@ -0,0 +1,142 @@
+# Compilation and Building
+
+- [Compilation Environment Setup](#section3336103410314)
+- [Introduction to the Compilation and Building Subsystem](#section354343816319)
+- [Adding a Chipset Solution](#section18612153175011)
+
+## Compilation Environment Setup
+
+Set up the basic environment by following instructions in [Ubuntu Build Environment](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_environment_lin-0000001105407498). Both the user space and LiteOS Cortex-A kernel space are compiled using the LLVM compiler. If you choose to port the Linux kernel, run the following command to install the gcc-arm-linux-gnueabi cross compiler for compiling the Linux kernel-space image:
+
+```
+sudo apt-get install gcc-arm-linux-gnueabi
+```
+
+## Introduction to the Compilation and Building Subsystem
+
+To learn more about the compilation and building subsystem, including the compilation and building process, compilation scripts, and building chipset source code or single components, see [Compilation and Building](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/compilation-and-building.md).
+
+## Adding a Chipset Solution
+
+After learning the compilation framework and setting up the compilation environment, perform the following steps to create a chipset solution:
+
+1. Create a category.
+
+ The directory structure is as follows: device/\{_chipset solution vendor_\}/\{_development board_\}. For example, if you are using the hispark\_taurus development board from HiSilicon, create the following directory in the root directory of the code:
+
+ ```
+ mkdir -p device/hisilicon/hispark_taurus
+ ```
+
+ The chipset solution directory tree is as follows:
+
+ ```
+ device
+ └── company # Chipset solution vendor
+ └── board # Name of the development board
+ ├── BUILD.gn # Build script
+ ├── hals # Southbound APIs for OS adaptation
+ ├── linux # Linux kernel version (optional)
+ │ └── config.gni # Build options for the Linux version
+ └── liteos_a # LiteOS kernel version (optional)
+ └── config.gni # Build options for the LiteOS Cortex-A version
+ ```
+
+ For example, if you are porting the Linux kernel to the hispark\_taurus development board, the directory tree is as follows:
+
+ ```
+ device
+ └── hisilicon
+ └── hispark_tautus
+ ├── BUILD.gn
+ ├── hals
+ ├── ......
+ └── linux
+ └── config.gni
+ ```
+
+ After the directory tree is created, store the source code related to the development board in the **hispark\_taurus** directory.
+
+2. Configure the build options of the development board.
+
+ You can configure the build options in the **config.gni** file described in [1](#li20894101862). The compilation and building framework will then compile all OS components in the user space based on your configuration. The **config.gni** file contains the following key fields:
+
+ ```
+ kernel_type: kernel used by the development board, for example, liteos_a, liteos_m, or linux.
+ kernel_version: kernel version used by the development board, for example, 4.19.
+ board_cpu: CPU of the development board, for example, cortex-a7 or riscv32.
+ board_arch: chipset architecture of the development board, for example, armv7-a or rv32imac.
+ board_toolchain: name of the customized compiler used by the development board, for example, gcc-arm-none-eabi. If this field is not specified, ohos-clang will be used by default.
+ board_toolchain_prefix: prefix of the compiler, for example, gcc-arm-none-eabi.
+ board_toolchain_type: compiler type, for example, gcc or clang. Currently, only GCC and clang are supported.
+ board_cflags: build options of the .c file configured for the development board.
+ board_cxx_flags: build options of the .cpp file configured for the development board.
+ board_ld_flags: link options configured for the development board.
+ ```
+
+ For HiSilicon's hispark\_taurus development board, the content in **device/hisilicon/hispark\_taurus/config.gni** is as follows:
+
+ ```
+ # Board CPU type, e.g. "cortex-a7", "riscv32".
+ board_cpu = "cortex-a7"
+
+ # Name of the compiler that is used for system building
+ # E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang, riscv32-unknown-elf.
+ # Note: The "ohos-clang" toolchain is used by default. You can also customize the toolchain.
+ board_toolchain = "mips-linux-gnu-gcc"
+
+ # Path where the toolchain is installed, which can be left blank if the installation path has been added to ~/.bashrc.
+ board_toolchain_path =
+ rebase_path("//prebuilts/gcc/linux-x86/arm/arm-linux-ohoseabi-gcc/bin",
+ root_build_dir)
+
+ # Prefix of the toolchain
+ board_toolchain_prefix = "arm-linux-ohoseabi-"
+
+ # Type of the compiler, which can be gcc or clang
+ board_toolchain_type = "gcc"
+
+ # Building flags related to the board
+ board_cflags = [
+ ]
+ board_cxx_flags = [
+ ]
+ board_ld_flags = []
+
+ # Board related headfiles search path.
+ board_include_dirs = []
+ board_include_dirs += [ rebase_path(
+ "//prebuilts/gcc/linux-x86/arm/arm-linux-ohoseabi-gcc/target/usr/include",
+ root_build_dir) ]
+
+ # Board adapter dir for OHOS components.
+ board_adapter_dir = ""
+
+ # Sysroot path.
+ board_configed_sysroot = ""
+
+ # Board storage type, it used for file system generation.
+ storage_type = "emmc"
+ ```
+
+3. Edit the build script of the development board.
+
+ In the **BUILD.gn** file described in 1, build code related to the development board, such as code for the on-device driver, on-device interface adaptation \(media and graphics\), and SDK on the development board.
+
+ For example, edit the **device/hisilicon/hispark\_taurus/BUILD.gn** file as follows:
+
+ ```
+ # It is recommended that the group name be the same as the developer board name.
+ group("hispark_taurus") {
+ deps = [ "//kernel/linux/patches:linux_kernel" ] # Start kernel compilation.
+ deps += [
+ ...... # Other compilation units of the development board
+ ]
+ }
+ ```
+
+4. Start building and debugging.
+
+ In the directory of the development board, run the **hb set** and **hb build** commands to start building the chipset solution. The compilation framework starts the building with the **BUILD.gn** file in the directory as the entry.
+
+
diff --git a/en/device-dev/porting/transplant-smallchip-prepare-needs.md b/en/device-dev/porting/transplant-smallchip-prepare-needs.md
new file mode 100644
index 0000000000000000000000000000000000000000..685a2a7a8cd49654abc2326776f3b8f276372af2
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-prepare-needs.md
@@ -0,0 +1,98 @@
+# Before You Start
+
+This document provides guidance on how to port the Linux and LiteOS Cortex-A kernels on the OpenHarmony [small system](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des-0000001105598722) to a development board. It is intended for developers with experience in developing embedded systems. Before following instructions in this document, it is recommended that you familiarize yourself with [OpenHarmony](https://gitee.com/openharmony/docs/blob/master/en/OpenHarmony-Overview.md), including its technical architecture, directory structure, kernel subsystem, and driver subsystem. The following table lists the development boards that have been adapted to the small system.
+
+**Table 1** Development boards compatible with the OpenHarmony small system
+
+
+
Development Board
+
+
Kernel
+
+
Architecture
+
+
ROM
+
+
RAM
+
+
File System
+
+
Flash Type
+
+
+
+
hispark_taurus
+
+
LiteOS Cortex-A and Linux 4.19
+
+
Arm Cortex-A7
+
+
8 GB
+
+
1 GB
+
+
VFAT, EXT4
+
+
eMMC4.5
+
+
+
hispark_aries
+
+
LiteOS-A
+
+
Arm Cortex-A7
+
+
16 MB
+
+
512 MB
+
+
JFFS2
+
+
SPI NOR
+
+
+
+
+
+In addition to the aforementioned development boards, LiteOS Cortex-A and Linux 4.19 can be ported to development boards that meet the requirements described in the table below.
+
+**Table 2** Requirements for porting OpenHarmony small system kernels
+
+
+
Kernel
+
+
Supported Architecture
+
+
ROM
+
+
File System
+
+
Flash Type
+
+
+
+
LiteOS-A
+
+
ARMv7
+
+
> 2 MB
+
+
VFAT, JFFS2, YAFFS2
+
+
SPI NOR, NAND, eMMC
+
+
+
Linux 4.19
+
+
ARM, Arm64, MIPS, x86
+
+
> 5 MB
+
+
VFAT, JFFS2, YAFFS, EXT/2/3/4, NFS
+
+
NOR, NAND, eMMC
+
+
+
+
+
diff --git a/en/device-dev/porting/transplant-smallchip-prepare.md b/en/device-dev/porting/transplant-smallchip-prepare.md
new file mode 100644
index 0000000000000000000000000000000000000000..91c9cecaa0bb12598425d416c72a58c4b0f992c7
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip-prepare.md
@@ -0,0 +1,7 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..818a9af1211dce6f85ee8d5c584fa0de10dfe3ad
--- /dev/null
+++ b/en/device-dev/porting/transplant-smallchip.md
@@ -0,0 +1,9 @@
+# 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-cmake.md b/en/device-dev/porting/transplant-thirdparty-cmake.md
new file mode 100644
index 0000000000000000000000000000000000000000..b8a9f3590019de6a82cdfcb992452b0013077d22
--- /dev/null
+++ b/en/device-dev/porting/transplant-thirdparty-cmake.md
@@ -0,0 +1,435 @@
+# Porting a Library Built Using CMake
+
+- [Source Code Acquisition](#section1771132116245)
+- [Porting Guidelines](#section9737174410328)
+- [Cross-Compilation](#section38205577332)
+ - [Compilation Reference](#section1088111263418)
+ - [Cross-Compilation Settings](#section8168182883515)
+
+- [Library Test](#section6686144293611)
+- [Adding the Compiled double-conversion Library to the OpenHarmony Project](#section1651053153715)
+
+The following shows how to port the double-conversion library.
+
+## Source Code Acquisition
+
+Acquire the source code of double-conversion from [https://github.com/google/double-conversion](https://github.com/google/double-conversion). The following table lists the directory structure.
+
+**Table 1** Directory structure of the source code
+
+
+
Directory
+
+
Description
+
+
+
+
double-conversion/cmake/
+
+
Template used for building with CMake
+
+
+
double-conversion/double-conversion/
+
+
Directory of source files
+
+
+
double-conversion/msvc/
+
+
-
+
+
+
double-conversion/test/
+
+
Source files of the test cases
+
+
+
double-conversion/.gitignore
+
+
-
+
+
+
double-conversion/AUTHORS
+
+
-
+
+
+
double-conversion/BUILD
+
+
-
+
+
+
double-conversion/CMakeLists.txt
+
+
Top-level file used for building with CMake
+
+
+
double-conversion/COPYING
+
+
-
+
+
+
double-conversion/Changelog
+
+
-
+
+
+
double-conversion/LICENSE
+
+
-
+
+
+
double-conversion/Makefile
+
+
-
+
+
+
double-conversion/README.md
+
+
-
+
+
+
double-conversion/SConstruct
+
+
-
+
+
+
double-conversion/WORKSPACE
+
+
-
+
+
+
+
+
+## Porting Guidelines
+
+Cross-compile the double-conversion library by modifying the toolchain to generate executable files for the OpenHarmony platform and then add these files to the OpenHarmony project by invoking CMake via GN.
+
+## Cross-Compilation
+
+### Compilation Reference
+
+The [README.md](https://github.com/google/double-conversion/blob/master/README.md) file in the code repository details the procedures for compiling the double-conversion library using CMake as well as the testing methods. This document focuses on the building, compilation, and testing of the library. If you have any questions during library porting, refer to the **README.md** file. For porting of other third-party libraries that can be independently built with CMake, you can refer to the compilation guides provided by the libraries.
+
+### Cross-Compilation Settings
+
+The following steps show how to configure and modify the toolchains for cross-compiling the libraries built using CMake to compile executable files for the OpenHarmony platform.
+
+1. Configure the toolchains.
+
+ Add configuration of the clang toolchains to the top-level file **CMakeLists.txt** listed in [Table 1](#table824211132418).
+
+ ```
+ set(CMAKE_CROSSCOMPILING TRUE)
+ set(CMAKE_SYSTEM_NAME Generic)
+ set(CMAKE_CXX_COMPILER_ID Clang)
+ set(CMAKE_TOOLCHAIN_PREFIX llvm-)
+ # Specify the C compiler (ensure that the path of the toolchain has been added to the PATH environment variable) and its flags. To perform cross-compilation using clang, the --target flag must be specified.
+ set(CMAKE_C_COMPILER clang)
+ set(CMAKE_C_FLAGS "--target=arm-liteos -D__clang__ -march=armv7-a -w")
+ # Specify the C++ compiler (ensure that the path of the toolchain has been added to the PATH environment variable) and its flags. To perform cross-compilation, the --target flag must be specified.
+ set(CMAKE_CXX_COMPILER clang++)
+ set(CMAKE_CXX_FLAGS "--target=arm-liteos -D__clang__ -march=armv7-a -w")
+ # Specify the linker and its flags. --target and --sysroot must be specified. You can specify OHOS_ROOT_PATH via the suffix parameter of the cmake command.
+ set(MY_LINK_FLAGS "--target=arm-liteos --sysroot=${OHOS_SYSROOT_PATH}")
+ 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 ")
+ # Specify the path for searching chained libraries.
+ set(CMAKE_SYSROOT ${OHOS_SYSROOT_PATH})
+ ```
+
+2. Perform the compilation.
+
+ Run a Linux command to enter the directory \(listed in [Table 1](#table824211132418)\) for storing double-conversion source files and then run the following commands:
+
+ ```
+ mkdir build && cd build
+ cmake .. -DBUILD_TESTING=ON -DOHOS_SYSROOT_PATH="..."
+ make -j
+ ```
+
+ **OHOS\_SYSROOT\_PATH** specifies the absolute path where **sysroot** is located. Taking OpenHarmony for example, set **OHOS\_SYSROOT\_PATH** to the absolute path of **openHarmony/prebuilts/lite/sysroot**.
+
+3. View the result.
+
+ After step 2 is complete, a static library file and test cases are generated in the **build** directory.
+
+ **Table 2** Directory structure of compiled files
+
+
+
Directory
+
+
Description
+
+
+
+
double-conversion/build/libdouble-conversion.a
+
+
Static library file
+
+
+
double-conversion/build/test/
+
+
Test cases and CMake cache files
+
+
+
double-conversion/build/CMakeCache.txt
+
+
Cache files during CMake building
+
+
+
double-conversion/build/CMakeFiles/
+
+
-
+
+
+
double-conversion/build/cmake_install.cmake
+
+
-
+
+
+
double-conversion/build/CTestTestfile.cmake
+
+
-
+
+
+
double-conversion/build/DartConfiguration.tcl
+
+
-
+
+
+
double-conversion/build/generated/
+
+
-
+
+
+
double-conversion/build/Makefile
+
+
-
+
+
+
double-conversion/build/Testing/
+
+
-
+
+
+
+
+
+
+## Library Test
+
+1. Set up the OpenHarmony environment.
+
+ Using Hi3518EV300 as an example, compile the OpenHarmony image and burn it to the development board. For details, see [Developing the First Example Program Running on Hi3518](../quick-start/quickstart-lite-steps-board3518-running.md).
+
+ The following screen is displayed after a successful login to the OS.
+
+ **Figure 1** Successful startup of OpenHarmony
+ 
+
+2. Mount the **nfs** directory and put the executable file **cctest** into the **test** directory \(listed in [Table 2](#table1452412391911)\) to the **nfs** directory.
+3. Perform the test cases.
+
+ If the double-conversion library is not cross-compiled, you can execute the test cases by running the **make test** command and obtain the result via CMake. However, this command is not applicable to the library after cross-compilation. This way, you can perform the test cases by executing the generated test case files.
+
+ - After the **nfs** directory is successfully mounted, run the following command to list all items in the test cases:
+
+ ```
+ cd nfs
+ ./cctest --list
+ ```
+
+ Some items are as follows:
+
+ ```
+ test-bignum/Assign<
+ test-bignum/ShiftLeft<
+ test-bignum/AddUInt64<
+ test-bignum/AddBignum<
+ test-bignum/SubtractBignum<
+ test-bignum/MultiplyUInt32<
+ test-bignum/MultiplyUInt64<
+ test-bignum/MultiplyPowerOfTen<
+ test-bignum/DivideModuloIntBignum<
+ test-bignum/Compare<
+ test-bignum/PlusCompare<
+ test-bignum/Square<
+ test-bignum/AssignPowerUInt16<
+ test-bignum-dtoa/BignumDtoaVariousDoubles<
+ test-bignum-dtoa/BignumDtoaShortestVariousFloats<
+ test-bignum-dtoa/BignumDtoaGayShortest<
+ test-bignum-dtoa/BignumDtoaGayShortestSingle<
+ test-bignum-dtoa/BignumDtoaGayFixed<
+ test-bignum-dtoa/BignumDtoaGayPrecision<
+ test-conversions/DoubleToShortest<
+ test-conversions/DoubleToShortestSingle<
+ ...
+ ```
+
+ - Run the following command to test **test-bignum**:
+
+ ```
+ ./cctest test-bignum
+ ```
+
+ The test is passed if the following information is displayed:
+
+ ```
+ Ran 13 tests.
+ ```
+
+
+## Adding the Compiled double-conversion Library to the OpenHarmony Project
+
+1. Copy the double-conversion library to the OpenHarmony project.
+
+ Copy this library that can be cross-compiled to the **third\_party** directory of OpenHarmony. To avoid modifying the **BUILD.gn** file in the directory of the third-party library to be ported, add a directory to store adaptation files, including **BUILD.gn**, **build\_thirdparty.py**, and **config.gni**, for converting GN to CMake building.
+
+ **Table 3** Directory structure of the ported library
+
+
+
+
+2. Add the GN file to the CMake adaptation file.
+
+ - The following shows the implementation for building using the newly added **BUILD.gn** file. For other third-party libraries that can be independently compiled using CMake, you only need to change the target paths when porting them to OpenHarmony.
+
+ ```
+ import("config.gni")
+ group("double-conversion") {
+ if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
+ deps = [":make"]
+ }
+ }
+ if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
+ action("make") {
+ script = "//third_party/double-conversion/build_thirdparty.py"
+ outputs = ["$root_out_dir/log_dc.txt"]
+ exec_path = rebase_path(rebase_path("./build", ohos_third_party_dir))
+ command = "rm * .* -rf && $CMAKE_TOOLS_PATH/cmake .. $CMAKE_FLAG $CMAKE_TOOLCHAIN_FLAG && make -j"
+ args = [
+ "--path=$exec_path",
+ "--command=${command}"
+ ]
+ }
+ }
+ ```
+
+ - The newly added **config.gni** file is used to configure the library in the following example implementation. For other third-party libraries that can be independently compiled using CMake, you only need to change the configuration of **CMAKE\_FLAG** when porting them to OpenHarmony.
+
+ ```
+ #CMAKE_FLAG: config compile feature
+ CMAKE_FLAG = "-DBUILD_TESTING=ON -DCMAKE_CXX_STANDARD=11"
+
+ #toolchain: follow up-layer, depend on $ohos_build_compiler
+ if (ohos_build_compiler == "clang") {
+ CMAKE_TOOLCHAIN_FLAG = "-DOHOS_SYSROOT_PATH=${ohos_root_path}prebuilts/lite/sysroot/"
+ } else {
+ CMAKE_TOOLCHAIN_FLAG = ""
+ }
+
+ #CMake tools path,no need setting if this path already joined to $PATH.
+ CMAKE_TOOLS_PATH = "setting CMake tools path..."
+ ```
+
+ - The following shows the implementation of the newly added **build\_thirdparty.py** file. For other third-party libraries that can be independently compiled using CMake, you can port them to OpenHarmony without modifications.
+
+ ```
+ import os
+ import sys
+ from subprocess import Popen
+ import argparse
+ import shlex
+
+ def cmd_exec(command):
+ cmd = shlex.split(command)
+ proc = Popen(cmd)
+ proc.wait()
+ ret_code = proc.returncode
+ if ret_code != 0:
+ raise Exception("{} failed, return code is {}".format(cmd, ret_code))
+
+ def main():
+ parser = argparse.ArgumentParser()
+ parser.add_argument('--path', help='Build path.')
+ parser.add_argument('--command', help='Build command.')
+ parser.add_argument('--enable', help='enable python.', nargs='*')
+ args = parser.parse_args()
+
+ if args.enable:
+ if args.enable[0] == 'false':
+ return
+
+ if args.path:
+ curr_dir = os.getcwd()
+ os.chdir(args.path)
+ if args.command:
+ if '&&' in args.command:
+ command = args.command.split('&&')
+ for data in command:
+ cmd_exec(data)
+ else:
+ cmd_exec(args.command)
+ os.chdir(curr_dir)
+
+ if __name__ == '__main__':
+ sys.exit(main())
+ ```
+
+ - Add a configuration item in the configuration file to control compiling of the library. By default, library compilation is disabled.
+
+ For example, add the following configuration to the **//build/lite/ohos\_var.gni** file:
+
+ ```
+ declare_args() {
+ ohos_build_thirdparty_migrated_from_fuchisa = true
+ }
+ ```
+
+3. Build the library.
+
+ - Manual building
+
+ Execute the following command:
+
+ ```
+ hb build -T //third_party/double-conversion:double-conversion
+ ```
+
+ If the compilation is successful, a static library file and test cases will be generated in the [build](#li15717101715249) directory.
+
+
diff --git a/en/device-dev/porting/transplant-thirdparty-makefile.md b/en/device-dev/porting/transplant-thirdparty-makefile.md
new file mode 100644
index 0000000000000000000000000000000000000000..a6d80725a238b519b3b72950255ccfb1ed9050df
--- /dev/null
+++ b/en/device-dev/porting/transplant-thirdparty-makefile.md
@@ -0,0 +1,309 @@
+# Porting a Library Built Using Makefile
+
+- [Source Code Acquisition](#section114115321416)
+- [Cross-Compilation Settings](#section81263255384)
+- [Library Test](#section1830015913391)
+- [Adding the Compiled yxml Library to the OpenHarmony Project](#section1898016213406)
+
+The following shows how to port the yxml library.
+
+## Source Code Acquisition
+
+Acquire the source code of yxml from [the open-source repository](https://github.com/getdnsapi/yxml). The following table lists the directory structure.
+
+**Table 1** Directory structure of the source code
+
+
+
Directory
+
+
Description
+
+
+
+
yxml/bench/
+
+
Benchmark-related code
+
+
+
yxml/test/
+
+
Input and output files as well as scripts of the test cases
+
+
+
yxml/Makefile
+
+
File for organizing compilation
+
+
+
yxml/.gitattributes
+
+
-
+
+
+
yxml/.gitignore
+
+
-
+
+
+
yxml/COPYING
+
+
-
+
+
+
yxml/yxml.c
+
+
-
+
+
+
yxml/yxml.c.in
+
+
-
+
+
+
yxml/yxml-gen.pl
+
+
-
+
+
+
yxml/yxml.h
+
+
-
+
+
+
yxml/yxml.md
+
+
-
+
+
+
yxml/yxml-states
+
+
-
+
+
+
+
+
+## Cross-Compilation Settings
+
+The following steps show how to configure and modify the toolchains for cross-compiling the libraries built using CMake to compile executable files for the OpenHarmony platform.
+
+1. Configure the toolchains.
+
+ Replace the original configuration of MakeFile \(listed in [Table 1](#table16520154171813)\) in the root directory of the yxml library with the following clang toolchains configuration.
+
+ clang toolchains configuration:
+
+ ```
+ # Set the cross-compilation toolchain and ensure that the path of the toolchain has been added to the PATH environment variable.
+ CC:=clang
+ AR:=llvm-ar
+ # The --target and --sysroot flags must be specified.
+ CFLAGS:=-Wall -Wextra -Wno-unused-parameter -O2 -g --target=arm-liteos -march=armv7-a --sysroot=$(OHOS_ROOT_PATH)prebuilts/lite/sysroot
+ ```
+
+ Original configuration:
+
+ ```
+ CC:=gcc
+ AR:=ar
+ CFLAGS:=-Wall -Wextra -Wno-unused-parameter -O2 -g
+ ```
+
+2. Perform the compilation.
+
+ Run a Linux command to enter the directory \(listed in [Table 1](#table16520154171813)\) for storing yxml source files and then run the following command:
+
+ ```
+ make test OHOS_SYSROOT_PATH=...
+ ```
+
+ **OHOS\_SYSROOT\_PATH** specifies the absolute path of the directory where **sysroot** is located. Taking OpenHarmony for example, set **OHOS\_SYSROOT\_PATH** to the absolute path of **prebuilts/lite/sysroot/**.
+
+3. View the result.
+
+ After step 2 is complete, a static library file and test case are generated in the **out** directory of the yxml library.
+
+ **Table 2** Directory structure of compiled files
+
+
+
Directory
+
+
Description
+
+
+
+
openHarmony/third_party/yxml/yxml/out/lib/
+
+
Static library file
+
+
+
openHarmony/third_party/yxml/yxml/out/test/
+
+
Test cases as well as the input and output files
+
+
+
+
+
+
+## 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.
+
+**Table 3** Directory structure of the test directory
+
+
+
Automatic test script, which cannot be used because OpenHarmony does not support automatic script execution. However, you can refer to this script to conduct a manual test.
+
+
+
openHarmony/third_party/yxml/yxml/out/test/test
+
+
Executable file for testing.
+
+
+
openHarmony/third_party/yxml/yxml/out/test/*.xml
+
+
Input test file.
+
+
+
openHarmony/third_party/yxml/yxml/out/test/*.out
+
+
Expected output file.
+
+
+
+
+
+The content of the **test.sh** file is as follows:
+
+```
+#!/bin/sh
+for i in *.xml; do
+ b=`basename $i .xml`
+ o=${b}.out
+ t=${b}.test
+ ./test <$i >$t
+ if [ -n "`diff -q $o $t`" ]; then
+ echo "Test failed for $i:"
+ diff -u $o $t
+ exit 1
+ fi
+done
+echo "All tests completed successfully."
+```
+
+The shell of OpenHarmony does not support input and output redirection symbols \(< and \>\). During the test, you need to copy the content in the **_\*_.xml** file to the shell and press **Enter**. The output content is displayed in the shell screen.
+
+The following operations are performed based on the assumption that the OpenHarmony environment has been set up and the **nfs** directory has been mounted and accessed.
+
+1. Execute the following command:
+
+ ```
+ ./test
+ ```
+
+2. Copy the content in the **_\*_.xml** file to shell.
+
+ Taking the **pi01.xml** file in the [test](#table115941423164318) directory as an example, copy the following content to shell and press **Enter**:
+
+ ```
+
+ ```
+
+3. Check whether the output in the shell is the same as that of the **_\*_.out** file in the [test](#table115941423164318) directory.
+
+ The output is as follows:
+
+ ```
+ pistart SomePI
+ picontent abc
+ piend
+ elemstart a
+ elemend
+ ok
+ ```
+
+ The output is the same as the **pi01.out** file in the [test](#table115941423164318) directory. The test is passed.
+
+
+## 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 implementation of the newly added **BUILD.gn** file in the yxml library is as follows:
+
+```
+import("config.gni")
+group("yxml") {
+ if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
+ deps = [":make"]
+ }
+}
+if (ohos_build_thirdparty_migrated_from_fuchisa == true) {
+ action("make") {
+ script = "//third_party/yxml/build_thirdparty.py"
+ outputs = ["$target_out_dir/log_yxml.txt"]
+ exec_path = rebase_path(rebase_path("./yxml", root_build_dir))
+ command = "make clean && $MAKE_COMMAND"
+ args = [
+ "--path=$exec_path",
+ "--command=${command}"
+ ]
+ }
+}
+```
+
+- The configuration of the newly added **config.gni** file in the yxml library is as follows:
+
+```
+TEST_ENABLE = "YES"
+
+if (TEST_ENABLE == "YES") {
+ MAKE_COMMAND = "make test OHOS_SYSROOT_PATH=${ohos_root_path}prebuilts/lite/sysroot/"
+} else {
+ MAKE_COMMAND = "make OHOS_SYSROOT_PATH=${ohos_root_path}prebuilts/lite/sysroot/"
+}
+```
+
+- The following table lists the directory structure of the OpenHarmony project.
+
+**Table 4** Directory structure of the ported library
+
+
+
Directory
+
+
Description
+
+
+
+
openHarmony/third_party/yxml/BUILD.gn
+
+
GN file for adding the third-party library to the OpenHarmony project
+
+
+
openHarmony/third_party/yxml/build_thirdparty.py
+
+
Script file for GN to call the shell command to convert compilation from GN to Makefile.
+
+
+
openHarmony/third_party/yxml/config.gni
+
+
Third-party library compilation configuration file, which can be modified to determine whether the test cases will be used during the building
+
+
+
openHarmony/third_party/yxml/yxml/
+
+
Directory of the third-party library to be ported
+
+
+
+
+
diff --git a/en/device-dev/porting/overview.md b/en/device-dev/porting/transplant-thirdparty-overview.md
similarity index 100%
rename from en/device-dev/porting/overview.md
rename to en/device-dev/porting/transplant-thirdparty-overview.md
diff --git a/en/device-dev/porting/transplant-thirdparty.md b/en/device-dev/porting/transplant-thirdparty.md
new file mode 100644
index 0000000000000000000000000000000000000000..c8b071004faf57fb2255574649181cd04e7c12aa
--- /dev/null
+++ b/en/device-dev/porting/transplant-thirdparty.md
@@ -0,0 +1,9 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..059e5ea0f84e85155b49e626989d2585c81a56e4
--- /dev/null
+++ b/en/device-dev/porting/transplant.md
@@ -0,0 +1,9 @@
+# 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/porting/xts.md b/en/device-dev/porting/xts.md
deleted file mode 100644
index 95899d2212185d0bcad58051cc92371e42e41024..0000000000000000000000000000000000000000
--- a/en/device-dev/porting/xts.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# XTS
-
-- [Introduction](#section6725155811454)
- - [Adding the XTS Subsystem to the Building Component](#section46981118105417)
- - [Executing ACTS Cases for the IoTLink Module](#section9489122319819)
-
-
-## Introduction
-
-X Test Suite \(XTS\) is a set of OpenHarmony certification test suites. Currently, the application compatibility test suite \(ACTS\) is supported. The **test/xts** repository contains the **acts** directory and **tools** software package.
-
-- The **acts** directory stores the source code and configuration files of ACTS test cases. The ACTS helps device vendors detect the software incompatibility as early as possible and ensures that the software is compatible with OpenHarmony during the entire development process.
-- The **tools** software package stores the test case development framework related to **acts**.
-
-> **NOTE:**
->The startup of the XTS depends on the SAMGR module.
-
-The XTS adaptation consists of the following steps:
-
-1. Add the XTS subsystem to the building component.
-2. Execute ACTS cases for the IoTLink module.
-
-### Adding the XTS Subsystem to the Building Component
-
-The following example shows how to add the XTS subsystem to the building component **hispark\_aries**:
-
-1. Add the definition of the XTS subsystem to the **vendor/hisilicon/hispark\_aries/config.json** file.
-
- ```
- {
- "subsystem": "test",
- "components": [
- { "component": "xts_acts", "features":[] },
- { "component": "xts_tools", "features":[] }
- ]
- },
- ```
-
-2. Set the building type to the debug version so that the XTS subsystem can be built.
-
-### Executing ACTS Cases for the IoTLink Module
-
-The following example shows how to execute ACTS cases for the IoTLink module of **hispark\_aries**:
-
-1. Obtain the built image.
-
- Obtain the image from the **out/hispark\_pegasus/wifiiot\_hispark\_pegasus/** directory.
-
- > **NOTE:**
- >To check whether the ACTS is integrated into the current image, check whether the corresponding **.a** file is compiled.
-
-2. Burn the image into the development board.
-3. Execute the test by performing the following steps.
- - Use a serial port tool to log in to the development board and save information about the serial port.
-
- - Restart the device and view serial port logs.
-
-4. Analyze the test result.
- - View the serial port logs, whose format is as follows:
-
- - The log for each test suite starts with **Start to run test suite:** and ends with **xx Tests xx Failures xx Ignored**.
-
-
diff --git a/en/device-dev/bundles/public_sys-resources/icon-caution.gif b/en/device-dev/public_sys-resources/icon-caution.gif
similarity index 100%
rename from en/device-dev/bundles/public_sys-resources/icon-caution.gif
rename to en/device-dev/public_sys-resources/icon-caution.gif
diff --git a/en/device-dev/bundles/public_sys-resources/icon-danger.gif b/en/device-dev/public_sys-resources/icon-danger.gif
similarity index 100%
rename from en/device-dev/bundles/public_sys-resources/icon-danger.gif
rename to en/device-dev/public_sys-resources/icon-danger.gif
diff --git a/en/device-dev/bundles/public_sys-resources/icon-note.gif b/en/device-dev/public_sys-resources/icon-note.gif
similarity index 100%
rename from en/device-dev/bundles/public_sys-resources/icon-note.gif
rename to en/device-dev/public_sys-resources/icon-note.gif
diff --git a/en/device-dev/bundles/public_sys-resources/icon-notice.gif b/en/device-dev/public_sys-resources/icon-notice.gif
similarity index 100%
rename from en/device-dev/bundles/public_sys-resources/icon-notice.gif
rename to en/device-dev/public_sys-resources/icon-notice.gif
diff --git a/en/device-dev/bundles/public_sys-resources/icon-tip.gif b/en/device-dev/public_sys-resources/icon-tip.gif
similarity index 100%
rename from en/device-dev/bundles/public_sys-resources/icon-tip.gif
rename to en/device-dev/public_sys-resources/icon-tip.gif
diff --git a/en/device-dev/bundles/public_sys-resources/icon-warning.gif b/en/device-dev/public_sys-resources/icon-warning.gif
similarity index 100%
rename from en/device-dev/bundles/public_sys-resources/icon-warning.gif
rename to en/device-dev/public_sys-resources/icon-warning.gif
diff --git a/en/device-dev/quick-start/Readme-EN.md b/en/device-dev/quick-start/Readme-EN.md
index 7c52dded2505a5db6cd57a6614e2f3665ccf66e8..2741990f65202db0f48811a47da98f73725022eb 100644
--- a/en/device-dev/quick-start/Readme-EN.md
+++ b/en/device-dev/quick-start/Readme-EN.md
@@ -1,42 +1,40 @@
-# Getting Started
+# Getting Started
-- [Overview](overview.md)
-- [Mini and Small Systems](mini-and-small-systems.md)
- - [Overview](overview-0.md)
- - [Introduction to the Development Boards](introduction-to-the-development-boards.md)
- - [Hi3861 Development Board](hi3861-development-board.md)
- - [Hi3516 Development Board](hi3516-development-board.md)
- - [Hi3518 Development Board](hi3518-development-board.md)
+- [Mini and Small Systems](quickstart-lite.md)
+ - [Overview](quickstart-lite-overview.md)
+ - [Introduction to the Development Boards](quickstart-lite-introduction.md)
+ - [Hi3861 Development Board](quickstart-lite-introduction-hi3861.md)
+ - [Hi3516 Development Board](quickstart-lite-introduction-hi3516.md)
+ - [Hi3518 Development Board](quickstart-lite-introduction-hi3518.md)
- - [Environment Setup](environment-setup.md)
- - [Overview](overview-1.md)
- - [Windows Development Environment](windows-development-environment.md)
- - [Ubuntu Build Environment](ubuntu-build-environment.md)
- - [FAQ](faq.md)
+ - [Environment Setup](quickstart-lite-env-setup.md)
+ - [Overview](quickstart-lite-env-setup-des.md)
+ - [Windows Development Environment](quickstart-lite-env-setup-win.md)
+ - [Ubuntu Build Environment](quickstart-lite-env-setup-lin.md)
+ - [FAQ](quickstart-lite-env-setup-faqs.md)
- - [How to Develop](how-to-develop.md)
- - [Hi3861](hi3861.md)
- - [Setting Up the Environment](setting-up-the-environment.md)
- - [WLAN Connection](wlan-connection.md)
- - [Running a Hello World Program](running-a-hello-world-program.md)
- - [FAQs](faqs.md)
+ - [How to Develop](quickstart-lite-steps.md)
+ - [Hi3861](quickstart-lite-steps-board3861.md)
+ - [Setting Up the Environment](quickstart-lite-steps-board3861-setting.md)
+ - [WLAN Connection](quickstart-lite-steps-board3861-connection.md)
+ - [Running a Hello World Program](quickstart-lite-steps-board3861-running.md)
+ - [FAQs](quickstart-lite-steps-board3861-faqs.md)
- - [Hi3516](hi3516.md)
- - [Setting Up the Environment](setting-up-the-environment-2.md)
- - [Running a Hello OHOS Program](running-a-hello-ohos-program.md)
- - [Developing a Driver](developing-a-driver.md)
- - [FAQs](faqs-3.md)
+ - [Hi3516](quickstart-lite-steps-board3516.md)
+ - [Setting Up the Environment](quickstart-lite-steps-board3516-setting.md)
+ - [Running a Hello OHOS Program](quickstart-lite-steps-board3516-running.md)
+ - [Developing a Driver](quickstart-lite-steps-board3516-program.md)
+ - [FAQs](quickstart-lite-steps-board3516-faqs.md)
- - [Hi3518](hi3518.md)
- - [Setting Up the Environment](setting-up-the-environment-4.md)
- - [Running a Hello OHOS Program](running-a-hello-ohos-program-5.md)
- - [FAQs](faqs-6.md)
-
-- [Standard System](standard-system.md)
- - [Introduction](introduction.md)
- - [Setting Up Windows Development Environment](setting-up-windows-development-environment.md)
- - [Setting Up Ubuntu Development Environment in Docker Mode and Building Source Code](setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md)
- - [Setting Up Ubuntu Development Environment with Installation Package and Building Source Code](setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md)
- - [Burning Images](burning-images.md)
- - [FAQs](faqs-7.md)
+ - [Hi3518](quickstart-lite-steps-board3518.md)
+ - [Setting Up the Environment](quickstart-lite-steps-board3518-setting.md)
+ - [Running a Hello OHOS Program](quickstart-lite-steps-board3518-running.md)
+ - [FAQs](quickstart-lite-steps-board3518-faqs.md)
+- [Standard System](quickstart-standard.md)
+ - [FAQ](quickstart-lite-env-setup-faqs.md)
+ - [Setting Up Windows Development Environment](quickstart-standard-windows-environment.md)
+ - [Setting Up Ubuntu Development Environment in Docker Mode and Building Source Code](quickstart-standard-docker-environment.md)
+ - [Setting Up Ubuntu Development Environment with Installation Package and Building Source Code](quickstart-standard-package-environment.md)
+ - [Burning Images](quickstart-standard-burn.md)
+ - [FAQs](quickstart-standard-faq.md)
\ No newline at end of file
diff --git a/en/device-dev/quick-start/burning-images.md b/en/device-dev/quick-start/burning-images.md
deleted file mode 100644
index b63966d94334be8ec473b7d641fb4f36c33b8866..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/burning-images.md
+++ /dev/null
@@ -1,205 +0,0 @@
-# Burning Images
-
-- [Next](#section5600113114323)
-
-Programming flash memory of a regular system requires DevEco Device Tool v2.2 Beta1 or later.
-
-The Hi3516DV300 of the Hi3516 series development boards supports programming flash memory of a regular system through the USB port, network port, or serial port, where:
-
-- **Windows system: Supports programming through the USB port, serial port, or network port**
-- **Linux system: Supports programming through the serial port or network port \(Linux+Windows dual system: Also supports programming through the USB port\)**
-
-Except for environment setup, the operations of programming are the same for Windows and Linux.
-
-> **NOTE:**
->Currently, the Hi3516D V300 development board supports system burning over the network port, USB port, or serial port. This document uses the network port as an example. For details about system burning over other ports, see [Programming Flash Memory on the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681).
-
-### Prerequisites
-
-[Open a project](https://device.harmonyos.com/en/docs/ide/user-guides/open_project-0000001071680043) in DevEco Device Tool and select the folder where the file to be programmed is located. Select **Hi3516DV300** for the development board type and **Hb** for **Framework**.
-
-### Programming Flash Memory Through the Network Port
-
-The Hi3516DV300 supports programming through the network port in Windows or Linux.
-
-1. Connect the PC and the target development board through the power port, serial port, and network port. In this section, the Hi3516DV300 is used as an example. For details, please refer to [Introduction to the Hi3516 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_camera_start_3516-0000001052670587).
-2. Open Device Manager, then check and record the serial port number corresponding to the development board.
-
- > **NOTE:**
- >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695).
-
- 
-
-3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
-
- 
-
-4. On the **Partition Configuration** tab page, enter the information about the files to be programmed, including the following.
-
-
-
Name
-
-
Binary
-
-
Memory
-
-
System
-
-
Address
-
-
Length
-
-
Board
-
-
Type
-
-
-
-
fastboot
-
-
Select u-boot-hi3516dv300_emmc.bin.
-
-
emmc
-
-
none
-
-
0x000000
-
-
0x100000
-
-
Select hi3516dv300.
-
-
NA
-
-
-
boot
-
-
Select uImage.
-
-
emmc
-
-
none
-
-
0x100000
-
-
0xf00000
-
-
NA
-
-
-
updater
-
-
Select updater.img.
-
-
emmc
-
-
ext3/4
-
-
0x1000000
-
-
0x1400000
-
-
NA
-
-
-
misc
-
-
Leave it blank.
-
-
emmc
-
-
none
-
-
0x2400000
-
-
0x100000
-
-
NA
-
-
-
system
-
-
Select system.img.
-
-
emmc
-
-
ext3/4
-
-
0x2500000
-
-
0xceb00000
-
-
NA
-
-
-
vendor
-
-
Select vendor.img.
-
-
emmc
-
-
ext3/4
-
-
0xd1000000
-
-
0x10000000
-
-
NA
-
-
-
userdata
-
-
Select userdata.img.
-
-
emmc
-
-
ext3/4
-
-
0xe1000000
-
-
0x5b800000
-
-
NA
-
-
-
-
-
- 
-
-5. On the **hi3516dv300** tab page, configure the programming options.
-
- - **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001056443961_li1050616379507).
- - **upload\_protocol**: Select the programming protocol **hiburn-net**.
- - **upload\_partitions**: Select the file to be programmed, including the following: fastboot, boot, updater, misc, system, vendor, and userdata.
-
- 
-
-6. Check and set the IP address of the network adapter connected to the development board. For details, see [Setting the IP Address of the Network Port for Programming on Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/set_ipaddress-0000001141825075).
-7. Set the IP address of the network port for programming:
-
- - **upload\_net\_server\_ip**: Select the IP address set in [6](en-us_topic_0000001056443961.md#li1558813168234), such as 192.168.1.2.
- - **upload\_net\_client\_mask**: Set the subnet mask of the development board, such as 255.255.255.0. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
- - **upload\_net\_client\_gw**: Set the gateway of the development board, such as 192.168.1.1. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
- - **upload\_net\_client\_ip**: Set the IP address of the development board, such as 192.168.1.3. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
-
- 
-
-8. When you finish modifying, click **Save** in the upper right corner.
-9. Open the project file, go to  \> **PROJECT TASKS** \> **fastboot** \> **Erase** to erase U-boot.
-
- 
-
-10. When the following message is displayed, power off the development board and then power it on.
-
- 
-
-11. Start programming. When the following message is displayed, it indicates that the programming is successful.
-
- 
-
-
-## 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/development-example-for-clock-apps.md).
-
diff --git a/en/device-dev/quick-start/developing-a-driver.md b/en/device-dev/quick-start/developing-a-driver.md
deleted file mode 100644
index 46e8fc8d73366f89a16d84312e418e2c0a7d60b3..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/developing-a-driver.md
+++ /dev/null
@@ -1,503 +0,0 @@
-# Developing a Driver
-
-- [Introduction to Driver](#s8efc1952ebfe4d1ea717182e108c29bb)
-- [Compiling and Burning](#section660016185110)
-- [Running an Image](#section333215226219)
-- [Follow-up Learning](#section9712145420182)
-
-This section describes how to develop a driver on the board, including introduction, compilation, burning, and running of the driver.
-
-## Introduction to Driver
-
-The following operations take a HDF-based UART driver as an example to show how to add configuration files, code the driver, and compile the code for interactions between the user-space applications and the driver. The driver source code is stored in the **vendor/huawei/hdf/sample** directory.
-
-1. Add Configurations.
-
- Add driver configurations to the HDF driver configuration file \(for example, **device/hisilicon/hi3516dv300/sdk\_liteos/config/uart/uart\_config.hcs**\).
-
- ```
- root {
- platform {
- uart_sample {
- num = 5; // UART device number
- base = 0x120a0000; // Base address of the UART register
- irqNum = 38;
- baudrate = 115200;
- uartClk = 24000000;
- wlen = 0x60;
- parity = 0;
- stopBit = 0;
- match_attr = "sample_uart_5";
- }
- }
- }
- ```
-
- Add the device node information to the HDF device configuration file \(for example, **vendor/hisilicon/ipcamera\_hi3516dv300\_liteos/config/device\_info/device\_info.hcs**\)
-
- ```
- root {
- device_info {
- platform :: host {
- hostName = "platform_host";
- priority = 50;
- device_uart :: device {
- device5 :: deviceNode {
- policy = 2;
- priority = 10;
- permission = 0660;
- moduleName = "UART_SAMPLE";
- serviceName = "HDF_PLATFORM_UART_5";
- deviceMatchAttr = "sample_uart_5";
- }
- }
- }
- }
- }
- ```
-
- > **NOTE:**
- >The configuration files are in the same path as the source code of the UART driver. You need to manually add the files to the path of the Hi3516D V300 development board.
-
-2. Register a UART driver entry.
-
- Register the **HdfDriverEntry** of the UART driver with the HDF.
-
- ```
- // Bind the UART driver interface to the HDF.
- static int32_t SampleUartDriverBind(struct HdfDeviceObject *device)
- {
- struct UartHost *uartHost = NULL;
-
- if (device == NULL) {
- return HDF_ERR_INVALID_OBJECT;
- }
- HDF_LOGI("Enter %s:", __func__);
-
- uartHost = UartHostCreate(device);
- if (uartHost == NULL) {
- HDF_LOGE("%s: UartHostCreate failed", __func__);
- return HDF_FAILURE;
- }
- uartHost->service.Dispatch = SampleDispatch;
- return HDF_SUCCESS;
- }
-
- // Obtain configuration information from the HCS of the UART driver.
- static uint32_t GetUartDeviceResource(
- struct UartDevice *device, const struct DeviceResourceNode *resourceNode)
- {
- struct UartResource *resource = &device->resource;
- struct DeviceResourceIface *dri = NULL;
- dri = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);
- if (dri == NULL || dri->GetUint32 == NULL) {
- HDF_LOGE("DeviceResourceIface is invalid");
- return HDF_FAILURE;
- }
-
- if (dri->GetUint32(resourceNode, "num", &resource->num, 0) != HDF_SUCCESS) {
- HDF_LOGE("uart config read num fail");
- return HDF_FAILURE;
- }
- if (dri->GetUint32(resourceNode, "base", &resource->base, 0) != HDF_SUCCESS) {
- HDF_LOGE("uart config read base fail");
- return HDF_FAILURE;
- }
- resource->physBase = (unsigned long)OsalIoRemap(resource->base, 0x48);
- if (resource->physBase == 0) {
- HDF_LOGE("uart config fail to remap physBase");
- return HDF_FAILURE;
- }
- if (dri->GetUint32(resourceNode, "irqNum", &resource->irqNum, 0) != HDF_SUCCESS) {
- HDF_LOGE("uart config read irqNum fail");
- return HDF_FAILURE;
- }
- if (dri->GetUint32(resourceNode, "baudrate", &resource->baudrate, 0) != HDF_SUCCESS) {
- HDF_LOGE("uart config read baudrate fail");
- return HDF_FAILURE;
- }
- if (dri->GetUint32(resourceNode, "wlen", &resource->wlen, 0) != HDF_SUCCESS) {
- HDF_LOGE("uart config read wlen fail");
- return HDF_FAILURE;
- }
- if (dri->GetUint32(resourceNode, "parity", &resource->parity, 0) != HDF_SUCCESS) {
- HDF_LOGE("uart config read parity fail");
- return HDF_FAILURE;
- }
- if (dri->GetUint32(resourceNode, "stopBit", &resource->stopBit, 0) != HDF_SUCCESS) {
- HDF_LOGE("uart config read stopBit fail");
- return HDF_FAILURE;
- }
- if (dri->GetUint32(resourceNode, "uartClk", &resource->uartClk, 0) != HDF_SUCCESS) {
- HDF_LOGE("uart config read uartClk fail");
- return HDF_FAILURE;
- }
- return HDF_SUCCESS;
- }
-
- // Attach the configuration and interface of the UART driver to the HDF.
- static int32_t AttachUartDevice(struct UartHost *host, struct HdfDeviceObject *device)
- {
- int32_t ret;
- struct UartDevice *uartDevice = NULL;
- if (device->property == NULL) {
- HDF_LOGE("%s: property is NULL", __func__);
- return HDF_FAILURE;
- }
- uartDevice = (struct UartDevice *)OsalMemCalloc(sizeof(struct UartDevice));
- if (uartDevice == NULL) {
- HDF_LOGE("%s: OsalMemCalloc uartDevice error", __func__);
- return HDF_ERR_MALLOC_FAIL;
- }
- ret = GetUartDeviceResource(uartDevice, device->property);
- if (ret != HDF_SUCCESS) {
- (void)OsalMemFree(uartDevice);
- return HDF_FAILURE;
- }
- host->num = uartDevice->resource.num;
- host->priv = uartDevice;
- AddUartDevice(host);
- return InitUartDevice(uartDevice);
- }
-
- // Initialize the UART driver.
- static int32_t SampleUartDriverInit(struct HdfDeviceObject *device)
- {
- int32_t ret;
- struct UartHost *host = NULL;
-
- if (device == NULL) {
- HDF_LOGE("%s: device is NULL", __func__);
- return HDF_ERR_INVALID_OBJECT;
- }
- HDF_LOGI("Enter %s:", __func__);
- host = UartHostFromDevice(device);
- if (host == NULL) {
- HDF_LOGE("%s: host is NULL", __func__);
- return HDF_FAILURE;
- }
- ret = AttachUartDevice(host, device);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE("%s: attach error", __func__);
- return HDF_FAILURE;
- }
- host->method = &g_sampleUartHostMethod;
- return ret;
- }
-
- static void DeinitUartDevice(struct UartDevice *device)
- {
- struct UartRegisterMap *regMap = (struct UartRegisterMap *)device->resource.physBase;
- /* Wait for the UART to enter the idle state. */
- while (UartPl011IsBusy(regMap));
- UartPl011ResetRegisters(regMap);
- uart_clk_cfg(0, false);
- OsalIoUnmap((void *)device->resource.physBase);
- device->state = UART_DEVICE_UNINITIALIZED;
- }
-
- // Detach and release the UART driver.
- static void DetachUartDevice(struct UartHost *host)
- {
- struct UartDevice *uartDevice = NULL;
-
- if (host->priv == NULL) {
- HDF_LOGE("%s: invalid parameter", __func__);
- return;
- }
- uartDevice = host->priv;
- DeinitUartDevice(uartDevice);
- (void)OsalMemFree(uartDevice);
- host->priv = NULL;
- }
-
- // Release the UART driver.
- static void SampleUartDriverRelease(struct HdfDeviceObject *device)
- {
- struct UartHost *host = NULL;
- HDF_LOGI("Enter %s:", __func__);
-
- if (device == NULL) {
- HDF_LOGE("%s: device is NULL", __func__);
- return;
- }
- host = UartHostFromDevice(device);
- if (host == NULL) {
- HDF_LOGE("%s: host is NULL", __func__);
- return;
- }
- if (host->priv != NULL) {
- DetachUartDevice(host);
- }
- UartHostDestroy(host);
- }
-
- struct HdfDriverEntry g_sampleUartDriverEntry = {
- .moduleVersion = 1,
- .moduleName = "UART_SAMPLE",
- .Bind = SampleUartDriverBind,
- .Init = SampleUartDriverInit,
- .Release = SampleUartDriverRelease,
- };
-
- HDF_INIT(g_sampleUartDriverEntry);
- ```
-
-3. Register a UART driver interface.
-
- Implement the UART driver interface using the template **UartHostMethod** provided by the HDF.
-
- ```
- static int32_t SampleUartHostInit(struct UartHost *host)
- {
- HDF_LOGI("%s: Enter", __func__);
- if (host == NULL) {
- HDF_LOGE("%s: invalid parameter", __func__);
- return HDF_ERR_INVALID_PARAM;
- }
- return HDF_SUCCESS;
- }
-
- static int32_t SampleUartHostDeinit(struct UartHost *host)
- {
- HDF_LOGI("%s: Enter", __func__);
- if (host == NULL) {
- HDF_LOGE("%s: invalid parameter", __func__);
- return HDF_ERR_INVALID_PARAM;
- }
- return HDF_SUCCESS;
- }
-
- // Write data into the UART device.
- static int32_t SampleUartHostWrite(struct UartHost *host, uint8_t *data, uint32_t size)
- {
- HDF_LOGI("%s: Enter", __func__);
- uint32_t idx;
- struct UartRegisterMap *regMap = NULL;
- struct UartDevice *device = NULL;
-
- if (host == NULL || data == NULL || size == 0) {
- HDF_LOGE("%s: invalid parameter", __func__);
- return HDF_ERR_INVALID_PARAM;
- }
- device = (struct UartDevice *)host->priv;
- if (device == NULL) {
- HDF_LOGE("%s: device is NULL", __func__);
- return HDF_ERR_INVALID_PARAM;
- }
- regMap = (struct UartRegisterMap *)device->resource.physBase;
- for (idx = 0; idx < size; idx++) {
- UartPl011Write(regMap, data[idx]);
- }
- return HDF_SUCCESS;
- }
-
- // Set the baud rate for the UART device.
- static int32_t SampleUartHostSetBaud(struct UartHost *host, uint32_t baudRate)
- {
- HDF_LOGI("%s: Enter", __func__);
- struct UartDevice *device = NULL;
- struct UartRegisterMap *regMap = NULL;
- UartPl011Error err;
-
- if (host == NULL) {
- HDF_LOGE("%s: invalid parameter", __func__);
- return HDF_ERR_INVALID_PARAM;
- }
- device = (struct UartDevice *)host->priv;
- if (device == NULL) {
- HDF_LOGE("%s: device is NULL", __func__);
- return HDF_ERR_INVALID_PARAM;
- }
- regMap = (struct UartRegisterMap *)device->resource.physBase;
- if (device->state != UART_DEVICE_INITIALIZED) {
- return UART_PL011_ERR_NOT_INIT;
- }
- if (baudRate == 0) {
- return UART_PL011_ERR_INVALID_BAUD;
- }
- err = UartPl011SetBaudrate(regMap, device->uartClk, baudRate);
- if (err == UART_PL011_ERR_NONE) {
- device->baudrate = baudRate;
- }
- return err;
- }
-
- // Obtain the baud rate of the UART device.
- static int32_t SampleUartHostGetBaud(struct UartHost *host, uint32_t *baudRate)
- {
- HDF_LOGI("%s: Enter", __func__);
- struct UartDevice *device = NULL;
-
- if (host == NULL) {
- HDF_LOGE("%s: invalid parameter", __func__);
- return HDF_ERR_INVALID_PARAM;
- }
- device = (struct UartDevice *)host->priv;
- if (device == NULL) {
- HDF_LOGE("%s: device is NULL", __func__);
- return HDF_ERR_INVALID_PARAM;
- }
- *baudRate = device->baudrate;
- return HDF_SUCCESS;
- }
-
- // Bind the UART device using HdfUartSampleInit.
- struct UartHostMethod g_sampleUartHostMethod = {
- .Init = SampleUartHostInit,
- .Deinit = SampleUartHostDeinit,
- .Read = NULL,
- .Write = SampleUartHostWrite,
- .SetBaud = SampleUartHostSetBaud,
- .GetBaud = SampleUartHostGetBaud,
- .SetAttribute = NULL,
- .GetAttribute = NULL,
- .SetTransMode = NULL,
- };
- ```
-
- Add the sample module of the UART driver to the compilation script **device/hisilicon/drivers/lite.mk**.
-
- ```
- LITEOS_BASELIB += -lhdf_uart_sample
- LIB_SUBDIRS += $(LITEOS_SOURCE_ROOT)/vendor/huawei/hdf/sample/platform/uart
- ```
-
-4. Implement the code for interaction between the user-space applications and driver.
-
- Create the **/dev/uartdev-5** node after the UART driver is initialized successfully. The following example shows how to interact with the UART driver through the node.
-
- ```
- #include
- #include
- #include
- #include "hdf_log.h"
-
- #define HDF_LOG_TAG "hello_uart"
- #define INFO_SIZE 16
-
- int main(void)
- {
- int ret;
- int fd;
- const char info[INFO_SIZE] = {" HELLO UART! "};
-
- fd = open("/dev/uartdev-5", O_RDWR);
- if (fd < 0) {
- HDF_LOGE("hello_uart uartdev-5 open failed %d", fd);
- return -1;
- }
- ret = write(fd, info, INFO_SIZE);
- if (ret != 0) {
- HDF_LOGE("hello_uart write uartdev-5 ret is %d", ret);
- }
- ret = close(fd);
- if (ret != 0) {
- HDF_LOGE("hello_uart uartdev-5 close failed %d", fd);
- return -1;
- }
- return ret;
- }
- ```
-
- Add the **hello\_uart\_sample** component to **targets** of the **hdf\_hi3516dv300\_liteos\_a** component in the **build/lite/components/drivers.json** file.
-
- ```
- {
- "components": [
- {
- "component": "hdf_hi3516dv300_liteos_a",
- ...
- "targets": [
- "//vendor/huawei/hdf/sample/platform/uart:hello_uart_sample"
- ]
- }
- ]
- }
- ```
-
- > **NOTE:**
- >Preceding code snippets are for reference only. You can view the complete sample code in **vendor/huawei/hdf/sample.**
- >The sample code is not automatically compiled by default. You can add it to the compilation script.
-
-
-## Compiling and Burning
-
-Compile and burn images by referring to [Building](../guide/development-example-for-platform-drivers.md)and [Burning](../guide/development-example-for-platform-drivers.md).
-
-## Running an Image
-
-1. Connect to a serial port.
-
- > **NOTICE:**
- >If the connection fails, rectify the fault by referring to [FAQs](../quick-start/faqs-3.md).
-
- **Figure 1** Serial port connection
-
-
- 
-
- 1. Click **Monitor** to enable the serial port.
- 2. Press **Enter** repeatedly until **hisilicon** displays.
- 3. Go to [2](running-a-hello-ohos-program.md#l5b42e79a33ea4d35982b78a22913b0b1) if the board is started for the first time or the startup parameters need to be modified; go to [3](running-a-hello-ohos-program.md#ld26f18828aa44c36bfa36be150e60e49) otherwise.
-
-2. \(Mandatory when the board is started for the first time\) Modify the **bootcmd** and **bootargs** parameters of U-Boot. You need to perform this step only once if the parameters need not to be modified during the operation. The board automatically starts after it is reset.
-
- > **NOTICE:**
- >The default waiting time in the U-Boot is 2s. You can press **Enter** to interrupt the waiting and run the **reset** command to restart the system after "hisilicon" is displayed.
-
- **Table 1** Parameters of the U-Boot
-
-
-
Command
-
-
Description
-
-
-
-
setenv bootcmd "mmc read 0x0 0x80000000 0x800 0x4800; go 0x80000000";
-
-
Run this command to read content that has a size of 0x4800 (9 MB) and a start address of 0x800 (1 MB) to the memory address 0x80000000. The file size must be the same as that of the OHOS_Image.bin file in the IDE.
Run this command to set the output mode to serial port output, baud rate to 115200, data bit to 8, rootfs to be mounted to the emmc component, and file system type to vfat.
-
rootaddr=10M rootsize=20M rw indicates the start address and size of the rootfs.img file to be burnt, respectively. The file size must be the same as that of the rootfs.img file in the IDE.
-
-
-
saveenv
-
-
saveenv means to save the current configuration.
-
-
-
reset
-
-
reset means to reset the board.
-
-
-
-
-
- > **NOTICE:**
- >**go 0x80000000** is optional. It indicates that the command is fixed in the startup parameters by default and the board automatically starts after it is reset. If you want to manually start the board, press **Enter** in the countdown phase of the U-Boot startup to interrupt the automatic startup.
-
-3. Run the **reset** command and press **Enter** to restart the board. After the board is restarted, **OHOS** is displayed when you press **Enter**.
-
- **Figure 2** System startup
-
-
- 
-
-4. In the root directory, run the **./bin/hello\_uart** command line to execute the demo program. The compilation result is shown in the following example.
-
- ```
- OHOS # ./bin/hello_uart
- OHOS # HELLO UART!
- ```
-
-
-## Follow-up Learning
-
-Congratulations! You have finished all steps! You are advised to go on learning how to develop [Cameras with a Screen](../guide/cameras-without-a-screen.md).
-
diff --git a/en/device-dev/quick-start/environment-setup.md b/en/device-dev/quick-start/environment-setup.md
deleted file mode 100644
index 289f31965d0c38aea69d9ff15c917b6df62d8019..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/environment-setup.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Environment Setup
-
-- **[Overview](overview-1.md)**
-
-- **[Windows Development Environment](windows-development-environment.md)**
-
-- **[Ubuntu Build Environment](ubuntu-build-environment.md)**
-
-- **[FAQ](faq.md)**
-
-
diff --git a/en/device-dev/quick-start/faqs-3.md b/en/device-dev/quick-start/faqs-3.md
deleted file mode 100644
index 12c3a207b5cb348e0fc45f60c7985eacb886e61b..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/faqs-3.md
+++ /dev/null
@@ -1,172 +0,0 @@
-# FAQs
-
-- [What should I do when the images failed to be burnt over the selected serial port?](#section627268185113)
-- [What should I do when Windows-based PC failed to be connected to the board?](#section195391036568)
-- [What should I do when the image failed to be burnt?](#section571164016565)
-- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#section1039835245619)
-- [What should I do when no command output is displayed?](#section14871149155911)
-
-## What should I do when the images failed to be burnt over the selected serial port?
-
-- **Symptom**
-
- **Error: Opening COMxx: Access denied** is displayed after clicking **Burn** and selecting a serial port.
-
- **Figure 1** Failed to open the serial port
- 
-
-- **Possible Causes**
-
- The serial port has been used.
-
-- **Solutions**
-
-1. Search for the terminal using serial-xx from the drop-down list in the **TERMINAL** panel.
-
- **Figure 2** Checking whether the serial port is used
- 
-
-2. Click the dustbin icon as shown in the following figure to disable the terminal using the serial port.
-
- **Figure 3** Disabling the terminal using the serial port
- 
-
-3. Click **Burn**, select the serial port, and start burning images again.
-
- **Figure 4** Restarting burning
-
-
- 
-
-
-## What should I do when Windows-based PC failed to be connected to the board?
-
-- **Symptom**
-
- The file image cannot be obtained after clicking **Burn** and selecting a serial port.
-
- **Figure 5** Failed to obtain the image file due to unavailable connection
- 
-
-- **Possible Causes**
-
- The board is disconnected from the Windows-based PC.
-
- Windows Firewall does not allow Visual Studio Code to access the network.
-
-- **Solutions**
-
-1. Check whether the network cable is properly connected.
-2. Click **Windows Firewall**.
-
- **Figure 6** Network and firewall setting
- 
-
-3. Click **Firewall & network protection**, and on the displayed page, click **Allow applications to communicate through Windows Firewall**.
-
- **Figure 7** Firewall and network protection
- 
-
-4. Select the Visual Studio Code application.
-
- **Figure 8** Selecting the Visual Studio Code application
- 
-
-5. Select the **Private** and **Public** network access rights for the Visual Studio Code application.
-
- **Figure 9** Allowing the Visual Studio Code application to access the network
- 
-
-
-## What should I do when the image failed to be burnt?
-
-- **Symptom**
-
- The burning status is not displayed after clicking **Burn** and selecting a serial port.
-
-- **Possible Causes**
-
- The IDE is not restarted after the DevEco plug-in is installed.
-
-- **Solutions**
-
- Restart the IDE.
-
-
-## What should I do when the message indicating Python cannot be found is displayed during compilation and building?
-
-- **Symptom**
-
- 
-
-
-- **Possible Cause 1**: Python is not installed.
-- **Solutions**
-
- Install Python by referring to [Installing and Configuring Python](../quick-start/ubuntu-build-environment.md).
-
-- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
-
- 
-
-- **Solutions**
-
- Run the following commands:
-
- ```
- # cd /usr/bin/
- # which python3
- # ln -s /usr/local/bin/python3 python
- # python --version
- ```
-
- Example:
-
- 
-
-
-## What should I do when no command output is displayed?
-
-- **Symptom**
-
- The serial port shows that the connection has been established. After the board is restarted, nothing is displayed when you press **Enter**.
-
-- **Possible Cause 1**
-
- The serial port is connected incorrectly.
-
-- **Solutions**
-
- Change the serial port number.
-
- Start **Device Manager** to check whether the serial port connected to the board is the same as that connected to the terminal device. If the serial ports are different, perform step [1](../quick-start/running-a-hello-ohos-program.md) in the **Running an Image** section to change the serial port number.
-
-
-- **Possible Cause 2**
-
- The U-boot of the board is damaged.
-
-- **Solutions**
-
- Burn the U-boot.
-
- If the fault persists after you perform the preceding operations, the U-boot of the board may be damaged. You can burn the U-boot by performing the following steps:
-
-
-1. Obtain the U-boot file.
-
- > **NOTICE:**
- >The U-boot file of the two boards can be obtained from the following paths, respectively.
- >Hi3516D V300: **device\\hisilicon\\hispark\_taurus\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3516dv300.bin**
- >Hi3518E V300: **device\\hisilicon\\hispark\_aries\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3518ev300.bin**
-
-2. Burn the U-boot file by following the procedures for burning a U-boot file over USB.
-
- Select the U-boot files of corresponding development boards for burning by referring to [Programming Flash Memory on the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681)/[Programming Flash Memory on the Hi3518](https://device.harmonyos.com/en/docs/ide/user-guides/hi3518_upload-0000001057313128)
-
-3. Log in to the serial port after the burning is complete.
-
- **Figure 10** Serial port displayed after the U-boot is burnt
- 
-
-
diff --git a/en/device-dev/quick-start/faqs-6.md b/en/device-dev/quick-start/faqs-6.md
deleted file mode 100644
index 05d53356aed9ab16ac8fe65e19da9dbe70089533..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/faqs-6.md
+++ /dev/null
@@ -1,174 +0,0 @@
-# FAQs
-
-- [What should I do when the images failed to be burnt over the selected serial port?](#section1498892119619)
-- [What should I do when Windows-based PC failed to be connected to the board?](#section8512971816)
-- [What should I do when the image failed to be burnt?](#section1767804111198)
-- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#en-us_topic_0000001053466255_section1039835245619)
-- [What should I do when no command output is displayed?](#en-us_topic_0000001053466255_section14871149155911)
-
-## What should I do when the images failed to be burnt over the selected serial port?
-
-- **Symptom**
-
- **Error: Opening COMxx: Access denied** is displayed after clicking **Burn** and selecting a serial port.
-
- **Figure 1** Failed to open the serial port
- 
-
-- **Possible Causes**
-
- The serial port has been used.
-
-- **Solutions**
-
-1. Search for the terminal using serial-xx from the drop-down list in the **TERMINAL** panel.
-
- **Figure 2** Checking whether the serial port is used
- 
-
-2. Click the dustbin icon as shown in the following figure to disable the terminal using the serial port.
-
- **Figure 3** Disabling the terminal using the serial port
- 
-
-3. Click **Burn**, select the serial port, and start burning images again.
-
- **Figure 4** Restarting burning
-
-
- 
-
-
-## What should I do when Windows-based PC failed to be connected to the board?
-
-- **Symptom**
-
- The file image cannot be obtained after clicking **Burn** and selecting a serial port.
-
- **Figure 5** Failed to obtain the image file due to unavailable connection
- 
-
-- **Possible Causes**
-
- The board is disconnected from the Windows-based PC.
-
- Windows Firewall does not allow Visual Studio Code to access the network.
-
-- **Solutions**
-
-1. Check whether the network cable is properly connected.
-2. Click **Windows Firewall**.
-
- **Figure 6** Network and firewall setting
- 
-
-3. Click **Firewall & network protection**, and on the displayed page, click **Allow applications to communicate through Windows Firewall**.
-
- **Figure 7** Firewall and network protection
- 
-
-4. Select the Visual Studio Code application
-
- **Figure 8** Selecting the Visual Studio Code application
- 
-
-5. Select the **Private** and **Public** network access rights for the Visual Studio Code application.
-
- **Figure 9** Allowing the Visual Studio Code application to access the network
- 
-
-
-## What should I do when the image failed to be burnt?
-
-- **Symptom**
-
- The burning status is not displayed after clicking **Burn** and selecting a serial port.
-
-- **Possible Causes**
-
- The IDE is not restarted after the DevEco plug-in is installed.
-
-- **Solutions**
-
- Restart the IDE.
-
-
-## What should I do when the message indicating Python cannot be found is displayed during compilation and building?
-
-- **Symptom**
-
- 
-
-
-- **Possible Cause 1**
-
- Python is not installed.
-
-- **Solutions**
-
- Install Python by referring to [Installing and Configuring Python](../quick-start/ubuntu-build-environment.md).
-
-- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
-
- 
-
-- **Solutions**
-
- Run the following commands:
-
- ```
- # cd /usr/bin/
- # which python3
- # ln -s /usr/local/bin/python3 python
- # python --version
- ```
-
- Example:
-
- 
-
-
-## What should I do when no command output is displayed?
-
-- **Symptom**
-
- The serial port shows that the connection has been established. After the board is restarted, nothing is displayed when you press **Enter**.
-
-- **Possible Cause 1**
-
- The serial port is connected incorrectly.
-
-- **Solutions**
-
- Change the serial port number.
-
- Start **Device Manager** to check whether the serial port connected to the board is the same as that connected to the terminal device. If the serial ports are different, perform step [1](../quick-start/running-a-hello-ohos-program.md) in the **Running an Image** section to change the serial port number.
-
-
-- **Possible Cause 2**
-
- The U-boot of the board is damaged.
-
-- **Solutions**
-
- Burn the U-boot.
-
- If the fault persists after you perform the preceding operations, the U-boot of the board may be damaged. You can burn the U-boot by performing the following steps:
-
-
-1. Obtain the U-boot file.
-
- > **NOTICE:**
- >The U-boot file of the two boards can be obtained from the following paths, respectively.
- >Hi3516D V300: **device\\hisilicon\\hispark\_taurus\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3516dv300.bin**
- >Hi3518E V300: **device\\hisilicon\\hispark\_aries\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3518ev300.bin**
-
-2. Burn the U-boot file by following the procedures for burning a U-boot file over USB.
-
- Select the U-boot files of corresponding development boards for burning by referring to [Programming Flash Memory on the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681)/[Programming Flash Memory on the Hi3518](https://device.harmonyos.com/en/docs/ide/user-guides/hi3518_upload-0000001057313128)
-
-3. Log in to the serial port after the burning is complete.
-
- 
-
-
diff --git a/en/device-dev/quick-start/faqs.md b/en/device-dev/quick-start/faqs.md
deleted file mode 100644
index 43db6c0373612483fa0cc1e752058e256bf9665e..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/faqs.md
+++ /dev/null
@@ -1,286 +0,0 @@
-# FAQs
-
-- [What should I do when the message configure: error: no acceptable C compiler found in $PATH is displayed during Python 3 installation?](#section1221016541119)
-- [What should I do when the message -bash: make: command not found is displayed during Python 3 installation?](#section1913477181213)
-- [What should I do when the message zlib not available is displayed during Python 3 installation?](#section108211415131210)
-- [What should I do when the message No module named '\_ctypes' is displayed during Python 3 installation?](#section2062268124)
-- [What should I do when the message No module named 'Crypto' is displayed during compilation and building?](#section982315398121)
-- [What should I do when the message No module named 'ecdsa' is displayed during compilation and building?](#section102035451216)
-- [What should I do when the message Could not find a version that satisfies the requirement six\>=1.9.0 is displayed during compilation and building?](#section4498158162320)
-- [What should I do when the message cannot find -lgcc is displayed during compilation and building?](#section11181036112615)
-- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#section1571810194619)
-- [What should I do when an error with lsb\_release occurs during kconfiglib installation?](#section691681635814)
-
-## What should I do when the message **configure: error: no acceptable C compiler found in $PATH** is displayed during Python 3 installation?
-
-- **Symptom**
-
- The following error occurs during Python 3 installation:
-
- ```
- configure: error: no acceptable C compiler found in $PATH. See 'config.log' for more details
- ```
-
-- **Possible Causes**
-
- **GCC** is not installed.
-
-- **Solutions**
-
- 1. Run the **apt-get install gcc** command to install **GCC** online.
-
- 2. After the installation, reinstall Python 3.
-
-
-## What should I do when the message **-bash: make: command not found** is displayed during Python 3 installation?
-
-- **Symptom**
-
- The following error occurs during Python 3 installation:
-
- ```
- -bash: make: command not found
- ```
-
-- **Possible Causes**
-
- **Make** is not installed.
-
-- **Solutions**
-
- 1. Run the **apt-get install make** command to install **Make** online.
-
- 2. After the installation, reinstall Python 3.
-
-
-## What should I do when the message **zlib not available** is displayed during Python 3 installation?
-
-- **Symptom**
-
- The following error occurs during Python 3 installation:
-
- ```
- zipimport.ZipImportError: can't decompress data; zlib not avaliable
- ```
-
-- **Possible Causes**
-
- **zlib** is not installed.
-
-- **Solutions**
-
- Solution 1: Run the **apt-get install zlib** command to install **zlib** online.
-
- Solution 2: If the software source does not contain **zlib**, download the source code from [http://www.zlib.net/](http://www.zlib.net/).
-
- 
-
- Then run the following commands to install **zlib** offline:
-
- ```
- # tar xvf zlib-1.2.11.tar.gz
- # cd zlib-1.2.11
- # ./configure
- # make && make install
- ```
-
- After the installation, reinstall Python 3.
-
-
-## What should I do when the message **No module named '\_ctypes'** is displayed during Python 3 installation?
-
-- **Symptom**
-
- The following error occurs during Python 3 installation:
-
- ```
- ModuleNotFoundError: No module named '_ctypes'
- ```
-
-
-- **Possible Causes**
-
- **libffi** and **libffi-devel** are not installed.
-
-
-- **Solutions**
-
- 1. Run the **apt-get install libffi\* -y** command to install **libffi** and **libffi-devel** online.
-
- 2. After the installation, reinstall Python 3.
-
-
-## What should I do when the message **No module named 'Crypto'** is displayed during compilation and building?
-
-- **Symptom**
-
- The following error occurs during compilation and building:
-
- ```
- ModuleNotFoundError: No module named 'Crypto'
- ```
-
-
-- **Possible Causes**
-
- **Crypto** is not installed.
-
-
-- **Solutions**
-
- Solution 1: Run the **pip3 install Crypto** command to install **Crypto** online.
-
- Solution 2: Install **Crypto** offline.
-
- - Download the source code from [https://pypi.org/project/pycrypto/\#files](https://pypi.org/project/pycrypto/#files).
-
- 
-
- - Save the source code package to the Linux server, decompress the package, and run the **python3 setup.py install** command to install **Crypto**.
- - Rebuild an environment.
-
-
-## What should I do when the message **No module named 'ecdsa'** is displayed during compilation and building?
-
-- **Symptom**
-
- The following error occurs during compilation and building:
-
- ```
- ModuleNotFoundError: No module named 'ecdsa'
- ```
-
-
-- **Possible Causes**
-
- **ecdsa** is not installed.
-
-
-- **Solutions**
-
- Solution 1: Run the **pip3 install ecdsa** command to install **ecdsa** online.
-
- Solution 2: Install **ecdsa** offline.
-
- - Download the installation package from [https://pypi.org/project/ecdsa/\#files](https://pypi.org/project/ecdsa/#files).
-
- 
-
- - Save the installation package to the Linux server and run the **pip3 install ecdsa-0.15-py2.py3-none-any.whl** command to install **ecdsa**.
- - Rebuild an environment.
-
-
-## What should I do when the message **Could not find a version that satisfies the requirement six\>=1.9.0** is displayed during compilation and building?
-
-- **Symptom**
-
- The following error occurs during compilation and building:
-
- ```
- Could not find a version that satisfies the requirement six>=1.9.0
- ```
-
-
-- **Possible Causes**
-
- **six** is not installed.
-
-
-- **Solutions**
-
- Solution 1: Run the **pip3 install six** command to install **six** online.
-
- Solution 2: Install **six** offline.
-
- - Download the installation package from [https://pypi.org/project/six/\#files](https://pypi.org/project/six/#files).
-
- 
-
- - Save the source code to the Linux server and run the **pip3 install six-1.14.0-py2.py3-none-any.whl** command to install **six**.
- - Rebuild an environment.
-
-
-## What should I do when the message **cannot find -lgcc** is displayed during compilation and building?
-
-- **Symptom**
-
- The following error occurs during compilation and building:
-
- ```
- riscv32-unknown-elf-ld: cannot find -lgcc
- ```
-
-
-- **Possible Causes**
-
- The PATH is incorrectly written by **gcc\_riscv32**. There is an extra slash \(/\).
-
- ```
- ~/gcc_riscv32/bin/:/data/toolchain/
- ```
-
-
-- **Solutions**
-
- Modify the PATH by deleting the slash \(/\).
-
- ```
- ~/gcc_riscv32/bin:/data/toolchain/
- ```
-
-
-## What should I do when the message indicating Python cannot be found is displayed during compilation and building?
-
-- **Symptom**
-
- The following error occurs during compilation and building:
-
- ```
- -bash: /usr/bin/python: No such file or directory
- ```
-
-
-- **Possible Cause 1:** Python is not installed.
-- **Solutions**
-
- Install Python by referring to [Installing and Configuring Python](../quick-start/ubuntu-build-environment.md).
-
-- **Possible Cause 2:** The soft link that points to the Python does not exist in the **usr/bin** directory.
-
- 
-
-- **Solutions**
-
- Run the following commands to add a soft link:
-
- ```
- # cd /usr/bin/
- # which python3
- # ln -s /usr/local/bin/python3 python
- # python --version
- ```
-
- Example:
-
- 
-
-
-## What should I do when an error with **lsb\_release** occurs during **kconfiglib** installation?
-
-- **Symptom**
-
- The following error occurs during **kconfiglib** installation:
-
- ```
- subprocess.CalledProcessError: Command '('lsb_release', '-a')' returned non-zero exit status 1.
- ```
-
-- **Possible Causes**
-
- The Python version matched with the **lsb\_release** module is different from the current Python version.
-
-- **Solutions**
-
- Run the **find / -name lsb\_release** command, for example, **sudo rm -rf /usr/bin/lsb\_release** to locate and delete **lsb\_release**.
-
-
diff --git a/en/device-dev/quick-start/figures/1.png b/en/device-dev/quick-start/figure/1.png
similarity index 100%
rename from en/device-dev/quick-start/figures/1.png
rename to en/device-dev/quick-start/figure/1.png
diff --git a/en/device-dev/quick-start/figures/10.png b/en/device-dev/quick-start/figure/10.png
similarity index 100%
rename from en/device-dev/quick-start/figures/10.png
rename to en/device-dev/quick-start/figure/10.png
diff --git a/en/device-dev/quick-start/figures/2.png b/en/device-dev/quick-start/figure/2.png
similarity index 100%
rename from en/device-dev/quick-start/figures/2.png
rename to en/device-dev/quick-start/figure/2.png
diff --git a/en/device-dev/quick-start/figures/2021-01-27_170334-18.png b/en/device-dev/quick-start/figure/2021-01-27_170334-17.png
similarity index 100%
rename from en/device-dev/quick-start/figures/2021-01-27_170334-18.png
rename to en/device-dev/quick-start/figure/2021-01-27_170334-17.png
diff --git a/en/device-dev/quick-start/figures/2021-01-27_170334-19.png b/en/device-dev/quick-start/figure/2021-01-27_170334-18.png
similarity index 100%
rename from en/device-dev/quick-start/figures/2021-01-27_170334-19.png
rename to en/device-dev/quick-start/figure/2021-01-27_170334-18.png
diff --git a/en/device-dev/quick-start/figures/2021-01-27_170334-2.png b/en/device-dev/quick-start/figure/2021-01-27_170334-2.png
similarity index 100%
rename from en/device-dev/quick-start/figures/2021-01-27_170334-2.png
rename to en/device-dev/quick-start/figure/2021-01-27_170334-2.png
diff --git a/en/device-dev/quick-start/figures/2021-01-27_170334-5.png b/en/device-dev/quick-start/figure/2021-01-27_170334-5.png
similarity index 100%
rename from en/device-dev/quick-start/figures/2021-01-27_170334-5.png
rename to en/device-dev/quick-start/figure/2021-01-27_170334-5.png
diff --git a/en/device-dev/quick-start/figures/2021-01-27_170334.png b/en/device-dev/quick-start/figure/2021-01-27_170334.png
similarity index 100%
rename from en/device-dev/quick-start/figures/2021-01-27_170334.png
rename to en/device-dev/quick-start/figure/2021-01-27_170334.png
diff --git a/en/device-dev/quick-start/figures/3-0.png b/en/device-dev/quick-start/figure/3-0.png
similarity index 100%
rename from en/device-dev/quick-start/figures/3-0.png
rename to en/device-dev/quick-start/figure/3-0.png
diff --git a/en/device-dev/quick-start/figures/3.png b/en/device-dev/quick-start/figure/3.png
similarity index 100%
rename from en/device-dev/quick-start/figures/3.png
rename to en/device-dev/quick-start/figure/3.png
diff --git "a/en/device-dev/quick-start/figures/3516\346\255\243\351\235\242.png" "b/en/device-dev/quick-start/figure/3516\346\255\243\351\235\242.png"
similarity index 100%
rename from "en/device-dev/quick-start/figures/3516\346\255\243\351\235\242.png"
rename to "en/device-dev/quick-start/figure/3516\346\255\243\351\235\242.png"
diff --git "a/en/device-dev/quick-start/figures/3861\346\255\243\351\235\242.png" "b/en/device-dev/quick-start/figure/3861\346\255\243\351\235\242.png"
similarity index 100%
rename from "en/device-dev/quick-start/figures/3861\346\255\243\351\235\242.png"
rename to "en/device-dev/quick-start/figure/3861\346\255\243\351\235\242.png"
diff --git a/en/device-dev/quick-start/figures/4.png b/en/device-dev/quick-start/figure/4.png
similarity index 100%
rename from en/device-dev/quick-start/figures/4.png
rename to en/device-dev/quick-start/figure/4.png
diff --git a/en/device-dev/quick-start/figures/5-1.png b/en/device-dev/quick-start/figure/5-1.png
similarity index 100%
rename from en/device-dev/quick-start/figures/5-1.png
rename to en/device-dev/quick-start/figure/5-1.png
diff --git a/en/device-dev/quick-start/figures/5.png b/en/device-dev/quick-start/figure/5.png
similarity index 100%
rename from en/device-dev/quick-start/figures/5.png
rename to en/device-dev/quick-start/figure/5.png
diff --git a/en/device-dev/quick-start/figures/6.png b/en/device-dev/quick-start/figure/6.png
similarity index 100%
rename from en/device-dev/quick-start/figures/6.png
rename to en/device-dev/quick-start/figure/6.png
diff --git a/en/device-dev/quick-start/figures/allowing-the-visual-studio-code-application-to-access-the-network-16.png b/en/device-dev/quick-start/figure/allowing-the-visual-studio-code-application-to-access-the-network-16.png
similarity index 100%
rename from en/device-dev/quick-start/figures/allowing-the-visual-studio-code-application-to-access-the-network-16.png
rename to en/device-dev/quick-start/figure/allowing-the-visual-studio-code-application-to-access-the-network-16.png
diff --git a/en/device-dev/quick-start/figures/allowing-the-visual-studio-code-application-to-access-the-network.png b/en/device-dev/quick-start/figure/allowing-the-visual-studio-code-application-to-access-the-network.png
similarity index 100%
rename from en/device-dev/quick-start/figures/allowing-the-visual-studio-code-application-to-access-the-network.png
rename to en/device-dev/quick-start/figure/allowing-the-visual-studio-code-application-to-access-the-network.png
diff --git a/en/device-dev/quick-start/figures/changjian1-11.png b/en/device-dev/quick-start/figure/changjian1-11.png
similarity index 100%
rename from en/device-dev/quick-start/figures/changjian1-11.png
rename to en/device-dev/quick-start/figure/changjian1-11.png
diff --git a/en/device-dev/quick-start/figures/changjian1.png b/en/device-dev/quick-start/figure/changjian1.png
similarity index 100%
rename from en/device-dev/quick-start/figures/changjian1.png
rename to en/device-dev/quick-start/figure/changjian1.png
diff --git a/en/device-dev/quick-start/figures/checking-whether-the-serial-port-is-used-9.png b/en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used-9.png
similarity index 100%
rename from en/device-dev/quick-start/figures/checking-whether-the-serial-port-is-used-9.png
rename to en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used-9.png
diff --git a/en/device-dev/quick-start/figures/checking-whether-the-serial-port-is-used.png b/en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used.png
similarity index 100%
rename from en/device-dev/quick-start/figures/checking-whether-the-serial-port-is-used.png
rename to en/device-dev/quick-start/figure/checking-whether-the-serial-port-is-used.png
diff --git a/en/device-dev/quick-start/figures/chuankou1-6.png b/en/device-dev/quick-start/figure/chuankou1-6.png
similarity index 100%
rename from en/device-dev/quick-start/figures/chuankou1-6.png
rename to en/device-dev/quick-start/figure/chuankou1-6.png
diff --git a/en/device-dev/quick-start/figures/chuankou1.png b/en/device-dev/quick-start/figure/chuankou1.png
similarity index 100%
rename from en/device-dev/quick-start/figures/chuankou1.png
rename to en/device-dev/quick-start/figure/chuankou1.png
diff --git a/en/device-dev/quick-start/figures/disabling-the-terminal-using-the-serial-port-10.png b/en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port-10.png
similarity index 100%
rename from en/device-dev/quick-start/figures/disabling-the-terminal-using-the-serial-port-10.png
rename to en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port-10.png
diff --git a/en/device-dev/quick-start/figures/disabling-the-terminal-using-the-serial-port.png b/en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port.png
similarity index 100%
rename from en/device-dev/quick-start/figures/disabling-the-terminal-using-the-serial-port.png
rename to en/device-dev/quick-start/figure/disabling-the-terminal-using-the-serial-port.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001056814287.png b/en/device-dev/quick-start/figure/en-us_image_0000001056814287.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001056814287.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001056814287.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001057335403.png b/en/device-dev/quick-start/figure/en-us_image_0000001057335403.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001057335403.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001057335403.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001072468991.png b/en/device-dev/quick-start/figure/en-us_image_0000001072468991.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001072468991.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001072468991.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001072757874.png b/en/device-dev/quick-start/figure/en-us_image_0000001072757874.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001072757874.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001072757874.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001073840162.png b/en/device-dev/quick-start/figure/en-us_image_0000001073840162.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001073840162.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001073840162.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001096154076.png b/en/device-dev/quick-start/figure/en-us_image_0000001096154076.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001096154076.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001096154076.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001100641602.png b/en/device-dev/quick-start/figure/en-us_image_0000001100641602.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001100641602.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001100641602.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001113969542.png b/en/device-dev/quick-start/figure/en-us_image_0000001113969542.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001113969542.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001113969542.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001114129428.png b/en/device-dev/quick-start/figure/en-us_image_0000001114129428.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001114129428.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001114129428.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001114129432.png b/en/device-dev/quick-start/figure/en-us_image_0000001114129432.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001114129432.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001114129432.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001117463460.png b/en/device-dev/quick-start/figure/en-us_image_0000001117463460.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001117463460.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001117463460.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001117621400.png b/en/device-dev/quick-start/figure/en-us_image_0000001117621400.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001117621400.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001117621400.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311066.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311066.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311066.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311066.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311070.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311070.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311070.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311070.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311072.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311072.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311072.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311072.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311090.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311090.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311090.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311090.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311092.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311092.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311092.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311092.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311094.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311094.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311094.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311094.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311096.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311096.png
old mode 100755
new mode 100644
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311096.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311096.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311098.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311098.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311098.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311098.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311100.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311100.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311100.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311100.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311104.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311104.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311104.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311104.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311116.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311116.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311116.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311116.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128311118.png b/en/device-dev/quick-start/figure/en-us_image_0000001128311118.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128311118.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128311118.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128470864.png b/en/device-dev/quick-start/figure/en-us_image_0000001128470864.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128470864.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128470864.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128470880.png b/en/device-dev/quick-start/figure/en-us_image_0000001128470880.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128470880.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128470880.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128470900.png b/en/device-dev/quick-start/figure/en-us_image_0000001128470900.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128470900.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128470900.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128470902.png b/en/device-dev/quick-start/figure/en-us_image_0000001128470902.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128470902.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128470902.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128470904.png b/en/device-dev/quick-start/figure/en-us_image_0000001128470904.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128470904.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128470904.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128470906.png b/en/device-dev/quick-start/figure/en-us_image_0000001128470906.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128470906.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128470906.png
diff --git a/en/device-dev/quick-start/figure/en-us_image_0000001128470908.png b/en/device-dev/quick-start/figure/en-us_image_0000001128470908.png
new file mode 100644
index 0000000000000000000000000000000000000000..8aa65e82be8db2e7de62fca8980d00ae42215d96
Binary files /dev/null and b/en/device-dev/quick-start/figure/en-us_image_0000001128470908.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128470922.png b/en/device-dev/quick-start/figure/en-us_image_0000001128470922.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001128470922.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001128470922.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001142794291.png b/en/device-dev/quick-start/figure/en-us_image_0000001142794291.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001142794291.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001142794291.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001142802505.png b/en/device-dev/quick-start/figure/en-us_image_0000001142802505.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001142802505.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001142802505.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001143154485.png b/en/device-dev/quick-start/figure/en-us_image_0000001143154485.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001143154485.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001143154485.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001160527611.png b/en/device-dev/quick-start/figure/en-us_image_0000001160527611.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001160527611.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001160527611.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001163045527.png b/en/device-dev/quick-start/figure/en-us_image_0000001163045527.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001163045527.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001163045527.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270699.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270699.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270699.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270699.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270713.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270713.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270713.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270713.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270715.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270715.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270715.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270715.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270727.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270727.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270727.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270727.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270729.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270729.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270729.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270729.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270731.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270731.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270731.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270731.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270733.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270733.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270733.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270733.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270735.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270735.png
old mode 100755
new mode 100644
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270735.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270735.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270737.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270737.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270737.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270737.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270739.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270739.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270739.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270739.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270743.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270743.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270743.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270743.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270749.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270749.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270749.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270749.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174270751.png b/en/device-dev/quick-start/figure/en-us_image_0000001174270751.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174270751.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174270751.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350615.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350615.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350615.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350615.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350623.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350623.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350623.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350623.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350633.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350633.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350633.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350633.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350641.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350641.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350641.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350641.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350643.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350643.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350643.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350643.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350647.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350647.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350647.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350647.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350649.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350649.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350649.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350649.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350651.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350651.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350651.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350651.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350653.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350653.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350653.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350653.png
diff --git a/en/device-dev/quick-start/figure/en-us_image_0000001174350655.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350655.png
new file mode 100644
index 0000000000000000000000000000000000000000..2f6e93e40bf4abee3c83aebf0c5f3299e51dc630
Binary files /dev/null and b/en/device-dev/quick-start/figure/en-us_image_0000001174350655.png differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350659.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350659.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350659.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350659.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350661.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350661.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350661.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350661.png
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350669.png b/en/device-dev/quick-start/figure/en-us_image_0000001174350669.png
similarity index 100%
rename from en/device-dev/quick-start/figures/en-us_image_0000001174350669.png
rename to en/device-dev/quick-start/figure/en-us_image_0000001174350669.png
diff --git a/en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection-12.png b/en/device-dev/quick-start/figure/failed-to-obtain-the-image-file-due-to-unavailable-connection-12.png
similarity index 100%
rename from en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection-12.png
rename to en/device-dev/quick-start/figure/failed-to-obtain-the-image-file-due-to-unavailable-connection-12.png
diff --git a/en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection.png b/en/device-dev/quick-start/figure/failed-to-obtain-the-image-file-due-to-unavailable-connection.png
similarity index 100%
rename from en/device-dev/quick-start/figures/failed-to-obtain-the-image-file-due-to-unavailable-connection.png
rename to en/device-dev/quick-start/figure/failed-to-obtain-the-image-file-due-to-unavailable-connection.png
diff --git a/en/device-dev/quick-start/figures/failed-to-open-the-serial-port-8.png b/en/device-dev/quick-start/figure/failed-to-open-the-serial-port-8.png
similarity index 100%
rename from en/device-dev/quick-start/figures/failed-to-open-the-serial-port-8.png
rename to en/device-dev/quick-start/figure/failed-to-open-the-serial-port-8.png
diff --git a/en/device-dev/quick-start/figures/failed-to-open-the-serial-port.png b/en/device-dev/quick-start/figure/failed-to-open-the-serial-port.png
similarity index 100%
rename from en/device-dev/quick-start/figures/failed-to-open-the-serial-port.png
rename to en/device-dev/quick-start/figure/failed-to-open-the-serial-port.png
diff --git a/en/device-dev/quick-start/figures/firewall-and-network-protection-14.png b/en/device-dev/quick-start/figure/firewall-and-network-protection-14.png
similarity index 100%
rename from en/device-dev/quick-start/figures/firewall-and-network-protection-14.png
rename to en/device-dev/quick-start/figure/firewall-and-network-protection-14.png
diff --git a/en/device-dev/quick-start/figures/firewall-and-network-protection.png b/en/device-dev/quick-start/figure/firewall-and-network-protection.png
similarity index 100%
rename from en/device-dev/quick-start/figures/firewall-and-network-protection.png
rename to en/device-dev/quick-start/figure/firewall-and-network-protection.png
diff --git a/en/device-dev/quick-start/figures/front-view-of-the-hi3518e-v300-board.png b/en/device-dev/quick-start/figure/front-view-of-the-hi3518e-v300-board.png
similarity index 100%
rename from en/device-dev/quick-start/figures/front-view-of-the-hi3518e-v300-board.png
rename to en/device-dev/quick-start/figure/front-view-of-the-hi3518e-v300-board.png
diff --git a/en/device-dev/quick-start/figures/hardware-connections-3.png b/en/device-dev/quick-start/figure/hardware-connections-3.png
similarity index 100%
rename from en/device-dev/quick-start/figures/hardware-connections-3.png
rename to en/device-dev/quick-start/figure/hardware-connections-3.png
diff --git a/en/device-dev/quick-start/figures/hardware-connections.png b/en/device-dev/quick-start/figure/hardware-connections.png
similarity index 100%
rename from en/device-dev/quick-start/figures/hardware-connections.png
rename to en/device-dev/quick-start/figure/hardware-connections.png
diff --git "a/en/device-dev/quick-start/figures/hi3518\346\255\243\350\203\214\351\235\242.png" "b/en/device-dev/quick-start/figure/hi3518\346\255\243\350\203\214\351\235\242.png"
similarity index 100%
rename from "en/device-dev/quick-start/figures/hi3518\346\255\243\350\203\214\351\235\242.png"
rename to "en/device-dev/quick-start/figure/hi3518\346\255\243\350\203\214\351\235\242.png"
diff --git a/en/device-dev/quick-start/figures/network-and-firewall-setting-13.png b/en/device-dev/quick-start/figure/network-and-firewall-setting-13.png
similarity index 100%
rename from en/device-dev/quick-start/figures/network-and-firewall-setting-13.png
rename to en/device-dev/quick-start/figure/network-and-firewall-setting-13.png
diff --git a/en/device-dev/quick-start/figures/network-and-firewall-setting.png b/en/device-dev/quick-start/figure/network-and-firewall-setting.png
similarity index 100%
rename from en/device-dev/quick-start/figures/network-and-firewall-setting.png
rename to en/device-dev/quick-start/figure/network-and-firewall-setting.png
diff --git a/en/device-dev/quick-start/figures/qi1.png b/en/device-dev/quick-start/figure/qi1.png
similarity index 100%
rename from en/device-dev/quick-start/figures/qi1.png
rename to en/device-dev/quick-start/figure/qi1.png
diff --git a/en/device-dev/quick-start/figures/selecting-the-visual-studio-code-application-15.png b/en/device-dev/quick-start/figure/selecting-the-visual-studio-code-application-15.png
similarity index 100%
rename from en/device-dev/quick-start/figures/selecting-the-visual-studio-code-application-15.png
rename to en/device-dev/quick-start/figure/selecting-the-visual-studio-code-application-15.png
diff --git a/en/device-dev/quick-start/figures/selecting-the-visual-studio-code-application.png b/en/device-dev/quick-start/figure/selecting-the-visual-studio-code-application.png
similarity index 100%
rename from en/device-dev/quick-start/figures/selecting-the-visual-studio-code-application.png
rename to en/device-dev/quick-start/figure/selecting-the-visual-studio-code-application.png
diff --git a/en/device-dev/quick-start/figures/serial-port-displayed-after-the-u-boot-is-burnt.png b/en/device-dev/quick-start/figure/serial-port-displayed-after-the-u-boot-is-burnt.png
similarity index 100%
rename from en/device-dev/quick-start/figures/serial-port-displayed-after-the-u-boot-is-burnt.png
rename to en/device-dev/quick-start/figure/serial-port-displayed-after-the-u-boot-is-burnt.png
diff --git a/en/device-dev/quick-start/figures/settings-4.png b/en/device-dev/quick-start/figure/settings-4.png
similarity index 100%
rename from en/device-dev/quick-start/figures/settings-4.png
rename to en/device-dev/quick-start/figure/settings-4.png
diff --git a/en/device-dev/quick-start/figures/settings.png b/en/device-dev/quick-start/figure/settings.png
similarity index 100%
rename from en/device-dev/quick-start/figures/settings.png
rename to en/device-dev/quick-start/figure/settings.png
diff --git a/en/device-dev/quick-start/figures/successful-installation-(scons-version-requirement-3-0-4-or-later).png b/en/device-dev/quick-start/figure/successful-installation-(scons-version-requirement-3-0-4-or-later).png
similarity index 100%
rename from en/device-dev/quick-start/figures/successful-installation-(scons-version-requirement-3-0-4-or-later).png
rename to en/device-dev/quick-start/figure/successful-installation-(scons-version-requirement-3-0-4-or-later).png
diff --git a/en/device-dev/quick-start/figures/successful-system-startup-and-program-execution-7.png b/en/device-dev/quick-start/figure/successful-system-startup-and-program-execution-7.png
similarity index 100%
rename from en/device-dev/quick-start/figures/successful-system-startup-and-program-execution-7.png
rename to en/device-dev/quick-start/figure/successful-system-startup-and-program-execution-7.png
diff --git a/en/device-dev/quick-start/figures/successful-system-startup-and-program-execution.png b/en/device-dev/quick-start/figure/successful-system-startup-and-program-execution.png
similarity index 100%
rename from en/device-dev/quick-start/figures/successful-system-startup-and-program-execution.png
rename to en/device-dev/quick-start/figure/successful-system-startup-and-program-execution.png
diff --git "a/en/device-dev/quick-start/figures/\346\210\252\345\233\276.png" "b/en/device-dev/quick-start/figure/\346\210\252\345\233\276.png"
similarity index 100%
rename from "en/device-dev/quick-start/figures/\346\210\252\345\233\276.png"
rename to "en/device-dev/quick-start/figure/\346\210\252\345\233\276.png"
diff --git "a/en/device-dev/quick-start/figures/\347\237\251\345\275\242\345\244\207\344\273\275-292.png" "b/en/device-dev/quick-start/figure/\347\237\251\345\275\242\345\244\207\344\273\275-292.png"
similarity index 100%
rename from "en/device-dev/quick-start/figures/\347\237\251\345\275\242\345\244\207\344\273\275-292.png"
rename to "en/device-dev/quick-start/figure/\347\237\251\345\275\242\345\244\207\344\273\275-292.png"
diff --git "a/en/device-dev/quick-start/figures/3516\346\255\243\351\235\242-17.png" "b/en/device-dev/quick-start/figures/3516\346\255\243\351\235\242-17.png"
deleted file mode 100644
index 1ccb47f20022261cc291e8b435f263c00e8d4a27..0000000000000000000000000000000000000000
Binary files "a/en/device-dev/quick-start/figures/3516\346\255\243\351\235\242-17.png" and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001128471042.png b/en/device-dev/quick-start/figures/en-us_image_0000001128471042.png
deleted file mode 100755
index dd4fd805a602980b08d54eb2856b27253b171d8d..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001128471042.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/en-us_image_0000001174350781.png b/en/device-dev/quick-start/figures/en-us_image_0000001174350781.png
deleted file mode 100755
index 8723967946c1f0bd471434d3422acc3bd6142535..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/en-us_image_0000001174350781.png and /dev/null differ
diff --git a/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png b/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png
deleted file mode 100644
index 216265660cd0364189cd438da8b7e2600a7a5099..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/figures/getting-started-for-the-standard-system.png and /dev/null differ
diff --git a/en/device-dev/quick-start/hi3516-development-board.md b/en/device-dev/quick-start/hi3516-development-board.md
deleted file mode 100644
index 53148cbe9a1fba7264055edc9fdad8eb193c00ad..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/hi3516-development-board.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Hi3516 Development Board
-
-- [Introduction](#section26131214194212)
-- [Development Board Specifications](#section15192203316533)
-
-## Introduction
-
-Hi3516D V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption.
-
-**Figure 1** Front view of the Hi3516D V300 board
-
-
-
-
-## Development Board Specifications
-
-**Table 1** Specifications of the Hi3516 development board
-
-
-
Type
-
-
Specification
-
-
-
-
Processor and internal memory
-
-
Hi3516D V300
DDR3 1GB
8 GB eMMC4.5
-
-
-
External components
-
-
Ethernet port
Audio and video
One voice input
One mono (AC_L) output, connected to a 3 W power amplifier (LM4871)
MicroHDMI (one HDMI 1.4)
-
Camera
Sensor IMX335
M12 lens with a focal length of 4 mm and an aperture of 1.8
-
Display
2.35-inch LCD connector
5.5-inch LCD connector
-
External components and interfaces
microSD card interface
JTAG/I2S interface
ADC interface
Steer gear interface
Grove connector
USB2.0(Type C)
Three function keys: two custom keys and one update key
LED indicator (including green and red)
-
-
-
-
-
-
diff --git a/en/device-dev/quick-start/hi3516.md b/en/device-dev/quick-start/hi3516.md
deleted file mode 100644
index e33aa899315932687a01de028a7f0fccba0a91b2..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/hi3516.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Hi3516
-
-- **[Setting Up the Environment](setting-up-the-environment-2.md)**
-
-- **[Running a Hello OHOS Program](running-a-hello-ohos-program.md)**
-
-- **[Developing a Driver](developing-a-driver.md)**
-
-- **[FAQs](faqs-3.md)**
-
-
diff --git a/en/device-dev/quick-start/hi3518-development-board.md b/en/device-dev/quick-start/hi3518-development-board.md
deleted file mode 100644
index 262d456b50b47d8c91593999dd5a8f2d5a935d66..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/hi3518-development-board.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# Hi3518 Development Board
-
-- [Introduction](#section14815247616)
-- [Development Board Specifications](#section765112478446)
-
-## Introduction
-
-Hi3518E V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and the advanced low-power process and architecture design, leading the industry in terms of low bit rate, high image quality, and low power consumption.
-
-**Figure 1** Front view of the Hi3518E V300 board
-
-
-**Figure 2** Rear view of the Hi3518E V300 board
-
-
-
-
-## Development Board Specifications
-
-**Table 1** Specifications of the Hi3518 development board
-
-
-
Type
-
-
Description
-
-
-
-
Processor core
-
-
Hi3518E V300
-
-
-
Imaging device
-
-
1/2.9 F23
-
-
-
External interfaces
-
-
External microphone
External 8 Ω/1.5 W speaker
-
-
-
External memory interface
-
-
TF card
A maximum file size of 128 GB is allowed (FAT32 format).
-
-
-
-
WLAN protocol
-
-
802.11 b/g/n
-
-
-
-
-
diff --git a/en/device-dev/quick-start/hi3518.md b/en/device-dev/quick-start/hi3518.md
deleted file mode 100644
index 817d4c826164210f795e36503f49dded0c49529e..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/hi3518.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Hi3518
-
-- **[Setting Up the Environment](setting-up-the-environment-4.md)**
-
-- **[Running a Hello OHOS Program](running-a-hello-ohos-program-5.md)**
-
-- **[FAQs](faqs-6.md)**
-
-
diff --git a/en/device-dev/quick-start/hi3861-development-board.md b/en/device-dev/quick-start/hi3861-development-board.md
deleted file mode 100644
index 6790ab0fe64db575950bef8225613438ccbad63a..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/hi3861-development-board.md
+++ /dev/null
@@ -1,157 +0,0 @@
-# Hi3861 Development Board
-
-- [Introduction](#section19352114194115)
-- [Resources and Constraints](#section82610215014)
-- [Development Board Specifications](#section169054431017)
-- [Key Features](#section1317173016507)
-
-## Introduction
-
-The Hi3861 WLAN module is a development board with 2 x 5 cm form factor. It contains a 2.4 GHz WLAN SoC that highly integrates the IEEE 802.11b/g/n baseband and radio frequency \(RF\) circuit. This module provides open and easy-to-use development and debugging environments for running OpenHarmony.
-
-**Figure 1** Appearance of Hi3861 WLAN module
-
-
-
-
-The Hi3861 WLAN module can also be connected to the Hi3861 mother board to expand its peripheral capabilities. The following figure shows the Hi3861 mother board.
-
-**Figure 2** Appearance of the Hi3861 mother board
-
-
-
-
-- The RF circuit includes modules such as the power amplifier \(PA\), low noise amplifier \(LNA\), RF Balun, antenna switch, and power management. It supports a standard bandwidth of 20 MHz and a narrow bandwidth of 5 MHz or 10 MHz, and provides a maximum rate of 72.2 Mbit/s at the physical layer.
-- The Hi3861 WLAN baseband supports the orthogonal frequency division multiplexing \(OFDM\) technology and is backward compatible with the direct sequence spread spectrum \(DSSS\) and complementary code keying \(CCK\) technologies. In addition, the Hi3861 WLAN baseband supports various data rates specified in the IEEE 802.11 b/g/n protocol.
-- The Hi3861 chip integrates the high-performance 32-bit microprocessor, hardware security engine, and various peripheral interfaces. The peripheral interfaces include the Synchronous Peripheral Interface \(SPI\), Universal Asynchronous Receiver & Transmitter \(UART\), the Inter Integrated Circuit \(I2C\), Pulse Width Modulation \(PWM\), General Purpose Input/Output \(GPIO\) interface, and Analog to Digital Converter \(ADC\). The Hi3861 chip also supports the high-speed Secure Digital Input/Output \(SDIO\) 2.0 interface, with a maximum clock frequency of 50 MHz. This chip has a built-in static random access memory \(SRAM\) and flash memory, so that programs can run independently or run from a flash drive.
-- The Hi3861 chip applies to Internet of Things \(IoT\) devices such as smart home appliances.
-
- **Figure 3** Hi3861 functions
-
-
- 
-
-
-## Resources and Constraints
-
-As the Hi3861 only offers 2 MB Flash and 352 KB RAM, use them efficiently when compiling code.
-
-## Development Board Specifications
-
-**Table 1** Hi3861 WLAN module specifications
-
-
-
Type
-
-
Description
-
-
-
-
General specifications
-
-
Operates over 1×1 2.4 GHz frequency band (ch1-ch14).
The physical layer (PHY) complies with the IEEE 802.11b/g/n protocol.
The media access control (MAC) layer complies with the IEEE802.11 d/e/h/i/k/v/w protocol.
-
Includes the built-in public address (PA) and local area network (LAN); integrates transmit-receive (Tx/Rx) switch and Balun.
Supports the station (STA) and access point (AP) modes. When the Hi3861 WLAN module functions as an AP, a maximum of six STAs are supported.
Supports WFA WPA, WFA WPA2 personal, and WPS2.0.
Supports three kinds of packet traffic arbiter (PTA) (2- , 3- , or 4-wire PTA), each of which coexists with the BT or BLE chip.
The input voltage ranges from 2.3 V to 3.6 V.
-
The input/output (I/O) power voltage can be 1.8 V or 3.3 V.
-
Supports self-calibration for RF hardware.
Performs with low power consumption:
Ultra deep sleep mode: 5 μA @ 3.3 V
DTIM1: 1.5 mA @ 3.3 V
DTIM3: 0.8 mA @ 3.3 V
-
-
-
-
PHY features
-
-
Supports all data rates of the single antenna required by the IEEE802.11b/g/n protocol.
Supports a maximum rate of 72.2 Mbps@HT20 MCS7
Supports the standard bandwidth (20 MHz) and narrow bandwidth (5 MHz or 10 MHz).
Supports space-time block coding (STBC).
Supports short guard interval (Short-GI).
-
-
-
MAC features
-
-
Supports aggregate MAC service data unit (A-MPDU) and aggregate MAC protocol data unit (A-MSDU).
Supports block acknowledgment (Blk-ACK).
Supports quality of service (QoS), meeting customer's service requirements.
-
-
-
CPU subsystem
-
-
Integrates a high-performance 32-bit microprocessor with a maximum operating frequency of 160 MHz.
Includes built-in 352 KB SRAM and 288 KB ROM.
Includes a built-in 2 MB flash memory.
-
-
-
Peripheral interfaces
-
-
Include one SDIO interface, two SPI interfaces, two I2C interfaces, three UART interfaces, 15 GPIO interfaces, seven ADC inputs, six PWM interfaces, and one I2S interface (Note: These interfaces are all multiplexed.)
The frequency of the external primary crystal oscillator is 40 MHz or 24 MHz.
-
-
-
Other information
-
-
Package: QFN-32, 5 mm x 5 mm
Operating temperature: –40°C to +85°C
-
-
-
-
-
-## Key Features
-
-OpenHarmony provides a series of available capabilities based on the Hi3861 platform. The following table describes the available key components.
-
-**Table 2** Key components
-
-
-
Component
-
-
Description
-
-
-
-
wlan
-
-
Provides WLAN service, such as connecting to or disconnecting from a station or hotspot, and querying the state of a station or hotspot.
-
-
-
iot controller
-
-
Provides the capability of operating peripherals, including the I2C, I2S, ADC, UART, SPI, SDIO, GPIO, PWM and FLASH.
-
-
-
soft bus
-
-
Provides the capabilities of device discovery and data transmission in the distributed network.
-
-
-
hichainsdk
-
-
Provides the capability of securely transferring data between devices when they are interconnected.
-
-
-
huks
-
-
Provides capabilities of key management, encryption, and decryption.
-
-
-
system ability manager
-
-
Provides a unified OpenHarmony service development framework based on the service-oriented architecture.
-
-
-
bootstrap
-
-
Provides the entry identifier for starting a system service. When the system service management is started, the function identified by bootstrap is called to start a system service.
-
-
-
syspara
-
-
Provides capabilities of obtaining and setting system attributes.
-
-
-
utils
-
-
Provides basic and public capabilities, such as file operations and key-value (KV) storage management.
-
-
-
DFX
-
-
Provides the DFX capabilities, such as logging and printing.
-
-
-
XTS
-
-
Provides a set of OpenHarmony certification test suites.
-
-
-
-
-
diff --git a/en/device-dev/quick-start/hi3861.md b/en/device-dev/quick-start/hi3861.md
deleted file mode 100644
index 100cdfcabc277a736ed2238f4b8cd93e345624a0..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/hi3861.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Hi3861
-
-- **[Setting Up the Environment](setting-up-the-environment.md)**
-
-- **[WLAN Connection](wlan-connection.md)**
-
-- **[Running a Hello World Program](running-a-hello-world-program.md)**
-
-- **[FAQs](faqs.md)**
-
-
diff --git a/en/device-dev/quick-start/how-to-develop.md b/en/device-dev/quick-start/how-to-develop.md
deleted file mode 100644
index 3e5f705cb569a6d3c7f9543dd24a75159e1682aa..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/how-to-develop.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# How to Develop
-
-- **[Hi3861](hi3861.md)**
-
-- **[Hi3516](hi3516.md)**
-
-- **[Hi3518](hi3518.md)**
-
-
diff --git a/en/device-dev/quick-start/introduction-to-the-development-boards.md b/en/device-dev/quick-start/introduction-to-the-development-boards.md
deleted file mode 100644
index 3848dad5841c053f27b1b5f6280a8a34cb6b41c4..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/introduction-to-the-development-boards.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Introduction to the Development Boards
-
-- **[Hi3861 Development Board](hi3861-development-board.md)**
-
-- **[Hi3516 Development Board](hi3516-development-board.md)**
-
-- **[Hi3518 Development Board](hi3518-development-board.md)**
-
-
diff --git a/en/device-dev/quick-start/introduction.md b/en/device-dev/quick-start/introduction.md
deleted file mode 100644
index 7209c5c0f18b55e253bca942025b9d0682e390b3..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/introduction.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Introduction
-
-- [Quick Start Process](#section7825218111517)
-- [Introduction to the Development Board](#en-us_topic_0000001053666242_section047719215429)
-- [Development Board Specifications](#en-us_topic_0000001053666242_section15192203316533)
-
-This document helps you quickly understand how to set up a standard OpenHarmony system, and how to build, burn, and start the system. You can develop the standard system in Windows and build source code in Linux.
-
-This document uses the recommended Hi3516D V300 development board as an example.
-
-## Quick Start Process
-
-The following figure shows the process of getting started for the standard system, during which, you can set up the Ubuntu development environment in Docker mode or by using the installation package.
-
-**Figure 1** Getting started for the standard system
-
-
-## Introduction to the Development Board
-
-Hi3516D V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption.
-
-**Figure 2** Hi3516D V300 front view
-
-
-
-
-## Development Board Specifications
-
-**Table 1** Specifications of the Hi3516 development board
-
-
-
Item
-
-
Description
-
-
-
-
Processor and internal memory
-
-
Hi3516D V300
1 GB DDR3
8 GB eMMC4.5
-
-
-
External components
-
-
Ethernet port
Audio and video
One voice input
One mono (AC_L) output, connected to a 3 W power amplifier (LM4871)
Micro-HDMI (one HDMI 1.4)
-
Cameras
Sensor IMX335
M12 lens with a focal length of 4 mm and an aperture of 1.8
-
Display
2.35-inch LCD connector
5.5-inch LCD connector
-
External components and interfaces
microSD card interface
JTAG/I2S interface
ADC interface
Steer gear interface
Grove connector
USB 2.0 (Type C)
Three function keys: two custom keys and one update key
LED indicator (including green and red)
-
-
-
-
-
-
diff --git a/en/device-dev/quick-start/mini-and-small-systems.md b/en/device-dev/quick-start/mini-and-small-systems.md
deleted file mode 100644
index 458c7109f928cc610f7da07069bebcafa507cda7..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/mini-and-small-systems.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Mini and Small Systems
-
-- **[Overview](overview-0.md)**
-
-- **[Introduction to the Development Boards](introduction-to-the-development-boards.md)**
-
-- **[Environment Setup](environment-setup.md)**
-
-- **[How to Develop](how-to-develop.md)**
-
-
diff --git a/en/device-dev/quick-start/overview.md b/en/device-dev/quick-start/overview.md
deleted file mode 100644
index 4a5832db5a9e81baccd6d4cbb4bf500c0f5a06a3..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/overview.md
+++ /dev/null
@@ -1,175 +0,0 @@
-# Overview
-
-- [System Types](#section767218232110)
-- [Document Outline](#section19810171681218)
-
-This topic provides a panorama of all documents for you to obtain helpful information quickly. These documents are classified based on your learning progress and development scenarios of OpenHarmony.
-
-## System Types
-
-It is good practice to understand the system types for you to find useful documents that can guide your development.
-
-OpenHarmony is an open-source distributed operating system for all scenarios. It uses a component-based design to tailor its features to better suit devices with 128 KiB to GiB-level of RAM. You can integrate a flexible combination of system components based on the hardware capabilities of the device.
-
-To make the integration simple and easy on different hardware, OpenHarmony defines three basic system types. You only need to select a suitable system type and configure the mandatory component set, thereby developing a system for your device at the minimum workload. The definitions of the basic system types are provided as follows for your reference:
-
-- Mini system
-
- A mini system runs on the devices whose memory is greater than or equal to 128 KiB and that are equipped with MCU processors such as Arm Cortex-M and 32-bit RISC-V. This system provides multiple lightweight network protocols and graphics frameworks, and a wide range of read/write components for the IoT bus. Typical products include connection modules, sensors, and wearables for smart home.
-
-- Small system
-
- A small system runs on the devices whose memory is greater than or equal to 1 MiB and that are equipped with application processors such as Arm Cortex-A. This system provides higher security capabilities, standard graphics frameworks, and video encoding and decoding capabilities. Typical products include smart home IP cameras, electronic cat eyes, and routers, and event data recorders \(EDRs\) for smart travel.
-
-- Standard system
-
- A standard system runs on the devices whose memory is greater than or equal to 128 MiB and that are equipped with application processors such as Arm Cortex-A. This system provides a complete application framework supporting the enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. This system applies to high-end refrigerator displays.
-
-
-In addition, OpenHarmony provides a series of optional system components that can be configured as required to support feature extension and customization. These system components are combined to form a series of system capabilities that, for better understanding, are described as features or functions for you to choose.
-
-## Document Outline
-
-- [Mini and Small System Development Guidelines](#table3762949121211)
-- [Standard System Development Guidelines](#table17667535516)
-
-**Table 1** Mini and small system development guidelines \(reference memory < 128 MB\)
-
-
-
-
diff --git a/en/device-dev/quick-start/public_sys-resources/icon-caution.gif b/en/device-dev/quick-start/public_sys-resources/icon-caution.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/public_sys-resources/icon-caution.gif and /dev/null differ
diff --git a/en/device-dev/quick-start/public_sys-resources/icon-danger.gif b/en/device-dev/quick-start/public_sys-resources/icon-danger.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/public_sys-resources/icon-danger.gif and /dev/null differ
diff --git a/en/device-dev/quick-start/public_sys-resources/icon-note.gif b/en/device-dev/quick-start/public_sys-resources/icon-note.gif
deleted file mode 100644
index 6314297e45c1de184204098efd4814d6dc8b1cda..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/public_sys-resources/icon-note.gif and /dev/null differ
diff --git a/en/device-dev/quick-start/public_sys-resources/icon-notice.gif b/en/device-dev/quick-start/public_sys-resources/icon-notice.gif
deleted file mode 100644
index 86024f61b691400bea99e5b1f506d9d9aef36e27..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/public_sys-resources/icon-notice.gif and /dev/null differ
diff --git a/en/device-dev/quick-start/public_sys-resources/icon-tip.gif b/en/device-dev/quick-start/public_sys-resources/icon-tip.gif
deleted file mode 100644
index 93aa72053b510e456b149f36a0972703ea9999b7..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/public_sys-resources/icon-tip.gif and /dev/null differ
diff --git a/en/device-dev/quick-start/public_sys-resources/icon-warning.gif b/en/device-dev/quick-start/public_sys-resources/icon-warning.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/quick-start/public_sys-resources/icon-warning.gif and /dev/null differ
diff --git a/en/device-dev/quick-start/overview-1.md b/en/device-dev/quick-start/quickstart-lite-env-setup-des.md
similarity index 100%
rename from en/device-dev/quick-start/overview-1.md
rename to en/device-dev/quick-start/quickstart-lite-env-setup-des.md
diff --git a/en/device-dev/quick-start/faq.md b/en/device-dev/quick-start/quickstart-lite-env-setup-faqs.md
similarity index 100%
rename from en/device-dev/quick-start/faq.md
rename to en/device-dev/quick-start/quickstart-lite-env-setup-faqs.md
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
new file mode 100644
index 0000000000000000000000000000000000000000..a5ec9aa0dae52356baeb3ba311efe54a00742619
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-env-setup-lin.md
@@ -0,0 +1,361 @@
+# Ubuntu Build Environment
+
+- [Obtaining Source Code and Tools](#section1897711811517)
+- [Obtaining Source Code](#section1545225464016)
+- [Installing and Configuring Python](#section1238412211211)
+- [Installing gn](#section29216201423)
+- [Installing ninja](#section8762358731)
+- [Installing LLVM](#section12202192215415)
+- [Installing hb](#section15794154618411)
+ - [Prerequisites](#section1083283711515)
+ - [Installation Procedure](#section11518484814)
+ - [Uninstalling hb](#section3512551574)
+
+- [Installing Other Tools](#section830511218494)
+ - [Installation Procedure](#section54409586499)
+
+
+Operating system: 64-bit version of Ubuntu 16.04 or later.
+
+Perform the following steps to set up the build environment:
+
+1. Obtain source code.
+2. Install and configure Python.
+3. Install GN.
+4. Install Ninja.
+5. Install LLVM.
+6. Install hb.
+
+> **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).
+
+## Obtaining Source Code and Tools
+
+The following table describes the tools and source code required for setting up the general environment for a Linux server and how to obtain these tools and the source code.
+
+**Table 1** Source code and development tools and their obtaining methods
+
+
+
Provide functions required in compilation and building, such as packaging and creating images.
+
+
Internet
+
+
+
+
+
+> **NOTICE:**
+>- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install compilation tools like **gn** and **ninja**.
+>- \(Recommended\) If you obtain the source code via the mirror site or code repository, install compilation tools such as **gn**, **ninja**, and LLVM. When installing these tools, ensure that their environment variable paths are unique.
+
+## Obtaining Source Code
+
+You need to acquire [source code](../get-code/sourcecode-acquire.md), download it on a Linux server, and decompress it.
+
+## Installing and Configuring Python
+
+1. Start a Linux server.
+2. Check the Python version \(Python 3.7 or later is required\).
+
+ ```
+ python3 --version
+ ```
+
+ If Python version is earlier than 3.7, reinstall Python. Do as follows to install Python, for example, Python 3.8.
+
+ 1. Check the Ubuntu version.
+
+ ```
+ cat /etc/issue
+ ```
+
+ 1. Install Python based on the Ubuntu version.
+ - If the Ubuntu version is 18 or later, run the following command:
+
+ ```
+ sudo apt-get install python3.8
+ ```
+
+ - If the Ubuntu version is 16, perform the following steps:
+
+ a. Install dependency packages.
+
+ ```
+ sudo apt update && sudo apt install software-properties-common
+ ```
+
+ b. Add the source of deadsnakes PPA and press **Enter**.
+
+ ```
+ sudo add-apt-repository ppa:deadsnakes/ppa
+ ```
+
+ c. Install Python 3.8.
+
+ ```
+ sudo apt upgrade && sudo apt install python3.8
+ ```
+
+
+
+3. Set the soft link of **python** and **python3** to **python3.8**.
+
+ ```
+ sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.8 1
+ sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.8 1
+ ```
+
+4. Install and upgrade the Python package management tool \(pip3\) using either of the following methods:
+ - **Command line:**
+
+ ```
+ sudo apt-get install python3-setuptools python3-pip -y
+ sudo pip3 install --upgrade pip
+ ```
+
+ - **Installation package:**
+
+ ```
+ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
+ python get-pip.py
+ ```
+
+
+
+## Installing gn
+
+1. Start a Linux server.
+2. Download [gn](https://repo.huaweicloud.com/harmonyos/compiler/gn/1717/linux/gn-linux-x86-1717.tar.gz).
+3. Create the **gn** folder in the root directory.
+
+ ```
+ mkdir ~/gn
+ ```
+
+4. Decompress the gn installation package to **\~/gn**.
+
+ ```
+ tar -xvf gn-linux-x86-1717.tar.gz -C ~/gn
+ ```
+
+5. Set an environment variable.
+
+ ```
+ vim ~/.bashrc
+ ```
+
+ Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
+
+ ```
+ export PATH=~/gn:$PATH
+ ```
+
+6. Validate the environment variable.
+
+ ```
+ source ~/.bashrc
+ ```
+
+
+## Installing ninja
+
+1. Start a Linux server.
+2. Download [ninja](https://repo.huaweicloud.com/harmonyos/compiler/ninja/1.9.0/linux/ninja.1.9.0.tar).
+3. Decompress the ninja installation package to **\~/ninja**.
+
+ ```
+ tar -xvf ninja.1.9.0.tar -C ~/
+ ```
+
+4. Set an environment variable.
+
+ ```
+ vim ~/.bashrc
+ ```
+
+ Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
+
+ ```
+ export PATH=~/ninja:$PATH
+ ```
+
+5. Validate the environment variable.
+
+ ```
+ source ~/.bashrc
+ ```
+
+
+## Installing LLVM
+
+1. Start a Linux server.
+2. [Download LLVM](https://repo.huaweicloud.com/harmonyos/compiler/clang/10.0.1-62608/linux/llvm.tar.gz).
+
+ > **NOTE:**
+ >For the OpenHarmony\_v1.x branches and tags, click [here](https://repo.huaweicloud.com/harmonyos/compiler/clang/9.0.0-36191/linux/llvm-linux-9.0.0-36191.tar) to download LLVM.
+
+3. Decompress the LLVM installation package to **\~/llvm**.
+
+ ```
+ tar -zxvf llvm.tar.gz -C ~/
+ ```
+
+ > **NOTE:**
+ >For the OpenHarmony\_v1.x branches and tags, run the following command to decompress the LLVM installation package:
+ >```
+ >tar -xvf llvm-linux-9.0.0-36191.tar -C ~/
+ >```
+
+4. Set an environment variable.
+
+ ```
+ vim ~/.bashrc
+ ```
+
+ Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
+
+ ```
+ export PATH=~/llvm/bin:$PATH
+ ```
+
+5. Validate the environment variable.
+
+ ```
+ source ~/.bashrc
+ ```
+
+
+## Installing hb
+
+### Prerequisites
+
+Python 3.7.4 or later has been installed. For details, see [Installing and Configuring Python](#section1238412211211).
+
+### Installation Procedure
+
+1. Install **hb**.
+
+ ```
+ python3 -m pip install --user ohos-build
+ ```
+
+2. Set an environment variable.
+
+ ```
+ vim ~/.bashrc
+ ```
+
+ Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
+
+ ```
+ export PATH=~/.local/bin:$PATH
+ ```
+
+ Update the environment variable.
+
+ ```
+ source ~/.bashrc
+ ```
+
+3. Run the **hb -h** command. If the following information is displayed, the installation is successful:
+
+ ```
+ usage: hb
+
+ OHOS build system
+
+ positional arguments:
+ {build,set,env,clean}
+ build Build source code
+ set OHOS build settings
+ env Show OHOS build env
+ clean Clean output
+
+ optional arguments:
+ -h, --help Show this help message and exit
+ ```
+
+
+### Uninstalling hb
+
+```
+python3 -m pip uninstall ohos-build
+```
+
+> **NOTICE:**
+>If you encounter any problem during the installation, resort to the [FAQ](quickstart-lite-env-setup-faqs.md).
+
+## Installing Other Tools
+
+### Installation Procedure
+
+1. Use **apt-get** to install dependent tools.
+
+ ```
+ sudo apt-get install build-essential gcc g++ make zlib* libffi-dev e2fsprogs pkg-config flex bison perl bc openssl libssl-dev libelf-dev libc6-dev-amd64 binutils binutils-dev libdwarf-dev u-boot-tools mtd-utils gcc-arm-linux-gnueabi
+ ```
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-env-setup-win.md b/en/device-dev/quick-start/quickstart-lite-env-setup-win.md
new file mode 100644
index 0000000000000000000000000000000000000000..5cb943bfdb1881cf0384cff15036cc6cdf7aea74
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-env-setup-win.md
@@ -0,0 +1,182 @@
+# Windows Development Environment
+
+- [Obtaining the Software](#en-us_topic_0000001058091994_section1483143015558)
+- [Installing Visual Studio Code](#en-us_topic_0000001058091994_section71401018163318)
+- [Installing Python](#en-us_topic_0000001058091994_section16266553175320)
+- [Installing Node.js](#en-us_topic_0000001058091994_section5353233124511)
+- [Installing hpm](#en-us_topic_0000001058091994_section173054793610)
+- [Installing the DevEco Device Tool Plug-in](#en-us_topic_0000001058091994_section4336315185716)
+
+Operating system: 64-bit version of Windows 10.
+
+DevEco Device Tool is a plug-in for Visual Studio Code. The installation procedure includes five parts:
+
+1. Installing Visual Studio Code
+2. Installing Python
+3. Installing Node.js
+4. Installing hpm
+5. Installing the DevEco Device Tool Plug-in
+
+## Obtaining the Software
+
+
+
+
+## Installing Visual Studio Code
+
+> **NOTE:**
+>If you have installed Visual Studio Code, open the CLT and run **code --version** to check whether the version is 1.53 or later. If the version number is returned, it indicates that the environment variables are set correctly.
+
+1. Double-click the Visual Studio Code package to install it. During the installation, select **Add to PATH \(requires shell restart\)**.
+
+ 
+
+2. After the installation is complete, restart the computer for the environment variables of Visual Studio Code to take effect.
+3. Open the CLT and run **code --version**. If the version number can be displayed, it indicates that the installation is successful.
+
+## Installing Python
+
+1. Double-click the Python software package, select **Add Python 3.8 to PATH**, and click **Install Now**.
+
+ 
+
+2. After the installation is complete, click **Close**.
+
+ 
+
+3. Open the CLT, and run **python --version** to check the installation result.
+
+ 
+
+4. In the CLT, run the following commands to set the pip source for downloading the dependencies required for later installation:
+
+ ```
+ pip config set global.trusted-host repo.huaweicloud.com
+ pip config set global.index-url https://repo.huaweicloud.com/repository/pypi/simple
+ pip config set global.timeout 120
+ ```
+
+
+## Installing Node.js
+
+> **NOTE:**
+>If you have installed Node.js, open the CLT and run **node -v** to check whether the version is 12.0.0 or later.
+
+1. Run the downloaded software package to install. Use the default settings when following the installation wizard, and click **Next** until **Finish** is displayed. During the installation, Node.js will automatically set the system Path environment variable to the installation directory of **node.exe**.
+2. Open the CLT and run **node -v**. If the version number of Node.js is displayed, it indicates that Node.js has been successfully installed.
+
+ 
+
+
+## Installing hpm
+
+Before installing hpm, ensure that Node.js has been installed
+
+and that your network can access the Internet. If your network requires a proxy to access the Internet, [set up the npm proxy](https://device.harmonyos.com/en/docs/ide/user-guides/npm_proxy-0000001054491032) first.
+
+> **NOTE:**
+>If hpm has been installed, run **npm update -g @ohos/hpm-cli** to update it to the latest version.
+
+1. You are advised to set the npm source to an image in China, for example, a HUAWEI CLOUD image source.
+
+ ```
+ npm config set registry https://repo.huaweicloud.com/repository/npm/
+ ```
+
+2. Open the CLT and run the following command to install the latest version of hpm:
+
+ ```
+ npm install -g @ohos/hpm-cli
+ ```
+
+ 
+
+3. After the installation is complete, run the following command to obtain the installation result:
+
+ ```
+ hpm -V
+ ```
+
+ 
+
+
+## Installing the DevEco Device Tool Plug-in
+
+To install the DevEco Device Tool plug-in, ensure that the **user name of the host cannot contain Chinese characters**; otherwise, the plug-in may fail to run.
+
+DevEco Device Tool will automatically download and install the C/C++ and CodeLLDB plug-ins from the Visual Studio Code Marketplace during the installation process. Therefore, make sure Visual Studio Code can access the Internet. If your network requires a proxy to access the Internet, [set up the Visual Studio Code proxy](https://device.harmonyos.com/en/docs/ide/user-guides/vscode_proxy-0000001074231144) first.
+
+> **NOTE:**
+>Before installing DevEco Device Tool, ensure that Visual Studio Code is closed.
+
+1. Decompress the DevEco Device Tool plug-in package and double-click the installer to install.
+2. During the installation, the dependency files \(such as C/C++ and CodeLLDB plug-ins\) and execution programs required by DevEco Device Tool are automatically installed.
+
+ 
+
+3. After the installation is complete, the CLT is automatically closed.
+4. Open Visual Studio Code, click the  button on the left, and check whether C/C++, CodeLLDB, and DevEco Device Tool are listed in **INSTALLED**.
+
+ > **NOTE:**
+ >If the C/C++ and CodeLLDB plug-ins fail to be installed, DevEco Device Tool cannot run properly. To solve the issue, see [Installing the C/C++ and CodeLLDB Plug-ins Offline](https://device.harmonyos.com/en/docs/ide/user-guides/offline_plugin_install-0000001074376846).
+
+ 
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-env-setup.md b/en/device-dev/quick-start/quickstart-lite-env-setup.md
new file mode 100644
index 0000000000000000000000000000000000000000..ae5573f8c093656b5b2dc1f91dc80ee5e9e7c4bf
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-env-setup.md
@@ -0,0 +1,11 @@
+# Environment Setup
+
+- **[Overview](quickstart-lite-env-setup-des.md)**
+
+- **[Windows Development Environment](quickstart-lite-env-setup-win.md)**
+
+- **[Ubuntu Build Environment](quickstart-lite-env-setup-lin.md)**
+
+- **[FAQ](quickstart-lite-env-setup-faqs.md)**
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md b/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md
new file mode 100644
index 0000000000000000000000000000000000000000..69fcc82dfeba427de884a26a709551cdd50aa0b8
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md
@@ -0,0 +1,42 @@
+# Hi3516 Development Board
+
+- [Introduction](#section26131214194212)
+- [Development Board Specifications](#section15192203316533)
+
+## Introduction
+
+Hi3516D V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and a high-performance NNIE engine, leading the industry in terms of low bit rate, high image quality, intelligent processing and analysis, and low power consumption.
+
+**Figure 1** Front view of the Hi3516D V300 board
+
+
+
+
+## Development Board Specifications
+
+**Table 1** Specifications of the Hi3516 development board
+
+
+
Type
+
+
Specification
+
+
+
+
Processor and internal memory
+
+
Hi3516D V300
DDR3 1GB
8 GB eMMC4.5
+
+
+
External components
+
+
Ethernet port
Audio and video
One voice input
One mono (AC_L) output, connected to a 3 W power amplifier (LM4871)
MicroHDMI (one HDMI 1.4)
+
Camera
Sensor IMX335
M12 lens with a focal length of 4 mm and an aperture of 1.8
+
Display
2.35-inch LCD connector
5.5-inch LCD connector
+
External components and interfaces
microSD card interface
JTAG/I2S interface
ADC interface
Steer gear interface
Grove connector
USB2.0(Type C)
Three function keys: two custom keys and one update key
LED indicator (including green and red)
+
+
+
+
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-introduction-hi3518.md b/en/device-dev/quick-start/quickstart-lite-introduction-hi3518.md
new file mode 100644
index 0000000000000000000000000000000000000000..4e050a388c0bd04733b5b37a6849e7a1d8fbf143
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-introduction-hi3518.md
@@ -0,0 +1,57 @@
+# Hi3518 Development Board
+
+- [Introduction](#section14815247616)
+- [Development Board Specifications](#section765112478446)
+
+## Introduction
+
+Hi3518E V300 is a next-generation system on chip \(SoC\) designed for the industry-dedicated smart HD IP camera. It introduces a next-generation image signal processor \(ISP\), the H.265 video compression encoder, and the advanced low-power process and architecture design, leading the industry in terms of low bit rate, high image quality, and low power consumption.
+
+**Figure 1** Front view of the Hi3518E V300 board
+
+
+**Figure 2** Rear view of the Hi3518E V300 board
+
+
+
+
+## Development Board Specifications
+
+**Table 1** Specifications of the Hi3518 development board
+
+
+
Type
+
+
Description
+
+
+
+
Processor core
+
+
Hi3518E V300
+
+
+
Imaging device
+
+
1/2.9 F23
+
+
+
External interfaces
+
+
External microphone
External 8 Ω/1.5 W speaker
+
+
+
External memory interface
+
+
TF card
A maximum file size of 128 GB is allowed (FAT32 format).
+
+
+
+
WLAN protocol
+
+
802.11 b/g/n
+
+
+
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md b/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md
new file mode 100644
index 0000000000000000000000000000000000000000..3a8c051e1c78e97241c6d8407a9e7c37afe50c4b
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md
@@ -0,0 +1,157 @@
+# Hi3861 Development Board
+
+- [Introduction](#section19352114194115)
+- [Resources and Constraints](#section82610215014)
+- [Development Board Specifications](#section169054431017)
+- [Key Features](#section1317173016507)
+
+## Introduction
+
+The Hi3861 WLAN module is a development board with 2 x 5 cm form factor. It contains a 2.4 GHz WLAN SoC that highly integrates the IEEE 802.11b/g/n baseband and radio frequency \(RF\) circuit. This module provides open and easy-to-use development and debugging environments for running OpenHarmony.
+
+**Figure 1** Appearance of Hi3861 WLAN module
+
+
+
+
+The Hi3861 WLAN module can also be connected to the Hi3861 mother board to expand its peripheral capabilities. The following figure shows the Hi3861 mother board.
+
+**Figure 2** Appearance of the Hi3861 mother board
+
+
+
+
+- The RF circuit includes modules such as the power amplifier \(PA\), low noise amplifier \(LNA\), RF Balun, antenna switch, and power management. It supports a standard bandwidth of 20 MHz and a narrow bandwidth of 5 MHz or 10 MHz, and provides a maximum rate of 72.2 Mbit/s at the physical layer.
+- The Hi3861 WLAN baseband supports the orthogonal frequency division multiplexing \(OFDM\) technology and is backward compatible with the direct sequence spread spectrum \(DSSS\) and complementary code keying \(CCK\) technologies. In addition, the Hi3861 WLAN baseband supports various data rates specified in the IEEE 802.11 b/g/n protocol.
+- The Hi3861 chip integrates the high-performance 32-bit microprocessor, hardware security engine, and various peripheral interfaces. The peripheral interfaces include the Synchronous Peripheral Interface \(SPI\), Universal Asynchronous Receiver & Transmitter \(UART\), the Inter Integrated Circuit \(I2C\), Pulse Width Modulation \(PWM\), General Purpose Input/Output \(GPIO\) interface, and Analog to Digital Converter \(ADC\). The Hi3861 chip also supports the high-speed Secure Digital Input/Output \(SDIO\) 2.0 interface, with a maximum clock frequency of 50 MHz. This chip has a built-in static random access memory \(SRAM\) and flash memory, so that programs can run independently or run from a flash drive.
+- The Hi3861 chip applies to Internet of Things \(IoT\) devices such as smart home appliances.
+
+ **Figure 3** Hi3861 functions
+
+
+ 
+
+
+## Resources and Constraints
+
+As the Hi3861 only offers 2 MB Flash and 352 KB RAM, use them efficiently when compiling code.
+
+## Development Board Specifications
+
+**Table 1** Hi3861 WLAN module specifications
+
+
+
Type
+
+
Description
+
+
+
+
General specifications
+
+
Operates over 1×1 2.4 GHz frequency band (ch1-ch14).
The physical layer (PHY) complies with the IEEE 802.11b/g/n protocol.
The media access control (MAC) layer complies with the IEEE802.11 d/e/h/i/k/v/w protocol.
+
Includes the built-in public address (PA) and local area network (LAN); integrates transmit-receive (Tx/Rx) switch and Balun.
Supports the station (STA) and access point (AP) modes. When the Hi3861 WLAN module functions as an AP, a maximum of six STAs are supported.
Supports WFA WPA, WFA WPA2 personal, and WPS2.0.
Supports three kinds of packet traffic arbiter (PTA) (2- , 3- , or 4-wire PTA), each of which coexists with the BT or BLE chip.
The input voltage ranges from 2.3 V to 3.6 V.
+
The input/output (I/O) power voltage can be 1.8 V or 3.3 V.
+
Supports self-calibration for RF hardware.
Performs with low power consumption:
Ultra deep sleep mode: 5 μA @ 3.3 V
DTIM1: 1.5 mA @ 3.3 V
DTIM3: 0.8 mA @ 3.3 V
+
+
+
+
PHY features
+
+
Supports all data rates of the single antenna required by the IEEE802.11b/g/n protocol.
Supports a maximum rate of 72.2 Mbps@HT20 MCS7
Supports the standard bandwidth (20 MHz) and narrow bandwidth (5 MHz or 10 MHz).
Supports space-time block coding (STBC).
Supports short guard interval (Short-GI).
+
+
+
MAC features
+
+
Supports aggregate MAC service data unit (A-MPDU) and aggregate MAC protocol data unit (A-MSDU).
Supports block acknowledgment (Blk-ACK).
Supports quality of service (QoS), meeting customer's service requirements.
+
+
+
CPU subsystem
+
+
Integrates a high-performance 32-bit microprocessor with a maximum operating frequency of 160 MHz.
Includes built-in 352 KB SRAM and 288 KB ROM.
Includes a built-in 2 MB flash memory.
+
+
+
Peripheral interfaces
+
+
Include one SDIO interface, two SPI interfaces, two I2C interfaces, three UART interfaces, 15 GPIO interfaces, seven ADC inputs, six PWM interfaces, and one I2S interface (Note: These interfaces are all multiplexed.)
The frequency of the external primary crystal oscillator is 40 MHz or 24 MHz.
+
+
+
Other information
+
+
Package: QFN-32, 5 mm x 5 mm
Operating temperature: –40°C to +85°C
+
+
+
+
+
+## Key Features
+
+OpenHarmony provides a series of available capabilities based on the Hi3861 platform. The following table describes the available key components.
+
+**Table 2** Key components
+
+
+
Component
+
+
Description
+
+
+
+
wlan
+
+
Provides WLAN service, such as connecting to or disconnecting from a station or hotspot, and querying the state of a station or hotspot.
+
+
+
iot controller
+
+
Provides the capability of operating peripherals, including the I2C, I2S, ADC, UART, SPI, SDIO, GPIO, PWM and FLASH.
+
+
+
soft bus
+
+
Provides the capabilities of device discovery and data transmission in the distributed network.
+
+
+
hichainsdk
+
+
Provides the capability of securely transferring data between devices when they are interconnected.
+
+
+
huks
+
+
Provides capabilities of key management, encryption, and decryption.
+
+
+
system ability manager
+
+
Provides a unified OpenHarmony service development framework based on the service-oriented architecture.
+
+
+
bootstrap
+
+
Provides the entry identifier for starting a system service. When the system service management is started, the function identified by bootstrap is called to start a system service.
+
+
+
syspara
+
+
Provides capabilities of obtaining and setting system attributes.
+
+
+
utils
+
+
Provides basic and public capabilities, such as file operations and key-value (KV) storage management.
+
+
+
DFX
+
+
Provides the DFX capabilities, such as logging and printing.
+
+
+
XTS
+
+
Provides a set of OpenHarmony certification test suites.
+
+
+
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-introduction.md b/en/device-dev/quick-start/quickstart-lite-introduction.md
new file mode 100644
index 0000000000000000000000000000000000000000..39c2b6911dc8f1b529884b5b5e457c6e01e65c62
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-introduction.md
@@ -0,0 +1,9 @@
+# Introduction to the Development Boards
+
+- **[Hi3861 Development Board](quickstart-lite-introduction-hi3861.md)**
+
+- **[Hi3516 Development Board](quickstart-lite-introduction-hi3516.md)**
+
+- **[Hi3518 Development Board](quickstart-lite-introduction-hi3518.md)**
+
+
diff --git a/en/device-dev/quick-start/overview-0.md b/en/device-dev/quick-start/quickstart-lite-overview.md
similarity index 100%
rename from en/device-dev/quick-start/overview-0.md
rename to en/device-dev/quick-start/quickstart-lite-overview.md
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3516-faqs.md b/en/device-dev/quick-start/quickstart-lite-steps-board3516-faqs.md
new file mode 100644
index 0000000000000000000000000000000000000000..8c597eeca8ee9b47ac9e7592e9d7846111f4e5b1
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3516-faqs.md
@@ -0,0 +1,172 @@
+# FAQs
+
+- [What should I do when the images failed to be burnt over the selected serial port?](#section627268185113)
+- [What should I do when Windows-based PC failed to be connected to the board?](#section195391036568)
+- [What should I do when the image failed to be burnt?](#section571164016565)
+- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#section1039835245619)
+- [What should I do when no command output is displayed?](#section14871149155911)
+
+## What should I do when the images failed to be burnt over the selected serial port?
+
+- **Symptom**
+
+ **Error: Opening COMxx: Access denied** is displayed after clicking **Burn** and selecting a serial port.
+
+ **Figure 1** Failed to open the serial port
+ 
+
+- **Possible Causes**
+
+ The serial port has been used.
+
+- **Solutions**
+
+1. Search for the terminal using serial-xx from the drop-down list in the **TERMINAL** panel.
+
+ **Figure 2** Checking whether the serial port is used
+ 
+
+2. Click the dustbin icon as shown in the following figure to disable the terminal using the serial port.
+
+ **Figure 3** Disabling the terminal using the serial port
+ 
+
+3. Click **Burn**, select the serial port, and start burning images again.
+
+ **Figure 4** Restarting burning
+
+
+ 
+
+
+## What should I do when Windows-based PC failed to be connected to the board?
+
+- **Symptom**
+
+ The file image cannot be obtained after clicking **Burn** and selecting a serial port.
+
+ **Figure 5** Failed to obtain the image file due to unavailable connection
+ 
+
+- **Possible Causes**
+
+ The board is disconnected from the Windows-based PC.
+
+ Windows Firewall does not allow Visual Studio Code to access the network.
+
+- **Solutions**
+
+1. Check whether the network cable is properly connected.
+2. Click **Windows Firewall**.
+
+ **Figure 6** Network and firewall setting
+ 
+
+3. Click **Firewall & network protection**, and on the displayed page, click **Allow applications to communicate through Windows Firewall**.
+
+ **Figure 7** Firewall and network protection
+ 
+
+4. Select the Visual Studio Code application.
+
+ **Figure 8** Selecting the Visual Studio Code application
+ 
+
+5. Select the **Private** and **Public** network access rights for the Visual Studio Code application.
+
+ **Figure 9** Allowing the Visual Studio Code application to access the network
+ 
+
+
+## What should I do when the image failed to be burnt?
+
+- **Symptom**
+
+ The burning status is not displayed after clicking **Burn** and selecting a serial port.
+
+- **Possible Causes**
+
+ The IDE is not restarted after the DevEco plug-in is installed.
+
+- **Solutions**
+
+ Restart the IDE.
+
+
+## What should I do when the message indicating Python cannot be found is displayed during compilation and building?
+
+- **Symptom**
+
+ 
+
+
+- **Possible Cause 1**: Python is not installed.
+- **Solutions**
+
+ Install Python by referring to [Installing and Configuring Python](quickstart-lite-env-setup-lin.md).
+
+- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
+
+ 
+
+- **Solutions**
+
+ Run the following commands:
+
+ ```
+ # cd /usr/bin/
+ # which python3
+ # ln -s /usr/local/bin/python3 python
+ # python --version
+ ```
+
+ Example:
+
+ 
+
+
+## What should I do when no command output is displayed?
+
+- **Symptom**
+
+ The serial port shows that the connection has been established. After the board is restarted, nothing is displayed when you press **Enter**.
+
+- **Possible Cause 1**
+
+ The serial port is connected incorrectly.
+
+- **Solutions**
+
+ Change the serial port number.
+
+ Start **Device Manager** to check whether the serial port connected to the board is the same as that connected to the terminal device. If the serial ports are different, perform step [1](#section627268185113) in the **Running an Image** section to change the serial port number.
+
+
+- **Possible Cause 2**
+
+ The U-boot of the board is damaged.
+
+- **Solutions**
+
+ Burn the U-boot.
+
+ If the fault persists after you perform the preceding operations, the U-boot of the board may be damaged. You can burn the U-boot by performing the following steps:
+
+
+1. Obtain the U-boot file.
+
+ > **NOTICE:**
+ >The U-boot file of the two boards can be obtained from the following paths, respectively.
+ >Hi3516D V300: **device\\hisilicon\\hispark\_taurus\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3516dv300.bin**
+ >Hi3518E V300: **device\\hisilicon\\hispark\_aries\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3518ev300.bin**
+
+2. Burn the U-boot file by following the procedures for burning a U-boot file over USB.
+
+ Select the U-boot files of corresponding development boards for burning by referring to [Programming Flash Memory on the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681)/[Programming Flash Memory on the Hi3518](https://device.harmonyos.com/en/docs/ide/user-guides/hi3518_upload-0000001057313128)
+
+3. Log in to the serial port after the burning is complete.
+
+ **Figure 10** Serial port displayed after the U-boot is burnt
+ 
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3516-program.md b/en/device-dev/quick-start/quickstart-lite-steps-board3516-program.md
new file mode 100644
index 0000000000000000000000000000000000000000..e541eb5237923c4715d3a4b16249360a1d06a9c3
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3516-program.md
@@ -0,0 +1,503 @@
+# Developing a Driver
+
+- [Introduction to Driver](#s8efc1952ebfe4d1ea717182e108c29bb)
+- [Compiling and Burning](#section660016185110)
+- [Running an Image](#section333215226219)
+- [Follow-up Learning](#section9712145420182)
+
+This section describes how to develop a driver on the board, including introduction, compilation, burning, and running of the driver.
+
+## Introduction to Driver
+
+The following operations take a HDF-based UART driver as an example to show how to add configuration files, code the driver, and compile the code for interactions between the user-space applications and the driver. The driver source code is stored in the **vendor/huawei/hdf/sample** directory.
+
+1. Add Configurations.
+
+ Add driver configurations to the HDF driver configuration file \(for example, **device/hisilicon/hi3516dv300/sdk\_liteos/config/uart/uart\_config.hcs**\).
+
+ ```
+ root {
+ platform {
+ uart_sample {
+ num = 5; // UART device number
+ base = 0x120a0000; // Base address of the UART register
+ irqNum = 38;
+ baudrate = 115200;
+ uartClk = 24000000;
+ wlen = 0x60;
+ parity = 0;
+ stopBit = 0;
+ match_attr = "sample_uart_5";
+ }
+ }
+ }
+ ```
+
+ Add the device node information to the HDF device configuration file \(for example, **vendor/hisilicon/ipcamera\_hi3516dv300\_liteos/config/device\_info/device\_info.hcs**\)
+
+ ```
+ root {
+ device_info {
+ platform :: host {
+ hostName = "platform_host";
+ priority = 50;
+ device_uart :: device {
+ device5 :: deviceNode {
+ policy = 2;
+ priority = 10;
+ permission = 0660;
+ moduleName = "UART_SAMPLE";
+ serviceName = "HDF_PLATFORM_UART_5";
+ deviceMatchAttr = "sample_uart_5";
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ > **NOTE:**
+ >The configuration files are in the same path as the source code of the UART driver. You need to manually add the files to the path of the Hi3516D V300 development board.
+
+2. Register a UART driver entry.
+
+ Register the **HdfDriverEntry** of the UART driver with the HDF.
+
+ ```
+ // Bind the UART driver interface to the HDF.
+ static int32_t SampleUartDriverBind(struct HdfDeviceObject *device)
+ {
+ struct UartHost *uartHost = NULL;
+
+ if (device == NULL) {
+ return HDF_ERR_INVALID_OBJECT;
+ }
+ HDF_LOGI("Enter %s:", __func__);
+
+ uartHost = UartHostCreate(device);
+ if (uartHost == NULL) {
+ HDF_LOGE("%s: UartHostCreate failed", __func__);
+ return HDF_FAILURE;
+ }
+ uartHost->service.Dispatch = SampleDispatch;
+ return HDF_SUCCESS;
+ }
+
+ // Obtain configuration information from the HCS of the UART driver.
+ static uint32_t GetUartDeviceResource(
+ struct UartDevice *device, const struct DeviceResourceNode *resourceNode)
+ {
+ struct UartResource *resource = &device->resource;
+ struct DeviceResourceIface *dri = NULL;
+ dri = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);
+ if (dri == NULL || dri->GetUint32 == NULL) {
+ HDF_LOGE("DeviceResourceIface is invalid");
+ return HDF_FAILURE;
+ }
+
+ if (dri->GetUint32(resourceNode, "num", &resource->num, 0) != HDF_SUCCESS) {
+ HDF_LOGE("uart config read num fail");
+ return HDF_FAILURE;
+ }
+ if (dri->GetUint32(resourceNode, "base", &resource->base, 0) != HDF_SUCCESS) {
+ HDF_LOGE("uart config read base fail");
+ return HDF_FAILURE;
+ }
+ resource->physBase = (unsigned long)OsalIoRemap(resource->base, 0x48);
+ if (resource->physBase == 0) {
+ HDF_LOGE("uart config fail to remap physBase");
+ return HDF_FAILURE;
+ }
+ if (dri->GetUint32(resourceNode, "irqNum", &resource->irqNum, 0) != HDF_SUCCESS) {
+ HDF_LOGE("uart config read irqNum fail");
+ return HDF_FAILURE;
+ }
+ if (dri->GetUint32(resourceNode, "baudrate", &resource->baudrate, 0) != HDF_SUCCESS) {
+ HDF_LOGE("uart config read baudrate fail");
+ return HDF_FAILURE;
+ }
+ if (dri->GetUint32(resourceNode, "wlen", &resource->wlen, 0) != HDF_SUCCESS) {
+ HDF_LOGE("uart config read wlen fail");
+ return HDF_FAILURE;
+ }
+ if (dri->GetUint32(resourceNode, "parity", &resource->parity, 0) != HDF_SUCCESS) {
+ HDF_LOGE("uart config read parity fail");
+ return HDF_FAILURE;
+ }
+ if (dri->GetUint32(resourceNode, "stopBit", &resource->stopBit, 0) != HDF_SUCCESS) {
+ HDF_LOGE("uart config read stopBit fail");
+ return HDF_FAILURE;
+ }
+ if (dri->GetUint32(resourceNode, "uartClk", &resource->uartClk, 0) != HDF_SUCCESS) {
+ HDF_LOGE("uart config read uartClk fail");
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+ }
+
+ // Attach the configuration and interface of the UART driver to the HDF.
+ static int32_t AttachUartDevice(struct UartHost *host, struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ struct UartDevice *uartDevice = NULL;
+ if (device->property == NULL) {
+ HDF_LOGE("%s: property is NULL", __func__);
+ return HDF_FAILURE;
+ }
+ uartDevice = (struct UartDevice *)OsalMemCalloc(sizeof(struct UartDevice));
+ if (uartDevice == NULL) {
+ HDF_LOGE("%s: OsalMemCalloc uartDevice error", __func__);
+ return HDF_ERR_MALLOC_FAIL;
+ }
+ ret = GetUartDeviceResource(uartDevice, device->property);
+ if (ret != HDF_SUCCESS) {
+ (void)OsalMemFree(uartDevice);
+ return HDF_FAILURE;
+ }
+ host->num = uartDevice->resource.num;
+ host->priv = uartDevice;
+ AddUartDevice(host);
+ return InitUartDevice(uartDevice);
+ }
+
+ // Initialize the UART driver.
+ static int32_t SampleUartDriverInit(struct HdfDeviceObject *device)
+ {
+ int32_t ret;
+ struct UartHost *host = NULL;
+
+ if (device == NULL) {
+ HDF_LOGE("%s: device is NULL", __func__);
+ return HDF_ERR_INVALID_OBJECT;
+ }
+ HDF_LOGI("Enter %s:", __func__);
+ host = UartHostFromDevice(device);
+ if (host == NULL) {
+ HDF_LOGE("%s: host is NULL", __func__);
+ return HDF_FAILURE;
+ }
+ ret = AttachUartDevice(host, device);
+ if (ret != HDF_SUCCESS) {
+ HDF_LOGE("%s: attach error", __func__);
+ return HDF_FAILURE;
+ }
+ host->method = &g_sampleUartHostMethod;
+ return ret;
+ }
+
+ static void DeinitUartDevice(struct UartDevice *device)
+ {
+ struct UartRegisterMap *regMap = (struct UartRegisterMap *)device->resource.physBase;
+ /* Wait for the UART to enter the idle state. */
+ while (UartPl011IsBusy(regMap));
+ UartPl011ResetRegisters(regMap);
+ uart_clk_cfg(0, false);
+ OsalIoUnmap((void *)device->resource.physBase);
+ device->state = UART_DEVICE_UNINITIALIZED;
+ }
+
+ // Detach and release the UART driver.
+ static void DetachUartDevice(struct UartHost *host)
+ {
+ struct UartDevice *uartDevice = NULL;
+
+ if (host->priv == NULL) {
+ HDF_LOGE("%s: invalid parameter", __func__);
+ return;
+ }
+ uartDevice = host->priv;
+ DeinitUartDevice(uartDevice);
+ (void)OsalMemFree(uartDevice);
+ host->priv = NULL;
+ }
+
+ // Release the UART driver.
+ static void SampleUartDriverRelease(struct HdfDeviceObject *device)
+ {
+ struct UartHost *host = NULL;
+ HDF_LOGI("Enter %s:", __func__);
+
+ if (device == NULL) {
+ HDF_LOGE("%s: device is NULL", __func__);
+ return;
+ }
+ host = UartHostFromDevice(device);
+ if (host == NULL) {
+ HDF_LOGE("%s: host is NULL", __func__);
+ return;
+ }
+ if (host->priv != NULL) {
+ DetachUartDevice(host);
+ }
+ UartHostDestroy(host);
+ }
+
+ struct HdfDriverEntry g_sampleUartDriverEntry = {
+ .moduleVersion = 1,
+ .moduleName = "UART_SAMPLE",
+ .Bind = SampleUartDriverBind,
+ .Init = SampleUartDriverInit,
+ .Release = SampleUartDriverRelease,
+ };
+
+ HDF_INIT(g_sampleUartDriverEntry);
+ ```
+
+3. Register a UART driver interface.
+
+ Implement the UART driver interface using the template **UartHostMethod** provided by the HDF.
+
+ ```
+ static int32_t SampleUartHostInit(struct UartHost *host)
+ {
+ HDF_LOGI("%s: Enter", __func__);
+ if (host == NULL) {
+ HDF_LOGE("%s: invalid parameter", __func__);
+ return HDF_ERR_INVALID_PARAM;
+ }
+ return HDF_SUCCESS;
+ }
+
+ static int32_t SampleUartHostDeinit(struct UartHost *host)
+ {
+ HDF_LOGI("%s: Enter", __func__);
+ if (host == NULL) {
+ HDF_LOGE("%s: invalid parameter", __func__);
+ return HDF_ERR_INVALID_PARAM;
+ }
+ return HDF_SUCCESS;
+ }
+
+ // Write data into the UART device.
+ static int32_t SampleUartHostWrite(struct UartHost *host, uint8_t *data, uint32_t size)
+ {
+ HDF_LOGI("%s: Enter", __func__);
+ uint32_t idx;
+ struct UartRegisterMap *regMap = NULL;
+ struct UartDevice *device = NULL;
+
+ if (host == NULL || data == NULL || size == 0) {
+ HDF_LOGE("%s: invalid parameter", __func__);
+ return HDF_ERR_INVALID_PARAM;
+ }
+ device = (struct UartDevice *)host->priv;
+ if (device == NULL) {
+ HDF_LOGE("%s: device is NULL", __func__);
+ return HDF_ERR_INVALID_PARAM;
+ }
+ regMap = (struct UartRegisterMap *)device->resource.physBase;
+ for (idx = 0; idx < size; idx++) {
+ UartPl011Write(regMap, data[idx]);
+ }
+ return HDF_SUCCESS;
+ }
+
+ // Set the baud rate for the UART device.
+ static int32_t SampleUartHostSetBaud(struct UartHost *host, uint32_t baudRate)
+ {
+ HDF_LOGI("%s: Enter", __func__);
+ struct UartDevice *device = NULL;
+ struct UartRegisterMap *regMap = NULL;
+ UartPl011Error err;
+
+ if (host == NULL) {
+ HDF_LOGE("%s: invalid parameter", __func__);
+ return HDF_ERR_INVALID_PARAM;
+ }
+ device = (struct UartDevice *)host->priv;
+ if (device == NULL) {
+ HDF_LOGE("%s: device is NULL", __func__);
+ return HDF_ERR_INVALID_PARAM;
+ }
+ regMap = (struct UartRegisterMap *)device->resource.physBase;
+ if (device->state != UART_DEVICE_INITIALIZED) {
+ return UART_PL011_ERR_NOT_INIT;
+ }
+ if (baudRate == 0) {
+ return UART_PL011_ERR_INVALID_BAUD;
+ }
+ err = UartPl011SetBaudrate(regMap, device->uartClk, baudRate);
+ if (err == UART_PL011_ERR_NONE) {
+ device->baudrate = baudRate;
+ }
+ return err;
+ }
+
+ // Obtain the baud rate of the UART device.
+ static int32_t SampleUartHostGetBaud(struct UartHost *host, uint32_t *baudRate)
+ {
+ HDF_LOGI("%s: Enter", __func__);
+ struct UartDevice *device = NULL;
+
+ if (host == NULL) {
+ HDF_LOGE("%s: invalid parameter", __func__);
+ return HDF_ERR_INVALID_PARAM;
+ }
+ device = (struct UartDevice *)host->priv;
+ if (device == NULL) {
+ HDF_LOGE("%s: device is NULL", __func__);
+ return HDF_ERR_INVALID_PARAM;
+ }
+ *baudRate = device->baudrate;
+ return HDF_SUCCESS;
+ }
+
+ // Bind the UART device using HdfUartSampleInit.
+ struct UartHostMethod g_sampleUartHostMethod = {
+ .Init = SampleUartHostInit,
+ .Deinit = SampleUartHostDeinit,
+ .Read = NULL,
+ .Write = SampleUartHostWrite,
+ .SetBaud = SampleUartHostSetBaud,
+ .GetBaud = SampleUartHostGetBaud,
+ .SetAttribute = NULL,
+ .GetAttribute = NULL,
+ .SetTransMode = NULL,
+ };
+ ```
+
+ Add the sample module of the UART driver to the compilation script **device/hisilicon/drivers/lite.mk**.
+
+ ```
+ LITEOS_BASELIB += -lhdf_uart_sample
+ LIB_SUBDIRS += $(LITEOS_SOURCE_ROOT)/vendor/huawei/hdf/sample/platform/uart
+ ```
+
+4. Implement the code for interaction between the user-space applications and driver.
+
+ Create the **/dev/uartdev-5** node after the UART driver is initialized successfully. The following example shows how to interact with the UART driver through the node.
+
+ ```
+ #include
+ #include
+ #include
+ #include "hdf_log.h"
+
+ #define HDF_LOG_TAG "hello_uart"
+ #define INFO_SIZE 16
+
+ int main(void)
+ {
+ int ret;
+ int fd;
+ const char info[INFO_SIZE] = {" HELLO UART! "};
+
+ fd = open("/dev/uartdev-5", O_RDWR);
+ if (fd < 0) {
+ HDF_LOGE("hello_uart uartdev-5 open failed %d", fd);
+ return -1;
+ }
+ ret = write(fd, info, INFO_SIZE);
+ if (ret != 0) {
+ HDF_LOGE("hello_uart write uartdev-5 ret is %d", ret);
+ }
+ ret = close(fd);
+ if (ret != 0) {
+ HDF_LOGE("hello_uart uartdev-5 close failed %d", fd);
+ return -1;
+ }
+ return ret;
+ }
+ ```
+
+ Add the **hello\_uart\_sample** component to **targets** of the **hdf\_hi3516dv300\_liteos\_a** component in the **build/lite/components/drivers.json** file.
+
+ ```
+ {
+ "components": [
+ {
+ "component": "hdf_hi3516dv300_liteos_a",
+ ...
+ "targets": [
+ "//vendor/huawei/hdf/sample/platform/uart:hello_uart_sample"
+ ]
+ }
+ ]
+ }
+ ```
+
+ > **NOTE:**
+ >Preceding code snippets are for reference only. You can view the complete sample code in **vendor/huawei/hdf/sample.**
+ >The sample code is not automatically compiled by default. You can add it to the compilation script.
+
+
+## Compiling and Burning
+
+Perform the [building](quickstart-lite-steps-board3516-running.md#section1077671315253) and [burning](quickstart-lite-steps-board3516-running.md#section1347011412201) as instructed in **Running a Hello OHOS Program**.
+
+## Running an Image
+
+1. Connect to a serial port.
+
+ > **NOTICE:**
+ >If the connection fails, rectify the fault by referring to [FAQs](quickstart-lite-steps-board3516-faqs.md).
+
+ **Figure 1** Serial port connection
+
+
+ 
+
+ 1. Click **Monitor** to enable the serial port.
+ 2. Press **Enter** repeatedly until **hisilicon** displays.
+ 3. Go to [2](quickstart-lite-steps-board3516-running.md#l5b42e79a33ea4d35982b78a22913b0b1) if the board is started for the first time or the startup parameters need to be modified; go to [3](quickstart-lite-steps-board3516-running.md#ld26f18828aa44c36bfa36be150e60e49) otherwise.
+
+2. \(Mandatory when the board is started for the first time\) Modify the **bootcmd** and **bootargs** parameters of U-Boot. You need to perform this step only once if the parameters need not to be modified during the operation. The board automatically starts after it is reset.
+
+ > **NOTICE:**
+ >The default waiting time in the U-Boot is 2s. You can press **Enter** to interrupt the waiting and run the **reset** command to restart the system after "hisilicon" is displayed.
+
+ **Table 1** Parameters of the U-Boot
+
+
+
Command
+
+
Description
+
+
+
+
setenv bootcmd "mmc read 0x0 0x80000000 0x800 0x4800; go 0x80000000";
+
+
Run this command to read content that has a size of 0x4800 (9 MB) and a start address of 0x800 (1 MB) to the memory address 0x80000000. The file size must be the same as that of the OHOS_Image.bin file in the IDE.
Run this command to set the output mode to serial port output, baud rate to 115200, data bit to 8, rootfs to be mounted to the emmc component, and file system type to vfat.
+
rootaddr=10M rootsize=20M rw indicates the start address and size of the rootfs.img file to be burnt, respectively. The file size must be the same as that of the rootfs.img file in the IDE.
+
+
+
saveenv
+
+
saveenv means to save the current configuration.
+
+
+
reset
+
+
reset means to reset the board.
+
+
+
+
+
+ > **NOTICE:**
+ >**go 0x80000000** is optional. It indicates that the command is fixed in the startup parameters by default and the board automatically starts after it is reset. If you want to manually start the board, press **Enter** in the countdown phase of the U-Boot startup to interrupt the automatic startup.
+
+3. Run the **reset** command and press **Enter** to restart the board. After the board is restarted, **OHOS** is displayed when you press **Enter**.
+
+ **Figure 2** System startup
+
+
+ 
+
+4. In the root directory, run the **./bin/hello\_uart** command line to execute the demo program. The compilation result is shown in the following example.
+
+ ```
+ OHOS # ./bin/hello_uart
+ OHOS # HELLO UART!
+ ```
+
+
+## Follow-up Learning
+
+Congratulations! You have finished all steps! You are advised to go on learning how to develop [Cameras with a Screen](../guide/device-camera.md).
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3516-running.md b/en/device-dev/quick-start/quickstart-lite-steps-board3516-running.md
new file mode 100644
index 0000000000000000000000000000000000000000..9b33afae1965ec4b0dd056280dab5eaf24deffc1
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3516-running.md
@@ -0,0 +1,269 @@
+# Running a Hello OHOS Program
+
+- [Creating a Program](#section204672145202)
+- [Building](#section1077671315253)
+- [Burning](#section1347011412201)
+- [Running an Image](#section24721014162010)
+- [Running a Program](#section5276734182615)
+
+This section describes how to create, compile, burn, and run the first program, and finally print **Hello OHOS!** on the develop board.
+
+## Creating a Program
+
+1. Create a directory and the program source code.
+
+ Create the **applications/sample/camera/apps/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **OHOS** to **World**. You can use either C or C++ to develop a program.
+
+ ```
+ #include
+
+ int main(int argc, char **argv)
+ {
+ printf("\n************************************************\n");
+ printf("\n\t\tHello OHOS!\n");
+ printf("\n************************************************\n\n");
+
+ return 0;
+ }
+ ```
+
+2. Create a build file.
+
+ Create the **applications/sample/camera/apps/BUILD.gn** file. The file content is as follows:
+
+ ```
+ import("//build/lite/config/component/lite_component.gni")
+ lite_component("hello-OHOS") {
+ features = [ ":helloworld" ]
+ }
+ executable("helloworld") {
+ output_name = "helloworld"
+ sources = [ "src/helloworld.c" ]
+ include_dirs = []
+ defines = []
+ cflags_c = []
+ ldflags = []
+ }
+ ```
+
+3. Add a new component.
+
+ Add the configuration of the **hello\_world\_app** component to the **build/lite/components/applications.json** file. The sample code below shows some configurations defined in the **applications.json** file, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\)
+
+ ```
+ {
+ "components": [
+ {
+ "component": "camera_sample_communication",
+ "description": "Communication related samples.",
+ "optional": "true",
+ "dirs": [
+ "applications/sample/camera/communication"
+ ],
+ "targets": [
+ "//applications/sample/camera/communication:sample"
+ ],
+ "rom": "",
+ "ram": "",
+ "output": [],
+ "adapted_kernel": [ "liteos_a" ],
+ "features": [],
+ "deps": {
+ "components": [],
+ "third_party": []
+ }
+ },
+ ##start##
+ {
+ "component": "hello_world_app",
+ "description": "Communication related samples.",
+ "optional": "true",
+ "dirs": [
+ "applications/sample/camera/apps"
+ ],
+ "targets": [
+ "//applications/sample/camera/apps:hello-OHOS"
+ ],
+ "rom": "",
+ "ram": "",
+ "output": [],
+ "adapted_kernel": [ "liteos_a" ],
+ "features": [],
+ "deps": {
+ "components": [],
+ "third_party": []
+ }
+ },
+ ##end##
+ {
+ "component": "camera_sample_app",
+ "description": "Camera related samples.",
+ "optional": "true",
+ "dirs": [
+ "applications/sample/camera/launcher",
+ "applications/sample/camera/cameraApp",
+ "applications/sample/camera/setting",
+ "applications/sample/camera/gallery",
+ "applications/sample/camera/media"
+ ],
+ ```
+
+4. Modify the board configuration file.
+
+ Add the **hello\_world\_app** component to the **vendor/hisilicon/hispark\_taurus/config.json** file. The sample code below shows the configurations of the **applications** subsystem, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\)
+
+ ```
+ {
+ "subsystem": "applications",
+ "components": [
+ { "component": "camera_sample_app", "features":[] },
+ { "component": "camera_sample_ai", "features":[] },
+ ##start##
+ { "component": "hello_world_app", "features":[] },
+ ##end##
+ { "component": "camera_screensaver_app", "features":[] }
+ ]
+ },
+ ```
+
+
+## Building
+
+If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/gettools-acquire.md). If the Linux environment is installed using a software package, go to the root directory of the source code and run the following commands for source code compilation:
+
+```
+hb set (Set the building path.)
+. (Select the current path.)
+Select ipcamera_hispark_taurus@hisilicon and press Enter.
+hb build -f (Start building.)
+```
+
+**Figure 1** Settings
+
+
+The result files are generated in the **out/hispark\_taurus/ipcamera\_hispark\_taurus** directory.
+
+> **NOTICE:**
+>The U-Boot file of the Hi3516D V300 development board can be obtained from the following path: device/hisilicon/hispark\_taurus/sdk\_liteos/uboot/out/boot/u-boot-hi3516dv300.bin
+
+## Burning
+
+The Hi3516 development board allows you to burn flash memory over the USB port, serial port, or network port. The following uses the network port burning as an example.
+
+1. Connect the PC and the target development board through the power port, serial port, and network port. In this section, the Hi3516DV300 is used as an example. For details, please refer to [Introduction to the Hi3516 Development Board](quickstart-lite-introduction-hi3516.md).
+2. Open Device Manager, then check and record the serial port number corresponding to the development board.
+
+ > **NOTE:**
+ >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695).
+
+ 
+
+3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
+
+ 
+
+4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings.
+5. On the **hi3516dv300** tab page, set the programming options.
+
+ - **upload\_port**: Select the serial port number obtained in [2](#en-us_topic_0000001056443961_li142386399535).
+ - **upload\_protocol**: Select the programming protocol **hiburn-net**.
+ - **upload\_partitions**: Select the file to be programmed. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are programmed at the same time.
+
+ 
+
+6. Check and set the IP address of the network adapter connected to the development board. For details, see [Setting the IP Address of the Network Port for Programming on Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/set_ipaddress-0000001141825075).
+7. Set the IP address of the network port for programming:
+
+ - **upload\_net\_server\_ip**: Select the IP address set in [6](#en-us_topic_0000001056443961_li1558813168234). Example: 192.168.1.2.
+ - **upload\_net\_client\_mask**: Set the subnet mask of the development board, such as 255.255.255.0. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. Example: 255.255.255.0.
+ - **upload\_net\_client\_gw**: Set the gateway of the development board, such as 192.168.1.1. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. Example: 192.168.1.1.
+ - **upload\_net\_client\_ip**: Set the IP address of the development board, such as 192.168.1.3. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. Example: 192.168.1.3.
+
+ 
+
+8. When you finish modifying, click **Save** in the upper right corner.
+9. Open the project file and click . In the DevEco Device Tool window, choose **PROJECT TASKS** \> **hi3516dv300** \> **Upload** to start programming.
+
+ 
+
+10. When the following message is displayed, power off the development board and then power it on.
+
+ 
+
+11. Start burning. When the following message is displayed, the burning is successful.
+
+ 
+
+
+## Running an Image
+
+1. Connect to a serial port.
+
+ > **NOTICE:**
+ >If the connection fails, rectify the fault by referring to [FAQs](quickstart-lite-steps-board3516-faqs.md).
+
+ **Figure 2** Serial port connection
+
+
+ 
+
+ 1. Click **Monitor** to enable the serial port.
+ 2. Press **Enter** repeatedly until **hisilicon** displays.
+ 3. Go to step [2](#l5b42e79a33ea4d35982b78a22913b0b1) if the board is started for the first time or the startup parameters need to be modified; go to step [3](#ld26f18828aa44c36bfa36be150e60e49) otherwise.
+
+2. \(Mandatory when the board is started for the first time\) Modify the bootcmd and bootargs parameters of U-Boot. You need to perform this step only once if the parameters need not to be modified during the operation. The board automatically starts after it is reset.
+
+ > **NOTICE:**
+ >The default waiting time in the U-Boot is 2s. You can press **Enter** to interrupt the waiting and run the **reset** command to restart the system after "hisilicon" is displayed.
+
+ **Table 1** Parameters of the U-Boot
+
+
+
Command
+
+
Description
+
+
+
+
setenv bootcmd "mmc read 0x0 0x80000000 0x800 0x4800; go 0x80000000";
+
+
Run this command to read content that has a size of 0x4800 (9 MB) and a start address of 0x800 (1 MB) to the memory address 0x80000000. The file size must be the same as that of the OHOS_Image.bin file in the IDE.
Run this command to set the output mode to serial port output, baud rate to 115200, data bit to 8, rootfs to be mounted to the emmc component, and file system type to vfat.
+
rootaddr=10M rootsize=20M rw indicates the start address and size of the rootfs.img file to be burnt, respectively. The file size must be the same as that of the rootfs.img file in the IDE.
+
+
+
saveenv
+
+
saveenv means to save the current configuration.
+
+
+
reset
+
+
reset means to reset the board.
+
+
+
+
+
+ > **NOTICE:**
+ >**go 0x80000000** \(optional\) indicates that the command is fixed in the startup parameters by default and the board automatically starts after it is reset. If you want to manually start the board, press **Enter** in the countdown phase of the U-Boot startup to interrupt the automatic startup.
+
+3. Run the **reset** command and press **Enter** to restart the board. After the board is restarted, **OHOS** is displayed when you press **Enter**.
+
+ **Figure 3** System startup
+
+
+ 
+
+
+## Running a Program
+
+In the root directory, run the **./bin/helloworld** command to operate the demo program. The compilation result is shown in the following example.
+
+**Figure 4** Successful system startup and program execution
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3516-setting.md b/en/device-dev/quick-start/quickstart-lite-steps-board3516-setting.md
new file mode 100644
index 0000000000000000000000000000000000000000..bb8595701a4f83270ac876a83f2846ce51d3e863
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3516-setting.md
@@ -0,0 +1,122 @@
+# Setting Up the Environment
+
+- [Environment Requirements](#section179175261196)
+ - [Hardware](#section5840424125014)
+ - [Software](#section965634210501)
+
+- [Installing Linux Build Tools](#section182916865219)
+ - [Changing Linux Shell to Bash](#section1715027152617)
+ - [Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)](#section45512412251)
+ - [Installing File Packing Tools and JVM](#section16199102083717)
+
+
+## Environment Requirements
+
+### Hardware
+
+- Hi3516D V300 IoT camera development board
+- USB-to-serial cable and network cable \(The Windows workstation is connected to the Hi3516D V300 development board through the USB-to-serial cable and network cable.\)
+
+The following figure shows the hardware connections.
+
+**Figure 1** Hardware connections
+
+
+
+
+### Software
+
+> **NOTICE:**
+>This section describes how to use an installation package to set up the compilation and development environment. If you are going to use Docker to set up the environment, skip this section and [Installing Linux Build Tools](#section182916865219).
+
+The following table describes the tools required for setting up the general environment for a Linux server of the Hi3516 development board and how to obtain these tools.
+
+**Table 1** Development tools and obtaining methods
+
+
+
Development Tool
+
+
Description
+
+
How to Obtain
+
+
+
+
bash
+
+
Processes CLI commands.
+
+
System configuration
+
+
+
Basic software package for compilation and building (required only for Ubuntu 20+)
+
+
Provides a basic software package for compilation and building.
+
+
Internet
+
+
+
dosfstools, mtools, and mtd-utils
+
+
Pack files.
+
+
apt-get install
+
+
+
Java virtual machine (JVM)
+
+
Compiles, debugs, and runs Java programs.
+
+
apt-get install
+
+
+
+
+
+## Installing Linux Build Tools
+
+> **NOTICE:**
+>- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install compilation tools like **LLVM** and **hc-gen**.
+>- \(Recommended\) If you obtain the source code via the mirror site or code repository, install **hc-gen**. When installing the compilation tool, ensure that its environment variable path is unique.
+
+### Changing Linux Shell to Bash
+
+Check whether bash is used as the shell.
+
+```
+ls -l /bin/sh
+```
+
+If **/bin/sh -\> bash** is not displayed, do as follows to change shell to bash.
+
+**Method 1:** Run the following command on the device and then click **No**.
+
+```
+sudo dpkg-reconfigure dash
+```
+
+**Method 2:** Run the first command to delete **sh** and then run the second command to create a new soft link.
+
+```
+sudo rm -rf /bin/sh
+sudo ln -s /bin/bash /bin/sh
+```
+
+### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)
+
+Install the software.
+
+```
+sudo apt-get install build-essential gcc g++ make zlib* libffi-dev
+```
+
+### Installing File Packing Tools and JVM
+
+1. Start a Linux server.
+2. Install the dosfstools, mtools, mtd-utils, Java Runtime Environment \(JRE\), and Java SDK.
+
+ ```
+ sudo apt-get install dosfstools mtools mtd-utils default-jre default-jdk
+ ```
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3516.md b/en/device-dev/quick-start/quickstart-lite-steps-board3516.md
new file mode 100644
index 0000000000000000000000000000000000000000..97db943fc49eedc60d2a1409ed319390b0df9624
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3516.md
@@ -0,0 +1,11 @@
+# Hi3516
+
+- **[Setting Up the Environment](quickstart-lite-steps-board3516-setting.md)**
+
+- **[Running a Hello OHOS Program](quickstart-lite-steps-board3516-running.md)**
+
+- **[Developing a Driver](quickstart-lite-steps-board3516-program.md)**
+
+- **[FAQs](quickstart-lite-steps-board3516-faqs.md)**
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3518-faqs.md b/en/device-dev/quick-start/quickstart-lite-steps-board3518-faqs.md
new file mode 100644
index 0000000000000000000000000000000000000000..384eac7cdccbc83828ce8259efcafad4fb29cc3d
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3518-faqs.md
@@ -0,0 +1,174 @@
+# FAQs
+
+- [What should I do when the images failed to be burnt over the selected serial port?](#section1498892119619)
+- [What should I do when Windows-based PC failed to be connected to the board?](#section8512971816)
+- [What should I do when the image failed to be burnt?](#section1767804111198)
+- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#en-us_topic_0000001053466255_section1039835245619)
+- [What should I do when no command output is displayed?](#en-us_topic_0000001053466255_section14871149155911)
+
+## What should I do when the images failed to be burnt over the selected serial port?
+
+- **Symptom**
+
+ **Error: Opening COMxx: Access denied** is displayed after clicking **Burn** and selecting a serial port.
+
+ **Figure 1** Failed to open the serial port
+ 
+
+- **Possible Causes**
+
+ The serial port has been used.
+
+- **Solutions**
+
+1. Search for the terminal using serial-xx from the drop-down list in the **TERMINAL** panel.
+
+ **Figure 2** Checking whether the serial port is used
+ 
+
+2. Click the dustbin icon as shown in the following figure to disable the terminal using the serial port.
+
+ **Figure 3** Disabling the terminal using the serial port
+ 
+
+3. Click **Burn**, select the serial port, and start burning images again.
+
+ **Figure 4** Restarting burning
+
+
+ 
+
+
+## What should I do when Windows-based PC failed to be connected to the board?
+
+- **Symptom**
+
+ The file image cannot be obtained after clicking **Burn** and selecting a serial port.
+
+ **Figure 5** Failed to obtain the image file due to unavailable connection
+ 
+
+- **Possible Causes**
+
+ The board is disconnected from the Windows-based PC.
+
+ Windows Firewall does not allow Visual Studio Code to access the network.
+
+- **Solutions**
+
+1. Check whether the network cable is properly connected.
+2. Click **Windows Firewall**.
+
+ **Figure 6** Network and firewall setting
+ 
+
+3. Click **Firewall & network protection**, and on the displayed page, click **Allow applications to communicate through Windows Firewall**.
+
+ **Figure 7** Firewall and network protection
+ 
+
+4. Select the Visual Studio Code application.
+
+ **Figure 8** Selecting the Visual Studio Code application
+ 
+
+5. Select the **Private** and **Public** network access rights for the Visual Studio Code application.
+
+ **Figure 9** Allowing the Visual Studio Code application to access the network
+ 
+
+
+## What should I do when the image failed to be burnt?
+
+- **Symptom**
+
+ The burning status is not displayed after clicking **Burn** and selecting a serial port.
+
+- **Possible Causes**
+
+ The IDE is not restarted after the DevEco plug-in is installed.
+
+- **Solutions**
+
+ Restart the IDE.
+
+
+## What should I do when the message indicating Python cannot be found is displayed during compilation and building?
+
+- **Symptom**
+
+ 
+
+
+- **Possible Cause 1**
+
+ Python is not installed.
+
+- **Solutions**
+
+ Install Python by referring to [Installing and Configuring Python](quickstart-lite-env-setup-lin.md).
+
+- **Possible Cause 2**: The soft link that points to the Python does not exist in the usr/bin directory.
+
+ 
+
+- **Solutions**
+
+ Run the following commands:
+
+ ```
+ # cd /usr/bin/
+ # which python3
+ # ln -s /usr/local/bin/python3 python
+ # python --version
+ ```
+
+ Example:
+
+ 
+
+
+## What should I do when no command output is displayed?
+
+- **Symptom**
+
+ The serial port shows that the connection has been established. After the board is restarted, nothing is displayed when you press **Enter**.
+
+- **Possible Cause 1**
+
+ The serial port is connected incorrectly.
+
+- **Solutions**
+
+ Change the serial port number.
+
+ Start **Device Manager** to check whether the serial port connected to the board is the same as that connected to the terminal device. If the serial ports are different, perform step [1](quickstart-lite-steps-board3518-running.md) in the **Running an Image** section to change the serial port number.
+
+
+- **Possible Cause 2**
+
+ The U-boot of the board is damaged.
+
+- **Solutions**
+
+ Burn the U-boot.
+
+ If the fault persists after you perform the preceding operations, the U-boot of the board may be damaged. You can burn the U-boot by performing the following steps:
+
+
+1. Obtain the U-boot file.
+
+ > **NOTICE:**
+ >The U-boot file of the two boards can be obtained from the following paths, respectively.
+ >Hi3516D V300: **device\\hisilicon\\hispark\_taurus\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3516dv300.bin**
+ >Hi3518E V300: **device\\hisilicon\\hispark\_aries\\sdk\_liteos\\uboot\\out\\boot\\u-boot-hi3518ev300.bin**
+
+2. Burn the U-boot file by following the procedures for burning a U-boot file over USB.
+
+ Select the U-boot files of corresponding development boards for burning by referring to [Programming Flash Memory on the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681)/[Programming Flash Memory on the Hi3518](https://device.harmonyos.com/en/docs/ide/user-guides/hi3518_upload-0000001057313128)
+
+3. Log in to the serial port after the burning is complete.
+
+ 
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3518-running.md b/en/device-dev/quick-start/quickstart-lite-steps-board3518-running.md
new file mode 100644
index 0000000000000000000000000000000000000000..7b8ec4ecd0d6d0541dbe37430a8aa05cf02f9cd1
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3518-running.md
@@ -0,0 +1,262 @@
+# Running a Hello OHOS Program
+
+- [Creating a Program](#section1550972416485)
+- [Building](#section234175193114)
+- [Burning](#section7609155824819)
+- [Running an Image](#section17612105814480)
+- [Follow-up Learning](#section9712145420182)
+
+This section describes how to create, compile, burn, and run the first program, and finally print **Hello OHOS!** on the develop board.
+
+## Creating a Program
+
+1. Create a directory and the program source code.
+
+ Create the **applications/sample/camera/apps/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **OHOS** to **World**. You can use either C or C++ to develop a program.
+
+ ```
+ #include
+
+ int main(int argc, char **argv)
+ {
+ printf("\n************************************************\n");
+ printf("\n\t\tHello OHOS!\n");
+ printf("\n************************************************\n\n");
+
+ return 0;
+ }
+ ```
+
+2. Create a build file.
+
+ Create the **applications/sample/camera/apps/BUILD.gn** file. The file content is as follows:
+
+ ```
+ import("//build/lite/config/component/lite_component.gni")
+ lite_component("hello-OHOS") {
+ features = [ ":helloworld" ]
+ }
+ executable("helloworld") {
+ output_name = "helloworld"
+ sources = [ "src/helloworld.c" ]
+ include_dirs = []
+ defines = []
+ cflags_c = []
+ ldflags = []
+ }
+ ```
+
+3. Add a component.
+
+ Add the configuration of the **hello\_world\_app** component to the **build/lite/components/applications.json** file. The sample code below shows some configurations defined in the **applications.json** file, and the code between **"\#\#start\#\#"** and **"\#\#end\#\#"** is the new configuration \(Delete the rows where **"\#\#start\#\#"** and **"\#\#end\#\#"** are located after the configurations are added.\)
+
+ ```
+ {
+ "components": [
+ {
+ "component": "camera_sample_communication",
+ "description": "Communication related samples.",
+ "optional": "true",
+ "dirs": [
+ "applications/sample/camera/communication"
+ ],
+ "targets": [
+ "//applications/sample/camera/communication:sample"
+ ],
+ "rom": "",
+ "ram": "",
+ "output": [],
+ "adapted_kernel": [ "liteos_a" ],
+ "features": [],
+ "deps": {
+ "components": [],
+ "third_party": []
+ }
+ },
+ ##start##
+ {
+ "component": "hello_world_app",
+ "description": "Communication related samples.",
+ "optional": "true",
+ "dirs": [
+ "applications/sample/camera/apps"
+ ],
+ "targets": [
+ "//applications/sample/camera/apps:hello-OHOS"
+ ],
+ "rom": "",
+ "ram": "",
+ "output": [],
+ "adapted_kernel": [ "liteos_a" ],
+ "features": [],
+ "deps": {
+ "components": [],
+ "third_party": []
+ }
+ },
+ ##end##
+ {
+ "component": "camera_sample_app",
+ "description": "Camera related samples.",
+ "optional": "true",
+ "dirs": [
+ "applications/sample/camera/launcher",
+ "applications/sample/camera/cameraApp",
+ "applications/sample/camera/setting",
+ "applications/sample/camera/gallery",
+ "applications/sample/camera/media"
+ ],
+ ```
+
+4. Modify the board configuration file.
+
+ Add the **hello\_world\_app** component to the **vendor/hisilicon/hispark\_aries/config.json** file. The sample code below shows the configurations of the **applications** subsystem, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\)
+
+ ```
+ {
+ "subsystem": "applications",
+ "components": [
+ ##start##
+ { "component": "hello_world_app", "features":[] },
+ ##end##
+ { "component": "camera_sample_app", "features":[] }
+
+ ]
+ },
+ ```
+
+
+## Building
+
+If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/gettools-acquire.md). If the Linux environment is installed using a software package, go to the root directory of the source code and run the following commands for source code compilation:
+
+```
+hb set (Set the building path.)
+. (Select the current path.)
+Select ipcamera_hispark_aries@hisilicon and press Enter.
+hb build -f (Start building.)
+```
+
+The result files are generated in the **out/hispark\_aries/ipcamera\_hispark\_aries** directory.
+
+**Figure 1** Settings
+
+
+> **NOTICE:**
+>The U-Boot file of the Hi3518E V300 development board can be obtained from the following path: device/hisilicon/hispark\_aries/sdk\_liteos/uboot/out/boot/u-boot-hi3518ev300.bin
+
+## Burning
+
+The USB port is the only burning mode supported by the Hi3518 development board.
+
+1. Connect the PC and the target development board through the serial port and USB port. In this section, the Hi3518EV300 is used as an example. For details, see [Introduction to the Hi3518 Development Board](quickstart-lite-introduction-hi3518.md).
+2. Open Device Manager, then check and record the serial port number corresponding to the development board.
+
+ > **NOTE:**
+ >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695).
+
+ 
+
+3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
+
+ 
+
+4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings.
+5. On the **hi3518ev300** tab page, set the programming options.
+
+ - **upload\_port**: Select the serial port number obtained in [2](#en-us_topic_0000001057313128_li46411811196).
+ - **upload\_protocol**: Select the programming protocol **hiburn-usb**.
+ - **upload\_partitions**: Select the file to be programmed. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are programmed at the same time.
+
+ 
+
+6. When you finish modifying, click **Save** in the upper right corner.
+7. Open the project file and click . In the DevEco Device Tool window, choose **PROJECT TASKS** \> **hi3518ev300\_fastboot** \> **Erase** to erase U-Boot.
+
+ 
+
+8. When the following message is displayed, power off the development board and then power it on.
+
+ 
+
+9. If the following message is displayed, it indicates that U-Boot is erased successfully.
+
+ 
+
+10. Go to **hi3518ev300** \> **Upload** to start programming.
+
+ 
+
+11. If the following message is displayed, it indicates that the programming is successful.
+
+ 
+
+
+## Running an Image
+
+1. Connect to a serial port.
+
+ > **NOTICE:**
+ >If the connection fails, rectify the fault by referring to [FAQs](quickstart-lite-steps-board3518-faqs.md).
+
+ **Figure 2** Serial port connection
+
+
+ 
+
+ 1. Click **Monitor** to enable the serial port. The **TERMINAL** window is displayed.
+ 2. Press **Enter** repeatedly until **hisilicon** displays.
+ 3. Go to [step 2](#li9441185382314) if the board is started for the first time or the startup parameters need to be modified; go to [step 3](#li6442853122312) otherwise.
+
+2. \(Mandatory for first-time burning\) Modify the **bootcmd** and **bootargs** parameters of U-Boot. This step is a fixed operation and the result can be saved. However, you need to perform the following steps again if U-Boot needs to be reburnt.
+
+ **Table 1** Parameters of the U-Boot
+
+
+
Run this command to set the content of bootcmd. Select the flash whose number is 0, and read content that has a size of 0x600000 (6 MB) and a start address of 0x100000 to memory address 0x40000000. The size must be the same as that of the OHOS_Image.bin file in the IDE.
In this command, bootargs is set to the serial port output, the baud rate is 115200, the data bit is 8, and the rootfs is mounted to the flash memory. The file system type is set to jffs2 rw, which provides the read-write attribute for the JFFS2 file system. rootaddr=7M rootsize=8M indicates the actual start address and length of the rootfs.img file to be burnt, respectively. The file size must be the same as that of the rootfs.img file in the IDE.
+
+
+
saveenv
+
+
saveenv means to save the current configuration.
+
+
+
reset
+
+
reset means to reset the board.
+
+
+
pri
+
+
pri means to view the displayed parameters.
+
+
+
+
+
+ > **NOTICE:**
+ >**go 0x40000000** \(optional\) indicates that the command is fixed in the startup parameters by default and the board automatically starts after it is reset. If you want to manually start the board, press **Enter** in the countdown phase of the U-Boot startup to interrupt the automatic startup.
+
+3. If **hisilicon \#** is displayed during the startup, run the **reset** command. After the system automatically starts and **OHOS** is displayed, run the **./bin/helloworld** command and then press **Enter**. The system is started successfully if information shown in the following figure is displayed.
+
+ **Figure 3** Successful system startup and program execution
+ 
+
+
+## Follow-up Learning
+
+Congratulations! You have finished all steps! You are advised to go on learning how to develop [Cameras with a Screen](../guide/device-iotcamera.md).
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3518-setting.md b/en/device-dev/quick-start/quickstart-lite-steps-board3518-setting.md
new file mode 100644
index 0000000000000000000000000000000000000000..9bc63015a4c5956197248d223e54de4bc1df1c1b
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3518-setting.md
@@ -0,0 +1,114 @@
+# Setting Up the Environment
+
+- [Environment Requirements](#section1724111409282)
+ - [Hardware](#section487353718276)
+ - [Software Requirements](#section17315193935817)
+
+- [Installing Linux Build Tools](#section8831868501)
+ - [Changing Linux Shell to Bash](#section434110241084)
+ - [Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)](#section25911132141020)
+ - [Installing File Packing Tools](#section390214473129)
+
+
+## Environment Requirements
+
+### Hardware
+
+- Hi3518E V300 IoT camera development board
+- USB-to-serial cable and network cable \(The Windows workstation is connected to the Hi3518E V300 development board through the USB-to-serial cable and network cable.\)
+
+ The following figure shows the hardware connections.
+
+
+**Figure 1** Hardware connections
+
+
+### Software Requirements
+
+> **NOTICE:**
+>This section describes how to use an installation package to set up the compilation and development environment. If you are going to use Docker to set up the environment, skip this section and [Installing Linux Build Tools](#section8831868501).
+
+The following table describes the tools required for setting up the general environment for a Linux server of the Hi3518 development board and how to obtain these tools.
+
+**Table 1** Development tools and obtaining methods
+
+
+
Development Tool
+
+
Description
+
+
How to Obtain
+
+
+
+
bash
+
+
Processes CLI commands.
+
+
System configuration
+
+
+
Basic software package for compilation and building (required only for Ubuntu 20+)
+
+
Provides a basic software package for compilation and building.
+
+
Internet
+
+
+
dosfstools, mtools, and mtd-utils
+
+
Pack files.
+
+
apt-get install
+
+
+
+
+
+## Installing Linux Build Tools
+
+> **NOTICE:**
+>- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install **hc-gen**.
+>- \(Recommended\) If you obtain the source code via the mirror site or code repository, install **hc-gen**. When installing the compilation tool, ensure that its environment variable path is unique.
+
+### Changing Linux Shell to Bash
+
+Check whether bash is used as the shell.
+
+```
+ls -l /bin/sh
+```
+
+If **/bin/sh -\> bash** is not displayed, do as follows to change shell to bash.
+
+**Method 1:** Run the following command on the device and then click **No**.
+
+```
+sudo dpkg-reconfigure dash
+```
+
+**Method 2:** Run the first command to delete **sh** and then run the second command to create a new soft link.
+
+```
+sudo rm -rf /bin/sh
+sudo ln -s /bin/bash /bin/sh
+```
+
+### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)
+
+Install the software.
+
+```
+sudo apt-get install build-essential gcc g++ make zlib* libffi-dev
+```
+
+### Installing File Packing Tools
+
+1. Start a Linux server.
+2. Install dosfstools, mtools, and mtd-utils.
+
+ ```
+ sudo apt-get install dosfstools mtools mtd-utils
+ ```
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3518.md b/en/device-dev/quick-start/quickstart-lite-steps-board3518.md
new file mode 100644
index 0000000000000000000000000000000000000000..e9f239a0ee8bcf928fe46dc35ba11fb2a48b31e1
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3518.md
@@ -0,0 +1,9 @@
+# Hi3518
+
+- **[Setting Up the Environment](quickstart-lite-steps-board3518-setting.md)**
+
+- **[Running a Hello OHOS Program](quickstart-lite-steps-board3518-running.md)**
+
+- **[FAQs](quickstart-lite-steps-board3518-faqs.md)**
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3861-connection.md b/en/device-dev/quick-start/quickstart-lite-steps-board3861-connection.md
new file mode 100644
index 0000000000000000000000000000000000000000..2ce585ea88b513619177b24358cc3f82e0442b86
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3861-connection.md
@@ -0,0 +1,142 @@
+# WLAN Connection
+
+- [Building](#section191121332125319)
+- [Burning Images](#section19458165166)
+- [Connecting WLAN Module to the Internet.](#section194671619167)
+
+This example shows how to connect the WLAN module to the gateway using attention \(AT\) commands.
+
+## Building
+
+This section describes how to perform the WLAN module building on a Linux server.
+
+If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/sourcecode-acquire.md). If the Linux environment is installed using a software package, perform the following steps:
+
+1. Open the HUAWEI DevEco Device Tool and choose **View** \> **Terminal**.
+
+ **Figure 1** Starting the IDE terminal tool
+
+
+ 
+
+ On the **TERMINAL** panel, run the ssh command, for example, **ssh** **_user_@_ipaddr_**, to connect to the Linux server.
+
+ **Figure 2** TERMINAL panel
+
+
+ 
+
+2. Go to the root directory of the code, run the **hb set** and **.** commands on the **TERMINAL** panel, and select the **wifiiot\_hispark\_pegasus** version.
+
+ **Figure 3** Selecting the target build version
+
+
+ 
+
+3. Run the **hb build** command to start building.
+
+ **Figure 4** Running commands on the TERMINAL panel
+
+
+ 
+
+4. Check whether the building is successful. If yes, **wifiiot\_hispark\_pegasus build success** will be displayed, as shown in the following figure.
+
+ **Figure 5** Successful building
+
+
+ 
+
+5. Check whether the following files are generated in the **./out/wifiiot/** directory.
+
+ ```
+ ls -l out/hispark_pegasus/wifiiot_hispark_pegasus/
+ ```
+
+ **Figure 6** Directory for storing the generated files
+
+
+ 
+
+
+## Burning Images
+
+You can use the DevEco tool to perform the image burning of the Hi3861 WLAN module. For details about how to use the tool, see [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905).
+
+1. Connect the PC and the target development board through the USB port. For details, see [Introduction to the Hi3861 Development Board](quickstart-lite-introduction-hi3861.md).
+2. Open Device Manager, then check and record the serial port number corresponding to the development board.
+
+ > **NOTE:**
+ >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3861 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3861-drivers-0000001058153433).
+
+ 
+
+3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
+
+ 
+
+4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings.
+5. On the **hi3861** tab page, set the programming options.
+
+ - **upload\_port**: Select the serial port number obtained in [2](#en-us_topic_0000001056563976_li848662117291).
+ - **upload\_protocol**: Select the burning protocol **burn-serial**.
+ - **upload\_partitions**: Select the file to be burned. **hi3861\_app** is selected by default.
+
+ 
+
+6. When you finish modifying, click **Save** in the upper right corner.
+7. Open the project file. In the DevEco Device Tool window, go to **PROJECT TASKS** \> **hi3861** \> **Upload** to start programming.
+
+ 
+
+8. When the following information is displayed, press the RST button on the development board to restart it.
+
+ 
+
+9. Start burning. When the following message is displayed, the burning is successful.
+
+ 
+
+
+## Connecting WLAN Module to the Internet.
+
+After completing version building and burning, do as follows to connect the WLAN module to the Internet using AT commands.
+
+1. Click the icon of **DevEco: Serial Monitor** at the bottom of DevEco Studio to keep the connection between the Windows workstation and the WLAN module.
+
+ **Figure 7** Opening the DevEco serial port
+
+
+ 
+
+2. Reset the WLAN module. The message **ready to OS start** is displayed on the **TERMINAL** panel, indicating that the WLAN module is started successfully.
+
+ **Figure 8** Successful resetting of the WLAN module
+
+
+ 
+
+3. Run the following AT commands in sequence via the DevEco serial port terminal to start the STA mode, connect to the specified AP, and enable Dynamic Host Configuration Protocol \(DHCP\).
+
+ ```
+ AT+STARTSTA # Start the STA mode.
+ AT+SCAN # Scan for available APs.
+ AT+SCANRESULT # Display the scanning result.
+ AT+CONN="SSID",,2,"PASSWORD" # Connect to the specified AP. (SSID and PASSWORD represent the name and password of the hotspot to be connected, respectively.)
+ AT+STASTAT # View the connection result.
+ AT+DHCP=wlan0,1 # Request the IP address of wlan0 from the AP using DHCP.
+ ```
+
+4. Check whether the WLAN module is properly connected to the gateway, as shown in the following figure.
+
+ ```
+ AT+IFCFG # View the IP address assigned to an interface of the module.
+ AT+PING=X.X.X.X # Check the connectivity between the module and the gateway. Replace X.X.X.X with the actual gateway address.
+ ```
+
+ **Figure 9** Successful networking of the WLAN module
+
+
+ 
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3861-faqs.md b/en/device-dev/quick-start/quickstart-lite-steps-board3861-faqs.md
new file mode 100644
index 0000000000000000000000000000000000000000..9f4f5b1583e64ed802a7b076f008b31a89e7c2ac
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3861-faqs.md
@@ -0,0 +1,286 @@
+# FAQs
+
+- [What should I do when the message configure: error: no acceptable C compiler found in $PATH is displayed during Python 3 installation?](#section1221016541119)
+- [What should I do when the message -bash: make: command not found is displayed during Python 3 installation?](#section1913477181213)
+- [What should I do when the message zlib not available is displayed during Python 3 installation?](#section108211415131210)
+- [What should I do when the message No module named '\_ctypes' is displayed during Python 3 installation?](#section2062268124)
+- [What should I do when the message No module named 'Crypto' is displayed during compilation and building?](#section982315398121)
+- [What should I do when the message No module named 'ecdsa' is displayed during compilation and building?](#section102035451216)
+- [What should I do when the message Could not find a version that satisfies the requirement six\>=1.9.0 is displayed during compilation and building?](#section4498158162320)
+- [What should I do when the message cannot find -lgcc is displayed during compilation and building?](#section11181036112615)
+- [What should I do when the message indicating Python cannot be found is displayed during compilation and building?](#section1571810194619)
+- [What should I do when an error with lsb\_release occurs during kconfiglib installation?](#section691681635814)
+
+## What should I do when the message **configure: error: no acceptable C compiler found in $PATH** is displayed during Python 3 installation?
+
+- **Symptom**
+
+ The following error occurs during Python 3 installation:
+
+ ```
+ configure: error: no acceptable C compiler found in $PATH. See 'config.log' for more details
+ ```
+
+- **Possible Causes**
+
+ **GCC** is not installed.
+
+- **Solutions**
+
+ 1. Run the **apt-get install gcc** command to install **GCC** online.
+
+ 2. After the installation, reinstall Python 3.
+
+
+## What should I do when the message **-bash: make: command not found** is displayed during Python 3 installation?
+
+- **Symptom**
+
+ The following error occurs during Python 3 installation:
+
+ ```
+ -bash: make: command not found
+ ```
+
+- **Possible Causes**
+
+ **Make** is not installed.
+
+- **Solutions**
+
+ 1. Run the **apt-get install make** command to install **Make** online.
+
+ 2. After the installation, reinstall Python 3.
+
+
+## What should I do when the message **zlib not available** is displayed during Python 3 installation?
+
+- **Symptom**
+
+ The following error occurs during Python 3 installation:
+
+ ```
+ zipimport.ZipImportError: can't decompress data; zlib not avaliable
+ ```
+
+- **Possible Causes**
+
+ **zlib** is not installed.
+
+- **Solutions**
+
+ Solution 1: Run the **apt-get install zlib** command to install **zlib** online.
+
+ Solution 2: If the software source does not contain **zlib**, download the source code from [http://www.zlib.net/](http://www.zlib.net/).
+
+ 
+
+ Then run the following commands to install **zlib** offline:
+
+ ```
+ # tar xvf zlib-1.2.11.tar.gz
+ # cd zlib-1.2.11
+ # ./configure
+ # make && make install
+ ```
+
+ After the installation, reinstall Python 3.
+
+
+## What should I do when the message **No module named '\_ctypes'** is displayed during Python 3 installation?
+
+- **Symptom**
+
+ The following error occurs during Python 3 installation:
+
+ ```
+ ModuleNotFoundError: No module named '_ctypes'
+ ```
+
+
+- **Possible Causes**
+
+ **libffi** and **libffi-devel** are not installed.
+
+
+- **Solutions**
+
+ 1. Run the **apt-get install libffi\* -y** command to install **libffi** and **libffi-devel** online.
+
+ 2. After the installation, reinstall Python 3.
+
+
+## What should I do when the message **No module named 'Crypto'** is displayed during compilation and building?
+
+- **Symptom**
+
+ The following error occurs during compilation and building:
+
+ ```
+ ModuleNotFoundError: No module named 'Crypto'
+ ```
+
+
+- **Possible Causes**
+
+ **Crypto** is not installed.
+
+
+- **Solutions**
+
+ Solution 1: Run the **pip3 install Crypto** command to install **Crypto** online.
+
+ Solution 2: Install **Crypto** offline.
+
+ - Download the source code from [https://pypi.org/project/pycrypto/\#files](https://pypi.org/project/pycrypto/#files).
+
+ 
+
+ - Save the source code package to the Linux server, decompress the package, and run the **python3 setup.py install** command to install **Crypto**.
+ - Rebuild an environment.
+
+
+## What should I do when the message **No module named 'ecdsa'** is displayed during compilation and building?
+
+- **Symptom**
+
+ The following error occurs during compilation and building:
+
+ ```
+ ModuleNotFoundError: No module named 'ecdsa'
+ ```
+
+
+- **Possible Causes**
+
+ **ecdsa** is not installed.
+
+
+- **Solutions**
+
+ Solution 1: Run the **pip3 install ecdsa** command to install **ecdsa** online.
+
+ Solution 2: Install **ecdsa** offline.
+
+ - Download the installation package from [https://pypi.org/project/ecdsa/\#files](https://pypi.org/project/ecdsa/#files).
+
+ 
+
+ - Save the installation package to the Linux server and run the **pip3 install ecdsa-0.15-py2.py3-none-any.whl** command to install **ecdsa**.
+ - Rebuild an environment.
+
+
+## What should I do when the message **Could not find a version that satisfies the requirement six\>=1.9.0** is displayed during compilation and building?
+
+- **Symptom**
+
+ The following error occurs during compilation and building:
+
+ ```
+ Could not find a version that satisfies the requirement six>=1.9.0
+ ```
+
+
+- **Possible Causes**
+
+ **six** is not installed.
+
+
+- **Solutions**
+
+ Solution 1: Run the **pip3 install six** command to install **six** online.
+
+ Solution 2: Install **six** offline.
+
+ - Download the installation package from [https://pypi.org/project/six/\#files](https://pypi.org/project/six/#files).
+
+ 
+
+ - Save the source code to the Linux server and run the **pip3 install six-1.14.0-py2.py3-none-any.whl** command to install **six**.
+ - Rebuild an environment.
+
+
+## What should I do when the message **cannot find -lgcc** is displayed during compilation and building?
+
+- **Symptom**
+
+ The following error occurs during compilation and building:
+
+ ```
+ riscv32-unknown-elf-ld: cannot find -lgcc
+ ```
+
+
+- **Possible Causes**
+
+ The PATH is incorrectly written by **gcc\_riscv32**. There is an extra slash \(/\).
+
+ ```
+ ~/gcc_riscv32/bin/:/data/toolchain/
+ ```
+
+
+- **Solutions**
+
+ Modify the PATH by deleting the slash \(/\).
+
+ ```
+ ~/gcc_riscv32/bin:/data/toolchain/
+ ```
+
+
+## What should I do when the message indicating Python cannot be found is displayed during compilation and building?
+
+- **Symptom**
+
+ The following error occurs during compilation and building:
+
+ ```
+ -bash: /usr/bin/python: No such file or directory
+ ```
+
+
+- **Possible Cause 1:** Python is not installed.
+- **Solutions**
+
+ Install Python by referring to [Installing and Configuring Python](quickstart-lite-env-setup-lin.md).
+
+- **Possible Cause 2:** The soft link that points to the Python does not exist in the **usr/bin** directory.
+
+ 
+
+- **Solutions**
+
+ Run the following commands to add a soft link:
+
+ ```
+ # cd /usr/bin/
+ # which python3
+ # ln -s /usr/local/bin/python3 python
+ # python --version
+ ```
+
+ Example:
+
+ 
+
+
+## What should I do when an error with **lsb\_release** occurs during **kconfiglib** installation?
+
+- **Symptom**
+
+ The following error occurs during **kconfiglib** installation:
+
+ ```
+ subprocess.CalledProcessError: Command '('lsb_release', '-a')' returned non-zero exit status 1.
+ ```
+
+- **Possible Causes**
+
+ The Python version matched with the **lsb\_release** module is different from the current Python version.
+
+- **Solutions**
+
+ Run the **find / -name lsb\_release** command, for example, **sudo rm -rf /usr/bin/lsb\_release** to locate and delete **lsb\_release**.
+
+
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
new file mode 100644
index 0000000000000000000000000000000000000000..573245e7e223f25163185110666b9344339cf7ed
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3861-running.md
@@ -0,0 +1,156 @@
+# Running a Hello World Program
+
+- [Modifying Source Code](#section79601457101015)
+- [Debugging and Verification](#section1621064881419)
+- [printf](#section1246911301217)
+- [Locating Exceptions Using the asm File](#section199621957141014)
+- [Viewing Execution Result](#section18115713118)
+- [Follow-up Learning](#section9712145420182)
+
+This example shows how to compile a simple service and print **Hello World** to help you preliminarily understand how to run OpenHarmony on Hi3861.
+
+## Modifying Source Code
+
+The source code needs to be modified when fixing bugs or compiling a new service. The following describes how to modify the source code when compiling a new service, for example, **my\_first\_app**.
+
+1. Determine the directory structure.
+
+ Before compiling a service, you must create a directory \(or a directory structure\) in **./applications/sample/wifi-iot/app** to store source code files.
+
+ For example, add the **my\_first\_app** service to the **app** directory, where **hello\_world.c** is the service code and **BUILD.gn** is the compilation script. The directory structure is shown as follows:
+
+ ```
+ .
+ └── applications
+ └── sample
+ └── wifi-iot
+ └── app
+ │── my_first_app
+ │ │── hello_world.c
+ │ └── BUILD.gn
+ └── BUILD.gn
+ ```
+
+2. Compile the service code.
+
+ Create the **hello\_world.c** file in **./applications/sample/wifi-iot/app/my\_first\_app**. Then, create the service entry function **HelloWorld** in **hello\_world.c** and implement service logic. Use the SYS\_RUN\(\) of the OpenHarmony **bootstrap** module to start services. \(**SYS\_RUN** is defined in the **ohos\_init.h** file.\)
+
+ ```
+ #include
+ #include "ohos_init.h"
+ #include "ohos_types.h"
+
+ void HelloWorld(void)
+ {
+ printf("[DEMO] Hello world.\n");
+ }
+ SYS_RUN(HelloWorld);
+ ```
+
+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.
+
+ ```
+ static_library("myapp") {
+ sources = [
+ "hello_world.c"
+ ]
+ include_dirs = [
+ "//utils/native/lite/include"
+ ]
+ }
+ ```
+
+ - Specify the compilation result named libmyapp.a in **static\_library**. You can fill in this part based on your need.
+ - 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. 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:
+
+ ```
+ import("//build/lite/config/component/lite_component.gni")
+
+ lite_component("app") {
+ features = [
+ "my_first_app:myapp",
+ ]
+ }
+ ```
+
+ - **my\_first\_app** is a relative path that points to **./applications/sample/wifi-iot/app/my\_first\_app/BUILD.gn**.
+ - **myapp** represents the **static\_library\("myapp"\)** in **./applications/sample/wifi-iot/app/my\_first\_app/BUILD.gn**.
+
+
+## Debugging and Verification
+
+Currently, there are two debugging and verification methods: using printf to print logs and using asm files to locate **panic** problems. You can select one of them based on your need.
+
+As the service shown is simple, use the printf method. The following describes the two debugging methods.
+
+## printf
+
+Add **printf** function to the code, which helps print data to the serial port. You can add log printing in key service paths or service exception locations, as shown in the following figure.
+
+```
+void HelloWorld(void)
+{
+ printf("[DEMO] Hello world.\n");
+}
+```
+
+## Locating Exceptions Using the asm File
+
+When the system exits abnormally, the call stack information about the abnormal exit is displayed on the serial port. The following is an example: You can locate the exception by parsing the exception stack information.
+
+```
+=======KERNEL PANIC=======
+**********************Call Stack*********************
+Call Stack 0 -- 4860d8 addr:f784c
+Call Stack 1 -- 47b2b2 addr:f788c
+Call Stack 2 -- 3e562c addr:f789c
+Call Stack 3 -- 4101de addr:f78ac
+Call Stack 4 -- 3e5f32 addr:f78cc
+Call Stack 5 -- 3f78c0 addr:f78ec
+Call Stack 6 -- 3f5e24 addr:f78fc
+********************Call Stack end*******************
+```
+
+To parse the call stack information, the **Hi3861\_wifiiot\_app.asm** file is required. This file records the symbol addresses of the functions in the code in the flash memory and the disassembly information. The asm file is built and output together with the version software package and is stored in the **./out/wifiiot/** directory.
+
+1. \(Optional\) Save the **CallStack** information to a TXT file for editing.
+2. Open the asm file, search for the function address in each call stack, and list the corresponding function. Generally, you only need to find the functions matching the first several stacks to locate exceptions.
+
+ ```
+ Call Stack 0 -- 4860d8 addr:f784c -- WadRecvCB
+ Call Stack 1 -- 47b2b2 addr:f788c -- wal_sdp_process_rx_data
+ Call Stack 2 -- 3e562c addr:f789c
+ Call Stack 3 -- 4101de addr:f78ac
+ Call Stack 4 -- 3e5f32 addr:f78cc
+ Call Stack 5 -- 3f78c0 addr:f78ec
+ Call Stack 6 -- 3f5e24 addr:f78fc
+ ```
+
+3. Determine that an exception occurs in the **WadRecvCB** function based on the call stack information.
+
+ 
+
+4. Check and modify the code.
+
+## Viewing Execution Result
+
+After the sample code is compiled, burnt, run, and debugged, the following information is displayed on the serial port interface:
+
+```
+ready to OS start
+FileSystem mount ok.
+wifi init success!
+[DEMO] Hello world.
+```
+
+## Follow-up Learning
+
+Congratulations! You have finished all steps! You are advised to go on learning how to develop [WLAN-connected products](../guide/device-wifi.md).
+
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
new file mode 100644
index 0000000000000000000000000000000000000000..92d567cd5d954a195ccde7826cbfc997f585505f
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3861-setting.md
@@ -0,0 +1,367 @@
+# Setting Up the Environment
+
+- [Environment Requirements](#section466851916410)
+ - [Hardware](#section19202111020215)
+ - [Software](#section727451210318)
+
+- [Installing Linux Build Tools](#section497484245614)
+ - [Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)](#section45512412251)
+ - [Installing Scons](#section7438245172514)
+ - [Installing Python Modules](#section88701892341)
+ - [Installing gcc\_riscv32 \(Compilation Toolchain for WLAN Module\)](#section34435451256)
+
+- [Installing the USB-to-Serial Driver](#section1027732411513)
+
+## Environment Requirements
+
+### Hardware
+
+- Linux compile server
+- Windows workstation \(host computer\)
+- Hi3861 WLAN module
+- USB Type-C cable used to connect the Windows workstation to Hi3861 WLAN module
+
+The following figure shows the hardware connections.
+
+**Figure 1** Hardware connections
+
+
+### Software
+
+> **NOTICE:**
+>The following part describes how to install tools using installation packages. If you use Docker to set up the build environment, you only need to install the Windows workstation described in [Table 1](#table6299192712513).
+
+The following table lists the tools required for the Hi3861 development board.
+
+**Table 1** Required tools
+
+
+
Platform
+
+
Development Tool
+
+
Description
+
+
How to Obtain
+
+
+
+
Linux server
+
+
Basic software package for compilation and building (required only for Ubuntu 20+)
+
+
Provides a basic software package for compilation and building.
+
+
Internet
+
+
+
Linux server
+
+
SCons 3.0.4+
+
+
Executes script compilation.
+
+
Internet
+
+
+
Linux server
+
+
Python modules: setuptools, Kconfiglib, PyCryptodome, six, and ecdsa
+
+## Installing Linux Build Tools
+
+> **NOTICE:**
+>- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install **gcc\_riscv32**.
+>- \(Recommended\) If you obtain the source code via the mirror site or code repository, install **gcc\_riscv32**. When installing the compilation tool, ensure that its environment variable path is unique.
+
+### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)
+
+Install the software.
+
+```
+sudo apt-get install build-essential gcc g++ make zlib* libffi-dev
+```
+
+### Installing Scons
+
+1. Start a Linux server.
+2. Install the SCons installation package.
+
+ ```
+ python3 -m pip install scons
+ ```
+
+3. Check whether the installation is successful.
+
+ ```
+ scons -v
+ ```
+
+ **Figure 2** Successful installation \(SCons version requirement: 3.0.4 or later\)
+ .png "successful-installation-(scons-version-requirement-3-0-4-or-later)")
+
+
+### Installing Python Modules
+
+1. Install setuptools.
+
+ ```
+ pip3 install setuptools
+ ```
+
+2. Install the GUI menuconfig tool \(Kconfiglib\). You are advised to install Kconfiglib 13.2.0 or later.
+ - **Command line:**
+
+ ```
+ 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.
+
+ ```
+ sudo pip3 install kconfiglib-13.2.0-py2.py3-none-any.whl
+ ```
+
+
+
+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.
+
+ - **Command line:**
+
+ ```
+ sudo pip3 install pycryptodome
+ ```
+
+ - **Installation package:**
+ 1. Download the **.whl** file \(for example, **pycryptodome-3.9.9-cp38-cp38-manylinux1\_x86\_64.whl**\).
+
+ Download path: [https://pypi.org/project/pycryptodome/\#files](https://pypi.org/project/pycryptodome/#files)
+
+
+ 1. Install the **.whl** file.
+
+ ```
+ sudo pip3 install pycryptodome-3.9.9-cp38-cp38-manylinux1_x86_64.whl
+ ```
+
+
+
+4. Install **six** using either of the following methods:
+ - **Command line:**
+
+ ```
+ 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.
+
+ ```
+ sudo pip3 install six-1.12.0-py2.py3-none-any.whl
+ ```
+
+
+
+5. Install **ecdsa** using either of the following methods:
+ - **Command line:**
+
+ ```
+ sudo pip3 install ecdsa
+ ```
+
+ - **Installation package:**
+ 1. Download the **.whl** file, for example, **ecdsa-0.14.1-py2.py3-none-any.whl**.
+
+ Download path: [https://pypi.org/project/ecdsa/\#files](https://pypi.org/project/ecdsa/#files)
+
+
+ 1. Install the **.whl** file.
+
+ ```
+ sudo pip3 install ecdsa-0.14.1-py2.py3-none-any.whl
+ ```
+
+
+
+
+### Installing gcc\_riscv32 \(Compilation Toolchain for WLAN Module\)
+
+> **NOTICE:**
+>- The Hi3861 platform supports only the static link of the libgcc library. The dynamic link is not recommended because version 3 of the GNU General Public License \(GPLv3\) will be polluted during commercial distribution.
+>- Steps 2 to 15 of the following procedure are used to build the **gcc\_riscv32** image. You can simply [download the image](https://repo.huaweicloud.com/harmonyos/compiler/gcc_riscv32/7.3.0/linux/gcc_riscv32-linux-7.3.0.tar.gz) and skip these steps.
+
+1. Start a Linux server.
+2. Install the **GCC**, **G++**, **Bison**, **Flex**, **Makeinfo** tools to ensure that the toolchain can be correctly compiled.
+
+ ```
+ sudo apt-get install gcc && sudo apt-get install g++ && sudo apt-get install flex bison && sudo apt-get install texinfo
+ ```
+
+3. Download the RISC-V GNU toolchain.
+
+ ```
+ git clone --recursive https://gitee.com/mirrors/riscv-gnu-toolchain.git
+ ```
+
+4. Open the **riscv-gnu-toolchain** folder and delete empty folders to prevent conflicts during the download of **Newlib**, **Binutils**, and **GCC**.
+
+ ```
+ cd riscv-gnu-toolchain && rm -rf riscv-newlib && rm -rf riscv-binutils && rm -rf riscv-gcc
+ ```
+
+5. Download RISC-V Newlib 3.0.0.
+
+ ```
+ git clone -b riscv-newlib-3.0.0 https://github.com/riscv/riscv-newlib.git
+ ```
+
+6. Download RISC-V Binutils 2.31.1.
+
+ ```
+ git clone -b riscv-binutils-2.31.1 https://github.com/riscv/riscv-binutils-gdb.git
+ ```
+
+7. Download RISC-V GCC 7.3.0.
+
+ ```
+ git clone -b riscv-gcc-7.3.0 https://github.com/riscv/riscv-gcc
+ ```
+
+8. Add the RISC-V GCC 7.3.0 patch.
+
+ Visit the GCC official patch links [89411](https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=026216a753ef0a757a9e368a59fa667ea422cf09;hp=2a23a1c39fb33df0277abd4486a3da64ae5e62c2) and [86724](https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/graphite.h;h=be0a22b38942850d88feb159603bb846a8607539;hp=4e0e58c60ab83f1b8acf576e83330466775fac17;hb=b1761565882ed6a171136c2c89e597bc4dd5b6bf;hpb=fbd5f023a03f9f60c6ae36133703af5a711842a3), and manually add the changes to the .c and .h files based on the requirements in the patch links. Note that the number of rows may not match because of different versions of the patch and GCC. You need to search for the keyword in the patch to locate the corresponding row.
+
+9. Download, decompress, and install [GMP 6.1.2](https://gmplib.org/download/gmp/gmp-6.1.2.tar.bz2).
+
+ ```
+ tar -xvf gmp-6.1.2.tar.bz2 && mkdir build_gmp && cd build_gmp && ../gmp-6.1.2/configure --prefix=/usr/local/gmp-6.1.2 --disable-shared --enable-cxx && make && make install
+ ```
+
+10. Download, decompress, and install [mpfr-4.0.2](https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.gz).
+
+ ```
+ tar -xvf mpfr-4.0.2.tar.gz && mkdir build_mpfr && cd build_mpfr && ../mpfr-4.0.2/configure --prefix=/usr/local/mpfr-4.0.2 --with-gmp=/usr/local/gmp-6.1.2 --disable-shared && make && make install
+ ```
+
+11. Download, decompress, and install [mpc-1.1.0](https://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz).
+
+ ```
+ tar -xvf mpc-1.1.0.tar.gz && mkdir build_mpc && cd build_mpc && ../mpc-1.1.0/configure --prefix=/usr/local/mpc-1.1.0 --with-gmp=/usr/local/gmp-6.1.2 --with-mpfr=/usr/local/mpfr-4.0.2 --disable-shared && make && make install
+ ```
+
+12. Open the **riscv-gnu-toolchain** folder and create a directory for toolchain output.
+
+ ```
+ cd /opt && mkdir gcc_riscv32
+ ```
+
+13. Compile **binutils**.
+
+ ```
+ mkdir build_binutils && cd build_binutils && ../riscv-binutils-gdb/configure --prefix=/opt/gcc_riscv32 --target=riscv32-unknown-elf --with-arch=rv32imc --with-abi=ilp32 --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --enable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-multilib --enable-poison-system-directories --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib CFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" CFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" --bindir=/opt/gcc_riscv32/bin --libexecdir=/opt/gcc_riscv32/riscv32 --libdir=/opt/gcc_riscv32 --includedir=/opt/gcc_riscv32 && make -j16 && make install && cd ..
+ ```
+
+14. Build **Newlib**.
+
+ ```
+ mkdir build_newlib && cd build_newlib && ../riscv-newlib/configure --prefix=/opt/gcc_riscv32 --target=riscv32-unknown-elf --with-arch=rv32imc --with-abi=ilp32 --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --enable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-multilib --enable-poison-system-directories --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib CFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" \CXXFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" CFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" --bindir=/opt/gcc_riscv32/bin --libexecdir=/opt/gcc_riscv32 --libdir=/opt/gcc_riscv32 --includedir=/opt/gcc_riscv32 && make -j16 && make install && cd ..
+ ```
+
+15. Build **GCC**.
+
+ ```
+ mkdir build_gcc && cd build_gcc && ../riscv-gcc/configure --prefix=/opt/gcc_riscv32 --target=riscv32-unknown-elf --with-arch=rv32imc --with-abi=ilp32 --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --enable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-multilib --enable-poison-system-directories --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib CFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" LDFLAGS="-Wl,-z,relro,-z,now,-z,noexecstack" CXXFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" CFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" --with-headers="/opt/gcc-riscv32/riscv32-unknown-elf/include" --with-mpc=/usr/local/mpc-1.1.0 --with-gmp=/usr/local/gmp-6.1.2 --with-mpfr=/usr/local/mpfr-4.0.2 && make -j16 && make install
+ ```
+
+16. Set an environment variable.
+
+ > **NOTE:**
+ >If you use the compiled **riscv32 gcc** package, perform the following steps to set environment variables:
+ >1. Decompress the package to the root directory.
+ > ```
+ > tar -xvf gcc_riscv32-linux-7.3.0.tar.gz -C ~
+ > ```
+ >2. Set an environment variable.
+ > ```
+ > vim ~/.bashrc
+ > ```
+ >3. Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
+ > ```
+ > export PATH=~/gcc_riscv32/bin:$PATH
+ > ```
+
+ ```
+ vim ~/.bashrc
+ ```
+
+ Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
+
+ ```
+ export PATH=~/gcc_riscv32/bin:$PATH
+ ```
+
+17. Validate the environment variable.
+
+ ```
+ source ~/.bashrc
+ ```
+
+18. Check whether the compiler is successfully installed. If the compiler version number is correctly displayed, the installation is successful.
+
+ ```
+ riscv32-unknown-elf-gcc -v
+ ```
+
+
+## Installing the USB-to-Serial Driver
+
+Perform the following operations on the Windows station.
+
+1. Download the USB-to-serial driver: [CH341SER USB-to-serial driver](http://www.hihope.org/en/download/download.aspx).
+2. Install the driver.
+3. After the driver is installed, remove and then insert the USB cable. The serial port entry should be displayed as shown in the following figure.
+
+ 
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps-board3861.md b/en/device-dev/quick-start/quickstart-lite-steps-board3861.md
new file mode 100644
index 0000000000000000000000000000000000000000..a0b8821b092c2b1e524a1f027c82eede39f8627b
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps-board3861.md
@@ -0,0 +1,11 @@
+# Hi3861
+
+- **[Setting Up the Environment](quickstart-lite-steps-board3861-setting.md)**
+
+- **[WLAN Connection](quickstart-lite-steps-board3861-connection.md)**
+
+- **[Running a Hello World Program](quickstart-lite-steps-board3861-running.md)**
+
+- **[FAQs](quickstart-lite-steps-board3861-faqs.md)**
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite-steps.md b/en/device-dev/quick-start/quickstart-lite-steps.md
new file mode 100644
index 0000000000000000000000000000000000000000..cd4b82e4fd43c3494e6c0f16a5773b13b4c262e0
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite-steps.md
@@ -0,0 +1,9 @@
+# How to Develop
+
+- **[Hi3861](quickstart-lite-steps-board3861.md)**
+
+- **[Hi3516](quickstart-lite-steps-board3516.md)**
+
+- **[Hi3518](quickstart-lite-steps-board3518.md)**
+
+
diff --git a/en/device-dev/quick-start/quickstart-lite.md b/en/device-dev/quick-start/quickstart-lite.md
new file mode 100644
index 0000000000000000000000000000000000000000..064e2ef51e72d289ab48512e29e01909530a6472
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-lite.md
@@ -0,0 +1,11 @@
+# Mini and Small Systems
+
+- **[Overview](quickstart-lite-overview.md)**
+
+- **[Introduction to the Development Boards](quickstart-lite-introduction.md)**
+
+- **[Environment Setup](quickstart-lite-env-setup.md)**
+
+- **[How to Develop](quickstart-lite-steps.md)**
+
+
diff --git a/en/device-dev/quick-start/quickstart-standard-burn.md b/en/device-dev/quick-start/quickstart-standard-burn.md
new file mode 100644
index 0000000000000000000000000000000000000000..5cfe9fccf987772fa26e2d64144c0416f7897dcc
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-standard-burn.md
@@ -0,0 +1,205 @@
+# Burning Images
+
+- [Next](#section5600113114323)
+
+Programming flash memory of a regular system requires DevEco Device Tool v2.2 Beta1 or later.
+
+The Hi3516DV300 of the Hi3516 series development boards supports programming flash memory of a regular system through the USB port, network port, or serial port, where:
+
+- **Windows system: Supports programming through the USB port, serial port, or network port**
+- **Linux system: Supports programming through the serial port or network port \(Linux+Windows dual system: Also supports programming through the USB port\)**
+
+Except for environment setup, the operations of programming are the same for Windows and Linux.
+
+> **NOTE:**
+>Currently, the Hi3516D V300 development board supports system burning over the network port, USB port, or serial port. This document uses the network port as an example. For details about system burning over other ports, see [Programming Flash Memory on the Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_upload-0000001052148681).
+
+### Prerequisites
+
+[Open a project](https://device.harmonyos.com/en/docs/ide/user-guides/open_project-0000001071680043) in DevEco Device Tool and select the folder where the file to be programmed is located. Select **Hi3516DV300** for the development board type and **Hb** for **Framework**.
+
+### Programming Flash Memory Through the Network Port
+
+The Hi3516DV300 supports programming through the network port in Windows or Linux.
+
+1. Connect the PC and the target development board through the power port, serial port, and network port. In this section, the Hi3516DV300 is used as an example. For details, please refer to [Introduction to the Hi3516 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_camera_start_3516-0000001052670587).
+2. Open Device Manager, then check and record the serial port number corresponding to the development board.
+
+ > **NOTE:**
+ >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695).
+
+ 
+
+3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
+
+ 
+
+4. On the **Partition Configuration** tab page, enter the information about the files to be programmed, including the following.
+
+
+
Name
+
+
Binary
+
+
Memory
+
+
System
+
+
Address
+
+
Length
+
+
Board
+
+
Type
+
+
+
+
fastboot
+
+
Select u-boot-hi3516dv300_emmc.bin.
+
+
emmc
+
+
none
+
+
0x000000
+
+
0x100000
+
+
Select hi3516dv300.
+
+
NA
+
+
+
boot
+
+
Select uImage.
+
+
emmc
+
+
none
+
+
0x100000
+
+
0xf00000
+
+
NA
+
+
+
updater
+
+
Select updater.img.
+
+
emmc
+
+
ext3/4
+
+
0x1000000
+
+
0x1400000
+
+
NA
+
+
+
misc
+
+
Leave it blank.
+
+
emmc
+
+
none
+
+
0x2400000
+
+
0x100000
+
+
NA
+
+
+
system
+
+
Select system.img.
+
+
emmc
+
+
ext3/4
+
+
0x2500000
+
+
0xceb00000
+
+
NA
+
+
+
vendor
+
+
Select vendor.img.
+
+
emmc
+
+
ext3/4
+
+
0xd1000000
+
+
0x10000000
+
+
NA
+
+
+
userdata
+
+
Select userdata.img.
+
+
emmc
+
+
ext3/4
+
+
0xe1000000
+
+
0x5b800000
+
+
NA
+
+
+
+
+
+ 
+
+5. On the **hi3516dv300** tab page, configure the programming options.
+
+ - **upload\_port**: Select the serial port number obtained in step [2](#en-us_topic_0000001056443961_li1050616379507).
+ - **upload\_protocol**: Select the programming protocol **hiburn-net**.
+ - **upload\_partitions**: Select the file to be programmed, including the following: fastboot, boot, updater, misc, system, vendor, and userdata.
+
+ 
+
+6. Check and set the IP address of the network adapter connected to the development board. For details, see [Setting the IP Address of the Network Port for Programming on Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/set_ipaddress-0000001141825075).
+7. Set the IP address of the network port for programming:
+
+ - **upload\_net\_server\_ip**: Select the IP address set in [6](en-us_topic_0000001056443961.md#li1558813168234), such as 192.168.1.2.
+ - **upload\_net\_client\_mask**: Set the subnet mask of the development board, such as 255.255.255.0. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
+ - **upload\_net\_client\_gw**: Set the gateway of the development board, such as 192.168.1.1. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
+ - **upload\_net\_client\_ip**: Set the IP address of the development board, such as 192.168.1.3. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated.
+
+ 
+
+8. When you finish modifying, click **Save** in the upper right corner.
+9. Open the project file, go to  \> **PROJECT TASKS** \> **fastboot** \> **Erase** to erase U-boot.
+
+ 
+
+10. When the following message is displayed, power off the development board and then power it on.
+
+ 
+
+11. Start programming. When the following message is displayed, it indicates that the programming is successful.
+
+ 
+
+
+## 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).
+
diff --git a/en/device-dev/quick-start/quickstart-standard-docker-environment.md b/en/device-dev/quick-start/quickstart-standard-docker-environment.md
new file mode 100644
index 0000000000000000000000000000000000000000..c9f27fb455f3de13052fbdf2e7454ff88d280fc7
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-standard-docker-environment.md
@@ -0,0 +1,118 @@
+# Setting Up Ubuntu Development Environment in Docker Mode and Building Source Code
+
+- [Obtaining Standard-System Source Code](#section8761819202511)
+ - [Prerequisites](#section102871547153314)
+ - [Procedure](#section429012478331)
+
+- [Obtaining the Docker Environment](#section181431248132513)
+- [Building Source Code](#section92391739152318)
+
+The standard OpenHarmony system provides a Docker environment which encapsulates build tools.
+
+> **NOTE:**
+>- Before using Docker, install it by following instructions in [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/).
+>- You can also use the [installation package](quickstart-standard-package-environment.md) to set up the Ubuntu development environment.
+
+## Obtaining Standard-System Source Code
+
+### Prerequisites
+
+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.
+
+ ```
+ git config --global user.name "yourname"
+ git config --global user.email "your-email-address"
+ git config --global credential.helper store
+ ```
+
+4. Run the following commands to install the **repo** tool:
+
+ ```
+ curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
+ chmod a+x /usr/local/bin/repo
+ pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
+ ```
+
+
+### Procedure
+
+Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\)
+
+```
+repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify
+repo sync -c
+repo forall -c 'git lfs pull'
+```
+
+Method 2: Use the **repo** tool to download the source code over HTTPS.
+
+```
+repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
+repo sync -c
+repo forall -c 'git lfs pull'
+```
+
+## Obtaining the Docker Environment
+
+**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
+
+1. Obtain the Docker image.
+
+ ```
+ docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
+ ```
+
+2. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
+ ```
+
+
+**Method 2: Using the Dockerfile to build a local docker image**
+
+1. Obtain the Dockerfile script for a local Docker image.
+
+ ```
+ git clone https://gitee.com/openharmony/docs.git
+ ```
+
+2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
+
+ ```
+ cd docs/docker/standard
+ ./build.sh
+ ```
+
+3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
+
+ ```
+ docker run -it -v $(pwd):/home/openharmony openharmony-docker-standard:0.0.1
+ ```
+
+
+## Building Source Code
+
+1. Run the preprocessing script in the root directory of the source code.
+
+ ```
+ ../scripts/prepare.sh
+ ```
+
+2. Run the following script to start building for Standard-System Devices \(reference memory ≥ 128 MB\):
+
+ ```
+ ./build.sh --product-name {product_name}
+ ```
+
+ **product\_name** indicates the product supported by the current distribution, for example, **Hi3516DV300**.
+
+ 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.
+
+3. Burn the image. For details, see [Burning Images](quickstart-standard-burn.md).
+
+> **NOTE:**
+>You can exit Docker by simply running the **exit** command.
+
diff --git a/en/device-dev/quick-start/faqs-7.md b/en/device-dev/quick-start/quickstart-standard-faq.md
similarity index 100%
rename from en/device-dev/quick-start/faqs-7.md
rename to en/device-dev/quick-start/quickstart-standard-faq.md
diff --git a/en/device-dev/quick-start/quickstart-standard-package-environment.md b/en/device-dev/quick-start/quickstart-standard-package-environment.md
new file mode 100644
index 0000000000000000000000000000000000000000..ee9049108fbefa96530e67bdc8ecb2211296cd21
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-standard-package-environment.md
@@ -0,0 +1,98 @@
+# Setting Up Ubuntu Development Environment with Installation Package and Building Source Code
+
+- [Installing Dependent Tools](#section18431165519244)
+- [Obtaining Standard-System Source Code](#section113751052102517)
+ - [Prerequisites](#section102871547153314)
+ - [Procedure](#section429012478331)
+
+- [Running prebuilts](#section0495320152619)
+- [Building Source Code](#section1664835963517)
+
+## Installing Dependent Tools
+
+The installation command is as follows:
+
+```
+sudo apt-get update && sudo apt-get install binutils git git-lfs gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4 bc gnutls-bin python3.8 python3-pip
+```
+
+> **NOTE:**
+>The preceding command is applicable to Ubuntu 18.04. For other Ubuntu versions, modify the preceding installation command based on the installation package name.
+
+## Obtaining Standard-System Source Code
+
+### Prerequisites
+
+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.
+
+ ```
+ git config --global user.name "yourname"
+ git config --global user.email "your-email-address"
+ git config --global credential.helper store
+ ```
+
+4. Run the following commands to install the **repo** tool:
+
+ ```
+ curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
+ chmod a+x /usr/local/bin/repo
+ pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
+ ```
+
+
+### Procedure
+
+Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\)
+
+```
+repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify
+repo sync -c
+repo forall -c 'git lfs pull'
+```
+
+Method 2: Use the **repo** tool to download the source code over HTTPS.
+
+```
+repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
+repo sync -c
+repo forall -c 'git lfs pull'
+```
+
+## Running prebuilts
+
+Go to the root directory of the source code and run the following script to install the compiler and binary tool:
+
+```
+bash build/prebuilts_download.sh
+```
+
+By default, the downloaded prebuilts binary file is stored in **OpenHarmony\_2.0\_canary\_prebuilts** \(which is in the same directory as **OpenHarmony**\).
+
+## Building Source Code
+
+Perform the following operations in the Linux environment:
+
+1. Go to the root directory of the source code and run the following command to build the distribution.
+
+ ```
+ ./build.sh --product-name {product_name}
+ ```
+
+ **product\_name** indicates the product supported by the current distribution, for example, **Hi3516DV300**.
+
+2. Check the build result. After the build is complete, the following information is displayed in the log:
+
+ ```
+ build system image successful.
+ =====build Hi3516DV300 successful.
+ ```
+
+ 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.
+
+ > **NOTE:**
+ >For details about module-specific build operations, see [Building Guidelines](../subsystems/subsys-build-standard-large.md).
+
+3. Burn the image. For details, see [Burning Images](quickstart-standard-burn.md).
+
diff --git a/en/device-dev/quick-start/quickstart-standard-windows-environment.md b/en/device-dev/quick-start/quickstart-standard-windows-environment.md
new file mode 100644
index 0000000000000000000000000000000000000000..c07334b53835411881e5373437a96974b43e175c
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-standard-windows-environment.md
@@ -0,0 +1,183 @@
+# Setting Up Windows Development Environment
+
+- [Obtaining the Software](#en-us_topic_0000001058091994_section1483143015558)
+- [Installing Visual Studio Code](#en-us_topic_0000001058091994_section71401018163318)
+- [Installing Python](#en-us_topic_0000001058091994_section16266553175320)
+- [Installing Node.js](#en-us_topic_0000001058091994_section5353233124511)
+- [Installing hpm](#en-us_topic_0000001058091994_section173054793610)
+- [Installing the DevEco Device Tool Plug-in](#en-us_topic_0000001058091994_section4336315185716)
+
+Operating system: 64-bit version of Windows 10.
+
+DevEco Device Tool is a plug-in for Visual Studio Code. The installation procedure includes five parts:
+
+1. Installing Visual Studio Code
+2. Installing Python
+3. Installing Node.js
+4. Installing hpm
+5. Installing the DevEco Device Tool Plug-in
+
+## Obtaining the Software
+
+
+
+
+## Installing Visual Studio Code
+
+> **NOTE:**
+>If you have installed Visual Studio Code, open the CLT and run **code --version** to check whether the version is 1.53 or later. If the version number is returned, it indicates that the environment variables are set correctly.
+
+1. Double-click the Visual Studio Code package to install it. During the installation, select **Add to PATH \(requires shell restart\)**.
+
+ 
+
+2. After the installation is complete, restart the computer for the environment variables of Visual Studio Code to take effect.
+3. Open the CLT and run **code --version**. If the version number can be displayed, it indicates that the installation is successful.
+
+## Installing Python
+
+1. Double-click the Python software package, select **Add Python xx to PATH**, and click **Install Now**.
+
+ 
+
+2. After the installation is complete, click **Close**.
+
+ 
+
+3. Open the CLT, and run **python --version** to check the installation result.
+
+ 
+
+4. In the CLT, run the following commands to set the pip source for downloading the dependencies required for later installation:
+
+ ```
+ pip config set global.trusted-host repo.huaweicloud.com
+ pip config set global.index-url https://repo.huaweicloud.com/repository/pypi/simple
+ pip config set global.timeout 120
+ ```
+
+
+## Installing Node.js
+
+> **NOTE:**
+>If you have installed Node.js, open the CLT and run **node -v** to check whether the version is 12.0.0 or later.
+
+1. Run the downloaded software package to install. Use the default settings when following the installation wizard, and click **Next** until **Finish** is displayed. During the installation, Node.js will automatically set the system Path environment variable to the installation directory of **node.exe**.
+2. Open the CLT and run **node -v**. If the version number of Node.js is displayed, it indicates that Node.js has been successfully installed.
+
+ 
+
+
+## Installing hpm
+
+Before installing hpm, ensure that Node.js has been installed
+
+and that your network can access the Internet. If your network requires a proxy to access the Internet, [set up the npm proxy](https://device.harmonyos.com/cn/docs/ide/user-guides/npm_proxy-0000001054491032) first.
+
+> **NOTE:**
+>If hpm has been installed, run **npm update -g @ohos/hpm-cli** to update it to the latest version.
+
+1. You are advised to set the npm source to an image in China, for example, a HUAWEI CLOUD image source.
+
+ ```
+ npm config set registry https://repo.huaweicloud.com/repository/npm/
+ ```
+
+2. Open the CLT and run the following command to install the latest version of hpm:
+
+ ```
+ npm install -g @ohos/hpm-cli
+ ```
+
+ 
+
+3. After the installation is complete, run the following command to obtain the installation result:
+
+ ```
+ hpm -V
+ ```
+
+ 
+
+
+## Installing the DevEco Device Tool Plug-in
+
+To install the DevEco Device Tool plug-in, ensure that the **user name of the host cannot contain Chinese characters**; otherwise, the plug-in may fail to run.
+
+DevEco Device Tool will automatically download and install the C/C++ and CodeLLDB plug-ins from the Visual Studio Code Marketplace during the installation process. Therefore, make sure Visual Studio Code can access the Internet. If your network requires a proxy to access the Internet, [set up the Visual Studio Code proxy](https://device.harmonyos.com/cn/docs/ide/user-guides/vscode_proxy-0000001074231144) first.
+
+> **NOTE:**
+>Before installing DevEco Device Tool, ensure that Visual Studio Code is closed.
+
+1. Decompress the DevEco Device Tool plug-in package and double-click the installer to install.
+2. During the installation, the dependency files \(such as C/C++ and CodeLLDB plug-ins\) and execution programs required by DevEco Device Tool are automatically installed.
+
+ 
+
+3. After the installation is complete, the CLT is automatically closed.
+4. Open Visual Studio Code, click the  button on the left, and check whether C/C++, CodeLLDB, and DevEco Device Tool are listed in **INSTALLED**.
+
+ > **NOTE:**
+ >If the C/C++ and CodeLLDB plug-ins fail to be installed, DevEco Device Tool cannot run properly. To solve the issue, see [Installing the C/C++ and CodeLLDB Plug-ins Offline](https://device.harmonyos.com/en/docs/ide/user-guides/offline_plugin_install-0000001074376846).
+
+ 
+
+
diff --git a/en/device-dev/quick-start/quickstart-standard.md b/en/device-dev/quick-start/quickstart-standard.md
new file mode 100644
index 0000000000000000000000000000000000000000..2801682ab40a69312b9918b7b4cd5aac67472570
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart-standard.md
@@ -0,0 +1,15 @@
+# Standard System
+
+- **[FAQ](quickstart-lite-env-setup-faqs.md)**
+
+- **[Setting Up Windows Development Environment](quickstart-standard-windows-environment.md)**
+
+- **[Setting Up Ubuntu Development Environment in Docker Mode and Building Source Code](quickstart-standard-docker-environment.md)**
+
+- **[Setting Up Ubuntu Development Environment with Installation Package and Building Source Code](quickstart-standard-package-environment.md)**
+
+- **[Burning Images](quickstart-standard-burn.md)**
+
+- **[FAQs](quickstart-standard-faq.md)**
+
+
diff --git a/en/device-dev/quick-start/quickstart.md b/en/device-dev/quick-start/quickstart.md
new file mode 100644
index 0000000000000000000000000000000000000000..3f82098be9f28557fc6a223f770197f21ee07c31
--- /dev/null
+++ b/en/device-dev/quick-start/quickstart.md
@@ -0,0 +1,7 @@
+# Getting Started
+
+- **[Mini and Small Systems](quickstart-lite.md)**
+
+- **[Standard System](quickstart-standard.md)**
+
+
diff --git a/en/device-dev/quick-start/running-a-hello-ohos-program-5.md b/en/device-dev/quick-start/running-a-hello-ohos-program-5.md
deleted file mode 100644
index e3f5d5e2955b1b44c9999d567a171ca426f5104b..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/running-a-hello-ohos-program-5.md
+++ /dev/null
@@ -1,262 +0,0 @@
-# Running a Hello OHOS Program
-
-- [Creating a Program](#section1550972416485)
-- [Building](#section234175193114)
-- [Burning](#section7609155824819)
-- [Running an Image](#section17612105814480)
-- [Follow-up Learning](#section9712145420182)
-
-This section describes how to create, compile, burn, and run the first program, and finally print **Hello OHOS!** on the develop board.
-
-## Creating a Program
-
-1. Create a directory and the program source code.
-
- Create the **applications/sample/camera/apps/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **OHOS** to **World**. You can use either C or C++ to develop a program.
-
- ```
- #include
-
- int main(int argc, char **argv)
- {
- printf("\n************************************************\n");
- printf("\n\t\tHello OHOS!\n");
- printf("\n************************************************\n\n");
-
- return 0;
- }
- ```
-
-2. Create a build file.
-
- Create the **applications/sample/camera/apps/BUILD.gn** file. The file content is as follows:
-
- ```
- import("//build/lite/config/component/lite_component.gni")
- lite_component("hello-OHOS") {
- features = [ ":helloworld" ]
- }
- executable("helloworld") {
- output_name = "helloworld"
- sources = [ "src/helloworld.c" ]
- include_dirs = []
- defines = []
- cflags_c = []
- ldflags = []
- }
- ```
-
-3. Add a component.
-
- Add the configuration of the **hello\_world\_app** component to the **build/lite/components/applications.json** file. The sample code below shows some configurations defined in the **applications.json** file, and the code between **"\#\#start\#\#"** and **"\#\#end\#\#"** is the new configuration \(Delete the rows where **"\#\#start\#\#"** and **"\#\#end\#\#"** are located after the configurations are added.\)
-
- ```
- {
- "components": [
- {
- "component": "camera_sample_communication",
- "description": "Communication related samples.",
- "optional": "true",
- "dirs": [
- "applications/sample/camera/communication"
- ],
- "targets": [
- "//applications/sample/camera/communication:sample"
- ],
- "rom": "",
- "ram": "",
- "output": [],
- "adapted_kernel": [ "liteos_a" ],
- "features": [],
- "deps": {
- "components": [],
- "third_party": []
- }
- },
- ##start##
- {
- "component": "hello_world_app",
- "description": "Communication related samples.",
- "optional": "true",
- "dirs": [
- "applications/sample/camera/apps"
- ],
- "targets": [
- "//applications/sample/camera/apps:hello-OHOS"
- ],
- "rom": "",
- "ram": "",
- "output": [],
- "adapted_kernel": [ "liteos_a" ],
- "features": [],
- "deps": {
- "components": [],
- "third_party": []
- }
- },
- ##end##
- {
- "component": "camera_sample_app",
- "description": "Camera related samples.",
- "optional": "true",
- "dirs": [
- "applications/sample/camera/launcher",
- "applications/sample/camera/cameraApp",
- "applications/sample/camera/setting",
- "applications/sample/camera/gallery",
- "applications/sample/camera/media"
- ],
- ```
-
-4. Modify the board configuration file.
-
- Add the **hello\_world\_app** component to the **vendor/hisilicon/hispark\_aries/config.json** file. The sample code below shows the configurations of the **applications** subsystem, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\)
-
- ```
- {
- "subsystem": "applications",
- "components": [
- ##start##
- { "component": "hello_world_app", "features":[] },
- ##end##
- { "component": "camera_sample_app", "features":[] }
-
- ]
- },
- ```
-
-
-## Building
-
-If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/docker-environment.md). If the Linux environment is installed using a software package, go to the root directory of the source code and run the following commands for source code compilation:
-
-```
-hb set (Set the building path.)
-. (Select the current path.)
-Select ipcamera_hispark_aries@hisilicon and press Enter.
-hb build -f (Start building.)
-```
-
-The result files are generated in the **out/hispark\_aries/ipcamera\_hispark\_aries** directory.
-
-**Figure 1** Settings
-
-
-> **NOTICE:**
->The U-Boot file of the Hi3518E V300 development board can be obtained from the following path: device/hisilicon/hispark\_aries/sdk\_liteos/uboot/out/boot/u-boot-hi3518ev300.bin
-
-## Burning
-
-The USB port is the only burning mode supported by the Hi3518 development board.
-
-1. Connect the PC and the target development board through the serial port and USB port. In this section, the Hi3518EV300 is used as an example. For details, see [Introduction to the Hi3518 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des_3518-0000001105201138).
-2. Open Device Manager, then check and record the serial port number corresponding to the development board.
-
- > **NOTE:**
- >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695).
-
- 
-
-3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
-
- 
-
-4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings.
-5. On the **hi3518ev300** tab page, set the programming options.
-
- - **upload\_port**: Select the serial port number obtained in [2](#en-us_topic_0000001057313128_li46411811196).
- - **upload\_protocol**: Select the programming protocol **hiburn-usb**.
- - **upload\_partitions**: Select the file to be programmed. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are programmed at the same time.
-
- 
-
-6. When you finish modifying, click **Save** in the upper right corner.
-7. Open the project file and click . In the DevEco Device Tool window, choose **PROJECT TASKS** \> **hi3518ev300\_fastboot** \> **Erase** to erase U-Boot.
-
- 
-
-8. When the following message is displayed, power off the development board and then power it on.
-
- 
-
-9. If the following message is displayed, it indicates that U-Boot is erased successfully.
-
- 
-
-10. Go to **hi3518ev300** \> **Upload** to start programming.
-
- 
-
-11. If the following message is displayed, it indicates that the programming is successful.
-
- 
-
-
-## Running an Image
-
-1. Connect to a serial port.
-
- > **NOTICE:**
- >If the connection fails, rectify the fault by referring to [FAQs](../quick-start/faqs-6.md).
-
- **Figure 2** Serial port connection
-
-
- 
-
- 1. Click **Monitor** to enable the serial port. The **TERMINAL** window is displayed.
- 2. Press **Enter** repeatedly until **hisilicon** displays.
- 3. Go to [step 2](#li9441185382314) if the board is started for the first time or the startup parameters need to be modified; go to [step 3](#li6442853122312) otherwise.
-
-2. \(Mandatory for first-time burning\) Modify the **bootcmd** and **bootargs** parameters of U-Boot. This step is a fixed operation and the result can be saved. However, you need to perform the following steps again if U-Boot needs to be reburnt.
-
- **Table 1** Parameters of the U-Boot
-
-
-
Run this command to set the content of bootcmd. Select the flash whose number is 0, and read content that has a size of 0x600000 (6 MB) and a start address of 0x100000 to memory address 0x40000000. The size must be the same as that of the OHOS_Image.bin file in the IDE.
In this command, bootargs is set to the serial port output, the baud rate is 115200, the data bit is 8, and the rootfs is mounted to the flash memory. The file system type is set to jffs2 rw, which provides the read-write attribute for the JFFS2 file system. rootaddr=7M rootsize=8M indicates the actual start address and length of the rootfs.img file to be burnt, respectively. The file size must be the same as that of the rootfs.img file in the IDE.
-
-
-
saveenv
-
-
saveenv means to save the current configuration.
-
-
-
reset
-
-
reset means to reset the board.
-
-
-
pri
-
-
pri means to view the displayed parameters.
-
-
-
-
-
- > **NOTICE:**
- >**go 0x40000000** \(optional\) indicates that the command is fixed in the startup parameters by default and the board automatically starts after it is reset. If you want to manually start the board, press **Enter** in the countdown phase of the U-Boot startup to interrupt the automatic startup.
-
-3. If **hisilicon \#** is displayed during the startup, run the **reset** command. After the system automatically starts and **OHOS** is displayed, run the **./bin/helloworld** command and then press **Enter**. The system is started successfully if information shown in the following figure is displayed.
-
- **Figure 3** Successful system startup and program execution
- 
-
-
-## Follow-up Learning
-
-Congratulations! You have finished all steps! You are advised to go on learning how to develop [Cameras with a Screen](../guide/cameras-with-a-screen.md).
-
diff --git a/en/device-dev/quick-start/running-a-hello-ohos-program.md b/en/device-dev/quick-start/running-a-hello-ohos-program.md
deleted file mode 100644
index 1bc2f5daad267626fea4ccda977975597197e26e..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/running-a-hello-ohos-program.md
+++ /dev/null
@@ -1,269 +0,0 @@
-# Running a Hello OHOS Program
-
-- [Creating a Program](#section204672145202)
-- [Building](#section1077671315253)
-- [Burning](#section1347011412201)
-- [Running an Image](#section24721014162010)
-- [Running a Program](#section5276734182615)
-
-This section describes how to create, compile, burn, and run the first program, and finally print **Hello OHOS!** on the develop board.
-
-## Creating a Program
-
-1. Create a directory and the program source code.
-
- Create the **applications/sample/camera/apps/src/helloworld.c** directory and file whose code is shown in the following example. You can customize the content to be printed. For example, you can change **OHOS** to **World**. You can use either C or C++ to develop a program.
-
- ```
- #include
-
- int main(int argc, char **argv)
- {
- printf("\n************************************************\n");
- printf("\n\t\tHello OHOS!\n");
- printf("\n************************************************\n\n");
-
- return 0;
- }
- ```
-
-2. Create a build file.
-
- Create the **applications/sample/camera/apps/BUILD.gn** file. The file content is as follows:
-
- ```
- import("//build/lite/config/component/lite_component.gni")
- lite_component("hello-OHOS") {
- features = [ ":helloworld" ]
- }
- executable("helloworld") {
- output_name = "helloworld"
- sources = [ "src/helloworld.c" ]
- include_dirs = []
- defines = []
- cflags_c = []
- ldflags = []
- }
- ```
-
-3. Add a new component.
-
- Add the configuration of the **hello\_world\_app** component to the **build/lite/components/applications.json** file. The sample code below shows some configurations defined in the **applications.json** file, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\)
-
- ```
- {
- "components": [
- {
- "component": "camera_sample_communication",
- "description": "Communication related samples.",
- "optional": "true",
- "dirs": [
- "applications/sample/camera/communication"
- ],
- "targets": [
- "//applications/sample/camera/communication:sample"
- ],
- "rom": "",
- "ram": "",
- "output": [],
- "adapted_kernel": [ "liteos_a" ],
- "features": [],
- "deps": {
- "components": [],
- "third_party": []
- }
- },
- ##start##
- {
- "component": "hello_world_app",
- "description": "Communication related samples.",
- "optional": "true",
- "dirs": [
- "applications/sample/camera/apps"
- ],
- "targets": [
- "//applications/sample/camera/apps:hello-OHOS"
- ],
- "rom": "",
- "ram": "",
- "output": [],
- "adapted_kernel": [ "liteos_a" ],
- "features": [],
- "deps": {
- "components": [],
- "third_party": []
- }
- },
- ##end##
- {
- "component": "camera_sample_app",
- "description": "Camera related samples.",
- "optional": "true",
- "dirs": [
- "applications/sample/camera/launcher",
- "applications/sample/camera/cameraApp",
- "applications/sample/camera/setting",
- "applications/sample/camera/gallery",
- "applications/sample/camera/media"
- ],
- ```
-
-4. Modify the board configuration file.
-
- Add the **hello\_world\_app** component to the **vendor/hisilicon/hispark\_taurus/config.json** file. The sample code below shows the configurations of the **applications** subsystem, and the code between **\#\#start\#\#** and **\#\#end\#\#** is the new configuration \(Delete the rows where **\#\#start\#\#** and **\#\#end\#\#** are located after the configurations are added.\)
-
- ```
- {
- "subsystem": "applications",
- "components": [
- { "component": "camera_sample_app", "features":[] },
- { "component": "camera_sample_ai", "features":[] },
- ##start##
- { "component": "hello_world_app", "features":[] },
- ##end##
- { "component": "camera_screensaver_app", "features":[] }
- ]
- },
- ```
-
-
-## Building
-
-If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/docker-environment.md). If the Linux environment is installed using a software package, go to the root directory of the source code and run the following commands for source code compilation:
-
-```
-hb set (Set the building path.)
-. (Select the current path.)
-Select ipcamera_hispark_taurus@hisilicon and press Enter.
-hb build -f (Start building.)
-```
-
-**Figure 1** Settings
-
-
-The result files are generated in the **out/hispark\_taurus/ipcamera\_hispark\_taurus** directory.
-
-> **NOTICE:**
->The U-Boot file of the Hi3516D V300 development board can be obtained from the following path: device/hisilicon/hispark\_taurus/sdk\_liteos/uboot/out/boot/u-boot-hi3516dv300.bin
-
-## Burning
-
-The Hi3516 development board allows you to burn flash memory over the USB port, serial port, or network port. The following uses the network port burning as an example.
-
-1. Connect the PC and the target development board through the power port, serial port, and network port. In this section, the Hi3516DV300 is used as an example. For details, please refer to [Introduction to the Hi3516 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des_3516-0000001152041033).
-2. Open Device Manager, then check and record the serial port number corresponding to the development board.
-
- > **NOTE:**
- >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3516 or Hi3518 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3516_hi3518-drivers-0000001050743695).
-
- 
-
-3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
-
- 
-
-4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings.
-5. On the **hi3516dv300** tab page, set the programming options.
-
- - **upload\_port**: Select the serial port number obtained in [2](#en-us_topic_0000001056443961_li142386399535).
- - **upload\_protocol**: Select the programming protocol **hiburn-net**.
- - **upload\_partitions**: Select the file to be programmed. By default, the **fastboot**, **kernel**, **rootfs**, and **userfs** files are programmed at the same time.
-
- 
-
-6. Check and set the IP address of the network adapter connected to the development board. For details, see [Setting the IP Address of the Network Port for Programming on Hi3516](https://device.harmonyos.com/en/docs/ide/user-guides/set_ipaddress-0000001141825075).
-7. Set the IP address of the network port for programming:
-
- - **upload\_net\_server\_ip**: Select the IP address set in [6](#en-us_topic_0000001056443961_li1558813168234). Example: 192.168.1.2.
- - **upload\_net\_client\_mask**: Set the subnet mask of the development board, such as 255.255.255.0. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. Example: 255.255.255.0.
- - **upload\_net\_client\_gw**: Set the gateway of the development board, such as 192.168.1.1. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. Example: 192.168.1.1.
- - **upload\_net\_client\_ip**: Set the IP address of the development board, such as 192.168.1.3. Once the **upload\_net\_server\_ip** field is set, this field will be automatically populated. Example: 192.168.1.3.
-
- 
-
-8. When you finish modifying, click **Save** in the upper right corner.
-9. Open the project file and click . In the DevEco Device Tool window, choose **PROJECT TASKS** \> **hi3516dv300** \> **Upload** to start programming.
-
- 
-
-10. When the following message is displayed, power off the development board and then power it on.
-
- 
-
-11. Start burning. When the following message is displayed, the burning is successful.
-
- 
-
-
-## Running an Image
-
-1. Connect to a serial port.
-
- > **NOTICE:**
- >If the connection fails, rectify the fault by referring to [FAQs](../quick-start/faqs-3.md).
-
- **Figure 2** Serial port connection
-
-
- 
-
- 1. Click **Monitor** to enable the serial port.
- 2. Press **Enter** repeatedly until **hisilicon** displays.
- 3. Go to step [2](#l5b42e79a33ea4d35982b78a22913b0b1) if the board is started for the first time or the startup parameters need to be modified; go to step [3](#ld26f18828aa44c36bfa36be150e60e49) otherwise.
-
-2. \(Mandatory when the board is started for the first time\) Modify the bootcmd and bootargs parameters of U-Boot. You need to perform this step only once if the parameters need not to be modified during the operation. The board automatically starts after it is reset.
-
- > **NOTICE:**
- >The default waiting time in the U-Boot is 2s. You can press **Enter** to interrupt the waiting and run the **reset** command to restart the system after "hisilicon" is displayed.
-
- **Table 1** Parameters of the U-Boot
-
-
-
Command
-
-
Description
-
-
-
-
setenv bootcmd "mmc read 0x0 0x80000000 0x800 0x4800; go 0x80000000";
-
-
Run this command to read content that has a size of 0x4800 (9 MB) and a start address of 0x800 (1 MB) to the memory address 0x80000000. The file size must be the same as that of the OHOS_Image.bin file in the IDE.
Run this command to set the output mode to serial port output, baud rate to 115200, data bit to 8, rootfs to be mounted to the emmc component, and file system type to vfat.
-
rootaddr=10M rootsize=20M rw indicates the start address and size of the rootfs.img file to be burnt, respectively. The file size must be the same as that of the rootfs.img file in the IDE.
-
-
-
saveenv
-
-
saveenv means to save the current configuration.
-
-
-
reset
-
-
reset means to reset the board.
-
-
-
-
-
- > **NOTICE:**
- >**go 0x80000000** \(optional\) indicates that the command is fixed in the startup parameters by default and the board automatically starts after it is reset. If you want to manually start the board, press **Enter** in the countdown phase of the U-Boot startup to interrupt the automatic startup.
-
-3. Run the **reset** command and press **Enter** to restart the board. After the board is restarted, **OHOS** is displayed when you press **Enter**.
-
- **Figure 3** System startup
-
-
- 
-
-
-## Running a Program
-
-In the root directory, run the **./bin/helloworld** command to operate the demo program. The compilation result is shown in the following example.
-
-**Figure 4** Successful system startup and program execution
-
-
diff --git a/en/device-dev/quick-start/running-a-hello-world-program.md b/en/device-dev/quick-start/running-a-hello-world-program.md
deleted file mode 100644
index 033f919351f898df2b656b5512bedf524a613adb..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/running-a-hello-world-program.md
+++ /dev/null
@@ -1,156 +0,0 @@
-# Running a Hello World Program
-
-- [Modifying Source Code](#section79601457101015)
-- [Debugging and Verification](#section1621064881419)
-- [printf](#section1246911301217)
-- [Locating Exceptions Using the asm File](#section199621957141014)
-- [Viewing Execution Result](#section18115713118)
-- [Follow-up Learning](#section9712145420182)
-
-This example shows how to compile a simple service and print **Hello World** to help you preliminarily understand how to run OpenHarmony on Hi3861.
-
-## Modifying Source Code
-
-The source code needs to be modified when fixing bugs or compiling a new service. The following describes how to modify the source code when compiling a new service, for example, **my\_first\_app**.
-
-1. Determine the directory structure.
-
- Before compiling a service, you must create a directory \(or a directory structure\) in **./applications/sample/wifi-iot/app** to store source code files.
-
- For example, add the **my\_first\_app** service to the **app** directory, where **hello\_world.c** is the service code and **BUILD.gn** is the compilation script. The directory structure is shown as follows:
-
- ```
- .
- └── applications
- └── sample
- └── wifi-iot
- └── app
- │── my_first_app
- │ │── hello_world.c
- │ └── BUILD.gn
- └── BUILD.gn
- ```
-
-2. Compile the service code.
-
- Create the **hello\_world.c** file in **./applications/sample/wifi-iot/app/my\_first\_app**. Then, create the service entry function **HelloWorld** in **hello\_world.c** and implement service logic. Use the SYS\_RUN\(\) of the OpenHarmony **bootstrap** module to start services. \(**SYS\_RUN** is defined in the **ohos\_init.h** file.\)
-
- ```
- #include
- #include "ohos_init.h"
- #include "ohos_types.h"
-
- void HelloWorld(void)
- {
- printf("[DEMO] Hello world.\n");
- }
- SYS_RUN(HelloWorld);
- ```
-
-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.
-
- ```
- static_library("myapp") {
- sources = [
- "hello_world.c"
- ]
- include_dirs = [
- "//utils/native/lite/include"
- ]
- }
- ```
-
- - Specify the compilation result named libmyapp.a in **static\_library**. You can fill in this part based on your need.
- - 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. 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:
-
- ```
- import("//build/lite/config/component/lite_component.gni")
-
- lite_component("app") {
- features = [
- "my_first_app:myapp",
- ]
- }
- ```
-
- - **my\_first\_app** is a relative path that points to **./applications/sample/wifi-iot/app/my\_first\_app/BUILD.gn**.
- - **myapp** represents the **static\_library\("myapp"\)** in **./applications/sample/wifi-iot/app/my\_first\_app/BUILD.gn**.
-
-
-## Debugging and Verification
-
-Currently, there are two debugging and verification methods: using printf to print logs and using asm files to locate **panic** problems. You can select one of them based on your need.
-
-As the service shown is simple, use the printf method. The following describes the two debugging methods.
-
-## printf
-
-Add **printf** function to the code, which helps print data to the serial port. You can add log printing in key service paths or service exception locations, as shown in the following figure.
-
-```
-void HelloWorld(void)
-{
- printf("[DEMO] Hello world.\n");
-}
-```
-
-## Locating Exceptions Using the asm File
-
-When the system exits abnormally, the call stack information about the abnormal exit is displayed on the serial port. The following is an example: You can locate the exception by parsing the exception stack information.
-
-```
-=======KERNEL PANIC=======
-**********************Call Stack*********************
-Call Stack 0 -- 4860d8 addr:f784c
-Call Stack 1 -- 47b2b2 addr:f788c
-Call Stack 2 -- 3e562c addr:f789c
-Call Stack 3 -- 4101de addr:f78ac
-Call Stack 4 -- 3e5f32 addr:f78cc
-Call Stack 5 -- 3f78c0 addr:f78ec
-Call Stack 6 -- 3f5e24 addr:f78fc
-********************Call Stack end*******************
-```
-
-To parse the call stack information, the **Hi3861\_wifiiot\_app.asm** file is required. This file records the symbol addresses of the functions in the code in the flash memory and the disassembly information. The asm file is built and output together with the version software package and is stored in the **./out/wifiiot/** directory.
-
-1. \(Optional\) Save the **CallStack** information to a TXT file for editing.
-2. Open the asm file, search for the function address in each call stack, and list the corresponding function. Generally, you only need to find the functions matching the first several stacks to locate exceptions.
-
- ```
- Call Stack 0 -- 4860d8 addr:f784c -- WadRecvCB
- Call Stack 1 -- 47b2b2 addr:f788c -- wal_sdp_process_rx_data
- Call Stack 2 -- 3e562c addr:f789c
- Call Stack 3 -- 4101de addr:f78ac
- Call Stack 4 -- 3e5f32 addr:f78cc
- Call Stack 5 -- 3f78c0 addr:f78ec
- Call Stack 6 -- 3f5e24 addr:f78fc
- ```
-
-3. Determine that an exception occurs in the **WadRecvCB** function based on the call stack information.
-
- 
-
-4. Check and modify the code.
-
-## Viewing Execution Result
-
-After the sample code is compiled, burnt, run, and debugged, the following information is displayed on the serial port interface:
-
-```
-ready to OS start
-FileSystem mount ok.
-wifi init success!
-[DEMO] Hello world.
-```
-
-## Follow-up Learning
-
-Congratulations! You have finished all steps! You are advised to go on learning how to develop [WLAN-connected products](../guide/wlan-connected-products.md).
-
diff --git a/en/device-dev/quick-start/setting-up-the-environment-2.md b/en/device-dev/quick-start/setting-up-the-environment-2.md
deleted file mode 100644
index 0e8430d75a7fa0bfe54420a0fcb8638108732710..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/setting-up-the-environment-2.md
+++ /dev/null
@@ -1,122 +0,0 @@
-# Setting Up the Environment
-
-- [Environment Requirements](#section179175261196)
- - [Hardware](#section5840424125014)
- - [Software](#section965634210501)
-
-- [Installing Linux Build Tools](#section182916865219)
- - [Changing Linux Shell to Bash](#section1715027152617)
- - [Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)](#section45512412251)
- - [Installing File Packing Tools and JVM](#section16199102083717)
-
-
-## Environment Requirements
-
-### Hardware
-
-- Hi3516D V300 IoT camera development board
-- USB-to-serial cable and network cable \(The Windows workstation is connected to the Hi3516D V300 development board through the USB-to-serial cable and network cable.\)
-
-The following figure shows the hardware connections.
-
-**Figure 1** Hardware connections
-
-
-
-
-### Software
-
-> **NOTICE:**
->This section describes how to use an installation package to set up the compilation and development environment. If you are going to use Docker to set up the environment, skip this section and [Installing Linux Build Tools](#section182916865219).
-
-The following table describes the tools required for setting up the general environment for a Linux server of the Hi3516 development board and how to obtain these tools.
-
-**Table 1** Development tools and obtaining methods
-
-
-
Development Tool
-
-
Description
-
-
How to Obtain
-
-
-
-
bash
-
-
Processes CLI commands.
-
-
System configuration
-
-
-
Basic software package for compilation and building (required only for Ubuntu 20+)
-
-
Provides a basic software package for compilation and building.
-
-
Internet
-
-
-
dosfstools, mtools, and mtd-utils
-
-
Pack files.
-
-
apt-get install
-
-
-
Java virtual machine (JVM)
-
-
Compiles, debugs, and runs Java programs.
-
-
apt-get install
-
-
-
-
-
-## Installing Linux Build Tools
-
-> **NOTICE:**
->- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install compilation tools like **LLVM** and **hc-gen**.
->- \(Recommended\) If you obtain the source code via the mirror site or code repository, install **hc-gen**. When installing the compilation tool, ensure that its environment variable path is unique.
-
-### Changing Linux Shell to Bash
-
-Check whether bash is used as the shell.
-
-```
-ls -l /bin/sh
-```
-
-If **/bin/sh -\> bash** is not displayed, do as follows to change shell to bash.
-
-**Method 1:** Run the following command on the device and then click **No**.
-
-```
-sudo dpkg-reconfigure dash
-```
-
-**Method 2:** Run the first command to delete **sh** and then run the second command to create a new soft link.
-
-```
-sudo rm -rf /bin/sh
-sudo ln -s /bin/bash /bin/sh
-```
-
-### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)
-
-Install the software.
-
-```
-sudo apt-get install build-essential gcc g++ make zlib* libffi-dev
-```
-
-### Installing File Packing Tools and JVM
-
-1. Start a Linux server.
-2. Install the dosfstools, mtools, mtd-utils, Java Runtime Environment \(JRE\), and Java SDK.
-
- ```
- sudo apt-get install dosfstools mtools mtd-utils default-jre default-jdk
- ```
-
-
diff --git a/en/device-dev/quick-start/setting-up-the-environment-4.md b/en/device-dev/quick-start/setting-up-the-environment-4.md
deleted file mode 100644
index 606871622b0805662544e092fd9c1e64e4f1cb27..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/setting-up-the-environment-4.md
+++ /dev/null
@@ -1,114 +0,0 @@
-# Setting Up the Environment
-
-- [Environment Requirements](#section1724111409282)
- - [Hardware](#section487353718276)
- - [Software Requirements](#section17315193935817)
-
-- [Installing Linux Build Tools](#section8831868501)
- - [Changing Linux Shell to Bash](#section434110241084)
- - [Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)](#section25911132141020)
- - [Installing File Packing Tools](#section390214473129)
-
-
-## Environment Requirements
-
-### Hardware
-
-- Hi3518E V300 IoT camera development board
-- USB-to-serial cable and network cable \(The Windows workstation is connected to the Hi3518E V300 development board through the USB-to-serial cable and network cable.\)
-
- The following figure shows the hardware connections.
-
-
-**Figure 1** Hardware connections
-
-
-### Software Requirements
-
-> **NOTICE:**
->This section describes how to use an installation package to set up the compilation and development environment. If you are going to use Docker to set up the environment, skip this section and [Installing Linux Build Tools](#section8831868501).
-
-The following table describes the tools required for setting up the general environment for a Linux server of the Hi3518 development board and how to obtain these tools.
-
-**Table 1** Development tools and obtaining methods
-
-
-
Development Tool
-
-
Description
-
-
How to Obtain
-
-
-
-
bash
-
-
Processes CLI commands.
-
-
System configuration
-
-
-
Basic software package for compilation and building (required only for Ubuntu 20+)
-
-
Provides a basic software package for compilation and building.
-
-
Internet
-
-
-
dosfstools, mtools, and mtd-utils
-
-
Pack files.
-
-
apt-get install
-
-
-
-
-
-## Installing Linux Build Tools
-
-> **NOTICE:**
->- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install **hc-gen**.
->- \(Recommended\) If you obtain the source code via the mirror site or code repository, install **hc-gen**. When installing the compilation tool, ensure that its environment variable path is unique.
-
-### Changing Linux Shell to Bash
-
-Check whether bash is used as the shell.
-
-```
-ls -l /bin/sh
-```
-
-If **/bin/sh -\> bash** is not displayed, do as follows to change shell to bash.
-
-**Method 1:** Run the following command on the device and then click **No**.
-
-```
-sudo dpkg-reconfigure dash
-```
-
-**Method 2:** Run the first command to delete **sh** and then run the second command to create a new soft link.
-
-```
-sudo rm -rf /bin/sh
-sudo ln -s /bin/bash /bin/sh
-```
-
-### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)
-
-Install the software.
-
-```
-sudo apt-get install build-essential gcc g++ make zlib* libffi-dev
-```
-
-### Installing File Packing Tools
-
-1. Start a Linux server.
-2. Install dosfstools, mtools, and mtd-utils.
-
- ```
- sudo apt-get install dosfstools mtools mtd-utils
- ```
-
-
diff --git a/en/device-dev/quick-start/setting-up-the-environment.md b/en/device-dev/quick-start/setting-up-the-environment.md
deleted file mode 100644
index 9eb8b040c6320fb44813778e45d0cfe647623a74..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/setting-up-the-environment.md
+++ /dev/null
@@ -1,367 +0,0 @@
-# Setting Up the Environment
-
-- [Environment Requirements](#section466851916410)
- - [Hardware](#section19202111020215)
- - [Software](#section727451210318)
-
-- [Installing Linux Build Tools](#section497484245614)
- - [Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)](#section45512412251)
- - [Installing Scons](#section7438245172514)
- - [Installing Python Modules](#section88701892341)
- - [Installing gcc\_riscv32 \(Compilation Toolchain for WLAN Module\)](#section34435451256)
-
-- [Installing the USB-to-Serial Driver](#section1027732411513)
-
-## Environment Requirements
-
-### Hardware
-
-- Linux compile server
-- Windows workstation \(host computer\)
-- Hi3861 WLAN module
-- USB Type-C cable used to connect the Windows workstation to Hi3861 WLAN module
-
-The following figure shows the hardware connections.
-
-**Figure 1** Hardware connections
-
-
-### Software
-
-> **NOTICE:**
->The following part describes how to install tools using installation packages. If you use Docker to set up the build environment, you only need to install the Windows workstation described in [Table 1](#table6299192712513).
-
-The following table lists the tools required for the Hi3861 development board.
-
-**Table 1** Required tools
-
-
-
Platform
-
-
Development Tool
-
-
Description
-
-
How to Obtain
-
-
-
-
Linux server
-
-
Basic software package for compilation and building (required only for Ubuntu 20+)
-
-
Provides a basic software package for compilation and building.
-
-
Internet
-
-
-
Linux server
-
-
SCons 3.0.4+
-
-
Executes script compilation.
-
-
Internet
-
-
-
Linux server
-
-
Python modules: setuptools, Kconfiglib, PyCryptodome, six, and ecdsa
-
-## Installing Linux Build Tools
-
-> **NOTICE:**
->- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install **gcc\_riscv32**.
->- \(Recommended\) If you obtain the source code via the mirror site or code repository, install **gcc\_riscv32**. When installing the compilation tool, ensure that its environment variable path is unique.
-
-### Installing Basic Software Used for Compilation and Building \(Required Only for Ubuntu 20+\)
-
-Install the software.
-
-```
-sudo apt-get install build-essential gcc g++ make zlib* libffi-dev
-```
-
-### Installing Scons
-
-1. Start a Linux server.
-2. Install the SCons installation package.
-
- ```
- python3 -m pip install scons
- ```
-
-3. Check whether the installation is successful.
-
- ```
- scons -v
- ```
-
- **Figure 2** Successful installation \(SCons version requirement: 3.0.4 or later\)
- .png "successful-installation-(scons-version-requirement-3-0-4-or-later)")
-
-
-### Installing Python Modules
-
-1. Install setuptools.
-
- ```
- pip3 install setuptools
- ```
-
-2. Install the GUI menuconfig tool \(Kconfiglib\). You are advised to install Kconfiglib 13.2.0 or later.
- - **Command line:**
-
- ```
- 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.
-
- ```
- sudo pip3 install kconfiglib-13.2.0-py2.py3-none-any.whl
- ```
-
-
-
-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.
-
- - **Command line:**
-
- ```
- sudo pip3 install pycryptodome
- ```
-
- - **Installation package:**
- 1. Download the **.whl** file \(for example, **pycryptodome-3.9.9-cp38-cp38-manylinux1\_x86\_64.whl**\).
-
- Download path: [https://pypi.org/project/pycryptodome/\#files](https://pypi.org/project/pycryptodome/#files)
-
-
- 1. Install the **.whl** file.
-
- ```
- sudo pip3 install pycryptodome-3.9.9-cp38-cp38-manylinux1_x86_64.whl
- ```
-
-
-
-4. Install **six** using either of the following methods:
- - **Command line:**
-
- ```
- 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.
-
- ```
- sudo pip3 install six-1.12.0-py2.py3-none-any.whl
- ```
-
-
-
-5. Install **ecdsa** using either of the following methods:
- - **Command line:**
-
- ```
- sudo pip3 install ecdsa
- ```
-
- - **Installation package:**
- 1. Download the **.whl** file, for example, **ecdsa-0.14.1-py2.py3-none-any.whl**.
-
- Download path: [https://pypi.org/project/ecdsa/\#files](https://pypi.org/project/ecdsa/#files)
-
-
- 1. Install the **.whl** file.
-
- ```
- sudo pip3 install ecdsa-0.14.1-py2.py3-none-any.whl
- ```
-
-
-
-
-### Installing gcc\_riscv32 \(Compilation Toolchain for WLAN Module\)
-
-> **NOTICE:**
->- The Hi3861 platform supports only the static link of the libgcc library. The dynamic link is not recommended because version 3 of the GNU General Public License \(GPLv3\) will be polluted during commercial distribution.
->- Steps 2 to 15 of the following procedure are used to build the **gcc\_riscv32** image. You can simply [download the image](https://repo.huaweicloud.com/harmonyos/compiler/gcc_riscv32/7.3.0/linux/gcc_riscv32-linux-7.3.0.tar.gz) and skip these steps.
-
-1. Start a Linux server.
-2. Install the **GCC**, **G++**, **Bison**, **Flex**, **Makeinfo** tools to ensure that the toolchain can be correctly compiled.
-
- ```
- sudo apt-get install gcc && sudo apt-get install g++ && sudo apt-get install flex bison && sudo apt-get install texinfo
- ```
-
-3. Download the RISC-V GNU toolchain.
-
- ```
- git clone --recursive https://gitee.com/mirrors/riscv-gnu-toolchain.git
- ```
-
-4. Open the **riscv-gnu-toolchain** folder and delete empty folders to prevent conflicts during the download of **Newlib**, **Binutils**, and **GCC**.
-
- ```
- cd riscv-gnu-toolchain && rm -rf riscv-newlib && rm -rf riscv-binutils && rm -rf riscv-gcc
- ```
-
-5. Download RISC-V Newlib 3.0.0.
-
- ```
- git clone -b riscv-newlib-3.0.0 https://github.com/riscv/riscv-newlib.git
- ```
-
-6. Download RISC-V Binutils 2.31.1.
-
- ```
- git clone -b riscv-binutils-2.31.1 https://github.com/riscv/riscv-binutils-gdb.git
- ```
-
-7. Download RISC-V GCC 7.3.0.
-
- ```
- git clone -b riscv-gcc-7.3.0 https://github.com/riscv/riscv-gcc
- ```
-
-8. Add the RISC-V GCC 7.3.0 patch.
-
- Visit the GCC official patch links [89411](https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=026216a753ef0a757a9e368a59fa667ea422cf09;hp=2a23a1c39fb33df0277abd4486a3da64ae5e62c2) and [86724](https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/graphite.h;h=be0a22b38942850d88feb159603bb846a8607539;hp=4e0e58c60ab83f1b8acf576e83330466775fac17;hb=b1761565882ed6a171136c2c89e597bc4dd5b6bf;hpb=fbd5f023a03f9f60c6ae36133703af5a711842a3), and manually add the changes to the .c and .h files based on the requirements in the patch links. Note that the number of rows may not match because of different versions of the patch and GCC. You need to search for the keyword in the patch to locate the corresponding row.
-
-9. Download, decompress, and install [GMP 6.1.2](https://gmplib.org/download/gmp/gmp-6.1.2.tar.bz2).
-
- ```
- tar -xvf gmp-6.1.2.tar.bz2 && mkdir build_gmp && cd build_gmp && ../gmp-6.1.2/configure --prefix=/usr/local/gmp-6.1.2 --disable-shared --enable-cxx && make && make install
- ```
-
-10. Download, decompress, and install [mpfr-4.0.2](https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.gz).
-
- ```
- tar -xvf mpfr-4.0.2.tar.gz && mkdir build_mpfr && cd build_mpfr && ../mpfr-4.0.2/configure --prefix=/usr/local/mpfr-4.0.2 --with-gmp=/usr/local/gmp-6.1.2 --disable-shared && make && make install
- ```
-
-11. Download, decompress, and install [mpc-1.1.0](https://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz).
-
- ```
- tar -xvf mpc-1.1.0.tar.gz && mkdir build_mpc && cd build_mpc && ../mpc-1.1.0/configure --prefix=/usr/local/mpc-1.1.0 --with-gmp=/usr/local/gmp-6.1.2 --with-mpfr=/usr/local/mpfr-4.0.2 --disable-shared && make && make install
- ```
-
-12. Open the **riscv-gnu-toolchain** folder and create a directory for toolchain output.
-
- ```
- cd /opt && mkdir gcc_riscv32
- ```
-
-13. Compile **binutils**.
-
- ```
- mkdir build_binutils && cd build_binutils && ../riscv-binutils-gdb/configure --prefix=/opt/gcc_riscv32 --target=riscv32-unknown-elf --with-arch=rv32imc --with-abi=ilp32 --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --enable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-multilib --enable-poison-system-directories --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib CFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" CFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" --bindir=/opt/gcc_riscv32/bin --libexecdir=/opt/gcc_riscv32/riscv32 --libdir=/opt/gcc_riscv32 --includedir=/opt/gcc_riscv32 && make -j16 && make install && cd ..
- ```
-
-14. Build **Newlib**.
-
- ```
- mkdir build_newlib && cd build_newlib && ../riscv-newlib/configure --prefix=/opt/gcc_riscv32 --target=riscv32-unknown-elf --with-arch=rv32imc --with-abi=ilp32 --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --enable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-multilib --enable-poison-system-directories --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib CFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" \CXXFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" CFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" --bindir=/opt/gcc_riscv32/bin --libexecdir=/opt/gcc_riscv32 --libdir=/opt/gcc_riscv32 --includedir=/opt/gcc_riscv32 && make -j16 && make install && cd ..
- ```
-
-15. Build **GCC**.
-
- ```
- mkdir build_gcc && cd build_gcc && ../riscv-gcc/configure --prefix=/opt/gcc_riscv32 --target=riscv32-unknown-elf --with-arch=rv32imc --with-abi=ilp32 --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --enable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-multilib --enable-poison-system-directories --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib CFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" CXXFLAGS="-fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now,-z,noexecstack -fPIE" LDFLAGS="-Wl,-z,relro,-z,now,-z,noexecstack" CXXFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" CFLAGS_FOR_TARGET="-Os -mcmodel=medlow -Wall -fstack-protector-strong -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fno-short-enums -fno-short-wchar" --with-headers="/opt/gcc-riscv32/riscv32-unknown-elf/include" --with-mpc=/usr/local/mpc-1.1.0 --with-gmp=/usr/local/gmp-6.1.2 --with-mpfr=/usr/local/mpfr-4.0.2 && make -j16 && make install
- ```
-
-16. Set an environment variable.
-
- > **NOTE:**
- >If you use the compiled **riscv32 gcc** package, perform the following steps to set environment variables:
- >1. Decompress the package to the root directory.
- > ```
- > tar -xvf gcc_riscv32-linux-7.3.0.tar.gz -C ~
- > ```
- >2. Set an environment variable.
- > ```
- > vim ~/.bashrc
- > ```
- >3. Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
- > ```
- > export PATH=~/gcc_riscv32/bin:$PATH
- > ```
-
- ```
- vim ~/.bashrc
- ```
-
- Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
-
- ```
- export PATH=~/gcc_riscv32/bin:$PATH
- ```
-
-17. Validate the environment variable.
-
- ```
- source ~/.bashrc
- ```
-
-18. Check whether the compiler is successfully installed. If the compiler version number is correctly displayed, the installation is successful.
-
- ```
- riscv32-unknown-elf-gcc -v
- ```
-
-
-## Installing the USB-to-Serial Driver
-
-Perform the following operations on the Windows station.
-
-1. Download the USB-to-serial driver: [CH341SER USB-to-serial driver](http://www.wch-ic.com/search?t=all&q=CH340g).
-2. Install the driver.
-3. After the driver is installed, remove and then insert the USB cable. The serial port entry should be displayed as shown in the following figure.
-
- 
-
-
diff --git a/en/device-dev/quick-start/setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md b/en/device-dev/quick-start/setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md
deleted file mode 100644
index 0a3ca86c3294e3af31e06cd636d3c886c897ce94..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md
+++ /dev/null
@@ -1,118 +0,0 @@
-# Setting Up Ubuntu Development Environment in Docker Mode and Building Source Code
-
-- [Obtaining Standard-System Source Code](#section8761819202511)
- - [Prerequisites](#section102871547153314)
- - [Procedure](#section429012478331)
-
-- [Obtaining the Docker Environment](#section181431248132513)
-- [Building Source Code](#section92391739152318)
-
-The standard OpenHarmony system provides a Docker environment which encapsulates build tools.
-
-> **NOTE:**
->- Before using Docker, install it by following instructions in [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/).
->- You can also use the [installation package](setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md) to set up the Ubuntu development environment.
-
-## Obtaining Standard-System Source Code
-
-### Prerequisites
-
-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.
-
- ```
- git config --global user.name "yourname"
- git config --global user.email "your-email-address"
- git config --global credential.helper store
- ```
-
-4. Run the following commands to install the **repo** tool:
-
- ```
- curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
- chmod a+x /usr/local/bin/repo
- pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
- ```
-
-
-### Procedure
-
-Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\)
-
-```
-repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify
-repo sync -c
-repo forall -c 'git lfs pull'
-```
-
-Method 2: Use the **repo** tool to download the source code over HTTPS.
-
-```
-repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
-repo sync -c
-repo forall -c 'git lfs pull'
-```
-
-## Obtaining the Docker Environment
-
-**Method 1: Obtaining the Docker image from HUAWEI CLOUD SWR**
-
-1. Obtain the Docker image.
-
- ```
- docker pull swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
- ```
-
-2. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
-
- ```
- docker run -it -v $(pwd):/home/openharmony swr.cn-south-1.myhuaweicloud.com/openharmony-docker/openharmony-docker-standard:0.0.1
- ```
-
-
-**Method 2: Using the Dockerfile to build a local docker image**
-
-1. Obtain the Dockerfile script for a local Docker image.
-
- ```
- git clone https://gitee.com/openharmony/docs.git
- ```
-
-2. Go to the directory of the Dockerfile code and run the following command to build the Docker image:
-
- ```
- cd docs/docker/standard
- ./build.sh
- ```
-
-3. Go to the root directory of OpenHarmony code and run the following command to access the Docker build environment:
-
- ```
- docker run -it -v $(pwd):/home/openharmony openharmony-docker-standard:0.0.1
- ```
-
-
-## Building Source Code
-
-1. Run the preprocessing script in the root directory of the source code.
-
- ```
- ../scripts/prepare.sh
- ```
-
-2. Run the following script to start building for Standard-System Devices \(reference memory ≥ 128 MB\):
-
- ```
- ./build.sh --product-name {product_name}
- ```
-
- **product\_name** indicates the product supported by the current distribution, for example, **Hi3516DV300**.
-
- 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.
-
-3. Burn the image. For details, see [Burning Images](burning-images.md).
-
-> **NOTE:**
->You can exit Docker by simply running the **exit** command.
-
diff --git a/en/device-dev/quick-start/setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md b/en/device-dev/quick-start/setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md
deleted file mode 100644
index 0aaa9188a038d1279efdb270e4ffc2ac04ea2273..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# Setting Up Ubuntu Development Environment with Installation Package and Building Source Code
-
-- [Installing Dependent Tools](#section18431165519244)
-- [Obtaining Standard-System Source Code](#section113751052102517)
- - [Prerequisites](#section102871547153314)
- - [Procedure](#section429012478331)
-
-- [Running prebuilts](#section0495320152619)
-- [Building Source Code](#section1664835963517)
-
-## Installing Dependent Tools
-
-The installation command is as follows:
-
-```
-sudo apt-get update && sudo apt-get install binutils git git-lfs gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4 bc gnutls-bin python3.8 python3-pip
-```
-
-> **NOTE:**
->The preceding command is applicable to Ubuntu 18.04. For other Ubuntu versions, modify the preceding installation command based on the installation package name.
-
-## Obtaining Standard-System Source Code
-
-### Prerequisites
-
-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.
-
- ```
- git config --global user.name "yourname"
- git config --global user.email "your-email-address"
- git config --global credential.helper store
- ```
-
-4. Run the following commands to install the **repo** tool:
-
- ```
- curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the access permission to this directory, download the tool to any other accessible directory and configure the directory to the environment variable.
- chmod a+x /usr/local/bin/repo
- pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
- ```
-
-
-### Procedure
-
-Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to Gitee.\)
-
-```
-repo init -u git@gitee.com:openharmony/manifest.git -b master --no-repo-verify
-repo sync -c
-repo forall -c 'git lfs pull'
-```
-
-Method 2: Use the **repo** tool to download the source code over HTTPS.
-
-```
-repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
-repo sync -c
-repo forall -c 'git lfs pull'
-```
-
-## Running prebuilts
-
-Go to the root directory of the source code and run the following script to install the compiler and binary tool:
-
-```
-bash build/prebuilts_download.sh
-```
-
-By default, the downloaded prebuilts binary file is stored in **OpenHarmony\_2.0\_canary\_prebuilts** \(which is in the same directory as **OpenHarmony**\).
-
-## Building Source Code
-
-Perform the following operations in the Linux environment:
-
-1. Go to the root directory of the source code and run the following command to build the distribution.
-
- ```
- ./build.sh --product-name {product_name}
- ```
-
- **product\_name** indicates the product supported by the current distribution, for example, **Hi3516DV300**.
-
-2. Check the build result. After the build is complete, the following information is displayed in the log:
-
- ```
- build system image successful.
- =====build Hi3516DV300 successful.
- ```
-
- 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.
-
- > **NOTE:**
- >For details about module-specific build operations, see [Compilation and Building Overview](../subsystems/building-guidelines-for-the-standard-system.md).
-
-3. Burn the image. For details, see [Burning Images](burning-images.md).
-
diff --git a/en/device-dev/quick-start/setting-up-windows-development-environment.md b/en/device-dev/quick-start/setting-up-windows-development-environment.md
deleted file mode 100644
index 4308389e169c415c5a502738359d0eed094fd3fc..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/setting-up-windows-development-environment.md
+++ /dev/null
@@ -1,183 +0,0 @@
-# Setting Up Windows Development Environment
-
-- [Obtaining the Software](#en-us_topic_0000001058091994_section1483143015558)
-- [Installing Visual Studio Code](#en-us_topic_0000001058091994_section71401018163318)
-- [Installing Python](#en-us_topic_0000001058091994_section16266553175320)
-- [Installing Node.js](#en-us_topic_0000001058091994_section5353233124511)
-- [Installing hpm](#en-us_topic_0000001058091994_section173054793610)
-- [Installing the DevEco Device Tool Plug-in](#en-us_topic_0000001058091994_section4336315185716)
-
-Operating system: 64-bit version of Windows 10.
-
-DevEco Device Tool is a plug-in for Visual Studio Code. The installation procedure includes five parts:
-
-1. Installing Visual Studio Code
-2. Installing Python
-3. Installing Node.js
-4. Installing hpm
-5. Installing the DevEco Device Tool Plug-in
-
-## Obtaining the Software
-
-
-
-
-## Installing Visual Studio Code
-
-> **NOTE:**
->If you have installed Visual Studio Code, open the CLT and run **code --version** to check whether the version is 1.53 or later. If the version number is returned, it indicates that the environment variables are set correctly.
-
-1. Double-click the Visual Studio Code package to install it. During the installation, select **Add to PATH \(requires shell restart\)**.
-
- 
-
-2. After the installation is complete, restart the computer for the environment variables of Visual Studio Code to take effect.
-3. Open the CLT and run **code --version**. If the version number can be displayed, it indicates that the installation is successful.
-
-## Installing Python
-
-1. Double-click the Python software package, select **Add Python xx to PATH**, and click **Install Now**.
-
- 
-
-2. After the installation is complete, click **Close**.
-
- 
-
-3. Open the CLT, and run **python --version** to check the installation result.
-
- 
-
-4. In the CLT, run the following commands to set the pip source for downloading the dependencies required for later installation:
-
- ```
- pip config set global.trusted-host repo.huaweicloud.com
- pip config set global.index-url https://repo.huaweicloud.com/repository/pypi/simple
- pip config set global.timeout 120
- ```
-
-
-## Installing Node.js
-
-> **NOTE:**
->If you have installed Node.js, open the CLT and run **node -v** to check whether the version is 12.0.0 or later.
-
-1. Run the downloaded software package to install. Use the default settings when following the installation wizard, and click **Next** until **Finish** is displayed. During the installation, Node.js will automatically set the system Path environment variable to the installation directory of **node.exe**.
-2. Open the CLT and run **node -v**. If the version number of Node.js is displayed, it indicates that Node.js has been successfully installed.
-
- 
-
-
-## Installing hpm
-
-Before installing hpm, ensure that Node.js has been installed
-
-and that your network can access the Internet. If your network requires a proxy to access the Internet, [set up the npm proxy](https://device.harmonyos.com/cn/docs/ide/user-guides/npm_proxy-0000001054491032) first.
-
-> **NOTE:**
->If hpm has been installed, run **npm update -g @ohos/hpm-cli** to update it to the latest version.
-
-1. You are advised to set the npm source to an image in China, for example, a HUAWEI CLOUD image source.
-
- ```
- npm config set registry https://repo.huaweicloud.com/repository/npm/
- ```
-
-2. Open the CLT and run the following command to install the latest version of hpm:
-
- ```
- npm install -g @ohos/hpm-cli
- ```
-
- 
-
-3. After the installation is complete, run the following command to obtain the installation result:
-
- ```
- hpm -V
- ```
-
- 
-
-
-## Installing the DevEco Device Tool Plug-in
-
-To install the DevEco Device Tool plug-in, ensure that the **user name of the host cannot contain Chinese characters**; otherwise, the plug-in may fail to run.
-
-DevEco Device Tool will automatically download and install the C/C++ and CodeLLDB plug-ins from the Visual Studio Code Marketplace during the installation process. Therefore, make sure Visual Studio Code can access the Internet. If your network requires a proxy to access the Internet, [set up the Visual Studio Code proxy](https://device.harmonyos.com/cn/docs/ide/user-guides/vscode_proxy-0000001074231144) first.
-
-> **NOTE:**
->Before installing DevEco Device Tool, ensure that Visual Studio Code is closed.
-
-1. Decompress the DevEco Device Tool plug-in package and double-click the installer to install.
-2. During the installation, the dependency files \(such as C/C++ and CodeLLDB plug-ins\) and execution programs required by DevEco Device Tool are automatically installed.
-
- 
-
-3. After the installation is complete, the CLT is automatically closed.
-4. Open Visual Studio Code, click the  button on the left, and check whether C/C++, CodeLLDB, and DevEco Device Tool are listed in **INSTALLED**.
-
- > **NOTE:**
- >If the C/C++ and CodeLLDB plug-ins fail to be installed, DevEco Device Tool cannot run properly. To solve the issue, see [Installing the C/C++ and CodeLLDB Plug-ins Offline](https://device.harmonyos.com/en/docs/ide/user-guides/offline_plugin_install-0000001074376846).
-
- 
-
-
diff --git a/en/device-dev/quick-start/standard-system.md b/en/device-dev/quick-start/standard-system.md
deleted file mode 100644
index f0aa95fdac24012324baa361c8958305bcfd436f..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/standard-system.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Standard System
-
-- **[Introduction](introduction.md)**
-
-- **[Setting Up Windows Development Environment](setting-up-windows-development-environment.md)**
-
-- **[Setting Up Ubuntu Development Environment in Docker Mode and Building Source Code](setting-up-ubuntu-development-environment-in-docker-mode-and-building-source-code.md)**
-
-- **[Setting Up Ubuntu Development Environment with Installation Package and Building Source Code](setting-up-ubuntu-development-environment-with-installation-package-and-building-source-code.md)**
-
-- **[Burning Images](burning-images.md)**
-
-- **[FAQs](faqs-7.md)**
-
-
diff --git a/en/device-dev/quick-start/ubuntu-build-environment.md b/en/device-dev/quick-start/ubuntu-build-environment.md
deleted file mode 100644
index 50c25fe1ea26c3f94dae8ce906c188d01e604850..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/ubuntu-build-environment.md
+++ /dev/null
@@ -1,361 +0,0 @@
-# Ubuntu Build Environment
-
-- [Obtaining Source Code and Tools](#section1897711811517)
-- [Obtaining Source Code](#section1545225464016)
-- [Installing and Configuring Python](#section1238412211211)
-- [Installing gn](#section29216201423)
-- [Installing ninja](#section8762358731)
-- [Installing LLVM](#section12202192215415)
-- [Installing hb](#section15794154618411)
- - [Prerequisites](#section1083283711515)
- - [Installation Procedure](#section11518484814)
- - [Uninstalling hb](#section3512551574)
-
-- [Installing Other Tools](#section830511218494)
- - [Installation Procedure](#section54409586499)
-
-
-Operating system: 64-bit version of Ubuntu 16.04 or later.
-
-Perform the following steps to set up the build environment:
-
-1. Obtain source code.
-2. Install and configure Python.
-3. Install GN.
-4. Install Ninja.
-5. Install LLVM.
-6. Install hb.
-
-> **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/docker-environment.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 the [Compilation and Building Overview](../subsystems/building-guidelines-for-mini-and-small-systems.md).
-
-## Obtaining Source Code and Tools
-
-The following table describes the tools and source code required for setting up the general environment for a Linux server and how to obtain these tools and the source code.
-
-**Table 1** Source code and development tools and their obtaining methods
-
-
-
Provide functions required in compilation and building, such as packaging and creating images.
-
-
Internet
-
-
-
-
-
-> **NOTICE:**
->- If you acquire the source code using an HPM component or HPM CLI tool, you do not need to install compilation tools like **gn** and **ninja**.
->- \(Recommended\) If you obtain the source code via the mirror site or code repository, install compilation tools such as **gn**, **ninja**, and LLVM. When installing these tools, ensure that their environment variable paths are unique.
-
-## Obtaining Source Code
-
-You need to acquire [source code](../get-code/source-code-acquisition.md), download it on a Linux server, and decompress it.
-
-## Installing and Configuring Python
-
-1. Start a Linux server.
-2. Check the Python version \(Python 3.7 or later is required\).
-
- ```
- python3 --version
- ```
-
- If Python version is earlier than 3.7, reinstall Python. Do as follows to install Python, for example, Python 3.8.
-
- 1. Check the Ubuntu version.
-
- ```
- cat /etc/issue
- ```
-
- 1. Install Python based on the Ubuntu version.
- - If the Ubuntu version is 18 or later, run the following command:
-
- ```
- sudo apt-get install python3.8
- ```
-
- - If the Ubuntu version is 16, perform the following steps:
-
- a. Install dependency packages.
-
- ```
- sudo apt update && sudo apt install software-properties-common
- ```
-
- b. Add the source of deadsnakes PPA and press **Enter**.
-
- ```
- sudo add-apt-repository ppa:deadsnakes/ppa
- ```
-
- c. Install Python 3.8.
-
- ```
- sudo apt upgrade && sudo apt install python3.8
- ```
-
-
-
-3. Set the soft link of **python** and **python3** to **python3.8**.
-
- ```
- sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.8 1
- sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.8 1
- ```
-
-4. Install and upgrade the Python package management tool \(pip3\) using either of the following methods:
- - **Command line:**
-
- ```
- sudo apt-get install python3-setuptools python3-pip -y
- sudo pip3 install --upgrade pip
- ```
-
- - **Installation package:**
-
- ```
- curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
- python get-pip.py
- ```
-
-
-
-## Installing gn
-
-1. Start a Linux server.
-2. Download [gn](https://repo.huaweicloud.com/harmonyos/compiler/gn/1717/linux/gn-linux-x86-1717.tar.gz).
-3. Create the **gn** folder in the root directory.
-
- ```
- mkdir ~/gn
- ```
-
-4. Decompress the gn installation package to **\~/gn**.
-
- ```
- tar -xvf gn-linux-x86-1717.tar.gz -C ~/gn
- ```
-
-5. Set an environment variable.
-
- ```
- vim ~/.bashrc
- ```
-
- Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
-
- ```
- export PATH=~/gn:$PATH
- ```
-
-6. Validate the environment variable.
-
- ```
- source ~/.bashrc
- ```
-
-
-## Installing ninja
-
-1. Start a Linux server.
-2. Download [ninja](https://repo.huaweicloud.com/harmonyos/compiler/ninja/1.9.0/linux/ninja.1.9.0.tar).
-3. Decompress the ninja installation package to **\~/ninja**.
-
- ```
- tar -xvf ninja.1.9.0.tar -C ~/
- ```
-
-4. Set an environment variable.
-
- ```
- vim ~/.bashrc
- ```
-
- Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
-
- ```
- export PATH=~/ninja:$PATH
- ```
-
-5. Validate the environment variable.
-
- ```
- source ~/.bashrc
- ```
-
-
-## Installing LLVM
-
-1. Start a Linux server.
-2. [Download LLVM](https://repo.huaweicloud.com/harmonyos/compiler/clang/10.0.1-62608/linux/llvm.tar.gz).
-
- > **NOTE:**
- >For the OpenHarmony\_v1.x branches and tags, click [here](https://repo.huaweicloud.com/harmonyos/compiler/clang/9.0.0-36191/linux/llvm-linux-9.0.0-36191.tar) to download LLVM.
-
-3. Decompress the LLVM installation package to **\~/llvm**.
-
- ```
- tar -zxvf llvm.tar.gz -C ~/
- ```
-
- > **NOTE:**
- >For the OpenHarmony\_v1.x branches and tags, run the following command to decompress the LLVM installation package:
- >```
- >tar -xvf llvm-linux-9.0.0-36191.tar -C ~/
- >```
-
-4. Set an environment variable.
-
- ```
- vim ~/.bashrc
- ```
-
- Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
-
- ```
- export PATH=~/llvm/bin:$PATH
- ```
-
-5. Validate the environment variable.
-
- ```
- source ~/.bashrc
- ```
-
-
-## Installing hb
-
-### Prerequisites
-
-Python 3.7.4 or later has been installed. For details, see [Installing and Configuring Python](#section1238412211211).
-
-### Installation Procedure
-
-1. Install **hb**.
-
- ```
- python3 -m pip install --user ohos-build
- ```
-
-2. Set an environment variable.
-
- ```
- vim ~/.bashrc
- ```
-
- Copy the following command to the last line of the **.bashrc** file, save the file, and exit.
-
- ```
- export PATH=~/.local/bin:$PATH
- ```
-
- Update the environment variable.
-
- ```
- source ~/.bashrc
- ```
-
-3. Run the **hb -h** command. If the following information is displayed, the installation is successful:
-
- ```
- usage: hb
-
- OHOS build system
-
- positional arguments:
- {build,set,env,clean}
- build Build source code
- set OHOS build settings
- env Show OHOS build env
- clean Clean output
-
- optional arguments:
- -h, --help Show this help message and exit
- ```
-
-
-### Uninstalling hb
-
-```
-python3 -m pip uninstall ohos-build
-```
-
-> **NOTICE:**
->If you encounter any problem during the installation, resort to the [FAQ](faq.md).
-
-## Installing Other Tools
-
-### Installation Procedure
-
-1. Use **apt-get** to install dependent tools.
-
- ```
- sudo apt-get install build-essential gcc g++ make zlib* libffi-dev e2fsprogs pkg-config flex bison perl bc openssl libssl-dev libelf-dev libc6-dev-amd64 binutils binutils-dev libdwarf-dev u-boot-tools mtd-utils
- ```
-
-
diff --git a/en/device-dev/quick-start/windows-development-environment.md b/en/device-dev/quick-start/windows-development-environment.md
deleted file mode 100644
index d0824ce00ea9573806c2a4c75f1df00a2de9aa0e..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/windows-development-environment.md
+++ /dev/null
@@ -1,183 +0,0 @@
-# Windows Development Environment
-
-- [Obtaining the Software](#en-us_topic_0000001058091994_section1483143015558)
-- [Installing Visual Studio Code](#en-us_topic_0000001058091994_section71401018163318)
-- [Installing Python](#en-us_topic_0000001058091994_section16266553175320)
-- [Installing Node.js](#en-us_topic_0000001058091994_section5353233124511)
-- [Installing hpm](#en-us_topic_0000001058091994_section173054793610)
-- [Installing the DevEco Device Tool Plug-in](#en-us_topic_0000001058091994_section4336315185716)
-
-Operating system: 64-bit version of Windows 10.
-
-DevEco Device Tool is a plug-in for Visual Studio Code. The installation procedure includes five parts:
-
-1. Installing Visual Studio Code
-2. Installing Python
-3. Installing Node.js
-4. Installing hpm
-5. Installing the DevEco Device Tool Plug-in
-
-## Obtaining the Software
-
-
-
-
-## Installing Visual Studio Code
-
-> **NOTE:**
->If you have installed Visual Studio Code, open the CLT and run **code --version** to check whether the version is 1.53 or later. If the version number is returned, it indicates that the environment variables are set correctly.
-
-1. Double-click the Visual Studio Code package to install it. During the installation, select **Add to PATH \(requires shell restart\)**.
-
- 
-
-2. After the installation is complete, restart the computer for the environment variables of Visual Studio Code to take effect.
-3. Open the CLT and run **code --version**. If the version number can be displayed, it indicates that the installation is successful.
-
-## Installing Python
-
-1. Double-click the Python software package, select **Add Python xx to PATH**, and click **Install Now**.
-
- 
-
-2. After the installation is complete, click **Close**.
-
- 
-
-3. Open the CLT, and run **python --version** to check the installation result.
-
- 
-
-4. In the CLT, run the following commands to set the pip source for downloading the dependencies required for later installation:
-
- ```
- pip config set global.trusted-host repo.huaweicloud.com
- pip config set global.index-url https://repo.huaweicloud.com/repository/pypi/simple
- pip config set global.timeout 120
- ```
-
-
-## Installing Node.js
-
-> **NOTE:**
->If you have installed Node.js, open the CLT and run **node -v** to check whether the version is 12.0.0 or later.
-
-1. Run the downloaded software package to install. Use the default settings when following the installation wizard, and click **Next** until **Finish** is displayed. During the installation, Node.js will automatically set the system Path environment variable to the installation directory of **node.exe**.
-2. Open the CLT and run **node -v**. If the version number of Node.js is displayed, it indicates that Node.js has been successfully installed.
-
- 
-
-
-## Installing hpm
-
-Before installing hpm, ensure that Node.js has been installed
-
-and that your network can access the Internet. If your network requires a proxy to access the Internet, [set up the npm proxy](https://device.harmonyos.com/cn/docs/ide/user-guides/npm_proxy-0000001054491032) first.
-
-> **NOTE:**
->If hpm has been installed, run **npm update -g @ohos/hpm-cli** to update it to the latest version.
-
-1. You are advised to set the npm source to an image in China, for example, a HUAWEI CLOUD image source.
-
- ```
- npm config set registry https://repo.huaweicloud.com/repository/npm/
- ```
-
-2. Open the CLT and run the following command to install the latest version of hpm:
-
- ```
- npm install -g @ohos/hpm-cli
- ```
-
- 
-
-3. After the installation is complete, run the following command to obtain the installation result:
-
- ```
- hpm -V
- ```
-
- 
-
-
-## Installing the DevEco Device Tool Plug-in
-
-To install the DevEco Device Tool plug-in, ensure that the **user name of the host cannot contain Chinese characters**; otherwise, the plug-in may fail to run.
-
-DevEco Device Tool will automatically download and install the C/C++ and CodeLLDB plug-ins from the Visual Studio Code Marketplace during the installation process. Therefore, make sure Visual Studio Code can access the Internet. If your network requires a proxy to access the Internet, [set up the Visual Studio Code proxy](https://device.harmonyos.com/cn/docs/ide/user-guides/vscode_proxy-0000001074231144) first.
-
-> **NOTE:**
->Before installing DevEco Device Tool, ensure that Visual Studio Code is closed.
-
-1. Decompress the DevEco Device Tool plug-in package and double-click the installer to install.
-2. During the installation, the dependency files \(such as C/C++ and CodeLLDB plug-ins\) and execution programs required by DevEco Device Tool are automatically installed.
-
- 
-
-3. After the installation is complete, the CLT is automatically closed.
-4. Open Visual Studio Code, click the  button on the left, and check whether C/C++, CodeLLDB, and DevEco Device Tool are listed in **INSTALLED**.
-
- > **NOTE:**
- >If the C/C++ and CodeLLDB plug-ins fail to be installed, DevEco Device Tool cannot run properly. To solve the issue, see [Installing the C/C++ and CodeLLDB Plug-ins Offline](https://device.harmonyos.com/en/docs/ide/user-guides/offline_plugin_install-0000001074376846).
-
- 
-
-
diff --git a/en/device-dev/quick-start/wlan-connection.md b/en/device-dev/quick-start/wlan-connection.md
deleted file mode 100644
index 6869012b733851e1555efbf1cce23ea5c51f7317..0000000000000000000000000000000000000000
--- a/en/device-dev/quick-start/wlan-connection.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# WLAN Connection
-
-- [Building](#section191121332125319)
-- [Burning Images](#section19458165166)
-- [Connecting WLAN Module to the Internet.](#section194671619167)
-
-This example shows how to connect the WLAN module to the gateway using attention \(AT\) commands.
-
-## Building
-
-This section describes how to perform the WLAN module building on a Linux server.
-
-If the Linux environment is installed using Docker, perform the building by referring to [Using Docker to Prepare the Build Environment](../get-code/docker-environment.md). If the Linux environment is installed using a software package, perform the following steps:
-
-1. Open the HUAWEI DevEco Device Tool and choose **View** \> **Terminal**.
-
- **Figure 1** Starting the IDE terminal tool
-
-
- 
-
- On the **TERMINAL** panel, run the ssh command, for example, **ssh** **_user_@_ipaddr_**, to connect to the Linux server.
-
- **Figure 2** TERMINAL panel
-
-
- 
-
-2. Go to the root directory of the code, run the **hb set** and **.** commands on the **TERMINAL** panel, and select the **wifiiot\_hispark\_pegasus** version.
-
- **Figure 3** Selecting the target build version
-
-
- 
-
-3. Run the **hb build** command to start building.
-
- **Figure 4** Running commands on the TERMINAL panel
-
-
- 
-
-4. Check whether the building is successful. If yes, **wifiiot\_hispark\_pegasus build success** will be displayed, as shown in the following figure.
-
- **Figure 5** Successful building
-
-
- 
-
-5. Check whether the following files are generated in the **./out/wifiiot/** directory.
-
- ```
- ls -l out/hispark_pegasus/wifiiot_hispark_pegasus/
- ```
-
- **Figure 6** Directory for storing the generated files
-
-
- 
-
-
-## Burning Images
-
-You can use the DevEco tool to perform the image burning of the Hi3861 WLAN module. For details about how to use the tool, see [HUAWEI DevEco Device Tool User Guide](https://device.harmonyos.com/en/docs/ide/user-guides/service_introduction-0000001050166905).
-
-1. Connect the PC and the target development board through the USB port. For details, please refer to [Introduction to the Hi3861 Development Board](https://device.harmonyos.com/en/docs/start/introduce/oem_minitinier_des_3861-0000001105041324).
-2. Open Device Manager, then check and record the serial port number corresponding to the development board.
-
- > **NOTE:**
- >If the serial port number is not displayed correctly, follow the steps described in [Installing the Serial Port Driver on the Hi3861 Series Development Boards](https://device.harmonyos.com/en/docs/ide/user-guides/hi3861-drivers-0000001058153433).
-
- 
-
-3. Open DevEco Device Tool and go to **Projects** \> **Settings**.
-
- 
-
-4. On the **Partition Configuration** tab page, modify the settings. In general cases, you can leave the fields at their default settings.
-5. On the **hi3861** tab page, set the programming options.
-
- - **upload\_port**: Select the serial port number obtained in [2](#en-us_topic_0000001056563976_li848662117291).
- - **upload\_protocol**: Select the burning protocol **burn-serial**.
- - **upload\_partitions**: Select the file to be burned. **hi3861\_app** is selected by default.
-
- 
-
-6. When you finish modifying, click **Save** in the upper right corner.
-7. Open the project file. In the DevEco Device Tool window, go to **PROJECT TASKS** \> **hi3861** \> **Upload** to start programming.
-
- 
-
-8. When the following information is displayed, press the RST button on the development board to restart it.
-
- 
-
-9. Start burning. When the following message is displayed, the burning is successful.
-
- 
-
-
-## Connecting WLAN Module to the Internet.
-
-After completing version building and burning, do as follows to connect the WLAN module to the Internet using AT commands.
-
-1. Click the icon of **DevEco: Serial Monitor** at the bottom of DevEco Studio to keep the connection between the Windows workstation and the WLAN module.
-
- **Figure 7** Opening the DevEco serial port
-
-
- 
-
-2. Reset the WLAN module. The message **ready to OS start** is displayed on the **TERMINAL** panel, indicating that the WLAN module is started successfully.
-
- **Figure 8** Successful resetting of the WLAN module
-
-
- 
-
-3. Run the following AT commands in sequence via the DevEco serial port terminal to start the STA mode, connect to the specified AP, and enable Dynamic Host Configuration Protocol \(DHCP\).
-
- ```
- AT+STARTSTA # Start the STA mode.
- AT+SCAN # Scan for available APs.
- AT+SCANRESULT # Display the scanning result.
- AT+CONN="SSID",,2,"PASSWORD" # Connect to the specified AP. (SSID and PASSWORD represent the name and password of the hotspot to be connected, respectively.)
- AT+STASTAT # View the connection result.
- AT+DHCP=wlan0,1 # Request the IP address of wlan0 from the AP using DHCP.
- ```
-
-4. Check whether the WLAN module is properly connected to the gateway, as shown in the following figure.
-
- ```
- AT+IFCFG # View the IP address assigned to an interface of the module.
- AT+PING=X.X.X.X # Check the connectivity between the module and the gateway. Replace X.X.X.X with the actual gateway address.
- ```
-
- **Figure 9** Successful networking of the WLAN module
-
-
- 
-
-
diff --git a/en/device-dev/security/Readme-EN.md b/en/device-dev/security/Readme-EN.md
index 03e75d7a357e34f3974eb34839b23992d2b998d6..09b0d20c4425a17dd609cffa530aaf54d0691c01 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](privacy-protection.md)
-- [Security Guidelines](security-guidelines.md)
+- [Privacy Protection](oem_security_privacy.md)
+- [Security Guidelines](safety-safeguide-security.md)
diff --git "a/en/device-dev/security/figures/1-\346\225\217\346\204\237\346\235\203\351\231\220\345\274\271\347\252\227.png" "b/en/device-dev/security/figure/1-\346\225\217\346\204\237\346\235\203\351\231\220\345\274\271\347\252\227.png"
similarity index 100%
rename from "en/device-dev/security/figures/1-\346\225\217\346\204\237\346\235\203\351\231\220\345\274\271\347\252\227.png"
rename to "en/device-dev/security/figure/1-\346\225\217\346\204\237\346\235\203\351\231\220\345\274\271\347\252\227.png"
diff --git "a/en/device-dev/security/figures/2-\345\272\224\347\224\250\345\220\257\345\212\250\351\242\204\346\216\210\346\235\203.png" "b/en/device-dev/security/figure/2-\345\272\224\347\224\250\345\220\257\345\212\250\351\242\204\346\216\210\346\235\203.png"
similarity index 100%
rename from "en/device-dev/security/figures/2-\345\272\224\347\224\250\345\220\257\345\212\250\351\242\204\346\216\210\346\235\203.png"
rename to "en/device-dev/security/figure/2-\345\272\224\347\224\250\345\220\257\345\212\250\351\242\204\346\216\210\346\235\203.png"
diff --git "a/en/device-dev/security/figures/3-\345\272\224\347\224\250\351\232\220\347\247\201\345\243\260\346\230\216.png" "b/en/device-dev/security/figure/3-\345\272\224\347\224\250\351\232\220\347\247\201\345\243\260\346\230\216.png"
similarity index 100%
rename from "en/device-dev/security/figures/3-\345\272\224\347\224\250\351\232\220\347\247\201\345\243\260\346\230\216.png"
rename to "en/device-dev/security/figure/3-\345\272\224\347\224\250\351\232\220\347\247\201\345\243\260\346\230\216.png"
diff --git "a/en/device-dev/security/figures/4-\351\232\220\347\247\201\345\243\260\346\230\216\345\217\230\346\233\264\351\200\232\347\237\245.png" "b/en/device-dev/security/figure/4-\351\232\220\347\247\201\345\243\260\346\230\216\345\217\230\346\233\264\351\200\232\347\237\245.png"
similarity index 100%
rename from "en/device-dev/security/figures/4-\351\232\220\347\247\201\345\243\260\346\230\216\345\217\230\346\233\264\351\200\232\347\237\245.png"
rename to "en/device-dev/security/figure/4-\351\232\220\347\247\201\345\243\260\346\230\216\345\217\230\346\233\264\351\200\232\347\237\245.png"
diff --git "a/en/device-dev/security/figures/5-\345\272\224\347\224\250\351\232\220\347\247\201\345\243\260\346\230\216\345\205\245\345\217\243.png" "b/en/device-dev/security/figure/5-\345\272\224\347\224\250\351\232\220\347\247\201\345\243\260\346\230\216\345\205\245\345\217\243.png"
similarity index 100%
rename from "en/device-dev/security/figures/5-\345\272\224\347\224\250\351\232\220\347\247\201\345\243\260\346\230\216\345\205\245\345\217\243.png"
rename to "en/device-dev/security/figure/5-\345\272\224\347\224\250\351\232\220\347\247\201\345\243\260\346\230\216\345\205\245\345\217\243.png"
diff --git "a/en/device-dev/security/figures/6-1-\351\232\220\347\247\201\345\243\260\346\230\216\346\222\244\351\224\200.png" "b/en/device-dev/security/figure/6-1-\351\232\220\347\247\201\345\243\260\346\230\216\346\222\244\351\224\200.png"
similarity index 100%
rename from "en/device-dev/security/figures/6-1-\351\232\220\347\247\201\345\243\260\346\230\216\346\222\244\351\224\200.png"
rename to "en/device-dev/security/figure/6-1-\351\232\220\347\247\201\345\243\260\346\230\216\346\222\244\351\224\200.png"
diff --git "a/en/device-dev/security/figures/6-2-\351\232\220\347\247\201\345\243\260\346\230\216\346\222\244\351\224\200.png" "b/en/device-dev/security/figure/6-2-\351\232\220\347\247\201\345\243\260\346\230\216\346\222\244\351\224\200.png"
similarity index 100%
rename from "en/device-dev/security/figures/6-2-\351\232\220\347\247\201\345\243\260\346\230\216\346\222\244\351\224\200.png"
rename to "en/device-dev/security/figure/6-2-\351\232\220\347\247\201\345\243\260\346\230\216\346\222\244\351\224\200.png"
diff --git a/en/device-dev/security/figures/how-an-iot-controller-and-an-iot-device-establish-a-trust-relationship.png b/en/device-dev/security/figure/how-an-iot-controller-and-an-iot-device-establish-a-trust-relationship.png
similarity index 100%
rename from en/device-dev/security/figures/how-an-iot-controller-and-an-iot-device-establish-a-trust-relationship.png
rename to en/device-dev/security/figure/how-an-iot-controller-and-an-iot-device-establish-a-trust-relationship.png
diff --git a/en/device-dev/security/figures/how-dac-works.png b/en/device-dev/security/figure/how-dac-works.png
similarity index 100%
rename from en/device-dev/security/figures/how-dac-works.png
rename to en/device-dev/security/figure/how-dac-works.png
diff --git a/en/device-dev/security/figures/huks-functions.png b/en/device-dev/security/figure/huks-functions.png
similarity index 100%
rename from en/device-dev/security/figures/huks-functions.png
rename to en/device-dev/security/figure/huks-functions.png
diff --git a/en/device-dev/security/figures/security-assurance-framework.png b/en/device-dev/security/figure/security-assurance-framework.png
similarity index 100%
rename from en/device-dev/security/figures/security-assurance-framework.png
rename to en/device-dev/security/figure/security-assurance-framework.png
diff --git a/en/device-dev/security/oem_security_privacy.md b/en/device-dev/security/oem_security_privacy.md
new file mode 100644
index 0000000000000000000000000000000000000000..0a3e53c1d8258693bb07dfe0637e3ea40f6e08ae
--- /dev/null
+++ b/en/device-dev/security/oem_security_privacy.md
@@ -0,0 +1,264 @@
+# Privacy Protection
+
+- [Overview](#section13200134331414)
+- [Data Classification](#section2371104991511)
+- [General Privacy Design Rules](#section10354102411162)
+- [Privacy Protection Requirements for Special Categories](#section118861450201618)
+
+## Overview
+
+Personal data plays an increasingly important role in social economy and daily life along with the development of the Internet and informatization. Meanwhile, personal data leakage risks are increasing. As consumer product developers, you shall take more effective measures to protect users' personal data and improve their trust in your products. To protect consumers' privacy and improve their experience on privacy, you should set high-level privacy protection policies for your product.
+
+**Basic Concepts**
+
+- **Personal data**
+
+ Any information relating to an identified or identifiable natural person \("Data Subject"\) who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, commercial, cultural, or social identity of that natural person. Personal data includes a natural person's email address, phone number, biometric information \(such as a fingerprint\), location data, IP address, healthcare information, religious belief, social security number, marital status, and so on.
+
+- **Sensitive personal data**
+
+ Sensitive personal data, a critical subset of personal data, refers to the most private information of a data subject or information that may cause severe adverse impacts on a data subject once disclosed. Sensitive personal data defined in laws and regulations of EU and its members includes personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric information, and data concerning health or sex life and sexual orientation.
+
+ With reference to industry best practices, we also define the following data related to a natural person's identity as sensitive: bank card number, identification number, passport number, and passwords. More strict protection measures are usually required for processing sensitive personal data.
+
+- **Public available personal data**
+
+ Personal data that is proactively disclosed by a data subject or that can be accessed on public web pages or applications, including posts and comments made on forums.
+
+- **User profile**
+
+ Any form of automated processing of personal data to assess a natural person in specific aspects, and in particular to analyze and predict the natural person's work performance, financial situation, health, personal preference, interest, creditability, behavior, and location or trace.
+
+- **Data controller**
+
+ A natural or legal person, public authority, agency, or any other body that, alone or jointly with others, determines the purposes and means of personal data processing.
+
+- **Data processor**
+
+ A natural or legal person, public authority, agency, or any other body that processes personal data on behalf of a data controller. A data processor must provide adequate protection following the data controller's requirements.
+
+- **Explicit consent**
+
+ Explicit consent applies to the following scenarios where the General Data Protection Regulation \(GDPR\) allows the legitimate processing of personal data based on data subjects' explicit consent:
+
+ - Processing of sensitive personal data
+ - Automated decision-making, including user profiles
+ - Transfer of personal data to countries without an adequate level of protection, which uses consent as the legal basis
+
+ Explicit consent can be implemented as follows:
+
+ - In the collection of specific data, display a privacy statement to notify data subjects of matters related to the processing of personal data, provide a check box which is deselected by default, and prompt data subjects to proactively select the option indicating that "I agree to process my personal data in the above manner" or click the "I agree" button.
+ - Expressly present consent in writing and request data subjects to sign it.
+ - Ask data subjects to upload an electronic form with their signature in the system.
+ - Adopt the double verification method by requesting data subjects to consent via an email and then re-click the email link for verification or enter the SMS verification code.
+ - Users provide information proactively, such as scenarios where a user enters their identification number and bank card number to bind the bank card.
+
+
+## Data Classification
+
+Data is classified into five levels: very high, high, moderate, low, and public based on the data protection objectives and consequences \(the impact of legal risks caused by data leakage or damage on individuals, organizations, or the public\).
+
+**Table 1** Standards for data classification
+
+
+
Level
+
+
Privacy Risk
+
+
Privacy Attribute
+
+
Typical Example
+
+
+
+
Very high
+
+
Once data is identified or associated with an individual or group of individuals, its disclosure or improper use may have a catastrophic negative impact on that individual or group of individuals.
+
+
Sensitive personal data
+
+
DNA, race, religious belief, and sexual orientation; biometric information; original communication content; bank account password and magnetic track data
+
+
+
High
+
+
Once data is identified or associated with an individual or group of individuals, its disclosure or improper use may have a severe negative impact on that individual or group of individuals.
+
+
Sensitive personal data
+
+
Social identity (such as ID card and passport number); web browsing history; tracks; content (such as images, audio, and video) uploaded to the cloud
+
+
+
Moderate
+
+
Once data is identified or associated with an individual or group of individuals, its disclosure or improper use may have a significant negative impact on that individual or group of individuals.
+
+
General personal data
+
+
Device ID (such as IMEI, SN, and OAID) and user ID; basic personal information (name and address); mobile number and email address
+
+
+
Low
+
+
Once data is identified or associated with an individual or group of individuals, its disclosure or improper use may have a limited negative impact on that individual or group of individuals.
+
+
General personal data
+
+
OS settings (including the OS version and country/region); device hardware information (device model, screen size, and screen resolution); network information (network connection status and access network information); device status (login time/duration)
+
+
+
Public
+
+
Public data has no adverse impact on individuals or organizations.
+
+
Non-personal data
+
+
Publicly released product introduction, public meeting information, and external open-source code
+
+
+
+
+
+Note: For details about the definitions of privacy protection and data classification, see GDPR.
+
+## General Privacy Design Rules
+
+To help you better complete privacy design for OpenHarmony products, we sort out general privacy design requirements.
+
+**Openness and Transparency in Data Collection and Use**
+
+When collecting personal data, clearly and explicitly notify users of the data to collect and how their personal data will be used.
+
+- Develop specific privacy processing policies for personal data at different levels.
+ - Explicit consent shall be obtained from the data subject before your product attempts to collect sensitive personal data.
+ - Generally, the collection of personal data requires the consent of the data subject or other legal authorizations.
+ - If non-personal data is to be collected in association with personal data at the moderate, high, or very high level, the data subject's consent or other legal authorization is required, and the consent or authorization shall be presented in the privacy statement.
+
+- Develop and follow appropriate privacy policies. Comply with all applicable laws, policies, and regulations when collecting, using, retaining, and sharing users' personal data with any third parties. For example, prior to data collection, fully inform users of the types, purposes, processing methods, and retention periods of personal data to meet the requirements of data subjects' rights.
+
+ Guided by the preceding principles, we have designed some examples for your reference. The figures below are examples of a privacy notice and a privacy statement, respectively.
+
+ **Figure 1** Examples of a privacy notice and a privacy statement
+
+
+ 
+
+- Personal data shall be collected for specified, explicit, and legitimate purposes and not further processed in a manner that is incompatible with those purposes. If the purposes are changed or a user withdraws their consent, you shall obtain user consent again before using the data. The figures below are examples of a privacy statement update and content withdrawal, respectively.
+
+ **Figure 2** Example dialog showing a privacy statement update
+
+
+ 
+
+ **Figure 3** Example dialog showing consent withdrawal
+
+
+ 
+
+- You shall provide an entry for users to view the privacy statement. For example, you can provide an entry on the **About** page of your application to view the privacy statement, as shown in the following figure.
+
+ **Figure 4** Example of About page providing an entry to the privacy statement
+
+
+ 
+
+
+**Minimization in Data Collection and Use**
+
+Collect personal data only when they are adequate, relevant, and limited to what is necessary in relation to the purposes for which they are processed. Apply anonymization or pseudonymization to personal data if possible to reduce the risks to the data subjects concerned. Data shall only be collected and processed for a specified purpose, and no further unnecessary operations shall be conducted on them.
+
+- When applying for sensitive permissions, adhere to permission minimization and apply for only the permissions required for obtaining necessary information or resources. For example, if your application can implement its functions without access to the camera, then it shall not request the user for the camera permission.
+- Comply with data collection minimization, and do not collect data irrelevant to services provided by the product. For example, a product that provides location services shall not collect users' web browsing history.
+- The functions that use personal data shall be able to benefit users. The collected data shall not be used for functions irrelevant to users' normal use. No data shall be collected for any functions irrelevant to user operations. For example, sensitive personal data, such as biometric features and health data, shall not be used for non-core service functions like service improvement, advertising, and marketing.
+- Printing sensitive personal data in logs is prohibited. If common personal data needs to be printed in logs, make sure the data is anonymized or pseudonymized.
+
+ Preferentially use identifiers that are resettable. For example, use the NetworkID and DVID as the device identifier in the distributed scenario; use the [OAID](https://developer.huawei.com/consumer/en/doc/development/HMSCore-Guides/oaid-0000001050783198) in the advertising scenario; use the [ODID](https://developer.huawei.com/consumer/en/doc/development/HMSCore-Guides/odid-0000001051063255) and [AAID](https://developer.huawei.com/consumer/en/doc/development/HMSCore-Guides/aaid-0000001051142988) in the application-based analysis scenario; and use the UUID in other scenarios where a unique identifier is required. Use permanent identifiers such as the sequence number and MAC address only when resettable identifiers cannot meet your service requirements.
+
+
+**Data Processing Selection and Control**
+
+You shall obtain consent from users and comply with applicable laws and regulations for processing personal data and give users full control over their data.
+
+- When applying for a certain sensitive permission, your product shall display a pop-up dialog to notify the user of the requested permission and the purpose of using the permission. The user shall be able to choose whether to grant the permission and how they would like to grant the permission. This ensures that permission granting and use are transparent, perceivable, and controllable. The following figure is an example dialog for requesting a sensitive permission.
+
+ **Figure 5** Example dialog for requesting a sensitive permission
+
+
+ 
+
+- Users shall have the right to modify or withdraw the permissions granted to your product. When a user does not agree to a permission or data collection, the user shall be allowed to use the functions irrelevant to the permission or data collection. For example, the user can refuse to grant the camera permission to social or communication apps on Smart TVs, when using product functions irrelevant to the camera, such as voice calls.
+- In scenarios where personal data is recorded, users shall be provided with the functions of adding, deleting, modifying, and viewing personal data.
+- Your products shall provide a mechanism or method for securely deleting personal data when hardware is recycled or returned to the factory.
+- The download or upgrade of user system software or application software may involve the modification of users' private space. Users shall have the right to know and control such behavior. They shall be informed of such behavior and be given the option to agree or disagree with such behavior.
+
+**Data Security**
+
+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.
+- 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).
+- Authentication data \(such as passwords and fingerprints\) shall be encrypted before being stored.
+
+**Localization**
+
+User data shall be preferentially processed on the local device. Data that cannot be processed on the local device shall be preferentially processed on Device+ \(super device in the distributed scenario\). If any data cannot be processed on Device+, the data shall be anonymized before being transferred out of Device+ for processing.
+
+**Minors' Data Protection**
+
+If your product is designed for minors or you can identify, based on the collected user age data, that the end user is a minor, you shall particularly analyze issues related to minors' personal data protection based on relevant national laws in the target market. Your product shall obtain explicit consent from the holders of parental responsibility over minors.
+
+## **Privacy Protection Requirements for Special Categories**
+
+In addition to these general privacy requirements, consumer hardware products have the following requirements for special categories. You shall comply with these requirements during product design.
+
+**Table 2** Privacy protection requirements for special categories
+
+
+
Product Category
+
+
Privacy Protection Requirements
+
+
+
+
Smart home
+
+
Biometric information (such as fingerprints, voiceprints, facial recognition, and irises) and user passwords involved in security products are sensitive personal data. They shall be processed using technical measures (for example, extracting the digest of biometric information) before being encrypted and stored in the products.
+
+
+
Smart home
+
+
For security products that involve audio, video, and images, their manufacturers, functioning as the data controller, shall provide an independent privacy notification and a brand log on their application UI. Transfer and storage of audio and video data shall be encrypted. Access to audio and video data of security products is permitted only after being authorized by the data subject.
+
+
+
Smart home/Entertainment
+
+
Cameras on products should be able to be physically disabled. For example, cameras can be hidden, shuttered, or re-oriented so that consumers can perceive that the cameras are disabled.
+
+
+
Smart home/Entertainment
+
+
Products with a microphone should provide an explicit display of the recording status. For example, the products can provide a status indicator that blinks when recording is started and turns off when recording is stopped.
+
+
+
Mobile office
+
+
In scenarios such as cross-device display and transfer of user data, your products shall obtain explicit consent from users and give them full control over their personal data.
+
+
+
In-vehicle infotainment (IVI)
+
+
1. Privacy notice and permission settings
+
Do not let users read privacy policies and permission settings in the driving state.
+
IVI applications shall consider the safety of vehicle use. The applications shall not require complex permission settings or reading of privacy policies when users are driving. For example, HiCar is usable only after users have set basic permissions and read privacy policies on their mobile phone.
+
The privacy statement shall be notified after the user identity is confirmed.
+
Vehicle data involves vehicle owners, drivers, and passengers. The data subject shall be notified of the privacy statement. The recommended practice is to make a privacy statement after confirming the user identity. For an application that requires login, the privacy statement should be displayed after, instead of before, a user is logged in.
+
2. Personal data protection for sharing applications
+
Shared applications shall exit after the IVI is restarted, and the personal data of the current user shall be cleared or encrypted. The applications shall also provide the function to permanently delete historical data.
+
3. Notifications
+
As the IVI is used in an open environment, applications shall not directly display the message content on the IVI. Instead, the applications shall only notify users that there is an incoming message.
+
+
+
+
+
diff --git a/en/device-dev/security/privacy-protection.md b/en/device-dev/security/privacy-protection.md
deleted file mode 100644
index c386470726ad799da888fd14bc371b95a9eaa82f..0000000000000000000000000000000000000000
--- a/en/device-dev/security/privacy-protection.md
+++ /dev/null
@@ -1,264 +0,0 @@
-# Privacy Protection
-
-- [Overview](#section13200134331414)
-- [Data Classification](#section2371104991511)
-- [General Privacy Design Rules](#section10354102411162)
-- [Privacy Protection Requirements for Special Categories](#section118861450201618)
-
-## Overview
-
-Personal data plays an increasingly important role in social economy and daily life along with the development of the Internet and informatization. Meanwhile, personal data leakage risks are increasing. As consumer product developers, you shall take more effective measures to protect users' personal data and improve their trust in your products. To protect consumers' privacy and improve their experience on privacy, you should set high-level privacy protection policies for your product.
-
-**Basic Concepts**
-
-- **Personal data**
-
- Any information relating to an identified or identifiable natural person \("Data Subject"\) who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, commercial, cultural, or social identity of that natural person. Personal data includes a natural person's email address, phone number, biometric information \(such as a fingerprint\), location data, IP address, healthcare information, religious belief, social security number, marital status, and so on.
-
-- **Sensitive personal data**
-
- Sensitive personal data, a critical subset of personal data, refers to the most private information of a data subject or information that may cause severe adverse impacts on a data subject once disclosed. Sensitive personal data defined in laws and regulations of EU and its members includes personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric information, and data concerning health or sex life and sexual orientation.
-
- With reference to industry best practices, we also define the following data related to a natural person's identity as sensitive: bank card number, identification number, passport number, and passwords. More strict protection measures are usually required for processing sensitive personal data.
-
-- **Public available personal data**
-
- Personal data that is proactively disclosed by a data subject or that can be accessed on public web pages or applications, including posts and comments made on forums.
-
-- **User profile**
-
- Any form of automated processing of personal data to assess a natural person in specific aspects, and in particular to analyze and predict the natural person's work performance, financial situation, health, personal preference, interest, creditability, behavior, and location or trace.
-
-- **Data controller**
-
- A natural or legal person, public authority, agency, or any other body that, alone or jointly with others, determines the purposes and means of personal data processing.
-
-- **Data processor**
-
- A natural or legal person, public authority, agency, or any other body that processes personal data on behalf of a data controller. A data processor must provide adequate protection following the data controller's requirements.
-
-- **Explicit consent**
-
- Explicit consent applies to the following scenarios where the General Data Protection Regulation \(GDPR\) allows the legitimate processing of personal data based on data subjects' explicit consent:
-
- - Processing of sensitive personal data
- - Automated decision-making, including user profiles
- - Transfer of personal data to countries without an adequate level of protection, which uses consent as the legal basis
-
- Explicit consent can be implemented as follows:
-
- - In the collection of specific data, display a privacy statement to notify data subjects of matters related to the processing of personal data, provide a check box which is deselected by default, and prompt data subjects to proactively select the option indicating that "I agree to process my personal data in the above manner" or click the "I agree" button.
- - Expressly present consent in writing and request data subjects to sign it.
- - Ask data subjects to upload an electronic form with their signature in the system.
- - Adopt the double verification method by requesting data subjects to consent via an email and then re-click the email link for verification or enter the SMS verification code.
- - Users provide information proactively, such as scenarios where a user enters their identification number and bank card number to bind the bank card.
-
-
-## Data Classification
-
-Data is classified into five levels: very high, high, moderate, low, and public based on the data protection objectives and consequences \(the impact of legal risks caused by data leakage or damage on individuals, organizations, or the public\).
-
-**Table 1** Standards for data classification
-
-
-
Level
-
-
Privacy Risk
-
-
Privacy Attribute
-
-
Typical Example
-
-
-
-
Very high
-
-
Once data is identified or associated with an individual or group of individuals, its disclosure or improper use may have a catastrophic negative impact on that individual or group of individuals.
-
-
Sensitive personal data
-
-
DNA, race, religious belief, and sexual orientation; biometric information; original communication content; bank account password and magnetic track data
-
-
-
High
-
-
Once data is identified or associated with an individual or group of individuals, its disclosure or improper use may have a severe negative impact on that individual or group of individuals.
-
-
Sensitive personal data
-
-
Social identity (such as ID card and passport number); web browsing history; tracks; content (such as images, audio, and video) uploaded to the cloud
-
-
-
Moderate
-
-
Once data is identified or associated with an individual or group of individuals, its disclosure or improper use may have a significant negative impact on that individual or group of individuals.
-
-
General personal data
-
-
Device ID (such as IMEI, SN, and OAID) and user ID; basic personal information (name and address); mobile number and email address
-
-
-
Low
-
-
Once data is identified or associated with an individual or group of individuals, its disclosure or improper use may have a limited negative impact on that individual or group of individuals.
-
-
General personal data
-
-
OS settings (including the OS version and country/region); device hardware information (device model, screen size, and screen resolution); network information (network connection status and access network information); device status (login time/duration)
-
-
-
Public
-
-
Public data has no adverse impact on individuals or organizations.
-
-
Non-personal data
-
-
Publicly released product introduction, public meeting information, and external open-source code
-
-
-
-
-
-Note: For details about the definitions of privacy protection and data classification, see GDPR.
-
-## General Privacy Design Rules
-
-To help you better complete privacy design for OpenHarmony products, we sort out general privacy design requirements.
-
-**Openness and Transparency in Data Collection and Use**
-
-When collecting personal data, clearly and explicitly notify users of the data to collect and how their personal data will be used.
-
-- Develop specific privacy processing policies for personal data at different levels.
- - Explicit consent shall be obtained from the data subject before your product attempts to collect sensitive personal data.
- - Generally, the collection of personal data requires the consent of the data subject or other legal authorizations.
- - If non-personal data is to be collected in association with personal data at the moderate, high, or very high level, the data subject's consent or other legal authorization is required, and the consent or authorization shall be presented in the privacy statement.
-
-- Develop and follow appropriate privacy policies. Comply with all applicable laws, policies, and regulations when collecting, using, retaining, and sharing users' personal data with any third parties. For example, prior to data collection, fully inform users of the types, purposes, processing methods, and retention periods of personal data to meet the requirements of data subjects' rights.
-
- Guided by the preceding principles, we have designed some examples for your reference. The figures below are examples of a privacy notice and a privacy statement, respectively.
-
- **Figure 1** Examples of a privacy notice and a privacy statement
-
-
- 
-
-- Personal data shall be collected for specified, explicit, and legitimate purposes and not further processed in a manner that is incompatible with those purposes. If the purposes are changed or a user withdraws their consent, you shall obtain user consent again before using the data. The figures below are examples of a privacy statement update and content withdrawal, respectively.
-
- **Figure 2** Example dialog showing a privacy statement update
-
-
- 
-
- **Figure 3** Example dialog showing consent withdrawal
-
-
- 
-
-- You shall provide an entry for users to view the privacy statement. For example, you can provide an entry on the **About** page of your application to view the privacy statement, as shown in the following figure.
-
- **Figure 4** Example of About page providing an entry to the privacy statement
-
-
- 
-
-
-**Minimization in Data Collection and Use**
-
-Collect personal data only when they are adequate, relevant, and limited to what is necessary in relation to the purposes for which they are processed. Apply anonymization or pseudonymization to personal data if possible to reduce the risks to the data subjects concerned. Data shall only be collected and processed for a specified purpose, and no further unnecessary operations shall be conducted on them.
-
-- When applying for sensitive permissions, adhere to permission minimization and apply for only the permissions required for obtaining necessary information or resources. For example, if your application can implement its functions without access to the camera, then it shall not request the user for the camera permission.
-- Comply with data collection minimization, and do not collect data irrelevant to services provided by the product. For example, a product that provides location services shall not collect users' web browsing history.
-- The functions that use personal data shall be able to benefit users. The collected data shall not be used for functions irrelevant to users' normal use. No data shall be collected for any functions irrelevant to user operations. For example, sensitive personal data, such as biometric features and health data, shall not be used for non-core service functions like service improvement, advertising, and marketing.
-- Printing sensitive personal data in logs is prohibited. If common personal data needs to be printed in logs, make sure the data is anonymized or pseudonymized.
-
- Preferentially use identifiers that are resettable. For example, use the NetworkID and DVID as the device identifier in the distributed scenario; use the [OAID](https://developer.huawei.com/consumer/en/doc/development/HMSCore-Guides/oaid-0000001050783198) in the advertising scenario; use the [ODID](https://developer.huawei.com/consumer/en/doc/development/HMSCore-Guides/odid-0000001051063255) and [AAID](https://developer.huawei.com/consumer/en/doc/development/HMSCore-Guides/aaid-0000001051142988) in the application-based analysis scenario; and use the UUID in other scenarios where a unique identifier is required. Use permanent identifiers such as the sequence number and MAC address only when resettable identifiers cannot meet your service requirements.
-
-
-**Data Processing Selection and Control**
-
-You shall obtain consent from users and comply with applicable laws and regulations for processing personal data and give users full control over their data.
-
-- When applying for a certain sensitive permission, your product shall display a pop-up dialog to notify the user of the requested permission and the purpose of using the permission. The user shall be able to choose whether to grant the permission and how they would like to grant the permission. This ensures that permission granting and use are transparent, perceivable, and controllable. The following figure is an example dialog for requesting a sensitive permission.
-
- **Figure 5** Example dialog for requesting a sensitive permission
-
-
- 
-
-- Users shall have the right to modify or withdraw the permissions granted to your product. When a user does not agree to a permission or data collection, the user shall be allowed to use the functions irrelevant to the permission or data collection. For example, the user can refuse to grant the camera permission to social or communication apps on Smart TVs, when using product functions irrelevant to the camera, such as voice calls.
-- In scenarios where personal data is recorded, users shall be provided with the functions of adding, deleting, modifying, and viewing personal data.
-- Your products shall provide a mechanism or method for securely deleting personal data when hardware is recycled or returned to the factory.
-- The download or upgrade of user system software or application software may involve the modification of users' private space. Users shall have the right to know and control such behavior. They shall be informed of such behavior and be given the option to agree or disagree with such behavior.
-
-**Data Security**
-
-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-guidelines.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-guidelines.md#section26153183616).
-- Authentication data \(such as passwords and fingerprints\) shall be encrypted before being stored.
-
-**Localization**
-
-User data shall be preferentially processed on the local device. Data that cannot be processed on the local device shall be preferentially processed on Device+ \(super device in the distributed scenario\). If any data cannot be processed on Device+, the data shall be anonymized before being transferred out of Device+ for processing.
-
-**Minors' Data Protection**
-
-If your product is designed for minors or you can identify, based on the collected user age data, that the end user is a minor, you shall particularly analyze issues related to minors' personal data protection based on relevant national laws in the target market. Your product shall obtain explicit consent from the holders of parental responsibility over minors.
-
-## **Privacy Protection Requirements for Special Categories**
-
-In addition to these general privacy requirements, consumer hardware products have the following requirements for special categories. You shall comply with these requirements during product design.
-
-**Table 2** Privacy protection requirements for special categories
-
-
-
Product Category
-
-
Privacy Protection Requirements
-
-
-
-
Smart home
-
-
Biometric information (such as fingerprints, voiceprints, facial recognition, and irises) and user passwords involved in security products are sensitive personal data. They shall be processed using technical measures (for example, extracting the digest of biometric information) before being encrypted and stored in the products.
-
-
-
Smart home
-
-
For security products that involve audio, video, and images, their manufacturers, functioning as the data controller, shall provide an independent privacy notification and a brand log on their application UI. Transfer and storage of audio and video data shall be encrypted. Access to audio and video data of security products is permitted only after being authorized by the data subject.
-
-
-
Smart home/Entertainment
-
-
Cameras on products should be able to be physically disabled. For example, cameras can be hidden, shuttered, or re-oriented so that consumers can perceive that the cameras are disabled.
-
-
-
Smart home/Entertainment
-
-
Products with a microphone should provide an explicit display of the recording status. For example, the products can provide a status indicator that blinks when recording is started and turns off when recording is stopped.
-
-
-
Mobile office
-
-
In scenarios such as cross-device display and transfer of user data, your products shall obtain explicit consent from users and give them full control over their personal data.
-
-
-
In-vehicle infotainment (IVI)
-
-
1. Privacy notice and permission settings
-
Do not let users read privacy policies and permission settings in the driving state.
-
IVI applications shall consider the safety of vehicle use. The applications shall not require complex permission settings or reading of privacy policies when users are driving. For example, HiCar is usable only after users have set basic permissions and read privacy policies on their mobile phone.
-
The privacy statement shall be notified after the user identity is confirmed.
-
Vehicle data involves vehicle owners, drivers, and passengers. The data subject shall be notified of the privacy statement. The recommended practice is to make a privacy statement after confirming the user identity. For an application that requires login, the privacy statement should be displayed after, instead of before, a user is logged in.
-
2. Personal data protection for sharing applications
-
Shared applications shall exit after the IVI is restarted, and the personal data of the current user shall be cleared or encrypted. The applications shall also provide the function to permanently delete historical data.
-
3. Notifications
-
As the IVI is used in an open environment, applications shall not directly display the message content on the IVI. Instead, the applications shall only notify users that there is an incoming message.
-
-
-
-
-
diff --git a/en/device-dev/security/public_sys-resources/icon-caution.gif b/en/device-dev/security/public_sys-resources/icon-caution.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/security/public_sys-resources/icon-caution.gif and /dev/null differ
diff --git a/en/device-dev/security/public_sys-resources/icon-danger.gif b/en/device-dev/security/public_sys-resources/icon-danger.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/security/public_sys-resources/icon-danger.gif and /dev/null differ
diff --git a/en/device-dev/security/public_sys-resources/icon-note.gif b/en/device-dev/security/public_sys-resources/icon-note.gif
deleted file mode 100644
index 6314297e45c1de184204098efd4814d6dc8b1cda..0000000000000000000000000000000000000000
Binary files a/en/device-dev/security/public_sys-resources/icon-note.gif and /dev/null differ
diff --git a/en/device-dev/security/public_sys-resources/icon-notice.gif b/en/device-dev/security/public_sys-resources/icon-notice.gif
deleted file mode 100644
index 86024f61b691400bea99e5b1f506d9d9aef36e27..0000000000000000000000000000000000000000
Binary files a/en/device-dev/security/public_sys-resources/icon-notice.gif and /dev/null differ
diff --git a/en/device-dev/security/public_sys-resources/icon-tip.gif b/en/device-dev/security/public_sys-resources/icon-tip.gif
deleted file mode 100644
index 93aa72053b510e456b149f36a0972703ea9999b7..0000000000000000000000000000000000000000
Binary files a/en/device-dev/security/public_sys-resources/icon-tip.gif and /dev/null differ
diff --git a/en/device-dev/security/public_sys-resources/icon-warning.gif b/en/device-dev/security/public_sys-resources/icon-warning.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/security/public_sys-resources/icon-warning.gif and /dev/null differ
diff --git a/en/device-dev/security/safety-safeguide-security.md b/en/device-dev/security/safety-safeguide-security.md
new file mode 100644
index 0000000000000000000000000000000000000000..bc0933021d484d046df7d54fa1de239b99deb195
--- /dev/null
+++ b/en/device-dev/security/safety-safeguide-security.md
@@ -0,0 +1,275 @@
+# Security Guidelines
+
+- [Overview](#section1521410017353)
+- [Hardware Security](#section2558121318351)
+ - [Mechanism](#section1399511541896)
+ - [Recommended Practices](#section948519243104)
+
+- [System Security](#section87802111361)
+ - [Mechanism](#section149107611118)
+ - [Recommended Practices](#section1364122019112)
+
+- [Data Security](#section2468927364)
+ - [Mechanism](#section1378993720111)
+ - [Recommended Practices](#section1531735481112)
+
+- [Device Interconnection Security](#section26153183616)
+- [Application Security](#section852593153614)
+ - [Mechanism](#section55012136125)
+ - [Recommended Practices](#section6341102610123)
+
+
+## Overview
+
+OpenHarmony is an open OS that allows you to easily develop services and applications. It provides an execution environment to ensure security of application data and user data.
+
+This environment combines chip security and system security features with upper-layer security services to secure hardware, the system, data, device interconnection, applications, and updates.
+
+**Figure 1** Security assurance framework
+
+
+## Hardware Security
+
+### Mechanism
+
+- Boot root of trust
+
+ OpenHarmony devices use the public key infrastructure \(PKI\) to protect software integrity and ensure that the software source is valid and the software is not tampered with.
+
+ In the device boot process, software signature verification is performed at each phase to form a secure boot chain. If signature verification fails at any phase, the device boot will be terminated. The hardware or software entity that initially performs signature verification in the secure boot chain is the boot root of trust. It must be valid and should not be tampered with. The boot root of trust can be a built-in code segment in the read-only memory \(ROM\). This code segment is written in the chip during the chip manufacturing and cannot be modified later. When the device is powered on and initialized, this code segment is executed first and used to verify software signatures.
+
+ When you use the code for signature verification, ensure the validity of the PKI public keys. OpenHarmony devices use a storage medium such as eFUSE and one-time password \(OTP\) to store the public keys \(for example, their hash values\) and guarantee their validity. A public key is usually programed into the eFuse or OTP of a device during device manufacturing.
+
+- Hardware-isolated trusted environment
+
+ The hardware-isolated trusted environment complies with the design concept of the trusted computing system. There is a clear boundary between the trusted environment and untrusted one. OpenHarmony devices protect core sensitive data in the trusted environment. Even if OS vulnerabilities in the untrusted environment are exploited, sensitive data in the trusted environment is secure.
+
+ The trusted environment of OpenHarmony devices is built based on a hardware security isolation mechanism. The chip isolation mechanism varies slightly on different OpenHarmony devices, and the most common mechanism is Arm TrustZone. On some RISC-V chip platforms, independent security cores may also be used to build a trusted environment.
+
+ A specific, simplified OS iTrustee lite runs in the trusted environment to manage resources and schedule tasks in the environment and provide security services for OpenHarmony devices. Key management and data security are the most common security services in the trusted environment. A device has a unique hardware root key in the eFuse/OTP. Based on this root key and service context, the trusted environment generates multiple keys that provide key management and data encryption/decryption services for applications. During their whole lifecycle, core keys of devices stay in the trusted environment. The trusted environment also provides security services such as identity authentication, system status monitoring, and secure data storage to enhance device security.
+
+- Hardware key engine
+
+ Cryptography is the basis of information security. Data encryption/decryption requires high efficiency and security of computing devices. Hardware encryption/decryption technologies use computer hardware to assist or even replace software to encrypt or decrypt data. Hardware-based encryption/decryption is more efficient and secure than software-based encryption/decryption.
+
+ Since some dedicated hardware resources are used for data encryption/decryption, the CPU can concurrently execute other computing tasks, which greatly improves performance and reduces the CPU load. In addition, a well-designed hardware key engine protects keys from leak even if the software is cracked and even defends against electromagnetic and radiation attacks from physical channels.
+
+ OpenHarmony devices support the hardware key engine, which allows OpenHarmony to perform computing tasks such as data encryption and decryption, certificate signature verification, and hash value calculation. The hardware key engine supports popular algorithms such as Advanced Encryption Standard \(AES\) and Rivest-Shamir-Adleman \(RSA\).
+
+
+### Recommended Practices
+
+- The boot root of trust consists of a built-in code segment in the chip and the root key of the device. The root of trust is written into the chip during manufacturing and cannot be modified in the device lifecycle. It is used to verify software certificates in the device boot process. The root key is the public key matching the private key of the device certificate signature. The private key is maintained on the PKI signature server and the public key is written to the device. To prevent attackers from tampering with the public key to bypass signature authentication, you can write the public key to media such as fuses on OpenHarmony devices. Considering that the fuse space is limited, you can store only the hash value of the public key in the fuse and verify the validity of the public key using the boot code.
+- Generally, a trusted execution environment \(TEE\) is built based on the Arm TrustZone technology, and can also adopt other isolation mechanisms, such as TrustZone-M and independent security cores, depending on the device form. A TEE OS must be deployed in the TEE to manage resources and schedule tasks. OpenHarmony provides iTrustee as the TEE OS. You can develop and deploy security services based on iTrustee.
+
+ Not all OpenHarmony devices need to support the TEE, for example, some devices with thin resources that run less sensitive services may not need the TEE. You can choose whether to support the TEE and how to implement the TEE based on service requirements.
+
+- The hardware key engine must provide key algorithms related to true random numbers, public keys, symmetric keys, and hash values. By deploying required drivers in OpenHarmony, you can provide unified key management and key algorithms for applications.
+
+## System Security
+
+### Mechanism
+
+For devices with 128 KB to 128 MB of memory, the OpenHarmony lite kernel is recommended. It provides the following features:
+
+- Process isolation
+
+ Process isolation prevents processes from reading and writing memory data of each other. Generally, virtual address space mapping is used for process isolation. The virtual addresses of two processes are mapped to physical address segments using the memory management unit \(MMU\). In this way, the non-shared memory data that can be accessed by one of the two processes through the virtual address is inaccessible to the other process.
+
+ Due to limited resources, OpenHarmony adopts different mechanisms for kernel-level and user-level processes. All kernel-level processes share the same VMM space, that is, kernel-level processes are not isolated from each other. When the OS is booted, two basic kernel-level processes KProcess and KIdle are created. KProcess is the root process of kernel-level process, and KIdle is the subprocess of KProcess. Each user-level process has its own VMM space that is invisible to other processes, and user-level processes are isolated from each other.
+
+- Discretionary access control
+
+ Discretionary access control \(DAC\) means that the file owner determines access permissions of other roles. There are three granularities of permission control: user, group, and other \(UGO\). The file owner can classify any user into one of the three dimensions and adopt a control policy to perform DAC permission verification.
+
+ DAC depends on the attributes of processes, such as the UID and GID, which are used as feature IDs during file creation and access. When creating a file, the creator writes its UID into the file. When a file is accessed, the UID is used for classifying the file.
+
+ Each application has a UID. When creating a file, an application adds its UID to the metadata of the file and sets permissions of the user, group, and other. When an application tries to access the file, the UID and permissions in the metadata of the file are used to verify the application UID.
+
+ The following figure shows how DAC works when a process accesses a file. The DAC first matches the process UID with the file UID, and then the process GID with the file GID. If the UID and GID both fail to match, DAC checks the **other** attribute of the file to determine whether the process is allowed to read, write, or execute the file. In addition, the system supports a privileged capability that is not subject to DAC mechanism \(read, write, and execute\) and can access files directly. Services with high permissions \(such as system services\) can manage files of applications with low permissions \(such as third-party applications\).
+
+ **Figure 2** How DAC works
+ 
+
+- Capability mechanism
+
+ The capability mechanism is a subdivision of the root permission. A multi-user computer system usually has a special role that has all system permissions, that is, the system administrator with the root permission. OpenHarmony needs to support kernels of the third-party application ecosystem, and privileged access to the system must be controlled. The system needs to restrict privileged system calls made by users to access the kernel. Only some applications with high-level permissions are allowed to perform privileged operations. To be specific, the kernel spawns the first user program INIT that has all privileged permissions. Then INIT starts other application framework services and retains only privileged permissions necessary for each application. When an application requests to call a privileged API, the kernel checks whether the application has the permission to access the API based on the process ID.
+
+- Secure boot
+
+ Secure boot is the basis of system security. A digital signature and integrity verification mechanism is used to verify the integrity and validity of software at each layer, starting from the boot root of trust in the chip. This ensures that a correct and valid OS is booted, preventing attackers from tampering with or implanting system software and providing a secure, basic running environment.
+
+ The chip does not need to be verified after it is powered on because the on-chip ROM code cannot be modified. The on-chip ROM verifies the bootloader based on the public key hash value which is calculated using the asymmetric algorithm in eFuse. The verification is performed based on the hardware trust root and is fully trusted. The bootloader that passes this verification is deemed to be trusted for subsequent use. This is the process of constructing a trust chain. Bootloader initializes the execution environment, including initializing the double data rate \(DDR\) and reading and writing the flash memory, to prepare for loading modules and executing more complex logic. After the bootloader is initialized, it verifies the integrity of the X.509 certificate and verifies image packages \(**kernel.bin**, **teeOS.bin**, and **rootfs.bin**\) using the public key of the X.509 certificate.
+
+
+### Recommended Practices
+
+- DAC and the capability mechanism are used to control who can access resources. It is recommended that the minimum permissions are granted.
+- Secure boot must be enabled, and the trusted root must be in the chip and cannot be modified. In addition, you must consider the impact of secure upgrade \(if available\) on secure boot, that is, the signature or hash value of an image file must be updated after a secure upgrade.
+
+## Data Security
+
+### Mechanism
+
+Huawei Universal Keystore Service \(HUKS\) provides key and certificate management. For OpenHarmony, it mainly provides key management for HiChain \(the device identity authentication platform\). The following figure shows the functions of HUKS
+
+**Figure 3** HUKS functions
+
+
+The following algorithms are supported:
+
+- Authentication and encryption: AES-128/192/256-GCM
+- Signature verification: ED25519
+- Key negotiation: X25519
+- Message authentication: HMAC-SHA256/512
+- Data digest: SHA256/512
+
+HUKS has the following restrictions:
+
+- Secure storage of keys: Keys must be stored in a secure area and cannot be modified. When factory settings are restored, preset keys are not deleted.
+- Key access security: OpenHarmony stores different data of an application separately to implement data isolation in the application, and includes the UID and process ID in the parameter structure to implement data isolation between different applications.
+- Concurrent access is not supported, that is, multiple applications cannot invoke HUKS simultaneously. As HUKS is a single library, resource exclusion is not a concern. If multiple applications need to use HUKS, each of them needs to connect to a HUKS library and pass a path for storing data. Data is stored in the directory of each application.
+
+### Recommended Practices
+
+To use the device certification function, it is recommended that you use HiChain to interconnect with HUKS. HUKS provides applications such as HiChain with key generation, import, export, encryption/decryption, storage, and destruction, certificate import and query, and secret information storage.
+
+## Device Interconnection Security
+
+To transmit user data securely between devices, ensure that the devices are trusted by each other. A trust relationship and a secure data transmission channel must be established between the devices. This section describes how an IoT controller and IoT device establish a trust relationship. The following figure shows how an IoT controller and an IoT device establish a trust relationship.
+
+**Figure 4** How an IoT controller and an IoT device establish a trust relationship
+
+
+- **IoT device interconnection security**
+
+ A trust relationship can be established between an IoT device that runs OpenHarmony \(such as an AI speaker, smart home device, and wearable\) and an IoT controller. Encrypted user data is transmitted between the IoT device and IoT controller through a secure connection.
+
+
+- **IoT service identifier of the IoT controller**
+
+ An IoT controller generates different identifiers for different IoT device management services to isolate these services. The identifier can be used for authentication and communication between an IoT controller and an IoT device. It is an Ed25519 public/private key pair generated using the elliptic curve cryptography.
+
+
+- **IoT device identifier**
+
+ An IoT device can generate its own device identifier for communicating with the IoT controller. It is also an Ed25519 public/private key pair generated using elliptic curve cryptography, with the private key stored on the IoT device. Each time the device is restored to factory settings, the public/private key pair will be reset.
+
+ The identifier can be used for secure communication between the IoT controller and IoT device. After the devices exchange the service identifier or device identifier, they can negotiate the key and establish a secure communication channel.
+
+
+- **P2P trusted binding between devices**
+
+ When an IoT controller and an IOT device establish a trust relationship, they exchange identifiers.
+
+ During this process, the user needs to enter or scan the PIN provided by the IoT device on the IoT controller. PIN is either dynamically generated if the IoT device has a screen, or preset by the manufacturer if it does not have a screen. A PIN can be a number or a QR code. Then the IoT controller and IoT device perform authentication and session key exchange based on password authenticated key exchange \(PAKE\), and use the session key to encrypt the channel for exchanging identity public keys.
+
+
+- **Secure communication between the IoT controller and IoT device**
+
+ When an IoT controller and an IoT device communicate with each other after establishing a trust relationship, they authenticate each other by using the locally stored identity public key of the peer. Bidirectional identity authentication and session key exchange are performed using the Station-to-Station \(STS\) protocol during each communication. The session key is used to encrypt the data transmission channel between the devices.
+
+
+## Application Security
+
+### Mechanism
+
+- Application signature management
+
+ After developing and debugging an OpenHarmony application, sign the application installation package using a private key, which matches a public key. Generally, the OEM generates a public/private key pair, presets the public key in the device, and stores the private key on a local server that is not connected to the Internet to prevent private key leakage. After you finish developing an application, you can use an external device \(such as a USB flash drive\) to upload the installation package to the server where the private key is stored, calculate the signature, and download the signature to the external device. During application installation, the hash value of the bundle is calculated using the SHA-256 algorithm. The hash value, together with the signature and preset public key, is used for authentication. The application can be installed only after the authentication is successful.
+
+ In addition, the application source must be verified to ensure that the application is from a valid developer. As a developer, you must apply for a development certificate and use it to sign the application you have developed. During application installation, the upper-level certificate stored on the device is used to verify the signature to ensure validity of the developer.
+
+- Application permission control
+
+ OpenHarmony allows users to install third-party applications and controls calls made by third-party applications to sensitive permissions. When developing an application, you need to declare the sensitive permissions that the application may invoke in the **profile.json** file. The permissions include static and dynamic ones. Static permissions need to be registered during application installation, and dynamic permissions can be invoked only upon user authorization. Authorization modes include system settings, manual authorization by applications, and others. In addition, application signature control is used to ensure that the application installation package has been confirmed by the device vendor.
+
+ **Table 1** OpenHarmony system permissions
+
+
+
OpenHarmony System Permission
+
+
Authorization Mode
+
+
Description
+
+
+
+
ohos.permission.LISTEN_BUNDLE_CHANGE
+
+
system_grant (static permission)
+
+
Allows an application to listen for application changes.
+
+
+
ohos.permission.GET_BUNDLE_INFO
+
+
system_grant (static permission)
+
+
Allows an application to obtain application information.
+
+
+
ohos.permission.INSTALL_BUNDLE
+
+
system_grant (static permission)
+
+
Allows an application to install applications.
+
+
+
ohos.permission.CAMERA
+
+
user_grant (dynamic permission)
+
+
Allows an application to use the camera to take photos and record videos at any time.
+
+
+
ohos.permission.MODIFY_AUDIO_SETTINGS
+
+
system_grant (static permission)
+
+
Allows an application to modify global audio settings, such as the volume and speaker for output.
+
+
+
ohos.permission.READ_MEDIA
+
+
user_grant (dynamic permission)
+
+
Allows an application to read users' favorite videos.
+
+
+
ohos.permission.MICROPHONE
+
+
user_grant (dynamic permission)
+
+
Allows an application to use the microphone for audio recording at any time.
+
+
+
ohos.permission.WRITE_MEDIA
+
+
user_grant (dynamic permission)
+
+
Allows an application to write users' favorite music.
+
+
+
ohos.permission.DISTRIBUTED_DATASYNC
+
+
user_grant (dynamic permission)
+
+
Allows an application to manage distributed data transmission.
+
+
+
ohos.permission.DISTRIBUTED_VIRTUALDEVICE
+
+
user_grant (dynamic permission)
+
+
Allows an application to use distributed virtualization features.
+
+
+
+
+
+
+### Recommended Practices
+
+When developing an application, determine what permissions your application needs and register the permissions in the **profile.json** file. Sign the application to ensure that the devices on which the application will be installed can verify its integrity and source.
+
diff --git a/en/device-dev/security/security-guidelines.md b/en/device-dev/security/security-guidelines.md
deleted file mode 100644
index e82aa5c28bd2b6816bc7226b14680cd45a899457..0000000000000000000000000000000000000000
--- a/en/device-dev/security/security-guidelines.md
+++ /dev/null
@@ -1,271 +0,0 @@
-# Security Guidelines
-
-- [Overview](#section1521410017353)
-- [Hardware Security](#section2558121318351)
-- [Mechanism](#section1312953842210)
-- [Recommended Practices](#section37901319112311)
-- [System Security](#section87802111361)
-- [Mechanism](#section1654963052914)
-- [Recommended Practices](#section45821048173613)
-- [Data Security](#section2468927364)
-- [Mechanism](#section11192175813293)
-- [Recommended Practices](#section174640713306)
-- [Device Interconnection Security](#section26153183616)
-- [Application Security](#section852593153614)
-- [Mechanism](#section12125105014377)
-- [Recommended Practices](#section1641420155381)
-
-## Overview
-
-OpenHarmony is an open OS that allows you to easily develop services and applications. It provides an execution environment to ensure security of application data and user data.
-
-This environment combines chip security and system security features with upper-layer security services to secure hardware, the system, data, device interconnection, applications, and updates.
-
-**Figure 1** Security assurance framework
-
-
-## Hardware Security
-
-## Mechanism
-
-- Boot root of trust
-
- OpenHarmony devices use the public key infrastructure \(PKI\) to protect software integrity and ensure that the software source is valid and the software is not tampered with.
-
- In the device boot process, software signature verification is performed at each phase to form a secure boot chain. If signature verification fails at any phase, the device boot will be terminated. The hardware or software entity that initially performs signature verification in the secure boot chain is the boot root of trust. It must be valid and should not be tampered with. The boot root of trust can be a built-in code segment in the read-only memory \(ROM\). This code segment is written in the chip during the chip manufacturing and cannot be modified later. When the device is powered on and initialized, this code segment is executed first and used to verify software signatures.
-
- When you use the code for signature verification, ensure the validity of the PKI public keys. OpenHarmony devices use a storage medium such as eFUSE and one-time password \(OTP\) to store the public keys \(for example, their hash values\) and guarantee their validity. A public key is usually programed into the eFuse or OTP of a device during device manufacturing.
-
-- Hardware-isolated trusted environment
-
- The hardware-isolated trusted environment complies with the design concept of the trusted computing system. There is a clear boundary between the trusted environment and untrusted one. OpenHarmony devices protect core sensitive data in the trusted environment. Even if OS vulnerabilities in the untrusted environment are exploited, sensitive data in the trusted environment is secure.
-
- The trusted environment of OpenHarmony devices is built based on a hardware security isolation mechanism. The chip isolation mechanism varies slightly on different OpenHarmony devices, and the most common mechanism is Arm TrustZone. On some RISC-V chip platforms, independent security cores may also be used to build a trusted environment.
-
- A specific, simplified OS iTrustee lite runs in the trusted environment to manage resources and schedule tasks in the environment and provide security services for OpenHarmony devices. Key management and data security are the most common security services in the trusted environment. A device has a unique hardware root key in the eFuse/OTP. Based on this root key and service context, the trusted environment generates multiple keys that provide key management and data encryption/decryption services for applications. During their whole lifecycle, core keys of devices stay in the trusted environment. The trusted environment also provides security services such as identity authentication, system status monitoring, and secure data storage to enhance device security.
-
-- Hardware key engine
-
- Cryptography is the basis of information security. Data encryption/decryption requires high efficiency and security of computing devices. Hardware encryption/decryption technologies use computer hardware to assist or even replace software to encrypt or decrypt data. Hardware-based encryption/decryption is more efficient and secure than software-based encryption/decryption.
-
- Since some dedicated hardware resources are used for data encryption/decryption, the CPU can concurrently execute other computing tasks, which greatly improves performance and reduces the CPU load. In addition, a well-designed hardware key engine protects keys from leak even if the software is cracked and even defends against electromagnetic and radiation attacks from physical channels.
-
- OpenHarmony devices support the hardware key engine, which allows OpenHarmony to perform computing tasks such as data encryption and decryption, certificate signature verification, and hash value calculation. The hardware key engine supports popular algorithms such as Advanced Encryption Standard \(AES\) and Rivest-Shamir-Adleman \(RSA\).
-
-
-## Recommended Practices
-
-- The boot root of trust consists of a built-in code segment in the chip and the root key of the device. The root of trust is written into the chip during manufacturing and cannot be modified in the device lifecycle. It is used to verify software certificates in the device boot process. The root key is the public key matching the private key of the device certificate signature. The private key is maintained on the PKI signature server and the public key is written to the device. To prevent attackers from tampering with the public key to bypass signature authentication, you can write the public key to media such as fuses on OpenHarmony devices. Considering that the fuse space is limited, you can store only the hash value of the public key in the fuse and verify the validity of the public key using the boot code.
-- Generally, a trusted execution environment \(TEE\) is built based on the Arm TrustZone technology, and can also adopt other isolation mechanisms, such as TrustZone-M and independent security cores, depending on the device form. A TEE OS must be deployed in the TEE to manage resources and schedule tasks. OpenHarmony provides iTrustee as the TEE OS. You can develop and deploy security services based on iTrustee.
-
- Not all OpenHarmony devices need to support the TEE, for example, some devices with thin resources that run less sensitive services may not need the TEE. You can choose whether to support the TEE and how to implement the TEE based on service requirements.
-
-- The hardware key engine must provide key algorithms related to true random numbers, public keys, symmetric keys, and hash values. By deploying required drivers in OpenHarmony, you can provide unified key management and key algorithms for applications.
-
-## System Security
-
-## Mechanism
-
-For devices with 128 KB to 128 MB of memory, the OpenHarmony lite kernel is recommended. It provides the following features:
-
-- Process isolation
-
- Process isolation prevents processes from reading and writing memory data of each other. Generally, virtual address space mapping is used for process isolation. The virtual addresses of two processes are mapped to physical address segments using the memory management unit \(MMU\). In this way, the non-shared memory data that can be accessed by one of the two processes through the virtual address is inaccessible to the other process.
-
- Due to limited resources, OpenHarmony adopts different mechanisms for kernel-level and user-level processes. All kernel-level processes share the same VMM space, that is, kernel-level processes are not isolated from each other. When the OS is booted, two basic kernel-level processes KProcess and KIdle are created. KProcess is the root process of kernel-level process, and KIdle is the subprocess of KProcess. Each user-level process has its own VMM space that is invisible to other processes, and user-level processes are isolated from each other.
-
-- Discretionary access control
-
- Discretionary access control \(DAC\) means that the file owner determines access permissions of other roles. There are three granularities of permission control: user, group, and other \(UGO\). The file owner can classify any user into one of the three dimensions and adopt a control policy to perform DAC permission verification.
-
- DAC depends on the attributes of processes, such as the UID and GID, which are used as feature IDs during file creation and access. When creating a file, the creator writes its UID into the file. When a file is accessed, the UID is used for classifying the file.
-
- Each application has a UID. When creating a file, an application adds its UID to the metadata of the file and sets permissions of the user, group, and other. When an application tries to access the file, the UID and permissions in the metadata of the file are used to verify the application UID.
-
- The following figure shows how DAC works when a process accesses a file. The DAC first matches the process UID with the file UID, and then the process GID with the file GID. If the UID and GID both fail to match, DAC checks the **other** attribute of the file to determine whether the process is allowed to read, write, or execute the file. In addition, the system supports a privileged capability that is not subject to DAC mechanism \(read, write, and execute\) and can access files directly. Services with high permissions \(such as system services\) can manage files of applications with low permissions \(such as third-party applications\).
-
- **Figure 2** How DAC works
- 
-
-- Capability mechanism
-
- The capability mechanism is a subdivision of the root permission. A multi-user computer system usually has a special role that has all system permissions, that is, the system administrator with the root permission. OpenHarmony needs to support kernels of the third-party application ecosystem, and privileged access to the system must be controlled. The system needs to restrict privileged system calls made by users to access the kernel. Only some applications with high-level permissions are allowed to perform privileged operations. To be specific, the kernel spawns the first user program INIT that has all privileged permissions. Then INIT starts other application framework services and retains only privileged permissions necessary for each application. When an application requests to call a privileged API, the kernel checks whether the application has the permission to access the API based on the process ID.
-
-- Secure boot
-
- Secure boot is the basis of system security. A digital signature and integrity verification mechanism is used to verify the integrity and validity of software at each layer, starting from the boot root of trust in the chip. This ensures that a correct and valid OS is booted, preventing attackers from tampering with or implanting system software and providing a secure, basic running environment.
-
- The chip does not need to be verified after it is powered on because the on-chip ROM code cannot be modified. The on-chip ROM verifies the bootloader based on the public key hash value which is calculated using the asymmetric algorithm in eFuse. The verification is performed based on the hardware trust root and is fully trusted. The bootloader that passes this verification is deemed to be trusted for subsequent use. This is the process of constructing a trust chain. Bootloader initializes the execution environment, including initializing the double data rate \(DDR\) and reading and writing the flash memory, to prepare for loading modules and executing more complex logic. After the bootloader is initialized, it verifies the integrity of the X.509 certificate and verifies image packages \(**kernel.bin**, **teeOS.bin**, and **rootfs.bin**\) using the public key of the X.509 certificate.
-
-
-## Recommended Practices
-
-- DAC and the capability mechanism are used to control who can access resources. It is recommended that the minimum permissions are granted.
-- Secure boot must be enabled, and the trusted root must be in the chip and cannot be modified. In addition, you must consider the impact of secure upgrade \(if available\) on secure boot, that is, the signature or hash value of an image file must be updated after a secure upgrade.
-
-## Data Security
-
-## Mechanism
-
-Huawei Universal Keystore Service \(HUKS\) provides key and certificate management. For OpenHarmony, it mainly provides key management for HiChain \(the device identity authentication platform\). The following figure shows the functions of HUKS
-
-**Figure 3** HUKS functions
-
-
-The following algorithms are supported:
-
-- Authentication and encryption: AES-128/192/256-GCM
-- Signature verification: ED25519
-- Key negotiation: X25519
-- Message authentication: HMAC-SHA256/512
-- Data digest: SHA256/512
-
-HUKS has the following restrictions:
-
-- Secure storage of keys: Keys must be stored in a secure area and cannot be modified. When factory settings are restored, preset keys are not deleted.
-- Key access security: OpenHarmony stores different data of an application separately to implement data isolation in the application, and includes the UID and process ID in the parameter structure to implement data isolation between different applications.
-- Concurrent access is not supported, that is, multiple applications cannot invoke HUKS simultaneously. As HUKS is a single library, resource exclusion is not a concern. If multiple applications need to use HUKS, each of them needs to connect to a HUKS library and pass a path for storing data. Data is stored in the directory of each application.
-
-## Recommended Practices
-
-To use the device certification function, it is recommended that you use HiChain to interconnect with HUKS. HUKS provides applications such as HiChain with key generation, import, export, encryption/decryption, storage, and destruction, certificate import and query, and secret information storage.
-
-## Device Interconnection Security
-
-To transmit user data securely between devices, ensure that the devices are trusted by each other. A trust relationship and a secure data transmission channel must be established between the devices. This section describes how an IoT controller and IoT device establish a trust relationship. The following figure shows how an IoT controller and an IoT device establish a trust relationship.
-
-**Figure 4** How an IoT controller and an IoT device establish a trust relationship
-
-
-- **IoT device interconnection security**
-
- A trust relationship can be established between an IoT device that runs OpenHarmony \(such as an AI speaker, smart home device, and wearable\) and an IoT controller. Encrypted user data is transmitted between the IoT device and IoT controller through a secure connection.
-
-
-- **IoT service identifier of the IoT controller**
-
- An IoT controller generates different identifiers for different IoT device management services to isolate these services. The identifier can be used for authentication and communication between an IoT controller and an IoT device. It is an Ed25519 public/private key pair generated using the elliptic curve cryptography.
-
-
-- **IoT device identifier**
-
- An IoT device can generate its own device identifier for communicating with the IoT controller. It is also an Ed25519 public/private key pair generated using elliptic curve cryptography, with the private key stored on the IoT device. Each time the device is restored to factory settings, the public/private key pair will be reset.
-
- The identifier can be used for secure communication between the IoT controller and IoT device. After the devices exchange the service identifier or device identifier, they can negotiate the key and establish a secure communication channel.
-
-
-- **P2P trusted binding between devices**
-
- When an IoT controller and an IOT device establish a trust relationship, they exchange identifiers.
-
- During this process, the user needs to enter or scan the PIN provided by the IoT device on the IoT controller. PIN is either dynamically generated if the IoT device has a screen, or preset by the manufacturer if it does not have a screen. A PIN can be a number or a QR code. Then the IoT controller and IoT device perform authentication and session key exchange based on password authenticated key exchange \(PAKE\), and use the session key to encrypt the channel for exchanging identity public keys.
-
-
-- **Secure communication between the IoT controller and IoT device**
-
- When an IoT controller and an IoT device communicate with each other after establishing a trust relationship, they authenticate each other by using the locally stored identity public key of the peer. Bidirectional identity authentication and session key exchange are performed using the Station-to-Station \(STS\) protocol during each communication. The session key is used to encrypt the data transmission channel between the devices.
-
-
-## Application Security
-
-## Mechanism
-
-- Application signature management
-
- After developing and debugging an OpenHarmony application, sign the application installation package using a private key, which matches a public key. Generally, the OEM generates a public/private key pair, presets the public key in the device, and stores the private key on a local server that is not connected to the Internet to prevent private key leakage. After you finish developing an application, you can use an external device \(such as a USB flash drive\) to upload the installation package to the server where the private key is stored, calculate the signature, and download the signature to the external device. During application installation, the hash value of the bundle is calculated using the SHA-256 algorithm. The hash value, together with the signature and preset public key, is used for authentication. The application can be installed only after the authentication is successful.
-
- In addition, the application source must be verified to ensure that the application is from a valid developer. As a developer, you must apply for a development certificate and use it to sign the application you have developed. During application installation, the upper-level certificate stored on the device is used to verify the signature to ensure validity of the developer.
-
-- Application permission control
-
- OpenHarmony allows users to install third-party applications and controls calls made by third-party applications to sensitive permissions. When developing an application, you need to declare the sensitive permissions that the application may invoke in the **profile.json** file. The permissions include static and dynamic ones. Static permissions need to be registered during application installation, and dynamic permissions can be invoked only upon user authorization. Authorization modes include system settings, manual authorization by applications, and others. In addition, application signature control is used to ensure that the application installation package has been confirmed by the device vendor.
-
- **Table 1** OpenHarmony system permissions
-
-
-
OpenHarmony System Permission
-
-
Authorization Mode
-
-
Description
-
-
-
-
ohos.permission.LISTEN_BUNDLE_CHANGE
-
-
system_grant (static permission)
-
-
Allows an application to listen for application changes.
-
-
-
ohos.permission.GET_BUNDLE_INFO
-
-
system_grant (static permission)
-
-
Allows an application to obtain application information.
-
-
-
ohos.permission.INSTALL_BUNDLE
-
-
system_grant (static permission)
-
-
Allows an application to install applications.
-
-
-
ohos.permission.CAMERA
-
-
user_grant (dynamic permission)
-
-
Allows an application to use the camera to take photos and record videos at any time.
-
-
-
ohos.permission.MODIFY_AUDIO_SETTINGS
-
-
system_grant (static permission)
-
-
Allows an application to modify global audio settings, such as the volume and speaker for output.
-
-
-
ohos.permission.READ_MEDIA
-
-
user_grant (dynamic permission)
-
-
Allows an application to read users' favorite videos.
-
-
-
ohos.permission.MICROPHONE
-
-
user_grant (dynamic permission)
-
-
Allows an application to use the microphone for audio recording at any time.
-
-
-
ohos.permission.WRITE_MEDIA
-
-
user_grant (dynamic permission)
-
-
Allows an application to write users' favorite music.
-
-
-
ohos.permission.DISTRIBUTED_DATASYNC
-
-
user_grant (dynamic permission)
-
-
Allows an application to manage distributed data transmission.
-
-
-
ohos.permission.DISTRIBUTED_VIRTUALDEVICE
-
-
user_grant (dynamic permission)
-
-
Allows an application to use distributed virtualization features.
-
-
-
-
-
-
-## Recommended Practices
-
-When developing an application, determine what permissions your application needs and register the permissions in the **profile.json** file. Sign the application to ensure that the devices on which the application will be installed can verify its integrity and source.
-
diff --git a/en/device-dev/subsystems/Readme-EN.md b/en/device-dev/subsystems/Readme-EN.md
index 4af4610ea81173dbfb4ee9b937151a95834b5575..e25ab80a3cc1d03c5d0165b3e9f49f0ea1de765e 100644
--- a/en/device-dev/subsystems/Readme-EN.md
+++ b/en/device-dev/subsystems/Readme-EN.md
@@ -1,95 +1,74 @@
-# Subsystems
-
-- [Compilation and Building](compilation-and-building.md)
- - [Building Guidelines for Mini and Small Systems](building-guidelines-for-mini-and-small-systems.md)
- - [Compilation and Building Overview](compilation-and-building-overview.md)
- - [Compilation and Building Guidelines](compilation-and-building-guidelines.md)
- - [Compilation and Building FAQ](compilation-and-building-faq.md)
-
- - [Building Guidelines for the Standard System](building-guidelines-for-the-standard-system.md)
- - [Compilation and Building Overview](compilation-and-building-overview-0.md)
- - [Compilation and Building Guidelines](compilation-and-building-guidelines-1.md)
-
-- [Distributed Remote Startup](distributed-remote-startup.md)
-- [Graphics](graphics.md)
- - [Graphics](graphics-2.md)
- - [Development Guidelines on Container Components](development-guidelines-on-container-components.md)
- - [Development Guidelines on Layout Container Components](development-guidelines-on-layout-container-components.md)
- - [Development Guidelines on Common Components](development-guidelines-on-common-components.md)
- - [Development Guidelines on Animators](development-guidelines-on-animators.md)
-
-- [Multimedia](multimedia.md)
- - [Camera](camera.md)
- - [Overview](overview.md)
- - [Development Guidelines on Photographing](development-guidelines-on-photographing.md)
- - [Development Guidelines on Video Recording](development-guidelines-on-video-recording.md)
- - [Development Guidelines on Previewing](development-guidelines-on-previewing.md)
-
- - [Audio/Video](audio-video.md)
- - [Overview](overview-3.md)
- - [Development Guidelines on Media Playback](development-guidelines-on-media-playback.md)
- - [Development Guidelines on Media Recording](development-guidelines-on-media-recording.md)
-
-- [Utils](utils.md)
- - [Utils Overview](utils-overview.md)
- - [Utils Development Guidelines](utils-development-guidelines.md)
- - [Utils FAQ](utils-faq.md)
-
-- [AI Framework](ai-framework.md)
- - [AI Engine Framework](ai-engine-framework.md)
- - [Development Environment](development-environment.md)
- - [Technical Specifications](technical-specifications.md)
- - [Code Management](code-management.md)
- - [Naming](naming.md)
- - [API Development](api-development.md)
-
- - [Development Guidelines](development-guidelines.md)
- - [SDK](sdk.md)
- - [Plug-in](plug-in.md)
- - [Configuration File](configuration-file.md)
-
- - [Development Examples](development-examples.md)
- - [KWS SDK](kws-sdk.md)
- - [KWS Plug-in](kws-plug-in.md)
- - [KWS Configuration File](kws-configuration-file.md)
-
-- [Sensors](sensors.md)
- - [Sensors Overview](sensors-overview.md)
- - [Sensors Usage Guidelines](sensors-usage-guidelines.md)
- - [Sensors Usage Example](sensors-usage-example.md)
-
-- [Application Framework](application-framework.md)
- - [Overview](overview-4.md)
- - [Setting Up a Development Environment](setting-up-a-development-environment.md)
- - [Development Guidelines](development-guidelines-5.md)
- - [Development Example](development-example.md)
-
-- [OTA Upgrade](ota-upgrade.md)
-- [Security](security.md)
- - [Overview](overview-9.md)
- - [Development Guidelines on Application Signature Verification](development-guidelines-on-application-signature-verification.md)
- - [Development Guidelines on Application Permission Management](development-guidelines-on-application-permission-management.md)
- - [Development Guidelines on IPC Authentication](development-guidelines-on-ipc-authentication.md)
-
-- [Startup](startup.md)
- - [Startup](startup-10.md)
- - [init Module](init-module.md)
- - [appspawn Module](appspawn-module.md)
- - [bootstrap Module](bootstrap-module.md)
- - [syspara Module](syspara-module.md)
- - [FAQs](faqs.md)
- - [Reference](reference.md)
-
-- [Testing](testing.md)
-- [DFX](dfx.md)
- - [DFX](dfx-11.md)
- - [Development Guidelines on HiLog ](development-guidelines-on-hilog.md)
- - [Development Guidelines on HiLog\_Lite](development-guidelines-on-hilog_lite.md)
- - [Development Guidelines on HiSysEvent](development-guidelines-on-hisysevent.md)
-
-- [R&D Tools](r-d-tools.md)
- - [bytrace Usage Guidelines](bytrace-usage-guidelines.md)
- - [hdc\_std Usage Guidelines](hdc_std-usage-guidelines.md)
-
-- [XTS](xts.md)
-
+# Subsystems
+
+- [Compilation and Building](subsys-build.md)
+ - [Building Guidelines for Mini and Small Systems](subsys-build-mini-lite.md)
+ - [Building Guidelines for Standard Systems](subsys-build-standard-large.md)
+- [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 Animators](subsys-graphics-animation-guide.md)
+- [Multimedia](subsys-multimedia.md)
+ - [Camera](subsys-multimedia-camera.md)
+ - [Overview](subsys-multimedia-camera-overview.md)
+ - [Development Guidelines on Photographing](subsys-multimedia-camera-photo-guide.md)
+ - [Development Guidelines on Video Recording](subsys-multimedia-camera-record-guide.md)
+ - [Development Guidelines on Previewing](subsys-multimedia-camera-preview-guide.md)
+ - [Audio/Video](subsys-multimedia-video.md)
+ - [Overview](subsys-multimedia-video-overview.md)
+ - [Development Guidelines on Media Playback](subsys-multimedia-video-play-guide.md)
+ - [Development Guidelines on Media Recording](subsys-multimedia-video-record-guide.md)
+- [Utils](subsys-utils.md)
+ - [Utils Overview](oem_subsys_utils_des.md)
+ - [Utils Development Guidelines](oem_subsys_utils_guide.md)
+ - [Utils FAQ](oem_subsys_utils_faq.md)
+- [AI Framework](subsys-aiframework.md)
+ - [AI Engine Framework](subsys-aiframework-guide.md)
+ - [Development Environment](subsys-aiframework-envbuild.md)
+ - [Technical Specifications](subsys-aiframework-tech.md)
+ - [Code Management](subsys-aiframework-tech-codemanage.md)
+ - [Naming](subsys-aiframework-tech-name.md)
+ - [API Development](subsys-aiframework-tech-interface.md)
+ - [Development Guidelines](subsys-aiframework-devguide.md)
+ - [SDK](subsys-aiframework-devguide-sdk.md)
+ - [Plug-in](subsys-aiframework-devguide-plugin.md)
+ - [Configuration File](subsys-aiframework-devguide-conf.md)
+ - [Development Examples](subsys-aiframework-demo.md)
+ - [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-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)
+ - [Development Guidelines](subsys-application-framework-guide.md)
+ - [Development Example](subsys-application-framework-demo.md)
+- [OTA Upgrade](subsys-ota-guide.md)
+- [Security](subsys-security.md)
+ - [Overview](subsys-security-overview.md)
+ - [Development Guidelines on Application Signature Verification](subsys-security-sigverify.md)
+ - [Development Guidelines on Application Permission Management](subsys-security-rightmanagement.md)
+ - [Development Guidelines on IPC Authentication](subsys-security-communicationverify.md)
+- [Startup](subsys-boot.md)
+ - [Startup](subsys-boot-overview.md)
+ - [init Module](subsys-boot-init.md)
+ - [appspawn Module](subsys-boot-appspawn.md)
+ - [bootstrap Module](subsys-boot-bootstrap.md)
+ - [syspara Module](subsys-boot-syspara.md)
+ - [FAQs](subsys-boot-faqs.md)
+ - [Reference](subsys-boot-ref.md)
+- [Testing](subsys-testguide-test.md)
+- [DFX](subsys-dfx.md)
+ - [DFX](subsys-dfx-overview.md)
+ - [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)
+ - [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/ai-engine-framework.md b/en/device-dev/subsystems/ai-engine-framework.md
deleted file mode 100644
index e5e3a40291288b075be04cb4d88f61e3dcabfd7f..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/ai-engine-framework.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AI Engine Framework
-
-The AI subsystem of OpenHarmony provides native distributed AI capabilities. At the heart of the subsystem is a unified AI engine framework, which implements quick integration of AI algorithm plug-ins. The framework consists of the plug-in management, module management, and communication management modules, fulfilling lifecycle management and on-demand deployment of AI algorithms. Plug-in management implements lifecycle management, on-demand deployment, and quick integration of AI algorithm plug-ins. Module management implements task scheduling and client instance management. Communication management implements inter-process communication \(IPC\) between the client and server and data transmission between the AI engine and plug-ins. Under this framework, AI algorithm APIs will be standardized to facilitate distributed calling of AI capabilities. In addition, unified inference APIs will be provided to adapt to different inference framework hierarchies. [Figure 1](#fig143186187187) shows the AI engine framework.
-
-**Figure 1** AI engine framework
-
-
-
-
diff --git a/en/device-dev/subsystems/ai-framework.md b/en/device-dev/subsystems/ai-framework.md
deleted file mode 100644
index 87f4c6a5f2656a15b063933d1556c90942520fd0..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/ai-framework.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# AI Framework
-
-- **[AI Engine Framework](ai-engine-framework.md)**
-
-- **[Development Environment](development-environment.md)**
-
-- **[Technical Specifications](technical-specifications.md)**
-
-- **[Development Guidelines](development-guidelines.md)**
-
-- **[Development Examples](development-examples.md)**
-
-
diff --git a/en/device-dev/subsystems/application-framework.md b/en/device-dev/subsystems/application-framework.md
deleted file mode 100644
index d58ed3003a09c0d1e1194097353e454d85afa061..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/application-framework.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Application Framework
-
-- **[Overview](overview-4.md)**
-
-- **[Setting Up a Development Environment](setting-up-a-development-environment.md)**
-
-- **[Development Guidelines](development-guidelines-5.md)**
-
-- **[Development Example](development-example.md)**
-
-
diff --git a/en/device-dev/subsystems/audio-video.md b/en/device-dev/subsystems/audio-video.md
deleted file mode 100644
index 16e2f5b0835dbade41d9c722ab0ff5de90d93b1f..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/audio-video.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Audio/Video
-
-- **[Overview](overview-3.md)**
-
-- **[Development Guidelines on Media Playback](development-guidelines-on-media-playback.md)**
-
-- **[Development Guidelines on Media Recording](development-guidelines-on-media-recording.md)**
-
-
diff --git a/en/device-dev/subsystems/building-guidelines-for-mini-and-small-systems.md b/en/device-dev/subsystems/building-guidelines-for-mini-and-small-systems.md
deleted file mode 100644
index d19baae14741babb44e57557e6b94a6e47401d91..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/building-guidelines-for-mini-and-small-systems.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Building Guidelines for Mini and Small Systems
-
-- **[Compilation and Building Overview](compilation-and-building-overview.md)**
-
-- **[Compilation and Building Guidelines](compilation-and-building-guidelines.md)**
-
-- **[Compilation and Building FAQ](compilation-and-building-faq.md)**
-
-
diff --git a/en/device-dev/subsystems/building-guidelines-for-the-standard-system.md b/en/device-dev/subsystems/building-guidelines-for-the-standard-system.md
deleted file mode 100644
index bbc92d83896d1912837d2d34b0791a4e47e46004..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/building-guidelines-for-the-standard-system.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Building Guidelines for the Standard System
-
-- **[Compilation and Building Overview](compilation-and-building-overview-0.md)**
-
-- **[Compilation and Building Guidelines](compilation-and-building-guidelines-1.md)**
-
-
diff --git a/en/device-dev/subsystems/bytrace-usage-guidelines.md b/en/device-dev/subsystems/bytrace-usage-guidelines.md
deleted file mode 100644
index 8219a014385d8d29fc7eecc7c5fbb6ac9671f6c3..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/bytrace-usage-guidelines.md
+++ /dev/null
@@ -1,119 +0,0 @@
-# bytrace Usage Guidelines
-
-- [Overview](#section11388623181619)
-- [Development Guidelines](#section1595564317164)
- - [bytrace Commands](#section2344125731617)
- - [Example Commands](#section5402591174)
-
-
-## Overview
-
-bytrace is a tool for you to trace processes and analyze performance. It encapsulates and extends the kernel ftrace and supports event tracking in the user space. With bytrace, you can open a user-space or kernel-space label you want to view \(run the **bytrace -l** command to query all the supported labels\) and run the **--trace\_begin** and **-o filename** \(or **--output filename**\) commands to capture traces and dump them to a specified file.
-
-## Development Guidelines
-
-### bytrace Commands
-
-bytrace supports the following commands:
-
-**Table 1** Commands
-
-
-
Option
-
-
Description
-
-
-
-
-h, --help
-
-
Views the help text for bytrace.
-
-
-
-b n, --buffer_size n
-
-
Sets the size of the buffer (KB) for storing and reading traces. The default buffer size is 2048 KB.
-
-
-
-t n, --time n
-
-
Sets the bytrace uptime in seconds, which depends on the time required for analysis.
-
-
-
--trace_clock clock
-
-
Sets the type of the clock for adding a timestamp to a trace, which can be boot (default), global, mono, uptime, or perf.
-
-
-
--trace_begin
-
-
Starts capturing traces.
-
-
-
--trace_dump
-
-
Dumps traces to a specified position (console where you run this command by default).
-
-
-
--trace_finish
-
-
Stops capturing traces and dumps traces to a specified position (console where you run this command by default).
-
-
-
-l, --list_categories
-
-
Lists the bytrace categories supported by the device.
-
-
-
--overwrite
-
-
Sets the action to take when the buffer is full. If this option is used, the latest traces are discarded; if this option is not used, the earliest traces are discarded (default).
-
-
-
-o filename, --output filename
-
-
Outputs traces to a specified file.
-
-
-
-z
-
-
Compresses a captured trace.
-
-
-
-
-
-### Example Commands
-
-The following are some examples of bytrace commands:
-
-- Run the following command to query supported labels:
-
-```
-bytrace -l
-```
-
-Alternatively, you can run the following command:
-
-```
-bytrace --list_categories
-```
-
-- Run the following command to capture traces whose label is ability, with the buffer size set to 4096 KB and bytrace uptime set to 10s:
-
-```
-bytrace -b 4096 -t 10 --overwrite ability > /data/mytrace.ftrace
-```
-
-- Run the following command to set the clock type for traces to **mono**:
-
-```
-bytrace --trace_clock mono -b 4096 -t 10 --overwrite ability > /data/mytrace.ftrace
-```
-
-- Run the following command to compress the captured trace:
-
-```
-bytrace -z -b 4096 -t 10 --overwrite ability > /data/mytrace.ftrace
-```
-
diff --git a/en/device-dev/subsystems/camera.md b/en/device-dev/subsystems/camera.md
deleted file mode 100644
index 4d38a63f4b587145b7d3fd953ae217a6576393dc..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/camera.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Camera
-
-- **[Overview](overview.md)**
-
-- **[Development Guidelines on Photographing](development-guidelines-on-photographing.md)**
-
-- **[Development Guidelines on Video Recording](development-guidelines-on-video-recording.md)**
-
-- **[Development Guidelines on Previewing](development-guidelines-on-previewing.md)**
-
-
diff --git a/en/device-dev/subsystems/code-management.md b/en/device-dev/subsystems/code-management.md
deleted file mode 100644
index 6dde40c04806b61c22c53c8192ac869fa505f094..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/code-management.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Code Management
-
-- [Recommendation: Develop plug-ins and northbound SDKs in the directories specified by the AI engine.](#section17176374131)
-- [Rule: Store all external APIs provided by plug-ins in the interfaces/kits directory of the AI subsystem.](#section2551029111312)
-- [Rule: Make sure that plug-in compilation results are stored in the /usr/lib directory.](#section97021558121310)
-
-Code of the AI engine framework consists of three parts: **client**, **server**, and **common**. The client module provides the server connection management function. The northbound SDK needs to encapsulate and call the public APIs provided by the client in the algorithm's external APIs. The server module provides functions such as plug-in loading and task management. Plug-ins are integrated using the plug-in APIs provided by the server. The common module provides platform-related operation methods, engine protocols, and tool classes for other modules.
-
-[Figure 1](#fig171811112818) shows the code dependency between modules of the AI engine framework.
-
-**Figure 1** Code dependency
-
-
-.jpg)
-
-## Recommendation: Develop plug-ins and northbound SDKs in the directories specified by the AI engine.
-
-In the overall planning of the AI engine framework, northbound SDKs are a part of the client, and plug-ins are called by the server and are considered a part of the server. Therefore, the following directories have been planned for plug-in and northbound SDK development in the AI engine framework:
-
-- SDK code directory: //foundation/ai/engine/services/client/algorithm\_sdk
-
- e.g. //foundation/ai/engine/services/client/algorithm\_sdk/cv
-
- e.g. //foundation/ai/engine/services/client/algorithm\_sdk/nlu
-
-- Plug-in code directory: //foundation/ai/engine/services/server/plugin
-
- e.g. //foundation/ai/engine/services/server/plugin/cv
-
- e.g. //foundation/ai/engine/services/server/plugin/nlu
-
-
-## Rule: Store all external APIs provided by plug-ins in the **interfaces/kits** directory of the AI subsystem.
-
-The AI subsystem exposes its capabilities through external APIs of northbound SDKs. According to API management requirements of OpenHarmony, store all external APIs of northbound SDKs in the **interfaces/kits** directory of the subsystem. Currently, the external APIs of plug-ins of the AI subsystem are stored in the following directory: **//foundation/ai/engine/interface/kits**. You can add a sub-directory for each newly added plug-in in this directory. For example, if you add a CV plug-in, then store its external APIs in the **//foundation/ai/engine/interfaces/kits/cv** directory.
-
-## Rule: Make sure that plug-in compilation results are stored in the **/usr/lib** directory.
-
-Plug-in loading on the server uses the dlopen mode and can only be performed in the **/usr/lib** directory. Therefore, when compiling the **.so** file of a plug-in, set the output directory as **/usr/lib** in the compilation configuration file.
-
diff --git a/en/device-dev/subsystems/compilation-and-building-faq.md b/en/device-dev/subsystems/compilation-and-building-faq.md
deleted file mode 100644
index 7c90a77cafe15b19f2bdcfbbc9d976158b83be9c..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/compilation-and-building-faq.md
+++ /dev/null
@@ -1,121 +0,0 @@
-# Compilation and Building FAQ
-
-- [Invalid -- w option](#section1019152312222)
-- [Ncurses library not found](#section21449422618)
-- [Mcopy not found](#section12477184992615)
-- [No riscv file or directory](#section178451337202716)
-- [No Crypto](#section1241481172819)
-- [Unexpected operator](#section3691222152919)
-
-## Invalid -- w option
-
-- **Problem**
-
- The compilation fails, and **usr/sbin/ninja: invalid option -- w** is displayed.
-
-- **Cause**
-
- The Ninja version in the compilation environment is outdated and does not support the **--w** option.
-
-- **Solution**
-
- Uninstall Ninja and GN and follow the instructions provided in [Acquiring Tools](../get-code/tool-acquisition.md) to obtain the provided compilation toolchain.
-
-
-## Ncurses library not found
-
-- **Problem**
-
- The compilation fails, and **/usr/bin/ld: cannot find -lncurses** is displayed.
-
-- **Cause**
-
- The ncurses library is not installed.
-
-- **Solution**
-
- ```
- sudo apt-get install lib32ncurses5-dev
- ```
-
-
-## Mcopy not found
-
-- **Problem**
-
- The compilation fails, and **line 77: mcopy: command not found** is displayed.
-
-- **Cause**
-
- Mcopy is not installed.
-
-- **Solution**
-
- ```
- sudo apt-get install dosfstools mtools
- ```
-
-
-## No riscv file or directory
-
-- **Problem**
-
- The compilation fails, and the following information is displayed: **riscv32-unknown-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory**.
-
-- **Cause**
-
- Permission is required to access files in the **riscv** compiler path.
-
-- **Solution**
- 1. Run the following command to query the directory where **gcc\_riscv32** is located:
-
- ```
- which riscv32-unknown-elf-gcc
- ```
-
- 2. Run the **chmod** command to change the directory permission to **755**.
-
-
-## No Crypto
-
-- **Problem**
-
- The compilation fails, and **No module named'Crypto loaded** is displayed.
-
-- **Cause**
-
- Crypto is not installed in Python 3.
-
-- **Solution**
- 1. Run the following command to query the Python version:
-
- ```
- python3 --version
- ```
-
- 2. Ensure that Python 3.7 or later is installed, and then run the following command to install pycryptodome:
-
- ```
- sudo pip3 install pycryptodome
- ```
-
-
-
-## Unexpected operator
-
-- **Problem**
-
- The compilation fails, and **xx.sh \[: xx unexpected operator** is displayed.
-
-- **Cause**
-
- The compilation environment is shell instead of bash.
-
-- **Solution**
-
- ```
- sudo rm -rf /bin/sh
- sudo ln -s /bin/bash /bin/sh
- ```
-
-
diff --git a/en/device-dev/subsystems/compilation-and-building-guidelines-1.md b/en/device-dev/subsystems/compilation-and-building-guidelines-1.md
deleted file mode 100644
index eddc2c96aaefe399e0c46c7d47eb3810ab59f67a..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/compilation-and-building-guidelines-1.md
+++ /dev/null
@@ -1,174 +0,0 @@
-# Compilation and Building Guidelines
-
-- [Directory Structure](#section56731811102915)
-- [Building](#section1069873833818)
- - [Build Command](#section2740182614395)
-
-- [How to Develop](#section4207112818418)
-
-## Directory Structure
-
-```
-/build # Primary directory
-├── config # Build configuration items
-├── core
-│ └── gn # Build entry configuration
-├── loader # Loader of module configuration, which also generates a template for the module
-├── ohos # Configuration of the process for building and packaging OpenHarmony
-│ ├── kits # Build and packaging templates and processing flow for kits
-│ ├── ndk # NDK template and processing flow
-│ ├── notice # Notice template and processing flow
-│ ├── packages # Distribution packaging template and processing flow
-│ ├── sa_profile # SA template and processing flow
-│ ├── sdk # SDK template and processing flow, which contains the module configuration in the SDK
-│ └── testfwk # Processing flow related to the test
-├── scripts # Build-related Python script
-├── templates # C/C++ build templates
-└── toolchain # Toolchain configuration
-```
-
-## Building
-
-### Build Command
-
-- Run the following command in the root directory of the source code to build the full distribution:
-
- ```
- ./build.sh --product-name {product_name}
- ```
-
- **product\_name** indicates the product supported by the current distribution, for example, Hi3516D V300.
-
- The image generated after build is stored in the **out/ohos-arm-release/packages/phone/images/** directory.
-
-- The build command supports the following options:
-
- ```
- --product-name # (Mandatory) Name of the product to build, for example, Hi3516D V300
- --build-target # (Optional) One or more build targets
- --gn-args # (Optional) One or more gn parameters
- --ccache # (Optional) Use of Ccache for build. This option takes effect only when Ccache is installed on the local PC.
- ```
-
-
-## How to Develop
-
-1. Add a module.
-
- The following steps use a custom module as an example to describe how to build the module, including build a library, an executable file, and a configuration file.
-
- The example module **partA** consists of **feature1**, **feature2**, and **feature3**. The target of **feature1** is a dynamic library, that of **feature2** is an executable file, and that of **feature3** is an etc configuration file.
-
- Add **partA** to a subsystem, for example, **subsystem\_examples** \(defined in the **test/examples/** directory\).
-
- The complete directory structure of **partA** is as follows:
-
- ```
- test/examples/partA
- ├── feature1
- │ ├── BUILD.gn
- │ ├── include
- │ │ └── helloworld1.h
- │ └── src
- │ └── helloworld1.cpp
- ├── feature2
- │ ├── BUILD.gn
- │ ├── include
- │ │ └── helloworld2.h
- │ └── src
- │ └── helloworld2.cpp
- └── feature3
- ├── BUILD.gn
- └── src
- └── config.conf
- ```
-
- Example 1: GN script \(**test/examples/partA/feature1/BUILD.gn**\) for building a dynamic library
-
- ```
- config("helloworld_lib_config") {
- include_dirs = [ "include" ]
- }
-
- ohos_shared_library("helloworld_lib") {
- sources = [
- "include/helloworld1.h",
- "src/helloworld1.cpp",
- ]
- public_configs = [ ":helloworld_lib_config" ]
- part_name = "partA"
- }
- ```
-
- Example 2: GN script \(**test/examples/partA/feature2/BUILD.gn**\) for building an executable file
-
- ```
- ohos_executable("helloworld_bin") {
- sources = [
- "src/helloworld2.cpp"
- ]
- include_dirs = [ "include" ]
- deps = [ # Dependent submodule
- "../feature1:helloworld_lib"
- ]
- external_deps = [ "partB:module1" ] # (Optional) If there is a cross-module dependency, the format is "module name: submodule name"
- install_enable = true # By default, the executable file is not installed. You need to set this parameter to true for installation.
- part_name = "partA"
- }
- ```
-
- Example 3: GN script \(**test/examples/partA/feature3/BUILD.gn**\) for building the etc configuration file \(submodule\).
-
- ```
- ohos_prebuilt_etc("feature3_etc") {
- source = "src/config.conf"
- relative_install_dir = "init" # (Optional) Directory for installing the submodule, which is relative to the default installation directory (/system/etc)
- part_name = "partA"
- }
- ```
-
- Example 4: Adding the module configuration file **test/examples/ohos.build** to the **ohos.build** file of this subsystem. Each subsystem has an **ohos.build** file in its root directory.
-
- ```
- "partA": {
- "module_list": [
- "//test/examples/partA/feature1:helloworld_lib",
- "//test/examples/partA/feature2:helloworld_bin",
- "//test/examples/partA/feature3:feature3_etc",
- ],
- "inner_kits": [
-
- ],
- "system_kits": [
-
- ],
- "test_list": [
-
- ]
- }
- ```
-
- The declaration of a module contains the following parts:
-
- - **module\_list**: submodule list of the module
- - **inner\_kits**: APIs for other modules that depend on this module through **external\_deps**
- - **system\_kits**: APIs for developers
- - **test\_list**: test cases for the submodules of the module
-
-2. Add the module to the product configuration file.
-
- Add **"subsystem\_examples:partA"** to the configuration file **productdefine/common/products/\{product-name\}.json** to build and package **partA** into the distribution.
-
-3. Build the module, including the library, executable file, and etc configuration file.
-
- For example, run the following command to build Hi3516D V300:
-
- ```
- ./build.sh --product-name Hi3516DV300 --ccache
- ```
-
-4. Obtain the build result.
-
- 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.
-
-
diff --git a/en/device-dev/subsystems/compilation-and-building-guidelines.md b/en/device-dev/subsystems/compilation-and-building-guidelines.md
deleted file mode 100644
index e89b07bebaaba173dafd27affe843b42d4e0e3f2..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/compilation-and-building-guidelines.md
+++ /dev/null
@@ -1,430 +0,0 @@
-# Compilation and Building Guidelines
-
-- [Prerequisites](#section13333171022312)
-- [How to Use the hb Command Line Tool](#section477242204612)
-- [Adding a Module](#section4207112818418)
-- [Adding a Chipset Solution](#section2737141421917)
-- [Adding a Product Solution](#section720881917199)
-
-## Prerequisites
-
-Ensure that the development environment has GN, Ninja, Python 3.7.4 or later, and hb commands. For details about installation methods, see [Basic OS Environment Setup](../quick-start/environment-setup.md).
-
-## How to Use the hb Command Line Tool
-
-hb is a command line tool for OpenHarmony to execute build commands. Common hb commands are described as follows:
-
-1. **hb set**
-
- ```
- hb set -h
- usage: hb set [-h] [-root [ROOT_PATH]] [-p]
-
- optional arguments:
- -h, --help show this help message and exit
- -root [ROOT_PATH], --root_path [ROOT_PATH]
- Set OHOS root path
- -p, --product Set OHOS board and kernel
- ```
-
- - If you run **hb set** with no argument, the default setting process starts.
- - You can run **hb set -root** _dir_ to set the root directory of the source code.
- - **hb set -p** is used to set the product to build.
-
-2. **hb env**
-
- View the current configuration.
-
- ```
- hb env
- [OHOS INFO] root path: xxx
- [OHOS INFO] board: hispark_taurus
- [OHOS INFO] kernel: liteos
- [OHOS INFO] product: ipcamera
- [OHOS INFO] product path: xxx/vendor/hisilicon/ipcamera
- [OHOS INFO] device path: xxx/device/hisilicon/hispark_taurus/sdk_linux_4.19
- ```
-
-3. **hb build**
-
- ```
- hb build -h
- usage: hb build [-h] [-b BUILD_TYPE] [-c COMPILER] [-t [TEST [TEST ...]]]
- [--dmverity] [-p PRODUCT] [-f] [-n]
- [component [component ...]]
-
- positional arguments:
- component name of the component
-
- optional arguments:
- -h, --help show this help message and exit
- -b BUILD_TYPE, --build_type BUILD_TYPE
- release or debug version
- -t [TEST [TEST ...]], --test [TEST [TEST ...]]
- compile test suit
- --dmverity Enable dmverity
- -p PRODUCT, --product PRODUCT
- build a specified product with
- {product_name}@{company}, eg: ipcamera@hisilcon
- -f, --full full code compilation
- -T [TARGET [TARGET ...]], --target [TARGET [TARGET ...]]
- Compile single target
- ```
-
- - If you run **hb build** with no argument, the previously configured code directory, product, and options are used for the build. The **-f** option will delete all products to be built, which is equivalent to running **hb clean** and **hb build**.
- - You can run **hb build** _\{module\_name\}_ to build product modules separately based on the development board and kernel set for the product, for example, **hb build kv\_store**.
- - You can run **hb build -p ipcamera@hisilicon** to skip the setting step and compile the product directly.
- - You can run **hb build** in **device/device\_company/board** to select the kernel and start the build based on the current development board and the selected kernel to generate an image that contains the kernel and driver only.
-
-4. **hb clean**
-
- Clear the build result of the product in the **out** directory, and retain the **args.gn** and **build.log** files only. To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean out/xxx/xxx**.
-
- ```
- hb clean
- usage: hb clean [-h] [out_path]
-
- positional arguments:
- out_path clean a specified path.
-
- optional arguments:
- -h, --help show this help message and exit
- ```
-
-
-## Adding a Module
-
-To add a module, determine the subsystem to which the module belongs and the module name, and then perform the following steps:
-
-1. Add the module build script after the source code development is complete.
-
- The following example adds the **BUILD.gn** script \(stored in the **applications/sample/hello\_world** directory\) to build the **hello\_world** module \(as an executable file\).
-
- ```
- executable("hello_world") {
- include_dirs = [
- "include",
- ]
- sources = [
- "src/hello_world.c"
- ]
- }
- ```
-
- The added script is used to build **hello\_world** that can run on OpenHarmony.
-
- To build the preceding module separately, select a product via the **hb set** command and run the **-T** command.
-
- ```
- hb build -f -T //applications/sample/hello_world
- ```
-
- After the module functions are verified based on the development board, perform steps 2 to 5 to configure the module for the product.
-
-2. Add the module description.
-
- The module description is stored in the **build/lite/components** directory. New modules must be added to the JSON file of the corresponding subsystem. A module description must contain the following fields:
-
- - **module**: name of the module
- - **description**: brief description of the module
- - **optional**: whether the module is optional
- - **dirs**: source code directory of the module
- - **targets**: module build entry
-
- For example, to add the **hello\_world** module to the application subsystem, add the **hello\_world** object to the **applications.json** file.
-
- ```
- {
- "components": [
- {
- "component": "hello_world",
- "description": "Hello world.",
- "optional": "true",
- "dirs": [
- "applications/sample/hello_world"
- ],
- "targets": [
- "//applications/sample/hello_world"
- ]
- },
- ...
- ]
- }
- ```
-
-3. Configure the module for the product.
-
- The **config.json** file is stored in the **vendor/company/product/** directory. The file must contain the product name, OpenHarmony version, device vendor, development board, kernel type, kernel version, and the subsystem and module to configure. The following example adds the **hello\_world** module to the **my\_product.json** configuration file:
-
- ```
- {
- "product_name": "hello_world_test",
- "ohos_version": "OpenHarmony 1.0",
- "device_company": "hisilicon",
- "board": "hispark_taurus",
- "kernel_type": "liteos_a",
- "kernel_version": "1.0.0",
- "subsystems": [
- {
- "subsystem": "applications",
- "components": [
- { "component": "hello_world", "features":[] }
- ]
- },
- ...
- ]
- }
- ```
-
-4. Build the product.
-
- 1. Run the **hb set** command in the root code directory to select the corresponding product.
-
- 2. Run the **hb build** command.
-
-
-## Adding a Chipset Solution
-
-The Compilation and Building subsystem allows you to add a chipset solution. Detailed operations are as follows:
-
-1. Create a directory for the chipset solution.
-
- Taking the RTL8720 development board of chipset provider Realtek for example, you need to run the following command in the root code directory to create a directory for the chipset solution based on [1-Configuration Rules for Modules, Chipset Solutions, and Product Solutions](compilation-and-building-overview.md#section1625463413327).
-
- ```
- mkdir -p device/realtek/rtl8720
- ```
-
-2. Create a directory for kernel adaptation and build the **config.gni** file of the development board.
-
- The following example adapts the LiteOS Cortex-M kernel to the RTL8720 development board of Realtek. The **device/realtek/rtl8720/liteos\_a/config.gni** file is configured as follows:
-
- ```
- # Kernel type, e.g. "linux", "liteos_a", "liteos_m".
- kernel_type = "liteos_a"
-
- # Kernel version.
- kernel_version = "3.0.0"
-
- # Board CPU type, e.g. "cortex-a7", "riscv32".
- board_cpu = "real-m300"
-
- # Board arch, e.g. "armv7-a", "rv32imac".
- board_arch = ""
-
- # Toolchain name used for system compiling.
- # E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang, riscv32-unknown-elf.
- # Note: The default toolchain is "ohos-clang". It's not mandatory if you use the default toochain.
- board_toolchain = "gcc-arm-none-eabi"
-
- # The toolchain path instatlled, it's not mandatory if you have added toolchian path to your ~/.bashrc.
- board_toolchain_path =
- rebase_path("//prebuilts/gcc/linux-x86/arm/gcc-arm-none-eabi/bin",
- root_build_dir)
-
- # Compiler prefix.
- board_toolchain_prefix = "gcc-arm-none-eabi-"
-
- # Compiler type, "gcc" or "clang".
- board_toolchain_type = "gcc"
-
- # Board related common compile flags.
- board_cflags = []
- board_cxx_flags = []
- board_ld_flags = []
- ```
-
-3. Build the script.
-
- Create the **BUILD.gn** file in the development board directory. The target name must be the same as that of the development board. Taking the RTL8720 development board of Realtek as an example, the content in the **device/realtek/rtl8720/BUILD.gn** file is configured as follows:
-
- ```
- group("rtl8720") { # The target can be shared_library, static_library, or an executable file.
- # Content
- ......
- }
- ```
-
-4. Build the chipset solution.
-
- Run the **hb build** command in the development board directory to start the build.
-
-
-## Adding a Product Solution
-
-The Compilation and Building subsystem supports flexible assembly of chipset solutions and modules to customize desired product solutions. The operation procedure is as follows:
-
-1. Create a product directory.
-
- Taking the Wi-Fi IoT module based on the RTL8720 development board as an example, you need to run the following command in the root code directory to create a product directory based on [1-Configuration Rules for Modules, Chipset Solutions, and Product Solutions](compilation-and-building-overview.md#section1625463413327).
-
- ```
- mkdir -p vendor/my_company/wifiiot
- ```
-
-2. Assemble the product.
-
- Create the **config.json** file in the product directory. Taking the Wi-Fi IoT module as an example, the **vendor/my\_company/wifiiot/config.json** file is as follows:
-
- ```
- {
- "product_name": "wifiiot", # Product name
- "ohos_version": "OpenHarmony 1.0", # In-use OS version
- "device_company": "realtek", # Name of the chipset solution vendor
- "board": "rtl8720", # Name of the development board
- "kernel_type": "liteos_m", # Selected kernel type
- "kernel_version": "3.0.0", # Selected kernel version
- "subsystems": [
- {
- "subsystem": "kernel", # Selected subsystem
- "components": [
- { "component": "liteos_m", "features":[] } # Selected module and its features
- ]
- },
- ...
- {
- More subsystems and modules
- }
- ]
- }
- ```
-
- Before the build, the Compilation and Building subsystem will check the validity of fields, including **device\_company**, **board**, **kernel\_type**, **kernel\_version**, **subsystem**, and **component**. The first four fields and the latter two fields must match the current chipset solution and the module description in the **build/lite/components** file, respectively.
-
-3. Implement adaptation of OS APIs.
-
- Create the **hals** directory in the product directory and store the source code as well as the build script for OS adaptation in this directory.
-
-4. Configure the system service.
-
- Create the **init\_configs** directory in the product directory and then the **init.cfg** file in the newly created directory. You can configure the system service to be started on demand.
-
-5. Configure the init process \(only for the Linux kernel\).
-
- You need to create the **etc** directory in the **init\_configs** directory, and then the **init.d** folder as well as the **fstab** file in the newly created directory. In addition, you need to create the **rcS** and **Sxxx** files in the **init.d** file and edit them based on product requirements.
-
-6. Configure the file system image \(required only for the development board that supports the file system\).
-
- Create the **fs.yml** file in the product directory and configure it as required. A typical **fs.yml** file is configured as follows:
-
- ```
- -
- fs_dir_name: rootfs # Image name
- fs_dirs:
- -
- # Copy the files in the out/my_board/my_product/bin directory to the rootfs/bin directory and ignore the .bin files related to testing.
- source_dir: bin
- target_dir: bin
- ignore_files:
- - Test.bin
- - TestSuite.bin
- -
- # Copy the files in the out/my_board/my_product/libs directory to the rootfs/lib directory, ignore all .a files, and set the permissions on the files and folders to 644 and 755, respectively.
- source_dir: libs
- target_dir: lib
- ignore_files:
- - .a
- dir_mode: 755
- file_mode: 644
- -
- source_dir: usr/lib
- target_dir: usr/lib
- ignore_files:
- - .a
- dir_mode: 755
- file_mode: 644
- -
- source_dir: config
- target_dir: etc
- -
- source_dir: system
- target_dir: system
- -
- source_dir: sbin
- target_dir: sbin
- -
- source_dir: usr/bin
- target_dir: usr/bin
- -
- source_dir: usr/sbin
- target_dir: usr/sbin
- -
- # Create an empty proc directory.
- target_dir: proc
- -
- target_dir: mnt
- -
- target_dir: opt
- -
- target_dir: tmp
- -
- target_dir: var
- -
- target_dir: sys
- -
- source_dir: etc
- target_dir: etc
- -
- source_dir: vendor
- target_dir: vendor
- -
- target_dir: storage
-
- fs_filemode:
- -
- file_dir: lib/ld-uClibc-0.9.33.2.so
- file_mode: 555
- -
- file_dir: lib/ld-2.24.so
- file_mode: 555
- -
- file_dir: etc/init.cfg
- file_mode: 400
- fs_symlink:
- -
- # Create the soft link ld-musl-arm.so.1 -> libc.so in the rootfs/lib directory.
- source: libc.so
- link_name: ${fs_dir}/lib/ld-musl-arm.so.1
- -
- source: mksh
- link_name: ${fs_dir}/bin/sh
- -
- source: mksh
- link_name: ${fs_dir}/bin/shell
- fs_make_cmd:
- # Create an ext4 image for the rootfs directory using the script.
- - ${root_path}/build/lite/make_rootfs/rootfsimg_linux.sh ${fs_dir} ext4
- -
- fs_dir_name: userfs
- fs_dirs:
- -
- source_dir: storage/etc
- target_dir: etc
- -
- source_dir: data
- target_dir: data
- fs_make_cmd:
- - ${root_path}/build/lite/make_rootfs/rootfsimg_linux.sh ${fs_dir} ext4
- ```
-
-7. Build the script.
-
- Create the **BUILD.gn** file in the product directory and build the script based on your requirements. Taking the Wi-Fi IoT module in step 1 as an example, the **BUILD.gn** is configured as follows:
-
- ```
- group("wifiiot") { # The target name must be the same as the product name.
- deps = []
- # Copy the init configuration.
- deps += [ "init_configs" ]
- # Build the hals directory.
- deps += [ "hals" ]
- # Others
- ......
- }
- ```
-
-8. Build the product.
-
- Run the **hb set** command in the root code directory to select the new product as prompted, and then run the **hb build** command to start the build.
-
-
diff --git a/en/device-dev/subsystems/compilation-and-building-overview-0.md b/en/device-dev/subsystems/compilation-and-building-overview-0.md
deleted file mode 100644
index de4d2beab9d8c3f91f9d1ff841af68e9311b0fb6..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/compilation-and-building-overview-0.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Compilation and Building Overview
-
-- [Basic Concepts](#section175012297491)
-- [Working Principles](#section193961322175011)
-- [Limitations and Constraints](#section2029921310472)
-
-The compilation and building subsystem provides a framework based on Generate Ninja \(GN\) and Ninja. This subsystem allows you to:
-
-- Build products based on different chipset platforms, for example, Hi3516D V300.
-
-- Package capabilities required by a product by assembling modules based on the product configuration.
-
-## Basic Concepts
-
-It is considered best practice to learn the following basic concepts before you start building:
-
-- **Platform**
-
- A platform is a combination of development boards and kernels.
-
- Supported subsystems and modules vary according to the platform.
-
-- **Subsystems**
-
- OpenHarmony is designed with a layered architecture, which from bottom to top consists of the kernel layer, system service layer, framework layer, and application layer. System functions are expanded by levels, from system to subsystem, and further to module. In a multi-device deployment scenario, unnecessary subsystems and modules can be excluded from the system as required. A subsystem is a logical concept and is a flexible combination of functions.
-
-- **Module**
-
- A module is a reusable software binary unit that contains source code, configuration files, resource files, and build scripts. A module can be built independently, integrated in binary mode, and then tested independently.
-
-- **GN**
-
- GN is short for Generate Ninja, which is used to generate Ninja files.
-
-- **Ninja**
-
- Ninja is a small high-speed build system.
-
-
-## Working Principles
-
-The process to build OpenHarmony is as follows:
-
-- Parsing commands: Parse the name of the product to build and load related configurations.
-- Running GN: Configure toolchains and global options based on the parsed product name and compilation type.
-- Running Ninja: Start building and generate a product distribution.
-
-## Limitations and Constraints
-
-- You must download the source code using method 3 described in [Source Code Acquisition](../get-code/source-code-acquisition.md).
-- The build environment must be Ubuntu 18.04 or later.
-- You must install the software package required for build.
-
- The installation command is as follows:
-
- ```
- sudo apt-get install binutils git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4
- ```
-
-
diff --git a/en/device-dev/subsystems/compilation-and-building-overview.md b/en/device-dev/subsystems/compilation-and-building-overview.md
deleted file mode 100644
index 8cf7a6a1c1459288b1430f022740ef3a229663dd..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/compilation-and-building-overview.md
+++ /dev/null
@@ -1,132 +0,0 @@
-# Compilation and Building Overview
-
-- [Basic Concepts](#section175012297491)
-- [Usage Guidelines](#section193961322175011)
-- [Limitations and Constraints](#section2029921310472)
-
-The compilation and building subsystem is a building framework based on Generate Ninja \(GN\) and Ninja, which supports component-based OpenHarmony development. This subsystem can be used to:
-
-- Build existing products.
-
-- Build chipset source code independently.
-- Build a single component independently.
-
-## Basic Concepts
-
-It is considered best practice to learn the following basic concepts before you start development and building:
-
-- **Component**
-
- A component is a reusable software unit that can contain source code, configuration files, resource files, and compilation scripts.
-
-- **GN**
-
- GN is short for Generate Ninja, which is used to generate Ninja files.
-
-- **Ninja**
-
- Ninja is a small high-speed building system.
-
-
-## Usage Guidelines
-
-1. **Building Process**
-
- [Figure 1](#fig9744112715161) shows the building process.
-
- **Figure 1** Building process
- 
-
- 1. **hb set**: Set the OpenHarmony source code directory and the product to build.
- 2. **hb build**: Build the product, development board, or component. The process to build the solution is as follows:
- - **Reading configuration**: Read the development board configuration, which covers the toolchain, linking commands, and compilation options.
- - **Running gn**: Run the **gn gen** command to read the product configuration \(related to the development board, kernel, and system components\) and generate the **out** directory and **ninja** files for the solution.
- - **Running Ninja**: Run **ninja -C out/company/product** to start compilation.
- - **Packaging**: Package the compilation result to create a file system image.
-
-
-2. **Building Commands**
-
- 1. **hb set**
-
- ```
- hb set -h
- usage: hb set [-h] [-root [ROOT_PATH]] [-p]
-
- optional arguments:
- -h, --help show this help message and exit
- -root [ROOT_PATH], --root_path [ROOT_PATH]
- Set OHOS root path
- -p, --product Set OHOS board and kernel
- ```
-
- - If you run **hb set** with no argument, the default setting process starts.
- - You can run **hb set -root** _dir_ to set the root directory of the source code.
- - **hb set -p** is used to set the product to compile.
-
- 2. **hb env**
-
- View the current configuration.
-
- ```
- hb env
- [OHOS INFO] root path: xxx
- [OHOS INFO] board: hispark_taurus
- [OHOS INFO] kernel: liteos
- [OHOS INFO] product: ipcamera
- [OHOS INFO] product path: xxx/vendor/hisilicon/ipcamera
- [OHOS INFO] device path: xxx/device/hisilicon/hispark_taurus/sdk_linux_4.19
- ```
-
- 3. **hb build**
-
- ```
- hb build -h
- usage: hb build [-h] [-b BUILD_TYPE] [-c COMPILER] [-t [TEST [TEST ...]]]
- [--dmverity] [-p PRODUCT] [-f] [-n]
- [component [component ...]]
-
- positional arguments:
- component name of the component
-
- optional arguments:
- -h, --help show this help message and exit
- -b BUILD_TYPE, --build_type BUILD_TYPE
- release or debug version
- -c COMPILER, --compiler COMPILER
- specify compiler
- -t [TEST [TEST ...]], --test [TEST [TEST ...]]
- compile test suite
- --dmverity Enable dmverity
- -p PRODUCT, --product PRODUCT
- build a specified product with
- {product_name}@{company}, eg: ipcamera@hisilcon
- -f, --full full code compilation
- ```
-
- - If you run **hb build** with no argument, the previously configured code directory, product, and options are used for the compilation. The **-f** option will delete all products to be compiled, which is equivalent to running **hb clean** and **hb build**.
- - You can run **hb build** _\{component\_name\}_ to compile product components separately based on the development board and kernel set for the product, for example, **hb build kv\_store**.
- - You can run **hb build -p ipcamera@hisilicon** to skip the setting step and compile the product directly.
- - You can run **hb build** in **device/device\_company/board** to select the kernel and start compilation based on the current development board and the selected kernel to generate an image that contains the kernel and driver only.
-
- 4. **hb clean**
-
- Clear the compilation result of the product in the **out** directory, and retain the **args.gn** and **build.log** files only. To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean** _xxx_**/out/**_xxx_.
-
-
- ```
- hb clean
- usage: hb clean [-h] [out_path]
-
- positional arguments:
- out_path clean a specified path.
-
- optional arguments:
- -h, --help show this help message and exit
- ```
-
-
-## Limitations and Constraints
-
-Ensure that the development environment has GN and Ninja, Python 3.7.4 and later, and hb commands. You must download the complete code before you start.
-
diff --git a/en/device-dev/subsystems/compilation-and-building.md b/en/device-dev/subsystems/compilation-and-building.md
deleted file mode 100644
index 54f18a521ee33440589cbeab2622d0969d1fb5a6..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/compilation-and-building.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Compilation and Building
-
-- **[Building Guidelines for Mini and Small Systems](building-guidelines-for-mini-and-small-systems.md)**
-
-- **[Building Guidelines for the Standard System](building-guidelines-for-the-standard-system.md)**
-
-
diff --git a/en/device-dev/subsystems/development-environment.md b/en/device-dev/subsystems/development-environment.md
deleted file mode 100644
index d8a387f47835f43689d8447fdec9a6f52d4875d3..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-environment.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Development Environment
-
-1. Prepare development boards Hi3516D V300 and Hi3518E V300.
-2. [Download the source code](https://device.harmonyos.com/en/docs/start/get-code/oem_sourcecode_guide-0000001050769927#EN-US_TOPIC_0000001050769927__section1186691118430).
-
diff --git a/en/device-dev/subsystems/development-examples.md b/en/device-dev/subsystems/development-examples.md
deleted file mode 100644
index 8c5964da0133ad046694a091a19e95eaad409ed8..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-examples.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Development Examples
-
-For your better understanding, a KWS application is used as an example to walk you through the development process. You can develop the KWS SDK and plug-in based on the AI engine framework on the Hi3516D V300 development board, compile an image for the new version, and burn the image into the version. Then, develop an application with the KWS function. The application can receive external audio and pass the audio to the SDK API. If the audio contains specified keywords, the application will be able to recognize these keywords and print them in the command line.
-
-This example uses a fixed keyword **Hi, xiaowen** for illustration. If the input audio contains **Hi, xiaowen**, the application prints **\[Hi, xiaowen\]**; otherwise, the application prints **\[UNKNOWN\]**.
-
-- **[KWS SDK](kws-sdk.md)**
-
-- **[KWS Plug-in](kws-plug-in.md)**
-
-- **[KWS Configuration File](kws-configuration-file.md)**
-
-
diff --git a/en/device-dev/subsystems/development-guidelines-5.md b/en/device-dev/subsystems/development-guidelines-5.md
deleted file mode 100644
index c86bd7b452bef75e1eeac280e801d80e36ed0d7f..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-5.md
+++ /dev/null
@@ -1,711 +0,0 @@
-# Development Guidelines
-
-- [When to Use](#section93012287133)
-- [Available APIs](#section11821047161319)
-- [How to Develop](#section10514141679)
- - [Creating a Service Ability](#section19921154214315)
- - [Development Guidelines on Bundle Management](#section1724016743217)
- - [Packing a HAP File](#section171771212328)
-
-
-## When to Use
-
-- Develop Page abilities for applications that have a UI for human-machine interaction, such as news applications, video players, navigation applications, and payment applications. Most applications we use in our daily lives are such type of applications.
-
-- Develop Service abilities for applications so that they can run particular services in the background, such as music playing, computing, and navigation services.
-
-- Pack both Page and Service abilities into HarmonyOS Ability Packages \(HAPs\). All applications must be packed into HAP files before being published to the application market. Once published, users can then download the applications from the application market.
-
-## Available APIs
-
-**Table 1** APIs of the ability management framework
-
-
-
Function
-
-
Description
-
-
-
-
Want *WantParseUri(const char *uri)
-
-
Converts a specified character string into a Want object.
-
-
-
const char *WantToUri(Want want)
-
-
Converts a specified Want object into a character string.
Sets the UI layout for the host ability of the ability slice.
-
-
-
void OnStart(const Want& want)
-
-
Called when the ability slice is started. This callback is invoked to handle transitions between ability slice lifecycle states.
-
-
-
void OnStop()
-
-
Called when the ability slice is being destroyed. This callback is invoked to handle transitions between ability slice lifecycle states.
-
-
-
void OnActive(const Want& want)
-
-
Called when the ability slice is visible to users. This callback is invoked to handle transitions between ability slice lifecycle states.
-
-
-
void OnInactive()
-
-
Called when the ability slice is invisible to users. This callback is invoked to handle transitions between ability slice lifecycle states.
-
-
-
void OnBackground()
-
-
Called when the ability slice is moved to the background. This callback is invoked to handle transitions between ability slice lifecycle states.
-
-
-
int StartAbility(const Want &want)
-
-
Starts an ability based on the specified Want information.
-
-
-
int StopAbility(const Want &want)
-
-
Stops a Service ability based on the specified Want information.
-
-
-
int TerminateAbility()
-
-
Destroys the ability.
-
-
-
int ConnectAbility(const Want &want, const IAbilityConnection &conn, void *data);
-
-
Connects to a Service ability based on the specified Want information.
-
-
-
int DisconnectAbility(const IAbilityConnection &conn)
-
-
Disconnects from a Service ability.
-
-
-
const char *GetBundleName()
-
-
Obtains the bundle name of the application to which the ability belongs.
-
-
-
const char *GetSrcPath()
-
-
Obtains the source code path of the ability.
-
-
-
const char *GetDataPath()
-
-
Obtains the data path of the ability.
-
-
-
int StartAbility(const Want *want)
-
-
Starts an Ability. This function does not need to be used in applications developed based on Ability.
-
-
-
int ConnectAbility(const Want *want, const IAbilityConnection *conn, void *data);
-
-
Connects to a Service ability based on the specified Want information. This function does not need to be used in applications developed based on Ability.
-
-
-
int DisconnectAbility(const IAbilityConnection *conn);
-
-
Disconnects from a Service ability. This function does not need to be used in applications developed based on Ability.
-
-
-
int StopAbility(const Want *want)
-
-
Stops a Service ability based on the specified Want information. This function does not need to be used in applications developed based on Ability.
-
-
-
void (*OnAbilityConnectDone)(ElementName *elementName, SvcIdentity *serviceSid, int resultCode, void *data)
-
-
Called when a client is connected to a Service ability.
-
-
-
void (*OnAbilityDisconnectDone)(ElementName *elementName, int resultCode, void *data)
-
-
Called after all connections to a Service ability are disconnected.
-
-
-
void PostTask(const Task& task)
-
-
Posts a task to an asynchronous thread.
-
-
-
void PostQuit()
-
-
Quits the event loop of the current thread.
-
-
-
static AbilityEventHandler* GetCurrentHandler()
-
-
Obtains the event handler of the current thread.
-
-
-
void Run()
-
-
Starts running the event loop of the current thread.
-
-
-
#define REGISTER_AA(className)
-
-
Registers the class name of an Ability child class.
-
-
-
#define REGISTER_AS(className)
-
-
Registers the class name of an AbilitySlice child class.
-
-
-
-
-
-## How to Develop
-
-### Creating a Service Ability
-
-1. Create the **MyServiceAbility** child class from **Ability** in **my\_service\_ability.h**.
-
- ```
- class MyServiceAbility: public Ability {
- protected:
- void OnStart(const Want& want);
- const SvcIdentity *OnConnect(const Want &want) override;
- void MsgHandle(uint32_t funcId, IpcIo *request, IpcIo *reply) override;
- };
- ```
-
-2. Call the **REGISTER\_AA** macro to register the **ServiceAbility** class with the application framework so that the framework can instantiate the **MyServiceAbility** class you have created.
-
- ```
- #include "my_service_ability.h"
-
- REGISTER_AA(ServiceAbility)
-
- void MyServiceAbility::OnStart(const Want& want)
- {
- printf("ServiceAbility::OnStart\n");
- Ability::OnStart(want);
- }
-
- const SvcIdentity *MyServiceAbility::OnConnect(const Want &want)
- {
- printf("ServiceAbility::OnConnect\n");
- return Ability::OnConnect(want);
- }
-
- void MyServiceAbility::MsgHandle(uint32_t funcId, IpcIo *request, IpcIo *reply)
- {
- printf("ServiceAbility::MsgHandle, funcId is %u\n", funcId);
- int result = 0;
- if (funcId == 0) {
- result = IpcIoPopInt32(request) + IpcIoPopInt32(request);
- }
- // push data
- IpcIoPushInt32(reply, result);
- }
- ```
-
-3. Override the following lifecycle callbacks for Service abilities to implement your own logic for your Service ability. When overriding a lifecycle callback, you must call the corresponding function from the parent class.
- - OnStart\(\)
-
- This callback is invoked when a Service ability is being created to perform Service ability initialization operations that take a short time. This callback is invoked only once in the entire lifecycle of a Service ability.
-
- ```
- void MyServiceAbility::OnStart(const Want& want)
- {
- printf("ServiceAbility::OnStart\n");
- Ability::OnStart(want);
- }
- ```
-
- - OnConnect\(\)
-
- This callback is invoked when another ability is connected to the Service ability. This callback returns an **SvcIdentity** object for the other ability to interact with the Service ability.
-
- ```
- const SvcIdentity *MyServiceAbility::OnConnect(const Want &want)
- {
- printf("ServiceAbility::OnConnect\n");
- return Ability::OnConnect(want);
- }
- ```
-
- - OnDisconnect\(\)
-
- This callback is invoked when another ability is disconnected from the Service ability.
-
- - OnStop\(\)
-
- 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**.
-
- ```
- void ServiceAbility::MsgHandle(uint32_t funcId, IpcIo *request, IpcIo *reply)
- {
- printf("ServiceAbility::MsgHandle, funcId is %d\n", funcId);
- int result = 0;
- if (funcId == PLUS) {
- result = IpcIoPopInt32(request) + IpcIoPopInt32(request);
- }
- // push data
- IpcIoPushInt32(reply, result);
- }
- ```
-
-5. Register a Service ability.
-
- Declare your Service ability in the **config.json** file by setting its **type** attribute to **service**.
-
- ```
- "abilities": [{
- "name": "ServiceAbility",
- "icon": "res/drawable/phone.png",
- "label": "test app 2",
- "launchType": "standard",
- "type": "service",
- "visible": true
- }
- ]
- ```
-
-6. Start a Service ability.
- - The **Ability** class provides the **StartAbility\(\)** function to start another ability. You can pass a **Want** object to this function to start a Service ability.
-
- You can use the **SetWantElement\(\)** function provided in the **AbilityKit** to set information about the target Service ability to start. The **element** parameter of the **SetWantElement\(\)** function indicates the **ElementName** structure that contains the bundle name and target ability name required for starting an ability.
-
- ```
- {
- Want want = { nullptr };
- ElementName element = { nullptr };
- SetElementBundleName(&element, "com.company.appname");
- SetElementAbilityName(&element, "ServiceAbility");
- SetWantElement(&want, element);
- StartAbility(want);
- ClearElement(&element);
- ClearWant(&want);
- }
- ```
-
- The **StartAbility\(\)** function is executed immediately. If the Service ability is not running while the function is called, the system invokes **OnStart\(\)** first.
-
- - Stops a Service ability.
-
- 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.
-
- ```
- {
- // Create an IAbilityConnection object and implement the two callbacks.
- IAbilityConnection abilityConnection = new IAbilityConnection();
- abilityConnection->OnAbilityConnectDone = OnAbilityConnectDone;
- abilityConnection->OnAbilityDisconnectDone = OnAbilityDisconnectDone;
-
- void OnAbilityConnectDone(ElementName *elementName, SvcIdentity *serviceSid,
- int resultCode, void *data)
- {
- if (resultCode != 0) {
- return;
- }
- // Push data.
- IpcIo request;
- char dataBuffer[IPC_IO_DATA_MAX];
- IpcIoInit(&request, dataBuffer, IPC_IO_DATA_MAX, 0);
- IpcIoPushInt32(&request, 10);
- IpcIoPushInt32(&request, 6);
-
- // Send and receive the reply.
- IpcIo reply;
- uintptr_t ptr = 0;
- if (Transact(nullptr, *serviceSid, 0, &request, &reply,
- LITEIPC_FLAG_DEFAULT, &ptr) != LITEIPC_OK) {
- printf("transact error\n");
- return;
- }
- int result = IpcIoPopInt32(&reply);
- printf("execute add method, result is %d\n", result);
- if (ptr != 0) {
- FreeBuffer(nullptr, reinterpret_cast(ptr));
- }
- }
-
- void OnAbilityDisconnectDone(ElementName *elementName,
- int resultCode, void *data)
- {
- printf("elementName is %s, %s\n",
- elementName->bundleName, elementName->abilityName);
- }
- }
- ```
-
- - The following sample code snippet shows how to initiate ability connection and disconnection:
-
- ```
- {
- // Connect an ability to a specified Service ability.
- Want want = { nullptr };
- ElementName element = { nullptr };
- SetElementBundleName(&element, "com.company.appname");
- SetElementAbilityName(&element, "ServiceAbility");
- SetWantElement(&want, element);
- ConnectAbility(want, *abilityConnection, this);
-
- // Disconnect from a Service ability.
- DisconnectAbility(*abilityConnection);
- }
- ```
-
-
-
-### Development Guidelines on Bundle Management
-
-**Installing an Application**
-
-The installation API can only be used by built-in system applications. Applications can be installed in either of the following paths:
-
-- Default installation directory **/storage/app/** in the system
-- Particular directory on the external storage, for example, a microSD card
-
-You can specify the installation path when creating an **InstallParam** instance. To install the application in the **/storage/app/** directory, set the **installLocation** member variable in the **InstallParam** instance to **INSTALL\_LOCATION\_INTERNAL\_ONLY**. To install the application in the **/sdcard/app/** directory of the external storage, set **installLocation** to **INSTALL\_LOCATION\_PREFER\_EXTERNAL**. The application installation process is asynchronous, and a semaphore-like mechanism is required to ensure that the installation callback can be executed.
-
-The procedure for installing an application is as follows \(the system directory is used as an example\):
-
-1. Place the signed HAP file in a specified directory.
-2. Create an **InstallParam** instance and define the semaphore.
-
- ```
- InstallParam installParam = {
- .installLocation = INSTALL_LOCATION_INTERNAL_ONLY, // Install the application in the system directory.
- .keepData = false
- };
- static sem_t g_sem;
- ```
-
-3. Define the callback function.
-
- ```
- static void InstallCallback(const uint8_t resultCode, const void *resultMessage)
- {
- std::string strMessage = reinterpret_cast(resultMessage);
- if (!strMessage.empty()) {
- printf("install resultMessage is %s, %d\n", strMessage.c_str(),resultCode);
- }
- sem_post(&g_sem);
- }
- ```
-
-4. Call the **Install** function.
-
- ```
- const uint32_t WAIT_TIMEOUT = 30;
- sem_init(&g_sem, 0, 0);
- std::string installPath = "/storage/bundle/demo.hap"; // Specify the path where the HAP file is stored.
- bool result = Install(installPath.c_str(), &installParam, InstallCallback);
- struct timespec ts = {};
- clock_gettime(CLOCK_REALTIME, &ts);
- ts.tv_sec += WAIT_TIMEOUT; // Release the semaphore upon timeout.
- sem_timedwait(&g_sem, &ts);
- ```
-
-
-**Uninstalling an Application**
-
-When uninstalling an application, you can specify whether to retain application data using the **keepData** member variable in the created **InstallParam** instance. If **keepData** is set to **true**, the application data will be retained after the application is uninstalled. If the variable is set to **false**, the application data will be removed during application installation.
-
-1. Create an **InstallParam** instance and define the semaphore.
-
- ```
- static sem_t g_sem;
- InstallParam installParam = {
- .installLocation = 1,
- .keepData = false // Remove application data.
- };
- ```
-
-2. Define the callback function.
-
- ```
- static void UninstallCallback(const uint8_t resultCode, const void *resultMessage)
- {
- std::string strMessage = reinterpret_cast(resultMessage);
- if (!strMessage.empty()) {
- printf("uninstall resultMessage is %s\n", strMessage.c_str());
- g_resultMessage = strMessage;
- }
- g_resultCode = resultCode;
- sem_post(&g_sem);
- }
- ```
-
-3. Call the **Uninstall** function.
-
- ```
- sem_init(&g_sem, 0, 0);
- const uint32_t WAIT_TIMEOUT = 30;
- std::string BUNDLE_NAME = "com.huawei.demo"; // Bundle name of the application to be uninstalled
- Uninstall(BUNDLE_NAME.c_str(), &installParam, UninstallCallback);
- struct timespec ts = {};
- clock_gettime(CLOCK_REALTIME, &ts);
- ts.tv_sec += WAIT_TIMEOUT;
- sem_timedwait(&g_sem, &ts);
- ```
-
-
-**Querying Bundle Information About an Installed Application**
-
-You can use the **GetBundleInfo** function provided by **BundleManager** to query the bundle information about installed applications in the system.
-
-1. Create and initialize a **BundleInfo** object.
-
- ```
- BundleInfo bundleInfo;
- (void) memset_s(&bundleInfo, sizeof(BundleInfo), 0, sizeof(BundleInfo));
- ```
-
-2. Call **GetBundleInfo** to obtain bundle information about a specified application. The **bundleName** parameter indicates the pointer to the application bundle name, and the **flags** parameter specifies whether the obtained **BundleInfo** object can contain **AbilityInfo**.
-
- ```
- std::string BUNDLE_NAME = "com.huawei.demo";
- uint8_t ret = GetBundleInfo(BUNDLE_NAME.c_str(), 1, &bundleInfo); // When flags is set to 1, the obtained BundleInfo object contains AbilityInfo.
- ```
-
-3. After you finish using the obtained **BundleInfo** object, clear the memory space occupied by the object in a timely manner to prevent memory leakage.
-
- ```
- ClearBundleInfo(&bundleInfo);
- ```
-
-
-### Packing a HAP File
-
-The packing tool is generally integrated into the development tool or IDE, and you rarely have the occasion to use it directly. This section is provided for you to have a general knowledge of the packing tool. The JAR file of the packing tool is stored in the **developtools/packing\_tool/jar** directory of the open-source code.
-
-- CLI command parameters for packing a HAP file
-
- **Table 2** Description of resource files required for packing
-
-
-
Command Parameter
-
-
Resource File
-
-
Description
-
-
Initial Value Allowed
-
-
-
-
--mode
-
-
-
-
-
This parameter is set to hap for packing the resource files into a HAP file.
-
-
No
-
-
-
--json-path
-
-
Configuration file config.json
-
-
-
-
-
No
-
-
-
--resources-path
-
-
Resource file resources
-
-
-
-
-
Yes
-
-
-
--assets-path
-
-
Resource file assets
-
-
-
-
-
Yes
-
-
-
--lib-path
-
-
Dependent library file
-
-
-
-
-
Yes
-
-
-
--shared-libs-path
-
-
Shared library file
-
-
The shared library is used by system applications in special cases.
-
-
Yes
-
-
-
--ability-so-path
-
-
SO file providing main functionality
-
-
-
-
-
Yes
-
-
-
--index-path
-
-
Resource index
-
-
The resource index file is generated by the resource generation tool and integrated by the resource pipeline.
-
-
Yes
-
-
-
--out-path
-
-
-
-
-
This parameter indicates the output path of the generated HAP file. The default value is the current directory.
-
-
Yes
-
-
-
--force
-
-
-
-
-
This parameter specifies whether to overwrite an existing file with the same name. The default value is false.
-
-
Yes
-
-
-
-
-
-- Example HAP File Structure
- - Development view
-
- 
-
- - Compilation view
-
- 
-
- - Run the following commands to pack a HAP file using the packing tool.
-
- 
-
- ```
- $ java -jar hmos_app_packing_tool.jar --mode hap --json-path ./config.json --assets-path ./assets/ --ability-so-path ./libentry.so --index-path ./resources.index --out-path out/entry.hap --force true
- ```
-
-
-
diff --git a/en/device-dev/subsystems/development-guidelines-on-animators.md b/en/device-dev/subsystems/development-guidelines-on-animators.md
deleted file mode 100644
index 0065d820ba5bfe7bd36471475366e9a335908c26..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-animators.md
+++ /dev/null
@@ -1,190 +0,0 @@
-# Development Guidelines on Animators
-
-- [When to Use](#section726685714018)
-- [Available APIs](#section85794718418)
-- [How to Develop](#section14101161317435)
-
-## When to Use
-
-A UI animator is implemented by calling the callback function you set for each tick using the task processing mechanism. The following classes are provided for you to implement an animator:
-
-- **AnimatorManager**: Manages Animator instances. This is a singleton class, which is registered with the system task callback when the **Init** function is executed. The system task mechanism ensures that each tick invokes the callback function of **AnimatorManager**.
-- **Animator**: Represents animator-related attributes, including the start and end time of an animator. It also provides animator-specific functions, for example, to start and stop an animator, to set the animator state, and to obtain the animator.
-- **AnimatorCallback**: Implements the content of each tick. You need to implement your own logic in this callback class so that the desired operation is executed upon the corresponding callback is invoked.
-
-## Available APIs
-
-**Table 1** Available functions for an animator
-
-
-
Module
-
-
Function
-
-
Description
-
-
-
-
Animator
-
-
void Start ()
-
-
Starts an animator.
-
-
-
Animator
-
-
void Stop ()
-
-
Stops the animator.
-
-
-
Animator
-
-
void Pause ()
-
-
Pauses the animator.
-
-
-
Animator
-
-
void Resume ()
-
-
Resumes the animator.
-
-
-
Animator
-
-
uint8_t GetState () const
-
-
Obtains the current state of the animator.
-
-
-
Animator
-
-
void SetState (uint8_t state)
-
-
Sets the current state for the animator.
-
-
-
Animator
-
-
uint32_t GetTime () const
-
-
Obtains the total duration of the animator.
-
-
-
Animator
-
-
void SetTime (uint32_t time)
-
-
Sets the total duration for the animator.
-
-
-
Animator
-
-
uint32_t GetRunTime () const
-
-
Obtains the running time of the animator.
-
-
-
Animator
-
-
void SetRunTime (uint32_t runTime)
-
-
Sets the running time for the animator.
-
-
-
Animator
-
-
bool IsRepeat () const
-
-
Checks whether the animator is repeated.
-
-
-
AnimatorCallback
-
-
virtual void Callback (UIView *view)=0
-
-
Represents the animator callback. You can implement your own logic in this callback.
-
-
-
AnimatorCallback
-
-
virtual void OnStop(UIView& view) {}
-
-
Called after the animator stops. You can implement your own logic in this callback.
-
-
-
AnimatorManager
-
-
static AnimatorManager* GetInstance()
-
-
Obtains an AnimatorManager instance.
-
-
-
AnimatorManager
-
-
void Add (Animator *animator)
-
-
Adds an animator.
-
-
-
AnimatorManager
-
-
void Remove(const Animator* animator);
-
-
Removes the animator.
-
-
-
-
-
-## How to Develop
-
-1. Implement the callback in **AnimatorCallback**.
-
- ```
- class AnimatorCallbackDemo : public OHOS::AnimatorCallback {
- public:
- AnimatorCallbackDemo(int16_t startPos, int16_t endPos, uint16_t time)
- : start_(startPos), end_(endPos), time_(time), curTime_(0) {}
-
- virtual void Callback(OHOS::UIView* view)
- {
- curTime_++;
- int16_t pos = EasingEquation::CubicEaseIn(start_, end_, curTime_, time_);
- view->Invalidate();
- view->SetPosition(pos, view->GetY());
- view->Invalidate();
- }
- protected:
- int16_t start_;
- int16_t end_;
- uint16_t time_;
- uint16_t curTime_;
- };
- ```
-
-2. Register **AnimatorCallback** to the animator.
-
- ```
- UIImageView* image = new UIImageView();
- image->SetSrc("..\\config\\images\\A021_001.bin");
- image->SetPosition(0, 50);
- AnimatorCallbackDemo* callback = new AnimatorCallbackDemo(0, 338, 60);
- Animator* animator = new Animator(callback, image, 0, true);
- ```
-
-3. Add the animator to **AnimatorManager**.
-
- ```
- AnimatorManager::GetInstance()->Add(animator);
- ```
-
-4. Click the buttons in the lower part of the following figure to verify that the animation effects are as expected.
-
- **Figure 1** Animator effect
- 
-
-
diff --git a/en/device-dev/subsystems/development-guidelines-on-application-permission-management.md b/en/device-dev/subsystems/development-guidelines-on-application-permission-management.md
deleted file mode 100644
index a72a6f889379575bf8b00bf351a3b0a6e539dd9b..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-application-permission-management.md
+++ /dev/null
@@ -1,228 +0,0 @@
-# Development Guidelines on Application Permission Management
-
-- [How Application Permission Management Works](#section193961322175011)
-- [When to Use](#section18502174174019)
-- [Available APIs](#section1633115419401)
-- [How to Develop](#section022611498210)
-
-## How Application Permission Management Works
-
-OpenHarmony allows users to install third-party applications and controls calls made by third-party applications to sensitive permissions. When developing an application, you need to declare the sensitive permissions that the application may require in the **profile.json** file. The permissions include static and dynamic ones. Static permissions need to be registered during application installation, and dynamic permissions can be obtained only upon user authorization. Authorization modes include system settings, manual authorization by applications, and others. In addition, application signature control is used to ensure that the application installation package has been confirmed by the device vendor.
-
-**Table 1** OpenHarmony permissions
-
-
-
OpenHarmony Permission
-
-
Grant Mode
-
-
Description
-
-
-
-
ohos.permission.LISTEN_BUNDLE_CHANGE
-
-
system_grant (static permission)
-
-
Allows an application to listen for application changes.
-
-
-
ohos.permission.GET_BUNDLE_INFO
-
-
system_grant (static permission)
-
-
Allows an application to obtain information about other applications.
-
-
-
ohos.permission.INSTALL_BUNDLE
-
-
system_grant (static permission)
-
-
Allows an application to install other applications.
-
-
-
ohos.permission.CAMERA
-
-
user_grant (dynamic permission)
-
-
Allows an application to use the camera to take photos and record videos at any time.
-
-
-
ohos.permission.MODIFY_AUDIO_SETTINGS
-
-
system_grant (static permission)
-
-
Allows an application to modify global audio settings, such as the volume and speaker for output.
-
-
-
ohos.permission.READ_MEDIA
-
-
user_grant (dynamic permission)
-
-
Allows an application to read users' favorite videos.
-
-
-
ohos.permission.MICROPHONE
-
-
user_grant (dynamic permission)
-
-
Allows an application to use the microphone for audio recording at any time.
-
-
-
ohos.permission.WRITE_MEDIA
-
-
user_grant (dynamic permission)
-
-
Allows an application to write users' favorite music.
-
-
-
ohos.permission.DISTRIBUTED_DATASYNC
-
-
user_grant (dynamic permission)
-
-
Allows an application to manage distributed data transmission.
-
-
-
ohos.permission.DISTRIBUTED_VIRTUALDEVICE
-
-
user_grant (dynamic permission)
-
-
Allows an application to use distributed virtualization features.
-
-
-
-
-
-> **NOTE:**
->Static permission: a permission granted by the system during application installation. The sensitivity level of this type of permission is **system\_grant**.
->Dynamic permission: a permission granted by users during application running. The sensitivity level of this type of permission is **user\_grant**.
-
-## When to Use
-
-Application permissions are used to control access to system resources and features. In scenarios where an application wants to access features or data related to users' privacy, such as accessing hardware features of personal devices like cameras and microphones, and reading and writing media files, OpenHarmony uses the application permission management component to protect such features and data.
-
-When developing a system application that requires a sensitive permission, you can call the corresponding API of the application permission management component to check whether the required permission is granted. If the permission is not granted, the application cannot use it.
-
-## Available APIs
-
-The following table lists the APIs available for application permission management. These APIs are only intended for system applications and services.
-
-**Table 2** APIs available for application permission management
-
-
-
Function
-
-
Description
-
-
-
-
int CheckPermission(int uid, const char *permissionName)
-
-
Checks whether the application with a specified UID has the permission to access system service APIs.
-
-
-
int CheckSelfPermission(const char *permissionName)
-
-
Checks whether the caller has the permission to access system service APIs.
-
-
-
int QueryPermission(const char *identifier, PermissionSaved **permissions, int *permNum)
-
-
Queries all permissions requested by the application and checks whether the requested permissions have been granted.
-
-
-
int GrantPermission(const char *identifier, const char *permName)
-
-
Grants a specified permission to the application.
-
-
-
int RevokePermission(const char *identifier, const char *permName)
-
-
Revokes a specified permission from the application.
-
-
-
int GrantRuntimePermission(int uid, const char *permissionName)
-
-
Grants a specified runtime permission to the application.
-
-
-
int RevokeRuntimePermission(int uid, const char *permissionName)
-
-
Revokes a specified runtime permission from the application.
-
-
-
-
-
-## How to Develop
-
-This section uses the BMS as an example to describe the application permission development. Before starting development, you need to declare the required sensitive permissions in the **config.json** file. During application installation, the BMS calls APIs of the application permission management component to check whether the required permissions have been granted. If yes, the installation proceeds; if not, the installation fails.
-
-1. Declare the required permission \(**ohos.permission.INSTALL\_BUNDLE**\) in the **config.json** file.
-
- ```
- {
- ...
- "module": {
- "package": "com.huawei.kitframework",
- "deviceType": [
- "phone", "tv","tablet", "pc","car","smartWatch","sportsWatch","smartCamera", "smartVision"
- ],
- "reqPermissions": [{
- // Declare the ohos.permission.INSTALL_BUNDLE permission required for installing the application.
- "name": "ohos.permission.INSTALL_BUNDLE",
- "reason": "install bundle",
- "usedScene": {
- "ability": [
- "KitFramework"
- ],
- "when": "always"
- }
- },
- {
- "name": "ohos.permission.LISTEN_BUNDLE_CHANGE",
- "reason": "install bundle",
- "usedScene": {
- "ability": [
- "KitFramework"
- ],
- "when": "always"
- }
- },
- {
- "name": "ohos.permission.GET_BUNDLE_INFO",
- "reason": "install bundle",
- "usedScene": {
- "ability": [
- "KitFramework"
- ],
- "when": "always"
- }
- }
- ],
- ...
- }
- ```
-
-2. The BMS calls the corresponding API of the application permission management component \(for example, the **CheckPermission** function with **ohos.permission.INSTALL\_BUNDLE** as an input parameter\) to check whether the BMS has the permission to install the application. If yes, the installation proceeds; if not, the installation fails.
-
- ```
- constexpr static char PERMISSION_INSTALL_BUNDLE[] = "ohos.permission.INSTALL_BUNDLE";
-
- bool Install(const char *hapPath, const InstallParam *installParam, InstallerCallback installerCallback)
- {
- if ((hapPath == nullptr) || (installerCallback == nullptr) || (installParam == nullptr)) {
- HILOG_ERROR(HILOG_MODULE_APP, "BundleManager install failed due to nullptr parameters");
- return false;
- }
- // Check whether the ohos.permission.INSTALL_BUNDLE permission has been granted.
- if (CheckPermission(0, static_cast(PERMISSION_INSTALL_BUNDLE)) != GRANTED) {
- HILOG_ERROR(HILOG_MODULE_APP, "BundleManager install failed due to permission denied");
- return false; // Application installation fails.
- }
- // Application installation process
- ...
- }
- ```
-
-
diff --git a/en/device-dev/subsystems/development-guidelines-on-application-signature-verification.md b/en/device-dev/subsystems/development-guidelines-on-application-signature-verification.md
deleted file mode 100644
index 8c477a78d351c4f2622dd27dc6b065bcbdfad98a..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-application-signature-verification.md
+++ /dev/null
@@ -1,272 +0,0 @@
-# Development Guidelines on Application Signature Verification
-
-- [When to Use](#section18502174174019)
-- [Signature Verification Process](#section554632717226)
-- [Available APIs](#section1633115419401)
-- [Development Procedure \(Scenario 1\)](#section4207112818418)
- - [Signature Verification](#section11470123816297)
- - [OpenHarmony Self-signed Application Generation](#section167151429133312)
- - [Development Examples](#section174318361353)
-
-- [Development Procedure \(Scenario 2\)](#section81272563427)
- - [Signature Verification](#section07028210442)
- - [Development Examples](#section1930711345445)
-
-- [Debugging and Verification](#section427316292411)
-
-## When to Use
-
-You can call the APIs provided by the signature verification component to check integrity of a debugging, released, or OpenHarmony self-signed application. You can also call APIs of the signature verification component to obtain some information in the profile, for example, **appid**. In addition, you can call APIs to check whether the UDID of a debugging application matches that of the device to ensure that the application is installed on the right device.
-
-## Signature Verification Process
-
-An unsigned HAP is in **.zip** format and consists of a file block, central directory, and end of central directory \(EOCD\).
-
-After the HAP is signed, a signature block is added between the file block and the central directory. The signature block consists of a file signature block, profile signature block, and signature header. The following figure shows the structure of a signed HAP.
-
-**Figure 1** Structure of a signed HAP
-
-
-
-
-The signature verification process consists of three steps: HAP signature verification, signature verification for the profile signature block, and profile content verification.
-
-**HAP signature verification**
-
-Use the preset root certificate of the device and the certificate chain to prove that the leaf certificate is trusted. Then use the digest obtained by decrypting the public key of the leaf certificate to prove that the HAP is not tampered with.
-
-The process is as follows:
-
-1. Use the preset root certificate of the device to verify the certificate chain in the file signature block and prove that the leaf certificate is trusted.
-2. Use the public key in the leaf certificate to verify the file signature block and prove that this block is not tampered with.
-3. Calculate and merge the digests of the file block, central directory, and EOCD. Merge the calculation result with the digest of the profile signature block in the signature block. Then compare the merge result with the digest of the file signature block. If they are the same, the HAP signature verification is successful.
-
-**Signature verification for the profile signature block**
-
-First of all, check who issued the signature of the profile signature block. If the signature was issued by the application market, the signature is trusted and does not need to be verified. Otherwise, the signature needs to be verified. Next, verify the certificate chain and then use the leaf certificate to verify the signature of the profile signature block to prove that it is not tampered with.
-
-**Profile content verification**
-
-Obtain the profile and check the validity of its content. If the HAP is a debugging application, check whether the UDID of the current device is contained in the UDID list in the profile. If yes, the verification is successful. Then compare the certificate in the profile with the leaf certificate used for HAP verification \(this is not required for a released or OpenHarmony self-signed application\). If they are the same, the entire signature verification process is complete.
-
-## Available APIs
-
-The following table lists the innerkits APIs provided by the signature verification component. These APIs are available only for system applications.
-
-**Table 1** APIs provided by the signature verification component
-
-
-
Function
-
-
Description
-
-
-
-
int APPVERI_AppVerify(const char *filePath, VerifyResult *verifyRst)
-
-
Verifies a signature by specifying the file path and returns the data obtained from the profile to the caller through verifyRst. This is the main entry function.
-
-
-
int APPVERI_SetDebugMode(bool mode)
-
-
Sets the debugging mode. If mode is set to true, certificate chain verification based on the debugging root key is enabled; if mode is set to false, it is disabled.
-
Note: Currently, no certificate based on the existing debugging root key is available. You can replace the debugging root key and perform related verification as required.
-
-## Development Procedure \(Scenario 1\)
-
-### Signature Verification
-
-To verify applications released in the application market, debugging applications signed with debugging certificates of the application market, and OpenHarmony self-signed applications, perform the following steps:
-
-1. Construct the VerifyResult structure.
-
- ```
- VerifyResult verifyResult = {0};
- ```
-
-2. Call the APPVERI\_AppVerify function by specifying the file path and VerifyResult to verify the application signature.
-
- ```
- int32_t ret = APPVERI_AppVerify(hapFilepath.c_str(), &verifyResult);
- ```
-
-3. Check the returned result. If the verification is successful, obtain and process the data in VerifyResult.
-
- ```
- signatureInfo.appId = verifyResult.profile.appid;
- signatureInfo.provisionBundleName = verifyResult.profile.bundleInfo.bundleName;
- ```
-
-4. Call the APPVERI\_FreeVerifyRst function to release memory in VerifyResult.
-
- ```
- APPVERI_FreeVerifyRst(&verifyResult);
- ```
-
-
-### OpenHarmony Self-signed Application Generation
-
-The procedure is as follows:
-
-1. Prepare required materials.
-
- Prepare the signature tool, system application HAP, system application profile \(\*.p7b\), signing certificate \(\*.cer\), and signing public/private key pair \(\*.jks\).
-
-2. Place all the materials in the same directory and start the shell.
-3. Run the following command in the shell to sign the application:
-
- ```
- 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
- ```
-
- Key fields:
-
- **-jar**: signature tool, which is **[hapsigntool](https://repo.huaweicloud.com/harmonyos/develop_tools/hapsigntoolv2.jar)**
-
- **-mode**: local signature flag, which is fixed at **localjks**
-
- **-privatekey**: alias of the public/private key pair, which is **OpenHarmony Software Signature**
-
- **-inputFile**: application to be signed, which is generated through compilation
-
- **-outputFile**: signed application
-
- **-signAlg**: signing algorithm, which is fixed at **SHA256withECDSA**
-
- **-keystore**: public/private key pair, which is [OpenHarmony.jks](https://gitee.com/openharmony/security_appverify/blob/master/interfaces/innerkits/appverify_lite/OpenHarmonyCer/OpenHarmony.jks) in the **OpenHarmonyCer** directory of the **security\_services\_app\_verify** repository. The default password is **123456**. You can use a tool \(such as keytool\) to change the password.
-
- **-keystorepasswd**: password of the public/private key pair, which is **123456** by default
-
- **-keyaliaspasswd**: password of the public/private key pair alias, which is **123456** by default
-
- **-profile**: application profile, which is stored in the code directory
-
- **-certpath**: signing certificate, which is [OpenHarmony.cer](https://gitee.com/openharmony/security_appverify/blob/master/interfaces/innerkits/appverify_lite/OpenHarmonyCer/OpenHarmony.cer) in the **OpenHarmonyCer** directory of the **security\_services\_app\_verify** repository.
-
- **-profileSigned**: whether the signature block contains the profile. The value is fixed at **1**, indicating that the signature block contains the profile.
-
-
-### Development Examples
-
-The following example describes how the application management framework component verifies the signature of an application during its installation.
-
-```
-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);
- // Construct the VerifyResult structure.
- VerifyResult verifyResult = {0};
- // Verify the signature by specifying the file path.
- int32_t ret = APPVERI_AppVerify(hapFilepath.c_str(), &verifyResult);
- uint8_t errorCode = SwitchErrorCode(ret);
- if (errorCode != ERR_OK) {
- return errorCode;
- }
- // Obtain appid from the VerifyResult structure.
- signatureInfo.appId = verifyResult.profile.appid;
- // Obtain the application name written in the profile from the VerifyResult structure.
- 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]);
- }
- // Release memory in VerifyResult.
- APPVERI_FreeVerifyRst(&verifyResult);
- return ERR_OK;
-}
-```
-
-## Development Procedure \(Scenario 2\)
-
-### Signature Verification
-
-To verify applications signed with certificates that are based on debugging root keys, perform the following steps:
-
-1. Call the APPVERI\_SetDebugMode\(true\) function to enable the debugging mode.
-
- ```
- 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. Construct the **VerifyResult** structure, verify the application signature, and release memory in **VerifyResult**.
-3. Call the APPVERI\_SetDebugMode\(false\) function to disable the debugging mode.
-
- ```
- ManagerService::SetDebugMode(false);
- ```
-
-
-### Development Examples
-
-The following is the example code \(supplemented based on the example code for scenario 1\):
-
-```
-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)
-{
- // Enable debugging mode.
- ManagerService::SetDebugMode(true);
- bool mode = ManagerService::GetInstance().IsDebugMode();
- HILOG_INFO(HILOG_MODULE_APP, "current mode is %d!", mode);
- // Construct the VerifyResult structure.
- VerifyResult verifyResult = {0};
- // Verify the signature by specifying the file path.
- int32_t ret = APPVERI_AppVerify(hapFilepath.c_str(), &verifyResult);
- uint8_t errorCode = SwitchErrorCode(ret);
- if (errorCode != ERR_OK) {
- return errorCode;
- }
- // Obtain appid from the VerifyResult structure.
- signatureInfo.appId = verifyResult.profile.appid;
- // Obtain the application name written in the profile from the VerifyResult structure.
- 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]);
- }
- // Release memory in VerifyResult.
- APPVERI_FreeVerifyRst(&verifyResult);
- // Disable debugging mode.
- ManagerService::SetDebugMode(false);
- return ERR_OK;
-}
-```
-
-## Debugging and Verification
-
-1. Choose an application that can be properly installed on OpenHarmony.
-2. Develop the application based on the development guidelines.
-3. Use a self-developed program to verify the signature of the developed application. If the verification is successful and **appid** can be obtained, the development is successful.
-
diff --git a/en/device-dev/subsystems/development-guidelines-on-common-components.md b/en/device-dev/subsystems/development-guidelines-on-common-components.md
deleted file mode 100644
index 556f8ee94d54b0a738d66544522f3ee30424075e..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-common-components.md
+++ /dev/null
@@ -1,555 +0,0 @@
-# Development Guidelines on Common Components
-
-- [UIButton](#section145353310214)
-- [When to Use](#section1169616141577)
-- [Available APIs](#section341211538315)
-- [How to Develop](#section22501726193214)
-- [UIImageView](#section19523161611259)
-- [When to Use](#section1274484210400)
-- [Available APIs](#section74981992411)
-- [How to Develop \(Adaptive Mode\)](#section144341333134114)
-- [How to Develop \(Tile Mode\)](#section97178160421)
-- [UILabel](#section16588132012911)
-- [When to Use](#section6870195634218)
-- [Available APIs](#section2012714510433)
-- [How to Develop \(Default Mode\)](#section83221538114410)
-- [How to Develop \(Background Color and Opacity\)](#section933360204510)
-- [How to Develop \(Letter Spacing\)](#section19447826124518)
-- [How to Develop \(Size-Adaptive Mode\)](#section101711842154617)
-- [How to Develop \(Ellipsis Mode\)](#section1249519410471)
-- [How to Develop \(Scrolling Mode\)](#section15643122618478)
-
-Common components inherit from the base class **UIView**. Child components cannot be added to common components, such as buttons, images, and labels.
-
-**Figure 1** Tree structure of common components
-
-
-**UIView** is a base class of the following components: **UIAbstractProgress**, **UIArcLabel**, **UIButton**, **UICanvas**, **UILabel**, and **UIImageView**. **UIBoxProgress** and **UICircleProgress** inherit from **UIAbstractProgress**. **UILabelButton** and **UIRepeatButton** inherit from **UIButton**. **UIImageAnimatorView** and **UITextureMapper** inherit from **UIImageView**.
-
-## UIButton
-
-## When to Use
-
-**UIButton** supports the click event and allows you to set styles in different states.
-
-## Available APIs
-
-**Table 1** Available functions in UIButton
-
-
-
Sets the style for the button in a specified state.
-
-
-
void Disable ()
-
-
Disables the button.
-
-
-
void Enable ()
-
-
Enables the button.
-
-
-
-
-
-## How to Develop
-
-1. Implement the click event.
-
- ```
- class TestBtnOnClickListener : public OHOS::UIView::OnClickListener {
- bool OnClick(UIView& view, const ClickEvent& event) override
- {
- int16_t width = view.GetWidth() + 10;
- int16_t height = view.GetHeight() + 10;
- view.Resize(width, height);
- view.Invalidate();
- return true;
- }
- };
- ```
-
-2. Create a **UIButton** instance.
-
- ```
- UIButton* button = new UIButton();
- button->SetPosition(50, 50);
- button->SetWidth(100);
- button->SetHeight(50);
- ```
-
-3. Register the click event callback for **UIButton**.
-
- ```
- button->SetOnClickListener(new TestBtnOnClickListener());
- ```
-
-4. Verify that the button is clicked and its size increases gradually, as shown in the following figure.
-
- **Figure 2** Effect of clicking a **UIButton**
- 
-
-
-## UIImageView
-
-## When to Use
-
-**UIImageView** supports the functions to display images, set opacity, rotate images, and zoom in or out images. The following image formats are supported: RGB565, RGB888, RGBA8888, PNG, and JPG.
-
-## Available APIs
-
-**Table 2** Available functions in UIImageView
-
-
-
Function
-
-
Description
-
-
-
-
void SetSrc (const char *src)
-
-
Sets the image path with binary data.
-
-
-
void SetSrc (const ImageInfo *src)
-
-
Sets the pointer to image information.
-
-
-
void SetAutoEnable (bool enable)
-
-
Sets whether the component size adapts to the image size.
-
-
-
const void* GetSrcType () const
-
-
Obtains the image type.
-
-
-
bool GetAutoEnable () const
-
-
Checks whether the component size adapts to the image size.
-
-## How to Develop \(Adaptive Mode\)
-
-1. Create a **UIImageView** instance.
-
- ```
- UIImageView* imageView = new UIImageView();
- imageView->SetPosition(0, 30);
- ```
-
-2. Set the image path with binary data.
-
- ```
- imageView->SetSrc("..\\config\\images\\A021_001.bin");
- ```
-
-3. Verify that the **UIImageView** component is adaptive to the image.
-
- **Figure 3** Image auto-adaption effect
- 
-
-
-## How to Develop \(Tile Mode\)
-
-1. Create a **UIImageView** instance.
-
- ```
- UIImageView* imageView = new UIImageView();
- imageView->SetPosition(0, 30);
- ```
-
-2. Set the image path.
-
- ```
- imageView->SetSrc("..\\config\\images\\A021_001.bin");
- ```
-
-3. Disable the image auto-adaptation effect and resize the image to display the image in tile mode.
-
- ```
- imageView->SetAutoEnable(false);
- imageView->Resize(454, 150);
- ```
-
-4. Verify that the tile mode has been enabled for the **UIImageView**.
-
- **Figure 4** Image tile effect
- 
-
-
-## UILabel
-
-## When to Use
-
-**UILabel** displays text in an area. You can set the background color, text display style, and long text display effect for a label.
-
-## Available APIs
-
-**Table 3** Available functions in UILabel
-
-
-
Sets the enumerated value of the text rotation angle.
-
-
-
LabelRotateDegree GetTextRotation() const
-
-
Obtains the enumerated value of the text rotation angle.
-
-
-
uint16_t GetTextRotateDegree() const
-
-
Obtains the number of text rotation degrees.
-
-
-
-
-
-## How to Develop \(Default Mode\)
-
-1. Create a **lUILabel** instance and set its size and position.
-
- ```
- UILabel* label = new UILabel();
- label->SetPosition(x, y);
- label->Resize(width, height);
- ```
-
-2. Set the font.
-
- ```
- label->SetFont("SourceHanSansSC-Regular.otf", 30);
- ```
-
-3. Set the text.
-
- ```
- label->SetText("label");
- ```
-
-4. Verify the label size and display effect, as shown in the following figure.
-
- 
-
-
-## How to Develop \(Background Color and Opacity\)
-
-1. Create a **lUILabel** instance and set its size and position.
-
- ```
- UILabel* label = new UILabel();
- label->SetPosition(x, y);
- label->Resize(width, height);
- ```
-
-2. Set the font.
-
- ```
- label->SetFont("SourceHanSansSC-Regular.otf", 30);
- ```
-
-3. Set the background color and opacity.
-
- ```
- label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
- label->SetStyle(STYLE_BACKGROUND_OPA, 127);
- label->SetText("Label");
- ```
-
-4. Verify that the background color of the label is **Gray**, as shown in the following figure.
-
- 
-
-
-## How to Develop \(Letter Spacing\)
-
-1. Create a **lUILabel** instance and set its size and position.
-
- ```
- UILabel* label = new UILabel();
- label->SetPosition(x, y);
- label->Resize(width, height);
- ```
-
-2. Set the font.
-
- ```
- label->SetFont("SourceHanSansSC-Regular.otf", 30);
- ```
-
-3. Set the font color and letter spacing.
-
- ```
- label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
- label->SetStyle(STYLE_LETTER_SPACE, 5);
- label->SetText("Label");
- ```
-
-4. Verify that the letter spacing is **5** pixels on the label, as shown in the following figure.
-
- 
-
-
-## How to Develop \(Size-Adaptive Mode\)
-
-Regarding too long text, the size of a label can be automatically adjusted based on the text, or the text can be truncated or displayed with the scrolling effect.
-
-1. Create a **lUILabel** instance and set its size and position.
-
- ```
- UILabel* label = new UILabel();
- label->SetPosition(x, y);
- label->Resize(width, height);
- ```
-
-2. Set the font.
-
- ```
- label->SetFont("SourceHanSansSC-Regular.otf", 30);
- ```
-
-3. Set the font color to **Gray** and enable the label size to adapt to the text.
-
- ```
- label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
- label->SetLineBreakMode(UILabel::LINE_BREAK_ADAPT);
- label->SetText("123\n567890");
- ```
-
-4. Verify that the label size adapts to the text, as shown in the following figure.
-
- 
-
-
-## How to Develop \(Ellipsis Mode\)
-
-In ellipsis mode, an ellipsis \(...\) is displayed at the end of the label if the text cannot be completely displayed.
-
-1. Create a **lUILabel** instance and set its size and position.
-
- ```
- UILabel* label = new UILabel();
- label->SetPosition(x, y);
- label->Resize(width, height);
- ```
-
-2. Set the font.
-
- ```
- label->SetFont("SourceHanSansSC-Regular.otf", 30);
- ```
-
-3. Set the text display mode to **LINE\_BREAK\_ELLIPSIS**.
-
- ```
- label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
- label->SetLineBreakMode(UILabel::LINE_BREAK_ELLIPSIS);
- label->SetText("123567890");
- ```
-
-4. Verify that the ellipsis mode has taken effect on the label, as shown in the following figure.
-
- 
-
-
-## How to Develop \(Scrolling Mode\)
-
-In scrolling mode, long text is kept scrolling on a screen to bring the entire text into view.
-
-1. Create a **lUILabel** instance and set its size and position.
-
- ```
- UILabel* label = new UILabel();
- label->SetPosition(x, y);
- label->Resize(width, height);
- ```
-
-2. Set the font.
-
- ```
- label->SetFont("SourceHanSansSC-Regular.otf", 30);
- ```
-
-3. Set the text display mode to **UI\_LABEL\_LONG\_ROLL**.
-
- ```
- label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
- label->SetStyle(STYLE_BACKGROUND_OPA, 127);
- label->SetLineBreakMode(UILabel::LINE_BREAK_MARQUEE);
- label->SetText("123567890");
- ```
-
-4. Verify that the text is scrolling on the label, as shown in the following figure.
-
- .gif)
-
-
diff --git a/en/device-dev/subsystems/development-guidelines-on-container-components.md b/en/device-dev/subsystems/development-guidelines-on-container-components.md
deleted file mode 100644
index 7f4c52c933edc39a8fe283ded70d22d63c514d42..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-container-components.md
+++ /dev/null
@@ -1,244 +0,0 @@
-# Development Guidelines on Container Components
-
-- [UIViewGroup](#section145471898812)
-- [When to Use](#section0916112362216)
-- [Available APIs](#section12641756192212)
-- [How to Develop](#section5412161692311)
-- [UIScrollView](#section174961523161315)
-- [When to Use](#section8937101902413)
-- [Available APIs](#section14789133142420)
-- [How to Develop](#section1769754422417)
-
-Container components are capable of containing UI components and inherit from **UIViewGroup**. Components that are commonly used and need to contain child components are placed in the container class inheritance structure. For example, you need to call the **Add** function to add information such as time statistics and icons to **UIAnalogClock**.
-
-**Figure 1** Structure of common container components
-
-
-The **RootView**, **UIAbstractScroll**, and **UIPicker** components inherit from **UIViewGroup**, and the **UIList**, **UIScrollView**, and **UISwipeView** components inherit from **UIAbstractScroll**.
-
-## UIViewGroup
-
-## When to Use
-
-**UIViewGroup** is a base class for container components. For example, you can call the functions in this class to add, remove, and insert container components. Also, you can call the **Add** function to add child components for a container component. You need to set the position information for child components in a common container component. The position information is the coordinates relative to those of their parent component. The following figure shows the tree structure of components.
-
-**Figure 2** Component tree structure
-
-
-As shown in the figure, the container component **ViewGroup1** and the component **View1** are added to **RootView**, the component **View2** and the container component **ViewGroup2** are added to **ViewGroup1**, and then the component **View3** \(as a sibling of **View1**\) is also added to **ViewGroup1**.
-
-- Rendering: During rendering of a container component, you need to call the **OnDraw** function on all its child components to update them.
-- Coordinates: As the position information of child components is the coordinates relative to those of their parent components, the system calculates and displays the absolute coordinates of child components during rendering.
-- Tree structure traversing: The **UIViewGroup** class provides the functions below to traverse, search for, and manage the component tree.
-
-## Available APIs
-
-**Table 1** Available functions in ViewGroup
-
-
-
-
-## How to Develop
-
-1. Create **ULLabelButton** instances and set their coordinates.
-
- ```
- UILabelButton* btn1 = new UILabelButton();
- btn1->SetPosition(0, 0, 100, 50);
- btn1->SetText("btn1");
-
- UILabelButton* btn2 = new UILabelButton();
- btn2->SetPosition(50, 50, 100, 50);
- btn2->SetText("btn2");
-
- UILabelButton* btn3 = new UILabelButton();
- btn3->SetPosition(100, 100, 100, 50);
- btn3->SetText("btn3");
- ```
-
-2. Create a **UIViewGroup** instance and set its coordinates.
-
- ```
- UIViewGroup* group = new UIViewGroup();
- group->SetPosition(0, 0, 300, 300);
- ```
-
-3. Add the **ULLabelButton** instances to **UIViewGroup**.
-
- ```
- group->Add(btn1);
- group->Add(btn2);
- group->Add(btn3);
- ```
-
-4. The following figure shows the effect of adding view instances to a **ViewGroup**.
-
- **Figure 3** Effect of adding view instances to a ViewGroup
- 
-
-
-## UIScrollView
-
-## When to Use
-
-**UIScrollView** provides scrolling container components, which enable child components to scroll upwards, downwards, leftwards, and rightwards upon a touch event. This class also supports horizontal and vertical cursor display.
-
-## Available APIs
-
-**Table 2** Available functions in ScrollView
-
-
-
-
-## How to Develop
-
-Add two buttons as child components and display horizontal and vertical cursors.
-
-```
-scrollView* scroll = new UIScrollView();
-scroll->SetStyle(STYLE_BACKGROUND_COLOR, Color::Red().full);
-scroll->SetPosition(0,0, 200, 200);
-scroll->SetXScrollBarVisible(true);
-scroll->SetYScrollBarVisible(true);
-UILabelButton* button1 = new UILabelButton();
-button1->SetText("button1");
-button1->SetPosition(0, 0, 300, 300);
-UILabelButton* button2 = new UILabelButton();
-button2->SetText("button2");
-button2->SetPosition(0, 300, 300, 300);
-scroll->Add(button1);
-scroll->Add(button2);
-```
-
-**Figure 4** Scrolling effect in both horizontal and vertical directions
-
-
diff --git a/en/device-dev/subsystems/development-guidelines-on-layout-container-components.md b/en/device-dev/subsystems/development-guidelines-on-layout-container-components.md
deleted file mode 100644
index b90467d679cb0819acba97d6454315bfdffeeacf..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-layout-container-components.md
+++ /dev/null
@@ -1,216 +0,0 @@
-# Development Guidelines on Layout Container Components
-
-- [UISwipeView](#section13631719181717)
-- [When to Use](#section11299120102617)
-- [Available APIs](#section767434119261)
-- [Development Procedure \(Non-Cyclic Horizontal Swiping\)](#section111911175287)
-- [Development Procedure \(Cyclic Horizontal Swiping\)](#section1976914915282)
-- [GridLayout](#section46819199173)
-- [When to Use](#section831618247294)
-- [Available APIs](#section597214622912)
-- [How to Develop](#section1418253410306)
-
-Layout container components consist of basic view classes. You can set the view positions to achieve nested and overlapped layouts, set the layout type and margin to standardize the child components in the layout, and call certain functions to implement layout views based on parent and sibling components.
-
-## UISwipeView
-
-## When to Use
-
-**UISwipeView** inherits from **UIViewGroup**. In addition to the **Add**, **Remove**, and **Insert** functions, **UISwipeView** provides the functions to swipe contents by page and center the current page after swiping. This component can be horizontally or vertically centered. Child components added via the **Add** function are automatically horizontally or vertically centered, adaptive to the **UISwipeView** direction, in the sequence they were added.
-
-## Available APIs
-
-**Table 1** Available functions in SwipeView
-
-
-
-
-## Development Procedure \(Non-Cyclic Horizontal Swiping\)
-
-1. Create a horizontal swiping **UISwipeView**.
-
- ```
- UISwipeView* swipe = new UISwipeView(UISwipeView::HORIZONTAL);
- ```
-
-2. Add child components to **UISwipeView**.
-
- ```
- UILabelButton* button1 = new UILabelButton();
- button1->SetPosition(0, 0, g_ButtonW, g_ButtonH);
- button1->SetText("button1");
- swipe->Add(button1);
- UILabelButton* button2 = new UILabelButton();
- button2->SetPosition(0, 0, g_ButtonW, g_ButtonH);
- button2->SetText("button2");
- swipe->Add(button2);
- UILabelButton* button3 = new UILabelButton();
- button3->SetPosition(0, 0, g_ButtonW, g_ButtonH);
- button3->SetText("button3");
- swipe->Add(button3);
- ```
-
-3. Verify that the components are swiping horizontally but not cyclically.
-
- **Figure 1** Horizontal swiping effect of **UISwipeView**
-
-
- 
-
-
-## Development Procedure \(Cyclic Horizontal Swiping\)
-
-1. Create a horizontal swiping **UISwipeView** and add its child components.
-
- ```
- UISwipeView* swipe = new UISwipeView(UISwipeView::HORIZONTAL);
- UILabelButton* button1 = new UILabelButton();
- button1->SetPosition(0, 0, g_ButtonW, g_ButtonH);
- button1->SetText("button1");
- swipe->Add(button1);
- UILabelButton* button2 = new UILabelButton();
- button2->SetPosition(0, 0, g_ButtonW, g_ButtonH);
- button2->SetText("button2");
- swipe->Add(button2);
- UILabelButton* button3 = new UILabelButton();
- button3->SetPosition(0, 0, g_ButtonW, g_ButtonH);
- button3->SetText("button3");
- swipe->Add(button3);
- ```
-
-2. Enable cyclic swiping for the **UISwipeView**.
-
- ```
- swipe->SetLoopState(true);
- ```
-
-3. Verify that the components are swiping horizontally and cyclically.
-
- **Figure 2** Cyclic horizontal swiping effect of **UISwipeView**
-
-
- 
-
-
-## GridLayout
-
-## When to Use
-
-**GridLayout** provides the basic layout capability to set the number of grid rows and columns. Child components added via the **Add** function are automatically arranged after the **LayoutChildren\(\)** function is called.
-
-## Available APIs
-
-**Table 2** Available functions in GridLayout
-
-
-
Function
-
-
Description
-
-
-
-
void SetRows(const uint16_t& rows)
-
-
Sets the number of grid rows.
-
-
-
void SetCols(const uint16_t& cols)
-
-
Sets the number of grid columns.
-
-
-
void LayoutChildren(bool needInvalidate = false)
-
-
Lays out child components.
-
-
-
-
-
-## How to Develop
-
-1. Create a **GridLayout** instance and set its position and size.
-
- ```
- GridLayout* layout_ = new GridLayout();
- layout_->SetPosition(0, g_y, HROIZONTAL_RESOLUTION, 200);
- layout_->SetLayoutDirection(LAYOUT_HOR);
- layout_->SetRows(2);
- layout_->SetCols(2);
- ```
-
-2. Create **UILabelButton** instances.
-
- ```
- UILabelButton* bt1 = new UILabelButton();
- bt1->SetPosition(0,0,100,50);
- bt1->SetText("bt1");
- UILabelButton* bt2 = new UILabelButton();
- bt2->SetPosition(0, 0, 100, 50);
- bt2->SetText("bt2");
- UILabelButton* bt3 = new UILabelButton();
- bt3->SetPosition(0, 0, 100, 50);
- bt3->SetText("bt3");
- UILabelButton* bt4 = new UILabelButton();
- bt4->SetPosition(0, 0, 100, 50);
- bt4->SetText("bt4");
- ```
-
-3. Add child components and call the **LayoutChildren\(\)** function.
-
- ```
- layout_->Add(bt1);
- layout_->Add(bt2);
- layout_->Add(bt3);
- layout_->Add(bt4);
- layout_->LayoutChildren();
- ```
-
-4. Verify the layout of buttons, as shown in the following figure.
-
- **Figure 3** Setting a 2x2 grid and adding four buttons in a layout
- 
-
-
diff --git a/en/device-dev/subsystems/development-guidelines-on-media-recording.md b/en/device-dev/subsystems/development-guidelines-on-media-recording.md
deleted file mode 100644
index 407bfa9e5ad89a15c251d5ad5c1907812989992a..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-media-recording.md
+++ /dev/null
@@ -1,287 +0,0 @@
-# Development Guidelines on Media Recording
-
-- [When to Use](#section186634310418)
-- [Available APIs](#section125479541744)
-- [Limitations and Constraints](#section1165911177314)
-- [How to Develop](#section34171333656)
-
-## When to Use
-
-To record audios and videos, use APIs described in this section to set the encoding format, sampling rate, and bit rate, and encapsulate output files based on the parameters.
-
-## Available APIs
-
-The following table describes APIs available for audio and video recording.
-
-**Table 1** APIs available for media recording
-
-
-
int32_t SetParameter(int32_t sourceId, const Format &format)
-
-
Sets an extended parameter for recording.
-
-
-
-
-
-## Limitations and Constraints
-
-None
-
-## How to Develop
-
-1. Create a **Recorder** instance.
-
- ```
- Recorder *recorder = new Recorder();
- ```
-
-2. Sets parameters for the **Recorder** instance, including the media source information, encoding format, sampling rate, bit rate, and video width and height.
-
- ```
- int32_t sampleRate = 48000;
- int32_t channelCount = 1;
- AudioCodecFormat audioFormat = AAC_LC;
- AudioSourceType inputSource = AUDIO_MIC;
- int32_t audioEncodingBitRate = sampleRate;
- VideoSourceType source = VIDEO_SOURCE_SURFACE_ES;
- int32_t frameRate = 30;
- double fps = 30;
- int32_t rate = 4096;
- int32_t sourceId = 0;
- int32_t audioSourceId = 0;
- int32_t width = 1920;
- int32_t height = 1080;
- VideoCodecFormat encoder = H264;
- recorder->SetVideoSource(source, sourceId); // Set the video source and obtain the source ID.
- recorder->SetVideoEncoder(sourceId, encoder); // Set the video encoding format.
- recorder->SetVideoSize(sourceId, width, height); // Set the video width and height.
- recorder->SetVideoFrameRate(sourceId, frameRate); // Set the video frame rate.
- recorder->SetVideoEncodingBitRate(sourceId, rate); // Set the video encoding bit rate.
- recorder->SetCaptureRate(sourceId, fps); // Set the capture rate for video frames.
- recorder->SetAudioSource(inputSource, audioSourceId); // Set the audio source and obtain the source ID.
- recorder->SetAudioEncoder(audioSourceId, audioFormat); // Set the audio encoding format.
- recorder->SetAudioSampleRate(audioSourceId, sampleRate); // Set the audio sampling rate.
- recorder->SetAudioChannels(audioSourceId, channelCount); // Set the number of audio channels.
- recorder->SetAudioEncodingBitRate(audioSourceId, audioEncodingBitRate); // Set the audio encoding bit rate.
- ```
-
-3. Prepare the **Recorder** instance for recording.
-
- ```
- recorder->Prepare(); // Prepare for recording.
- ```
-
-4. Start recording. The **Recorder** instance starts recording based on the audio and video sources.
-
- ```
- recorder->Start(); // Start recording.
- ```
-
-5. Stop recording and release resources.
-
- ```
- recorder->Stop(); // Stop recording.
- recorder->Release(); // Release recording resources.
- ```
-
-
diff --git a/en/device-dev/subsystems/development-guidelines-on-photographing.md b/en/device-dev/subsystems/development-guidelines-on-photographing.md
deleted file mode 100644
index 23f92734097a2c318c8701f8c30983b88100b7bc..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-photographing.md
+++ /dev/null
@@ -1,395 +0,0 @@
-# Development Guidelines on Photographing
-
-- [When to Use](#section1963312376119)
-- [Available APIs](#section56549532016)
-- [Limitations and Constraints](#section1165911177314)
-- [How to Develop](#section138543918214)
-
-## When to Use
-
-Use the camera module APIs to capture frames \(photographing\).
-
-## Available APIs
-
-**Table 1** APIs for photographing
-
-
-
-
-## Limitations and Constraints
-
-None
-
-## How to Develop
-
-1. Extend the **CameraDeviceCallback** class and call **OnCameraStatus** to customize operations when the camera device changes, for example, when a camera becomes available or unavailable.
-
- ```
- class SampleCameraDeviceCallback : public CameraDeviceCallback {
- void OnCameraStatus(std::string cameraId, int32_t status) override
- {
- // Do something when camera is available or unavailable.
- }
- };
- ```
-
-2. Extend the **FrameStateCallback** class. After obtaining the frame data, save the data as a file.
-
- ```
- static void SampleSaveCapture(const char *p, uint32_t size)
- {
- cout << "Start saving picture" << endl;
- struct timeval tv;
- gettimeofday(&tv, NULL);
- struct tm *ltm = localtime(&tv.tv_sec);
- if (ltm != nullptr) {
- ostringstream ss("Capture_");
- ss << "Capture" << ltm->tm_hour << "-" << ltm->tm_min << "-" << ltm->tm_sec << ".jpg";
-
- ofstream pic("/sdcard/" + ss.str(), ofstream::out | ofstream::trunc);
- cout << "write " << size << " bytes" << endl;
- pic.write(p, size);
- cout << "Saving picture end" << endl;
- }
- }
-
- class TestFrameStateCallback : public FrameStateCallback {
- void OnFrameFinished(Camera &camera, FrameConfig &fc, FrameResult &result) override
- {
- cout << "Receive frame complete inform." << endl;
- if (fc.GetFrameConfigType() == FRAME_CONFIG_CAPTURE) {
- cout << "Capture frame received." << endl;
- list surfaceList = fc.GetSurfaces();
- for (Surface *surface : surfaceList) {
- SurfaceBuffer *buffer = surface->AcquireBuffer();
- if (buffer != nullptr) {
- char *virtAddr = static_cast(buffer->GetVirAddr());
- if (virtAddr != nullptr) {
- SampleSaveCapture(virtAddr, buffer->GetSize());
- }
- surface->ReleaseBuffer(buffer);
- }
- delete surface;
- }
- delete &fc;
- }
- }
- };
- ```
-
-3. Extend the **CameraStateCallback** class and customize operations when the camera state changes \(configuration successful or failed, and creation successful or failed\).
-
- ```
- class SampleCameraStateMng : public CameraStateCallback {
- public:
- SampleCameraStateMng() = delete;
- SampleCameraStateMng(EventHandler &eventHdlr) : eventHdlr_(eventHdlr) {}
- ~SampleCameraStateMng()
- {
- if (recordFd_ != -1) {
- close(recordFd_);
- }
- }
- void OnCreated(Camera &c) override
- {
- cout << "Sample recv OnCreate camera." << endl;
- auto config = CameraConfig::CreateCameraConfig();
- config->SetFrameStateCallback(&fsCb_, &eventHdlr_);
- c.Configure(*config);
- cam_ = &c;
- }
- void OnCreateFailed(const std::string cameraId, int32_t errorCode) override {}
- void OnReleased(Camera &c) override {}
- };
- ```
-
-4. Create a **CameraKit** instance to set and obtain camera information.
-
- ```
- CameraKit *camKit = CameraKit::GetInstance();
- list camList = camKit->GetCameraIds();
- string camId;
- for (auto &cam : camList) {
- cout << "camera name:" << cam << endl;
- const CameraAbility *ability = camKit->GetCameraAbility(cam);
- /* Find the camera that fits your ability. */
- list sizeList = ability->GetSupportedSizes(0);
- if (find(sizeList.begin(), sizeList.end(), CAM_PIC_1080P) != sizeList.end()) {
- camId = cam;
- break;
- }
- }
- ```
-
-5. Create a **Camera** instance.
-
- ```
- EventHandler eventHdlr; // Create a thread to handle callback events.
- SampleCameraStateMng CamStateMng(eventHdlr);
-
- camKit->CreateCamera(camId, CamStateMng, eventHdlr);
- ```
-
-6. In the main process, synchronize configurations set by callback functions implemented in [step 1](#li378084192111), [step 2](#li8716104682913), and [step 3](#li6671035102514).
-
- ```
- void OnCreated(Camera &c) override
- {
- cout << "Sample recv OnCreate camera." << endl;
- auto config = CameraConfig::CreateCameraConfig();
- config->SetFrameStateCallback(&fsCb_, &eventHdlr_);
- c.Configure(*config);
- cam_ = &c;
- }
-
- void Capture()
- {
- if (cam_ == nullptr) {
- cout << "Camera is not ready." << endl;
- return;
- }
- FrameConfig *fc = new FrameConfig(FRAME_CONFIG_CAPTURE);
- Surface *surface = Surface::CreateSurface();
- if (surface == nullptr) {
- delete fc;
- }
- surface->SetWidthAndHeight(1920, 1080); /* 1920:width,1080:height */
- fc->AddSurface(*surface);
- cam_->TriggerSingleCapture(*fc);
- }
- ```
-
-
diff --git a/en/device-dev/subsystems/development-guidelines-on-trusted-device-group-management.md b/en/device-dev/subsystems/development-guidelines-on-trusted-device-group-management.md
deleted file mode 100644
index 91c4013935b5b3b8ce3cea7997dbeae25f7ac67d..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines-on-trusted-device-group-management.md
+++ /dev/null
@@ -1,264 +0,0 @@
-# Development Guidelines on Trusted Device Group Management
-
-- [When to Use](#section18502174174019)
-- [Available APIs](#section1633115419401)
-- [How to Develop](#section17516229192313)
-- [Debugging and Verification](#section427316292411)
-
-## When to Use
-
-When a distributed service needs to exploit the secure communication channel provided by the distributed virtual bus for different devices, it can use the trusted device group management component to create groups of trusted devices. Distributed applications can establish and use secure, trusted relationships between devices based on the authentication capabilities for devices using different HUAWEI IDs, such as PIN code, QR code, and OneHop, and the capabilities for grouped devices using the same HUAWEI ID. For a device on which you have not logged in using your HUAWEI ID, you can enter the PIN code or scan the QR code to obtain the connection and PIN code information of the device. Then you can create a group of trusted devices and add this device to the group. If other applications have created and shared their groups of trusted devices, or have logged in using the same HUAWEI ID as yours, you can call APIs to query and use the groups.
-
-## Available APIs
-
-The following tables list the innerkits APIs provided by trusted device group management. These APIs are intended for system applications only.
-
-**Table 1** Java APIs provided by trusted device group management
-
-
-
Function
-
-
Description
-
-
-
-
public static DeviceGroupManager getInstance(Abilityability, StringappID, IHichainGroupCallbackcallbackHandler)
-
-
Obtains a DeviceGroupManager instance and registers a listener.
-
-
-
int createGroup(String appId, String groupName, int groupType, String groupInfo)
-
-
Creates a group of trusted devices.
-
-
-
public int deleteGroup(String gourpId)
-
-
Deletes a group of trusted devices.
-
-
-
public String getLocalConnectInfo()
-
-
Obtains the network connection information of the local device.
-
-
-
int addMemberToGroup(String appId, long requestId, String addParams, String connectParams, int groupType)
-
-
Adds a member to a specified group.
-
-
-
int deleteMemberFromGroup(String appId, long requestId, String deleteParams, String connectParams)
-
-
Deletes a member from a specified group.
-
-
-
int cancelRequest(long requestId)
-
-
Cancels an ongoing request, for example, adding or deleting a member.
-
-
-
List<String> listJoinedGroups(int groupType)
-
-
Obtains a list of groups of a specified type to which the current device has been added.
Obtains information about all the groups that contain both the local device and the device with a specified ID.
-
-
-
-
-
-## How to Develop
-
-To develop trusted device group management, first obtain a management instance \(a callback to obtain group operation results is registered during the process\). Then you can use the instance to add or delete members, set a friend list for a group, and perform related query operations.
-
-**Scenario 1**: Create a group.
-
-```
-private HwDeviceGroupManager hwDeviceGroupManager;
-...
-private HichainGroupCallback groupCallbackByA = new HichainGroupCallback() {
- @Override public void onFinish(long requestId, GroupOperation operationCode, String returnData) {
-
- }
- @Override public void onError(long requestId, GroupOperation operationCode, int errorCode, String errorReturn) {
-
- }
- @Override public String onRequest(long requestId, GroupOperation operationCode, String reqParams) {
- JSONObject onRequestJson = generateConfirmation(REQUEST_ACCEPTED);
- return onRequestJson.toString();
- }
-};
-...
-Optional context = convertAbilityToContext(mAbility);
-Context ctxt = context.get();
-hwDeviceGroupManager = HwDeviceGroupManager.getInstance(ctxt, APP_ID, groupCallbackByA);
-int ret = hwDeviceGroupManager.createGroup(APP_ID, GROUP_NAME, GROUP_TYPE, GROUP_INFO);
-```
-
-1. Declare the private member variable of the **HwDeviceGroupManager** instance.
-
- ```
- private HwDeviceGroupManager hwDeviceGroupManager;
- ```
-
-2. Create a callback for group management operations.
-
- ```
- private HichainGroupCallback groupCallbackByA = new HichainGroupCallback();
- ```
-
-3. Obtain a **HwDeviceGroupManager** instance. \(In distributed scenarios, the same application on different devices must use the same **APP\_ID**.\)
-
- ```
- hwDeviceGroupManager = HwDeviceGroupManager.getInstance(ctxt, APP_ID, groupCallbackByA);
- ```
-
-4. Call the **createGroup** function to create a group. If **0** is returned, the creation request is submitted successfully.
-
- ```
- int ret = hwDeviceGroupManager.createGroup(APP_ID, GROUP_NAME, GROUP_TYPE, GROUP_INFO);
- ```
-
-5. After the group is created, **onFinish** is called. In this callback, the value of **operationCode** is **OperationCode.CREATE**, indicating a group creation operation. **returnData** is in JSON format and contains the **groupId** field, indicating the ID of the created group.
-
-**Scenario 2**: Add an authenticated device \(member\) to a group so that you can initiate trusted, encrypted connections to the device through the distributed virtual bus.
-
-```
-deviceGroupManager = DeviceGroupManager.getInstance(mAbility, APP_ID, hichainGroupCallback);
-private static final String CONN_PARAM ="{\"DEVICE_ID\":\"11111111\",\"WIFI_IP\":\"192.168.43.149\",\"WIFI_PORT\":\"30000\",\"BLE_MAC\":\"\"}";
-private static final String ADD_PARAM ="{\"groupId\":\"344C1C8B149\",\"groupName\":\"myGroup\",\"addId\":\"11111111\",\"isAdmin\":\"false\"}";
-private static final int GROUP_TYPE = 256;
-int result = deviceGroupManager.addMemberToGroup(APP_ID, reqId, ADD_PARAM, CONN_PARAM, GROUP_TYPE);
-```
-
-1. Obtain an **HwDeviceGroupManager** instance.
-
- ```
- deviceGroupManager = HwDeviceGroupManager.getInstance(mAbility, APP_ID, hichainGroupCallback);
- ```
-
-2. Set network connection parameters for the member to add \(in JSON format\), which are network parameters supported by the distributed virtual bus, such as **WIFI\_IP**, **WIFI\_PORT**, **BLR\_MAC**, and **DEVICE\_ID**. For details about the parameters, see the distributed virtual bus development guidelines.
-
- ```
- String CONN_PARAM ="{\"DEVICE_ID\":\"11111111\",\"WIFI_IP\":\"192.168.43.149\",\"WIFI_PORT\":\"30000\",\"BLE_MAC\":\"\"}";
- ```
-
-3. Set parameters for the member to add \(in JSON format\), including the group ID, name, and whether the member is an administrator. If the member is invited to add a group, the value of **isAdmin** is **true**; otherwise, the value of **isAdmin** is **false**.
-
- ```
- String ADD_PARAM ="{\"groupId\":\"344C1C8B149\",\"groupName\":\"myGroup\",\"addId\":\"11111111\",\"isAdmin\":\"false\"}";
- ```
-
-4. Set the type of the target group to **256**, indicating a P2P group.
-
- ```
- private static final int GROUP_TYPE = 256;
- ```
-
-5. Set **generateConfirmation** of the **onRequest** function in **HichainGroupCallback**. **PIN\_CODE** indicates the PIN code, which is input by users on the UI of the service. \(In a distributed communication, two devices must use the same PIN code.\)
-
- ```
- private JSONObject generateConfirmation(int confirmation) {
- JSONObject jsonObject = new JSONObject();
- try { jsonObject.put("pinCode", PIN_CODE);
- jsonObject.put("confirmation", confirmation);
- } catch (JSONException e) {
- LogUtil.error(TAG, "" + e.getMessage());
- }
- return jsonObject;
- }
- ```
-
-6. Call the **addMemberToGroup** function to add the member to the group.
-
- ```
- result = deviceGroupManager.addMemberToGroup(APP_ID, reqId, ADD_PARAM, CONN_PARAM, GROUP_TYPE);
- ```
-
-7. Check whether **HichainGroupCallback.onFinish** is called \(**operationCode** is **OperationCode.JOIN**\). If it is called, the member is added successfully.
-8. Call APIs of the distributed virtual bus to create secure sessions between devices.
-
-## Debugging and Verification
-
-1. Develop an application with OpenHarmony.
-
-2. Develop an application by following the development guidelines.
-
-3. Create a group. If the **onFinish** callback is invoked, the group is created successfully.
-
-4. Deploy the same application on two devices, A and B.
-
-5. Transmit the connection parameters of device B to device A through a QR code.
-
-6. In the application on device A, create group1 and call the API to add device B to group1. If **HichainGroupCallback.onFinish** is called, device B is successfully added to group1.
-
diff --git a/en/device-dev/subsystems/development-guidelines.md b/en/device-dev/subsystems/development-guidelines.md
deleted file mode 100644
index 6f14243a239391be4a4bce69425c6cca27844187..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/development-guidelines.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Development Guidelines
-
-To access the AI engine framework, you need to develop the SDKs and plug-ins shown in [Figure 1](ai-engine-framework.md#fig143186187187). In this way, you can call the APIs provided by the SDKs to call the algorithm capabilities of plug-ins to implement lifecycle management and on-demand deployment of AI capabilities.
-
-- **[SDK](sdk.md)**
-
-- **[Plug-in](plug-in.md)**
-
-- **[Configuration File](configuration-file.md)**
-
-
diff --git a/en/device-dev/subsystems/dfx-11.md b/en/device-dev/subsystems/dfx-11.md
deleted file mode 100644
index faf8b0d8fa8e4c39a1548d7a7e77b6eb6906bd95..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/dfx-11.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# DFX
-
-- [Basic Concepts](#section5635178134811)
-
-[Design for X](https://en.wikipedia.org/wiki/Design_for_X) \(DFX\) refers to the software design that aims to improve the quality attributes in OpenHarmony. It mainly consists of two parts: design for reliability \(DFR\) and design for testability \(DFT\).
-
-The DFX subsystem provides the following functions:
-
-- HiLog: Implements the logging function. It is applicable to Mini-System Devices \(reference memory ≥ 128 KB\), Small-System Devices \(reference memory ≥ 1 MB\), and Standard-System Devices \(reference memory ≥ 128 MB\).
-
-- HiSysEvent: Implements system event logging. It is applicable to Standard-System Devices \(reference memory ≥ 128 MB\).
-
-## Basic Concepts
-
-**Logging**
-
-Logging means to record the log information generated during system running so you can understand the running process and status of the system or applications.
-
-**Distributed call chain tracing**
-
-In a distributed system, the initiation of a service may involve multiple software modules, with control commands and data transmitted over intra-process, inter-process, and inter-device communication interfaces. To help you understand such complex communication processes and locate service faults efficiently, the DFX subsystem provides a distributed call chain tracing framework.
-
-**Thread suspension detection**
-
-If a thread is trapped in an infinite loop or the kernel state \(for example, Uninterruptable Sleep, Traced, Zombie, or synchronous wait\) when it is running, the thread cannot respond to normal service requests and cannot detect and recover from faults by itself. To detect and locate this type of faults, the DFX subsystem provides a simple watchdog mechanism by inserting detection probes to the process nodes that are prone to suspension. This ensures that suspension faults can be detected and logs can be collected.
-
-**Event logging**
-
-Event logging means to collect and log events reported during system running. The log information will help you better analyze the product usage.
-
-**System event**
-
-A system event is an indication of the system status at a given time point during system running. You can use these events to analyze the status change of the system.
-
diff --git a/en/device-dev/subsystems/dfx.md b/en/device-dev/subsystems/dfx.md
deleted file mode 100644
index 241303cae97af3db18251e836e22ca628efba17c..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/dfx.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# DFX
-
-- **[DFX](dfx-11.md)**
-
-- **[Development Guidelines on HiLog](development-guidelines-on-hilog.md)**
-
-- **[Development Guidelines on HiLog\_Lite](development-guidelines-on-hilog_lite.md)**
-
-- **[Development Guidelines on HiSysEvent](development-guidelines-on-hisysevent.md)**
-
-
diff --git a/en/device-dev/subsystems/faqs.md b/en/device-dev/subsystems/faqs.md
deleted file mode 100644
index f7acfe005f855c58ba12fd8bcb8cc8ae4a21e6de..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/faqs.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# FAQs
-
-- [System startup interrupted due to "parse failed!" error](#section2041345718513)
-- [System automatically restarted again and again](#section57381816168)
-- [Failed to call the SetParameter or GetParameter API with correct parameter values](#section129991227141512)
-
-## System startup interrupted due to "parse failed!" error
-
-**Problem**
-
-During system startup, the error message "\[Init\] InitReadCfg, parse failed! please check file /etc/init.cfg format." is displayed, and the startup is interrupted, as shown in the following figure.
-
-
-
-**Cause**
-
-During the modification of the **init.cfg** file, required commas \(,\) or parentheses are missing or unnecessary ones are added. As a result, the file's JSON format becomes invalid.
-
-**Solution**
-
-Check the **init.cfg** file and ensure that its format meets the JSON specifications.
-
-## System automatically restarted again and again
-
-**Problem**
-
-After the image burning is complete, the system keeps restarting.
-
-**Cause**
-
-Each service started by the init process has the **importance** attribute, as described in Table 3 in [init Module](init-module.md).
-
-- If the attribute value is **0**, the init process does not need to restart the development board when the current service process exits.
-- If the attribute value is **1**, the init process needs to restart the development board when the current service process exits.
-
-During the startup of a service whose **importance** is **1**, if the service exits due to a process crash or an error, the init process automatically restarts the development board.
-
-**Solution**
-
-1. View logs to identify the service that encounters a process crash or exits due to an error, rectify the issue, and then burn the image again.
-2. Alternatively, change the value of **importance** to **0** for the service that exits due to a process crash or an error, and then burn the image again. In this way, the development board will not be restarted even if the service exits.
-
-## Failed to call the **SetParameter** or **GetParameter** API with correct parameter values
-
-**Problem**
-
-Calling the **SetParameter** or **GetParameter** API fails even if correct values are passed to all input parameters.
-
-**Cause**
-
-Permission verification has been enabled for the **SetParameter** and **GetParameter** APIs. If the UID of the caller is greater than 1000, that is, the caller does not have the permission to call these APIs, API calls will fail even if the parameters are correct.
-
-**Solution**
-
-No action is required.
-
diff --git a/en/device-dev/subsystems/figures/20200721-223604(espace).gif b/en/device-dev/subsystems/figure/20200721-223604(espace).gif
similarity index 100%
rename from en/device-dev/subsystems/figures/20200721-223604(espace).gif
rename to en/device-dev/subsystems/figure/20200721-223604(espace).gif
diff --git a/en/device-dev/subsystems/figures/animator-effect.gif b/en/device-dev/subsystems/figure/animator-effect.gif
similarity index 100%
rename from en/device-dev/subsystems/figures/animator-effect.gif
rename to en/device-dev/subsystems/figure/animator-effect.gif
diff --git a/en/device-dev/subsystems/figures/application-startup-process.png b/en/device-dev/subsystems/figure/application-startup-process.png
similarity index 100%
rename from en/device-dev/subsystems/figures/application-startup-process.png
rename to en/device-dev/subsystems/figure/application-startup-process.png
diff --git a/en/device-dev/subsystems/figures/architecture-of-the-ability-management-framework.png b/en/device-dev/subsystems/figure/architecture-of-the-ability-management-framework.png
similarity index 100%
rename from en/device-dev/subsystems/figures/architecture-of-the-ability-management-framework.png
rename to en/device-dev/subsystems/figure/architecture-of-the-ability-management-framework.png
diff --git a/en/device-dev/subsystems/figures/architecture-of-the-bundle-management-framework.png b/en/device-dev/subsystems/figure/architecture-of-the-bundle-management-framework.png
similarity index 100%
rename from en/device-dev/subsystems/figures/architecture-of-the-bundle-management-framework.png
rename to en/device-dev/subsystems/figure/architecture-of-the-bundle-management-framework.png
diff --git a/en/device-dev/subsystems/figure/build-process.jpg b/en/device-dev/subsystems/figure/build-process.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..a48ea734509526b3ed0fe85b7c4a98b0a2a9c4f0
Binary files /dev/null and b/en/device-dev/subsystems/figure/build-process.jpg differ
diff --git a/en/device-dev/subsystems/figures/component-tree-structure.png b/en/device-dev/subsystems/figure/component-tree-structure.png
similarity index 100%
rename from en/device-dev/subsystems/figures/component-tree-structure.png
rename to en/device-dev/subsystems/figure/component-tree-structure.png
diff --git a/en/device-dev/subsystems/figures/effect-of-adding-view-instances-to-a-viewgroup.png b/en/device-dev/subsystems/figure/effect-of-adding-view-instances-to-a-viewgroup.png
similarity index 100%
rename from en/device-dev/subsystems/figures/effect-of-adding-view-instances-to-a-viewgroup.png
rename to en/device-dev/subsystems/figure/effect-of-adding-view-instances-to-a-viewgroup.png
diff --git a/en/device-dev/subsystems/figures/effect-of-clicking-a-uibutton.gif b/en/device-dev/subsystems/figure/effect-of-clicking-a-uibutton.gif
similarity index 100%
rename from en/device-dev/subsystems/figures/effect-of-clicking-a-uibutton.gif
rename to en/device-dev/subsystems/figure/effect-of-clicking-a-uibutton.gif
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001051782526.png b/en/device-dev/subsystems/figure/en-us_image_0000001051782526.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001051782526.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001051782526.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001052582522.png b/en/device-dev/subsystems/figure/en-us_image_0000001052582522.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001052582522.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001052582522.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001052662559.png b/en/device-dev/subsystems/figure/en-us_image_0000001052662559.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001052662559.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001052662559.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001052782555.png b/en/device-dev/subsystems/figure/en-us_image_0000001052782555.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001052782555.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001052782555.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001052942531.png b/en/device-dev/subsystems/figure/en-us_image_0000001052942531.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001052942531.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001052942531.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001053207924.gif b/en/device-dev/subsystems/figure/en-us_image_0000001053207924.gif
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001053207924.gif
rename to en/device-dev/subsystems/figure/en-us_image_0000001053207924.gif
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001053247975.gif b/en/device-dev/subsystems/figure/en-us_image_0000001053247975.gif
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001053247975.gif
rename to en/device-dev/subsystems/figure/en-us_image_0000001053247975.gif
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001054101094.png b/en/device-dev/subsystems/figure/en-us_image_0000001054101094.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001054101094.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001054101094.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001054421113.png b/en/device-dev/subsystems/figure/en-us_image_0000001054421113.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001054421113.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001054421113.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001059334449.png b/en/device-dev/subsystems/figure/en-us_image_0000001059334449.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001059334449.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001059334449.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001060200050.png b/en/device-dev/subsystems/figure/en-us_image_0000001060200050.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001060200050.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001060200050.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001061889268.png b/en/device-dev/subsystems/figure/en-us_image_0000001061889268.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001061889268.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001061889268.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001062334618.png b/en/device-dev/subsystems/figure/en-us_image_0000001062334618.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001062334618.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001062334618.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001062476933.png b/en/device-dev/subsystems/figure/en-us_image_0000001062476933.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001062476933.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001062476933.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001062942690.png b/en/device-dev/subsystems/figure/en-us_image_0000001062942690.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001062942690.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001062942690.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001063839940.png b/en/device-dev/subsystems/figure/en-us_image_0000001063839940.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001063839940.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001063839940.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001077724150.png b/en/device-dev/subsystems/figure/en-us_image_0000001077724150.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001077724150.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001077724150.png
diff --git a/en/device-dev/subsystems/figures/en-us_image_0000001077727032.png b/en/device-dev/subsystems/figure/en-us_image_0000001077727032.png
similarity index 100%
rename from en/device-dev/subsystems/figures/en-us_image_0000001077727032.png
rename to en/device-dev/subsystems/figure/en-us_image_0000001077727032.png
diff --git a/en/device-dev/subsystems/figure/en-us_image_0000001119924146.gif b/en/device-dev/subsystems/figure/en-us_image_0000001119924146.gif
new file mode 100644
index 0000000000000000000000000000000000000000..9cd37267672d3bea422b98d95c413e26df330de8
Binary files /dev/null and b/en/device-dev/subsystems/figure/en-us_image_0000001119924146.gif differ
diff --git a/en/device-dev/subsystems/figure/en-us_image_0000001166643927.jpg b/en/device-dev/subsystems/figure/en-us_image_0000001166643927.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..ace4cefd36637675f235df3cd596eca3ed218e6c
Binary files /dev/null and b/en/device-dev/subsystems/figure/en-us_image_0000001166643927.jpg differ
diff --git a/en/device-dev/subsystems/figures/image-auto-adaption-effect.png b/en/device-dev/subsystems/figure/image-auto-adaption-effect.png
similarity index 100%
rename from en/device-dev/subsystems/figures/image-auto-adaption-effect.png
rename to en/device-dev/subsystems/figure/image-auto-adaption-effect.png
diff --git a/en/device-dev/subsystems/figures/image-tile-effect.png b/en/device-dev/subsystems/figure/image-tile-effect.png
similarity index 100%
rename from en/device-dev/subsystems/figures/image-tile-effect.png
rename to en/device-dev/subsystems/figure/image-tile-effect.png
diff --git a/en/device-dev/subsystems/figures/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-a-kernel.png b/en/device-dev/subsystems/figure/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-a-kernel.png
similarity index 100%
rename from en/device-dev/subsystems/figures/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-a-kernel.png
rename to en/device-dev/subsystems/figure/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-a-kernel.png
diff --git a/en/device-dev/subsystems/figures/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-m-kernel.png b/en/device-dev/subsystems/figure/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-m-kernel.png
similarity index 100%
rename from en/device-dev/subsystems/figures/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-m-kernel.png
rename to en/device-dev/subsystems/figure/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-m-kernel.png
diff --git a/en/device-dev/subsystems/figures/platform-architecture.png b/en/device-dev/subsystems/figure/platform-architecture.png
similarity index 100%
rename from en/device-dev/subsystems/figures/platform-architecture.png
rename to en/device-dev/subsystems/figure/platform-architecture.png
diff --git a/en/device-dev/subsystems/figures/relationship-between-a-page-ability-and-its-ability-slices.png b/en/device-dev/subsystems/figure/relationship-between-a-page-ability-and-its-ability-slices.png
similarity index 100%
rename from en/device-dev/subsystems/figures/relationship-between-a-page-ability-and-its-ability-slices.png
rename to en/device-dev/subsystems/figure/relationship-between-a-page-ability-and-its-ability-slices.png
diff --git a/en/device-dev/subsystems/figures/running-sequence-of-the-test-platform.png b/en/device-dev/subsystems/figure/running-sequence-of-the-test-platform.png
similarity index 100%
rename from en/device-dev/subsystems/figures/running-sequence-of-the-test-platform.png
rename to en/device-dev/subsystems/figure/running-sequence-of-the-test-platform.png
diff --git a/en/device-dev/subsystems/figures/scrolling-effect-in-both-horizontal-and-vertical-directions.gif b/en/device-dev/subsystems/figure/scrolling-effect-in-both-horizontal-and-vertical-directions.gif
similarity index 100%
rename from en/device-dev/subsystems/figures/scrolling-effect-in-both-horizontal-and-vertical-directions.gif
rename to en/device-dev/subsystems/figure/scrolling-effect-in-both-horizontal-and-vertical-directions.gif
diff --git a/en/device-dev/subsystems/figures/setting-a-2x2-grid-and-adding-four-buttons-in-a-layout.png b/en/device-dev/subsystems/figure/setting-a-2x2-grid-and-adding-four-buttons-in-a-layout.png
similarity index 100%
rename from en/device-dev/subsystems/figures/setting-a-2x2-grid-and-adding-four-buttons-in-a-layout.png
rename to en/device-dev/subsystems/figure/setting-a-2x2-grid-and-adding-four-buttons-in-a-layout.png
diff --git a/en/device-dev/subsystems/figures/startup-of-the-ability-manager-service-and-bundle-manager-service.png b/en/device-dev/subsystems/figure/startup-of-the-ability-manager-service-and-bundle-manager-service.png
similarity index 100%
rename from en/device-dev/subsystems/figures/startup-of-the-ability-manager-service-and-bundle-manager-service.png
rename to en/device-dev/subsystems/figure/startup-of-the-ability-manager-service-and-bundle-manager-service.png
diff --git a/en/device-dev/subsystems/figures/structure-of-common-container-components.png b/en/device-dev/subsystems/figure/structure-of-common-container-components.png
similarity index 100%
rename from en/device-dev/subsystems/figures/structure-of-common-container-components.png
rename to en/device-dev/subsystems/figure/structure-of-common-container-components.png
diff --git a/en/device-dev/subsystems/figures/tree-structure-of-common-components.png b/en/device-dev/subsystems/figure/tree-structure-of-common-components.png
similarity index 100%
rename from en/device-dev/subsystems/figures/tree-structure-of-common-components.png
rename to en/device-dev/subsystems/figure/tree-structure-of-common-components.png
diff --git a/en/device-dev/subsystems/figures/unnaming.png b/en/device-dev/subsystems/figure/unnaming.png
similarity index 100%
rename from en/device-dev/subsystems/figures/unnaming.png
rename to en/device-dev/subsystems/figure/unnaming.png
diff --git "a/en/device-dev/subsystems/figures/\345\233\276\347\211\2071.png" "b/en/device-dev/subsystems/figure/\345\233\276\347\211\2071.png"
similarity index 100%
rename from "en/device-dev/subsystems/figures/\345\233\276\347\211\2071.png"
rename to "en/device-dev/subsystems/figure/\345\233\276\347\211\2071.png"
diff --git "a/en/device-dev/subsystems/figures/\345\256\211\345\205\250\345\255\220\347\263\273\347\273\237.png" "b/en/device-dev/subsystems/figure/\345\256\211\345\205\250\345\255\220\347\263\273\347\273\237.png"
similarity index 100%
rename from "en/device-dev/subsystems/figures/\345\256\211\345\205\250\345\255\220\347\263\273\347\273\237.png"
rename to "en/device-dev/subsystems/figure/\345\256\211\345\205\250\345\255\220\347\263\273\347\273\237.png"
diff --git "a/en/device-dev/subsystems/figures/\346\217\222\344\273\266\344\276\235\350\265\226-(2).jpg" "b/en/device-dev/subsystems/figure/\346\217\222\344\273\266\344\276\235\350\265\226-(2).jpg"
similarity index 100%
rename from "en/device-dev/subsystems/figures/\346\217\222\344\273\266\344\276\235\350\265\226-(2).jpg"
rename to "en/device-dev/subsystems/figure/\346\217\222\344\273\266\344\276\235\350\265\226-(2).jpg"
diff --git a/en/device-dev/subsystems/figures/build-process.jpg b/en/device-dev/subsystems/figures/build-process.jpg
deleted file mode 100644
index c8d58bc3d172524c78e3c45455622d081429529c..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/figures/build-process.jpg and /dev/null differ
diff --git a/en/device-dev/subsystems/figures/building-process.jpg b/en/device-dev/subsystems/figures/building-process.jpg
deleted file mode 100644
index c8d58bc3d172524c78e3c45455622d081429529c..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/figures/building-process.jpg and /dev/null differ
diff --git a/en/device-dev/subsystems/figures/ril-adapter.png b/en/device-dev/subsystems/figures/ril-adapter.png
deleted file mode 100644
index 51d8a0668a19b26071873247a5cf1f483d9044e5..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/figures/ril-adapter.png and /dev/null differ
diff --git "a/en/device-dev/subsystems/figures/\345\216\273\347\224\265.png" "b/en/device-dev/subsystems/figures/\345\216\273\347\224\265.png"
deleted file mode 100644
index fd53e705cde494b3b5a7a5e2c923a9b5ac07aa4f..0000000000000000000000000000000000000000
Binary files "a/en/device-dev/subsystems/figures/\345\216\273\347\224\265.png" and /dev/null differ
diff --git "a/en/device-dev/subsystems/figures/\346\235\245\347\224\265.png" "b/en/device-dev/subsystems/figures/\346\235\245\347\224\265.png"
deleted file mode 100644
index 9b27f13794e395cb6b05ec588f96bc938288ec01..0000000000000000000000000000000000000000
Binary files "a/en/device-dev/subsystems/figures/\346\235\245\347\224\265.png" and /dev/null differ
diff --git a/en/device-dev/subsystems/graphics.md b/en/device-dev/subsystems/graphics.md
deleted file mode 100644
index 254f1e0fa0022f821ba9ecb5f8f88846a868bfe7..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/graphics.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Graphics
-
-- **[Graphics](graphics-2.md)**
-
-- **[Development Guidelines on Container Components](development-guidelines-on-container-components.md)**
-
-- **[Development Guidelines on Layout Container Components](development-guidelines-on-layout-container-components.md)**
-
-- **[Development Guidelines on Common Components](development-guidelines-on-common-components.md)**
-
-- **[Development Guidelines on Animators](development-guidelines-on-animators.md)**
-
-
diff --git a/en/device-dev/subsystems/hdc_std-faqs.md b/en/device-dev/subsystems/hdc_std-faqs.md
deleted file mode 100644
index a767f3e60aad365ce1f66252889c5ccd3eb99773..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/hdc_std-faqs.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# hdc\_std FAQs
-
-- [hdc\_std Fails to Connect to a Device](#section1221016541119)
-- [hdc\_std Fails to Run](#section219185710311)
-
-## hdc\_std Fails to Connect to a Device
-
-- **Symptom**
-
- **\[Empty\]** is displayed in the output after the **hdc\_std list targets** command is run.
-
-- **Possible Causes and Solutions**
- 1. The device cannot be identified.
-
- Check whether **HDC Device** exists in the universal serial bus device of the device manager. If **HDC Device** does not exist, the device cannot be connected. In this case, remove and then insert the device or burn the latest image for the device.
-
- 2. hdc\_std works improperly.
-
- Run the **hdc kill** or **hdc start -r** command to kill or restart the hdc service, and then run the **hdc list targets** command to check whether device information is obtained.
-
- If no device information is obtained, check whether the adb process exists in the task manager. If the adb process exists, kill this process because it may affect the hdc service. After that, run **hdc kill** or **hdc start -r** and then **hdc list targets** again.
-
- 3. hdc\_std does not match the device.
-
- If the latest image is burnt for the device, hdc\_std must also be of the latest version. As hdc\_std is updated continuously, obtain hdc\_std of the latest version from the **developtools\_hdc\_standard** repository in the **prebuilt** directory.
-
-
-
-## hdc\_std Fails to Run
-
-- **Symptom**
-
- The **hdc\_std.exe** file does not run after being clicked.
-
-- **Possible Causes and Solutions**
-
- **hdc\_std.exe** requires no installation and can be directly used on a disk. It can also be added to environment variables. Open the cmd window and run the **hdc\_std** command to use **hdc\_std.exe**.
-
-
diff --git a/en/device-dev/subsystems/hdc_std-usage-guidelines.md b/en/device-dev/subsystems/hdc_std-usage-guidelines.md
deleted file mode 100644
index 76a821114ce609f1355d03c91c7cc7df7b43433b..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/hdc_std-usage-guidelines.md
+++ /dev/null
@@ -1,656 +0,0 @@
-# hdc\_std Usage Guidelines
-
-- [Preparations](#section05992022154916)
-- [Important Notes](#section19543134915210)
-- [Global Options](#section618522925119)
-- [Querying the Device List](#section174891132104218)
-- [Service Process Commands](#section680531510497)
-- [Network Commands](#section71176123212)
-- [File Commands](#section173133523013)
-- [App Commands](#section2072647133819)
-- [Debugging Commands](#section112861250195015)
-
-hdc\_std \(OpenHarmony Device Connector\) is a command line tool provided by OpenHarmony for debugging. With hdc, you can interact with real devices or simulators from a Windows or Linux OS.
-
-This section describes how to build the hdc\_std environment, its common commands, and how to use the commands.
-
-## Preparations
-
-**hdc\_std obtaining method:**
-
-Obtain hdc\_std from the **developtools\_hdc\_standard** repository in the **prebuilt** directory.
-
-**Example:**
-
-To obtain hdc\_std on Windows, obtain the executable file **hdc\_std.exe** from **prebuilt/windows** and place it in a specified directory on the disk.
-
-## Important Notes
-
-1. If an exception occurs when you are using hdc\_std, you can run the **hdc\_std kill** command to kill the hdc\_std service or run the **hdc\_std start -r** command to restart the service process.
-
-2. If no device information is obtained after **hdc\_std list targets** is executed, use the task manager to check whether the **hdc.exe** process exists. If it exists, kill the process.
-
-## Global Options
-
-The following options are globally available:
-
-- **-h/help -v/version**
-
-Obtains the hdc help and version information.
-
-**Table 1** Command description
-
-
-
Parameter
-
-
Description
-
-
-
-h/help -v/version
-
-
None
-
-
-
Return Value
-
-
Description
-
-
-
Required information
-
-
hdc help or version information
-
-
-
-
-
-Examples:
-
-hdc\_std -h / hdc\_std help
-
-hdc\_std -v / hdc\_std version
-
-- **-t key**
-
-Connects to a device with a specified key.
-
-**Table 2** Command description
-
-
-
Parameter
-
-
Description
-
-
-
key
-
-
Key that identifies the device. The value is in the IP address:Port number format or is a USB serial number.
-
-
-
Return Value
-
-
Description
-
-
-
1. error: device '***' not found
-
②Nothing to do...
-
-
1. The device does not exist.
-
2. The command does not exist.
-
-
-
-
-
-Examples:
-
-This option must be used together with a specific operation command. The following uses the shell command as an example:
-
-hdc\_std list targets \(for obtaining device information\)
-
-hdc\_std -t _key_ shell \(replace _key_ with the obtained device information\)
-
-> **NOTE:**
->You can connect to multiple devices from the device you use for development. Each device has a unique key, which is _IP address:Port number_ for a device that can be connected through a network and the serial number for a device that can be connected through USB.
-
-## Querying the Device List
-
-The following command is available:
-
-**list targets\[-v\]**
-
-Queries all the connected devices.
-
-**Table 3** Command description
-
-
-
Parameter
-
-
Description
-
-
-
-v
-
-
Prints detailed device information.
-
-
-
Return Value
-
-
Description
-
-
-
1. Device information
-
②[Empty]
-
-
1. A list of connected devices
-
1. No device information is found.
-
-
-
-
-
-Examples:
-
-hdc\_std list targets
-
-hdc\_std list targets -v
-
-## Service Process Commands
-
-The following commands are available:
-
-- **target mount**
-
-Mounts a partition such as **/system** with the read and write permissions.
-
-**Table 4** Command description
-
-
-
Parameter
-
-
Description
-
-
-
None
-
-
None
-
-
-
Return Value
-
-
Description
-
-
-
①Mount finish
-
2. Returned information
-
-
1. Information returned when the operation is successful.
-
2. Information returned when the operation fails.
-
-
-
-
-
-Example:
-
-hdc\_std target mount
-
-- **smode \[off\]**
-
-Grants the root permission to a background service process. The **off** option is used to revoke the granted permission.
-
-Examples:
-
-hdc\_std smode
-
-hdc\_std smode off
-
-- **kill \[-r\]**
-
-Stops a service process.
-
-**Table 5** Command description
-
-
-
Parameter
-
-
Description
-
-
-
-r
-
-
Triggers the service restart.
-
-
-
Return Value
-
-
Description
-
-
-
①Kill server finish
-
1. Error information
-
-
1. Information returned when the operation is successful.
-
-Examples:
-
-hdc\_std start
-
-## Network Commands
-
-The following commands are available:
-
-- **tconn _host_\[:_port_\]\[-remove\]**
-
-Connects to a device with a specified IP address and port number.
-
-**Table 7** Command description
-
-
-
Parameter
-
-
Description
-
-
-
host[:port]
-
-
IP address and port number of the device to be connected
-
-
-
-remove
-
-
Disconnects from the specified device.
-
-
-
Return Value
-
-
Description
-
-
-
1. Error information
-
2. None
-
-
1. The operation fails.
-
2. The operation is successful.
-
-
-
-
-
-Example:
-
-hdc\_std tconn 192.168.0.100:8710
-
-- **tmode usb**
-
-Restarts the daemon process and connects to the device using USB.
-
-**Table 8** Command description
-
-
-
Parameter
-
-
Description
-
-
-
None
-
-
None
-
-
-
Return Value
-
-
Description
-
-
-
1. Error information
-
2. None
-
-
1. The operation fails.
-
2. The operation is successful.
-
-
-
-
-
-Example:
-
-hdc\_std tmode usb
-
-- **tmode port _port-number_**
-
-Restarts the daemon process and connects to the device over TCP.
-
-**Table 9** Command description
-
-
-
Parameter
-
-
Description
-
-
-
port-number
-
-
Port number used to connect to the device
-
-
-
Return Value
-
-
Description
-
-
-
1. Error information
-
2. None
-
-
1. The operation fails.
-
2. The operation is successful.
-
-
-
-
-
-Example:
-
-hdc\_std tmode port 8710
-
-> **NOTE:**
->After this command is executed, the remote daemon process exits and restarts, and the TCP connection is enabled by default. If you do not include **port-number** in this command, a random port will be used to connect to the device.
-
-## File Commands
-
-The following commands are available:
-
-- **file send _local remote_**
-
-Sends a file to a remote device.
-
-**Table 10** Command description
-
-
-
-
-Example:
-
-hdc\_std hilog
-
-- **shell \[_command_\]**
-
-Executes a command remotely or enters an interactive command environment.
-
-**Table 15** Command description
-
-
-
Parameter
-
-
Description
-
-
-
command
-
-
Command to be executed
-
-
-
Return Value
-
-
Description
-
-
-
Returned information
-
-
Execution result of the command
-
-
-
-
-
-Examples:
-
-hdc\_std shell
-
diff --git a/en/device-dev/subsystems/kws-sdk.md b/en/device-dev/subsystems/kws-sdk.md
deleted file mode 100644
index 50cbbfb0fbf499e95455d7bda54292094b864a4b..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/kws-sdk.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# KWS SDK
-
-1. Add the API of the KWS SDK to the **//foundation/ai/engine /interfaces/kits** directory. This API can be called by third-party applications. The following code snippet is an example API for the KWS SDK. The reference code is available at the **//foundation/ai/engine /interfaces/kits/asr/keyword\_spotting** directory.
-
- ```
- class KWSSdk {
- public:
- KWSSdk();
- virtual ~KWSSdk();
-
- // Create a KWS SDK instance.
- int32_t Create();
-
- // Synchronously execute the KWS task.
- int32_t SyncExecute(const Array &audioInput);
-
- // Set the KWS callback.
- int32_t SetCallback(const std::shared_ptr &callback);
-
- // Destroy the KWS SDK instance to release the session engaged with the plug-in.
- int32_t Destroy();
- };
- ```
-
-2. Add the API implementation of the SDK to the **//foundation/ai/engine/services/client/algorithm\_sdk** directory and call the APIs provided by the client to use the algorithm plug-in capabilities. The following code snippet is an example implementation of the **create** method in the API of the KWS SDK. For more details, see the reference code at **//foundation/ai/engine/services/client/algorithm\_sdk/asr/keyword\_spotting**.
-
- ```
- int32_t KWSSdk::KWSSdkImpl::Create()
- {
- if (kwsHandle_ != INVALID_KWS_HANDLE) {
- HILOGE("[KWSSdkImpl]The SDK has been created");
- return KWS_RETCODE_FAILURE;
- }
- if (InitComponents() != RETCODE_SUCCESS) {
- HILOGE("[KWSSdkImpl]Fail to init sdk components");
- return KWS_RETCODE_FAILURE;
- }
- // Call the AieClientInit API provided by the client to initialize the engine service and activate IPC call.
- int32_t retCode = AieClientInit(configInfo_, clientInfo_, algorithmInfo_, nullptr);
- if (retCode != RETCODE_SUCCESS) {
- HILOGE("[KWSSdkImpl]AieClientInit failed. Error code[%d]", retCode);
- return KWS_RETCODE_FAILURE;
- }
- if (clientInfo_.clientId == INVALID_CLIENT_ID) {
- HILOGE("[KWSSdkImpl]Fail to allocate client id");
- return KWS_RETCODE_FAILURE;
- }
- DataInfo inputInfo = {
- .data = nullptr,
- .length = 0,
- };
- DataInfo outputInfo = {
- .data = nullptr,
- .length = 0,
- };
- // Call the AieClientPrepare API provided by the client to load the algorithm plug-in.
- retCode = AieClientPrepare(clientInfo_, algorithmInfo_, inputInfo, outputInfo, nullptr);
- if (retCode != RETCODE_SUCCESS) {
- HILOGE("[KWSSdkImpl]AieclientPrepare failed. Error code[%d]", retCode);
- return KWS_RETCODE_FAILURE;
- }
- if (outputInfo.data == nullptr || outputInfo.length <= 0) {
- HILOGE("[KWSSdkImpl]The data or length of output info is invalid");
- return KWS_RETCODE_FAILURE;
- }
- MallocPointerGuard pointerGuard(outputInfo.data);
- retCode = PluginHelper::UnSerializeHandle(outputInfo, kwsHandle_);
- if (retCode != RETCODE_SUCCESS) {
- HILOGE("[KWSSdkImpl]Get handle from inputInfo failed");
- return KWS_RETCODE_FAILURE;
- }
- return KWS_RETCODE_SUCCESS;
- }
- ```
-
- The preceding code is the specific API implementation. The **create** function in the API of the KWS SDK calls the open **AieClientInit** and **AieClientPrepare** APIs provided by the client to connect to the server and load the algorithm model. For details, see the implementation of the **create** method in following sections.
-
- > **NOTE:**
- >The sequence for the SDK to call client APIs: **AieClientInit** -\> **AieClientPrepare** -\> **AieClientSyncProcess** or **AieClientAsyncProcess** -\> **AieClientRelease** -\> **AieClientDestroy**. An exception will be thrown if the call sequence is violated.
-
-
diff --git a/en/device-dev/subsystems/multimedia.md b/en/device-dev/subsystems/multimedia.md
deleted file mode 100644
index 47ec966c82b0b54452feb625537d36538ca9c14e..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/multimedia.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Multimedia
-
-- **[Camera](camera.md)**
-
-- **[Audio/Video](audio-video.md)**
-
-
diff --git a/en/device-dev/subsystems/oem_subsys_toolchain_hdc_guide.md b/en/device-dev/subsystems/oem_subsys_toolchain_hdc_guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..8116d317a2f56abdd4fcd5304d2c5076fd5fdf6b
--- /dev/null
+++ b/en/device-dev/subsystems/oem_subsys_toolchain_hdc_guide.md
@@ -0,0 +1,706 @@
+# hdc\_std Usage Guidelines
+
+- [Preparations](#section05992022154916)
+- [Important Notes](#section19543134915210)
+- [Option-related Commands](#section618522925119)
+ - [-h/help -v/version](#section51533527212)
+ - [-t key](#section1180555115159)
+
+- [Querying the Device List](#section174891132104218)
+ - [list targets\[-v\]](#section12911142313168)
+
+- [Service Process Commands](#section680531510497)
+ - [target mount](#section396717571168)
+ - [smode \[off\]](#section179951621713)
+ - [kill \[-r\]](#section419144621712)
+ - [start \[-r\]](#section184811812183)
+
+- [Network Commands](#section71176123212)
+ - [tconn host\[:port\]\[-remove\]](#section191911334206)
+ - [tmode usb](#section17840182562015)
+ - [tmode port port-number](#section101113462113)
+
+- [File Commands](#section173133523013)
+ - [file send local remote](#section126223231307)
+ - [file recv \[-a\] remote local](#section26966541304)
+
+- [App Commands](#section2072647133819)
+ - [install \[-r/-d/-g\] package](#section49615195111)
+ - [uninstall \[-k\] package](#section167618461814)
+
+- [Debugging Commands](#section112861250195015)
+ - [hilog](#section32171612221)
+ - [shell \[command\]](#section524235625)
+
+- [Troubleshooting](#section592920255582)
+ - [hdc\_std Fails to Connect to a Device](#section74019384588)
+
+- [hdc\_std Fails to Run](#section6825095917)
+
+hdc\_std \(OpenHarmony Device Connector\) is a command line tool provided by OpenHarmony for debugging. With this tool, you can interact with real devices or simulators from a Windows or Linux OS.
+
+This section describes how to set up the hdc\_std environment and use its common commands.
+
+## Preparations
+
+**Obtaining hdc\_std:**
+
+Obtain hdc\_std from the **developtools\_hdc\_standard** repository in the **prebuilt** directory.
+
+**Example:**
+
+To obtain hdc\_std on Windows, obtain the executable file **hdc\_std.exe** from **prebuilt/windows** and place it in a directory on the disk.
+
+## Important Notes
+
+- If an exception occurs when you are using hdc\_std, run the **hdc\_std kill** command to kill the hdc\_std service or run the **hdc\_std start -r** command to restart the service process.
+- If no device information is obtained after **hdc\_std list targets** is executed, use the task manager to check whether the **hdc.exe** process exists. If it exists, kill the process.
+
+## Option-related Commands
+
+The following commands are available:
+
+### -h/help -v/version
+
+Obtains hdc help and version information.
+
+**Table 1** Command description
+
+
+
Return Value
+
+
Description
+
+
+
Required information
+
+
hdc help or version information
+
+
+
+
+
+Examples:
+
+hdc\_std -h / hdc\_std help
+
+hdc\_std -v / hdc\_std version
+
+### -t key
+
+Connects to a device with a specified key.
+
+**Table 2** Command description
+
+
+
Parameter
+
+
Description
+
+
+
key
+
+
Key that identifies the device. The value is in the IP address:Port number format or is a USB serial number.
+
+
+
Return Value
+
+
Description
+
+
+
1. error: device '***' not found
+
②Nothing to do...
+
+
1. The device does not exist.
+
2. The command appended to -t key does not exist.
+
+
+
+
+
+Examples:
+
+This option must be used together with a specific operation command. The following uses the shell command as an example:
+
+**hdc\_std list targets** \(obtain device information\)
+
+**hdc\_std -t _key_ shell** \(replace _key_ with the device information obtained\)
+
+> **NOTE:**
+>You can connect to multiple devices from the device you use for development. Each device has a unique key. The key can be _IP address:Port number_ for a device connected through a network or the serial number for a device connected through USB.
+
+## Querying the Device List
+
+The following command is used to query the device list:
+
+### list targets\[-v\]
+
+Displays all the connected devices.
+
+**Table 3** Command description
+
+
+
Parameter
+
+
Description
+
+
+
-v
+
+
Prints detailed device information.
+
+
+
Return Value
+
+
Description
+
+
+
1. Device information
+
②[Empty]
+
+
1. A list of connected devices
+
2. No device information is found.
+
+
+
+
+
+Examples:
+
+hdc\_std list targets
+
+hdc\_std list targets -v
+
+## Service Process Commands
+
+The following commands are available:
+
+### target mount
+
+Mounts a partition, such as **/system**, with the read and write permissions.
+
+**Table 4** Command description
+
+
+
Parameter
+
+
Description
+
+
+
None
+
+
None
+
+
+
Return Value
+
+
Description
+
+
+
①Mount finish
+
2. Returned information
+
+
1. Information returned when the operation is successful.
+
2. Information returned when the operation fails.
+
+
+
+
+
+Example:
+
+hdc\_std target mount
+
+### smode \[off\]
+
+Grants the root permission to a background service process. The **off** option is used to revoke the granted permission.
+
+Examples:
+
+hdc\_std smode
+
+hdc\_std smode off
+
+### kill \[-r\]
+
+Stops a service process.
+
+**Table 5** Command description
+
+
+
Parameter
+
+
Description
+
+
+
-r
+
+
Triggers the service restart.
+
+
+
Return Value
+
+
Description
+
+
+
①Kill server finish
+
2. Error information
+
+
1. Information returned when the operation is successful.
+
+Examples:
+
+hdc\_std start
+
+## Network Commands
+
+The following commands are available:
+
+### tconn _host_\[:_port_\]\[-remove\]
+
+Connects to a device with a specified IP address and port number.
+
+**Table 7** Command description
+
+
+
Parameter
+
+
Description
+
+
+
host[:port]
+
+
IP address and port number of the device to be connected
+
+
+
-remove
+
+
Disconnects from the specified device.
+
+
+
Return Value
+
+
Description
+
+
+
1. Error information
+
2. None
+
+
1. The operation fails.
+
2. The operation is successful.
+
+
+
+
+
+Example:
+
+hdc\_std tconn 192.168.0.100:8710
+
+### tmode usb
+
+Restarts the daemon process and connects to the device using USB.
+
+**Table 8** Command description
+
+
+
Parameter
+
+
Description
+
+
+
None
+
+
None
+
+
+
Return Value
+
+
Description
+
+
+
1. Error information
+
2. None
+
+
1. The operation fails.
+
2. The operation is successful.
+
+
+
+
+
+Example:
+
+hdc\_std tmode usb
+
+### tmode port _port-number_
+
+Restarts the daemon process and connects to the device over TCP.
+
+**Table 9** Command description
+
+
+
Parameter
+
+
Description
+
+
+
port-number
+
+
Port number used to connect to the device
+
+
+
Return Value
+
+
Description
+
+
+
1. Error information
+
2. None
+
+
1. The operation fails.
+
2. The operation is successful.
+
+
+
+
+
+Example:
+
+hdc\_std tmode port 8710
+
+> **NOTE:**
+>After this command is executed, the remote daemon process exits and restarts, and the TCP connection is enabled by default. If you do not include **port-number** in this command, a random port will be used to connect to the device.
+
+## File Commands
+
+The following commands are available:
+
+### file send _local remote_
+
+Sends a file to a remote device.
+
+**Table 10** Command description
+
+
+
+
+Example:
+
+hdc\_std hilog
+
+### shell \[_command_\]
+
+Executes a command remotely or enters an interactive command environment.
+
+**Table 15** Command description
+
+
+
Parameter
+
+
Description
+
+
+
command
+
+
Command to be executed
+
+
+
Return Value
+
+
Description
+
+
+
Returned information
+
+
Execution result of the command
+
+
+
+
+
+Examples:
+
+hdc\_std shell
+
+## Troubleshooting
+
+### hdc\_std Fails to Connect to a Device
+
+- **Symptom**
+
+ **\[Empty\]** is displayed in the output after the **hdc\_std list targets** command is executed.
+
+- **Solutions**
+ 1. The device cannot be identified.
+
+ Check whether **HDC Device** exists in the universal serial bus device of the device manager. If **HDC Device** does not exist, the device cannot be connected. In this case, remove and then insert the device or burn the latest image for the device.
+
+ 2. hdc\_std works improperly.
+
+ Run the **hdc kill** or **hdc start -r** command to kill or restart the hdc service. Then, run the **hdc list targets** command to check whether device information can be obtained.
+
+ 3. hdc\_std does not match the device.
+
+ If the latest image is burnt on the device, the latest hdc\_std version must be used. As hdc\_std is updated continuously, obtain hdc\_std of the latest version from the **developtools\_hdc\_standard** repository in the **prebuilt** directory.
+
+
+
+## hdc\_std Fails to Run
+
+- **Symptom**
+
+ The **hdc\_std.exe** file does not run after being clicked.
+
+- **Solutions**
+
+ **hdc\_std.exe** requires no installation. It can be directly used on a disk or added to environment variables. Open the cmd window and run the **hdc\_std** command to use **hdc\_std.exe**.
+
+
diff --git a/en/device-dev/subsystems/utils-overview.md b/en/device-dev/subsystems/oem_subsys_utils_des.md
similarity index 100%
rename from en/device-dev/subsystems/utils-overview.md
rename to en/device-dev/subsystems/oem_subsys_utils_des.md
diff --git a/en/device-dev/subsystems/utils-faq.md b/en/device-dev/subsystems/oem_subsys_utils_faq.md
similarity index 100%
rename from en/device-dev/subsystems/utils-faq.md
rename to en/device-dev/subsystems/oem_subsys_utils_faq.md
diff --git a/en/device-dev/subsystems/oem_subsys_utils_guide.md b/en/device-dev/subsystems/oem_subsys_utils_guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..48a566a1a921eb5f3a6fcaadbc2b47a852b0b2aa
--- /dev/null
+++ b/en/device-dev/subsystems/oem_subsys_utils_guide.md
@@ -0,0 +1,293 @@
+# Utils Development Guidelines
+
+- [Available APIs](#section1633115419401)
+- [How to Develop](#section17450172710292)
+ - [Developing a Native Application for the KV Store That Uses the LiteOS Cortex-A Kernel \(Hi3516 or Hi3518\)](#section258354119295)
+ - [Dumping System Attributes on the Platform That Uses the LiteOS Cortex-M Kernel](#section9179161863014)
+ - [Dumping System Attributes on the Platform That Uses the LiteOS Cortex-A Kernel](#section3179121853017)
+
+
+## Available APIs
+
+**Table 1** APIs for file operations
+
+
+
Function
+
+
Description
+
+
+
+
int UtilsFileOpen(const char* path, int oflag, int mode)
+
+
Opens or creates a file.
+
+
+
int UtilsFileClose(int fd)
+
+
Closes a file with a specified file descriptor.
+
+
+
int UtilsFileRead(int fd, char *buf, unsigned int len)
+
+
Reads a specified length of data from a file with the specified file descriptor and writes the data into the buffer.
+
+
+
int UtilsFileWrite(int fd, const char *buf, unsigned int len)
+
+
Writes a specified length of data into a file with the specified file descriptor.
+
+
+
int UtilsFileDelete(const char *path)
+
+
Deletes a specified file.
+
+
+
int UtilsFileStat(const char *path, unsigned int *fileSize)
+
+
Obtains the file size.
+
+
+
int UtilsFileSeek(int fd, int offset, unsigned int whence)
+
+
Adjusts the read and write position offset in a file.
+
+
+
int UtilsFileCopy(const char* src, const char* dest)
+
+
Copies the source file to a target file.
+
+
+
int UtilsFileMove(const char* src, const char* dest)
+
+
Moves the source file into a target file.
+
+
+
+
+
+Sample code for file operations:
+
+```
+// Open a file and write data.
+char fileName[] = "testfile";
+static const char def[] = "utils_file_operation implement.";
+int fd = UtilsFileOpen(fileName, O_RDWR_FS | O_CREAT_FS | O_TRUNC_FS, 0);
+printf("file handle = %d\n", fd);
+int ret = UtilsFileWrite(fd, def, strlen(def));
+printf("write ret = %d\n", ret);
+
+// Adjust the position offset in the file.
+ret = UtilsFileSeek(fd, 5, SEEK_SET_FS);
+printf("lseek ret = %d\n", ret);
+
+// Read data and close the file.
+char buf[64] = {0};
+int readLen = UtilsFileRead(fd, buf, 64);
+ret = UtilsFileClose(fd);
+printf("read len = %d : buf = %s\n", readLen, buf);
+
+// Obtain the file size.
+int fileLen = 0;
+ret = UtilsFileStat(fileName, &fileLen);
+printf("file size = %d\n", fileLen);
+
+// Delete the file.
+ret = UtilsFileDelete(fileName);
+printf("delete ret = %d\n", ret);
+```
+
+**Table 2** APIs for KV store operations
+
+
+
Function
+
+
Description
+
+
+
+
int UtilsGetValue(const char* key, char* value, unsigned int len)
+
+
Obtains the value matching a specified key from the file system or cache.
+
+
+
int UtilsSetValue(const char* key, const char* value)
+
+
Adds or updates the value matching a specified key in the file system or cache.
+
+
+
int UtilsDeleteValue(const char* key)
+
+
Deletes the value matching a specified key from the file system or cache.
+
+
+
+
+
+Sample code for the KV store:
+
+```
+// Set the value matching the specified key.
+char key[] = "rw.sys.version_100";
+char value[] = "Hello kv operation implement!";
+int ret = UtilsSetValue(key, value);
+printf("UtilsSetValue set ret = %d\n", ret);
+
+// Obtain the value matching the specified key.
+char temp[128] = {0};
+ret = UtilsGetValue(key, temp, 128);
+printf("UtilsGetValue get ret = %d, temp = %s\n", ret, temp);
+
+// Delete the value matching the specified key.
+ret = UtilsDeleteValue(key);
+printf("UtilsDeleteValue delete ret = %d\n", ret);
+```
+
+## How to Develop
+
+### Developing a Native Application for the KV Store That Uses the LiteOS Cortex-A Kernel \(Hi3516 or Hi3518\)
+
+1. Develop the native application for the KV store using **AbilityKit** APIs.
+ - Write the user program by calling the APIs provided by the KV store and compile the **libLauncher.so** file.
+
+ ```
+ // Set the value matching the specified key.
+ char key[] = "rw.sys.version_100";
+ char value[] = "Hello kv operation implement!";
+ int ret = UtilsSetValue(key, value);
+ printf("UtilsSetValue set ret = %d\n", ret);
+
+ // Obtain the value matching the specified key.
+ char temp[128] = {0};
+ ret = UtilsGetValue(key, temp, 128);
+ printf("UtilsGetValue get ret = %d, temp = %s\n", ret, temp);
+
+ // Delete the value matching the specified key.
+ ret = UtilsDeleteValue(key);
+ printf("UtilsDeleteValue delete ret = %d\n", ret);
+ ```
+
+ - Edit the **config.json** file as follows:
+
+ ```
+ {
+ "app": {
+ "bundleName": "com.huawei.launcher",
+ "vendor": "huawei",
+ "version": {
+ "code": 1,
+ "name": "1.0"
+ }
+ },
+ "deviceConfig": {
+ "default": {
+ "reqSdk": {
+ "compatible": "zsdk 1.0.0",
+ "target": "zsdk 1.0.1"
+ },
+ "keepAlive": false
+ },
+ "smartCamera": {
+ "reqSdk": {
+ "compatible": "zsdk 1.0.0",
+ "target": "zsdk 1.0.1"
+ },
+ "keepAlive": false
+ }
+ },
+ "module": {
+ "package": "com.huawei.launcher",
+ "name": ".MyHarmonyAbilityPackage",
+ "deviceType": [
+ "phone", "tv","tablet", "pc","car","smartWatch","sportsWatch","smartCamera"
+ ],
+ "distro": {
+ "deliveryWithInstall": true,
+ "moduleName": "Launcher",
+ "moduleType": "entry"
+ },
+ "abilities": [{
+ "name": "MainAbility",
+ "icon": "res/drawable/phone.png",
+ "label": "test app 1",
+ "launchType": "standard",
+ "type": "page"
+ },
+ {
+ "name": "SecondAbility",
+ "icon": "res/drawable/phone.png",
+ "label": "test app 2",
+ "launchType": "standard",
+ "type": "page"
+ },
+ {
+ "name": "ServiceAbility",
+ "icon": "res/drawable/phone.png",
+ "label": "test app 2",
+ "launchType": "standard",
+ "type": "service"
+ }
+ ]
+ }
+ }
+ ```
+
+
+ - Generate a HAP file.
+
+ - Add resource files in the **res/drawable** directory based on the following directory structure.
+
+ 
+
+ - 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.
+
+ ```
+ ./nfs/dev_tools/bin/bm install -p /nfs/Launcher.hap
+ ```
+
+3. Send the command for running the native KV store application to the board through the serial port.
+
+ ```
+ ./nfs/dev_tools/bin/aa start -p com.huawei.launcher -n ServiceAbility
+ ```
+
+
+### Dumping System Attributes on the Platform That Uses the LiteOS Cortex-M Kernel
+
+1. Connect the development board and send the **AT+SYSPARA** command to the board through the serial port.
+
+ ```
+ AT+SYSPARA
+ ```
+
+ **Figure 1** Output of the system attribute dumping command for the LiteOS Cortex-M kernel
+ 
+
+
+### Dumping System Attributes on the Platform That Uses the LiteOS Cortex-A Kernel
+
+1. Connect the development board and run the **os\_dump --help** command in the **bin** directory to view the **os\_dump** help information.
+
+ ```
+ ./bin/os_dump --help
+ ```
+
+2. Run the **os\_dump -l** command in the **bin** directory to view system modules that support attribute dumping.
+
+ ```
+ ./bin/os_dump -l
+ ```
+
+3. Run the **os\_dump syspara** command in the **bin** directory to dump the current system attributes.
+
+ ```
+ ./bin/os_dump syspara
+ ```
+
+ **Figure 2** Output of the system attribute dumping command for the LiteOS Cortex-A kernel
+ 
+
+
diff --git a/en/device-dev/subsystems/ota-upgrade.md b/en/device-dev/subsystems/ota-upgrade.md
deleted file mode 100644
index 6e6a648ba8aa60a29d3263ceb53401e4cfc5802f..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/ota-upgrade.md
+++ /dev/null
@@ -1,358 +0,0 @@
-# OTA Upgrade
-
-- [Limitations and Constraints](#section691733275418)
-- [Generating a Public/Private Key Pair](#section94411533155010)
-- [Generating an Upgrade Package](#section632383718539)
-- [Uploading the Upgrade Package](#section5772112473213)
-- [Downloading the Upgrade Package](#section251732474917)
-- [Integrating OTA Update Capabilities](#section298217330534)
-- [API Application Scenario \(Default\)](#section7685171192916)
- - [How to Develop](#section0745926153017)
- - [Sample Code](#section1337111363306)
-
-- [API Application Scenario \(Custom\)](#section1686395317306)
- - [How to Develop](#section524515314317)
- - [Sample Code](#section525974743120)
-
-- [Upgrading the System](#section151997114334)
-
-Over the Air \(OTA\) is a technology that makes it easier for you to remotely update devices, such as IP cameras. A device can be upgraded with a full or differential package. A full package contains all content of a new system, and a differential package contains the differences between the old and new systems. Currently, only the full-package upgrade is supported.
-
-## Limitations and Constraints
-
-- The open-source suites for devices developed based on Hi3861, Hi3518E V300 and Hi3516D V300 are supported.
-- Devices developed based on Hi3518E V300 and Hi3516D V300 must support the SD card in the Virtual Festival of Aerobatic Teams \(VFAT\) format.
-
-## Generating a Public/Private Key Pair
-
-1. Download the OpenSSL tool from the following website and install it on a Windows PC, and configure environment variables.
-
- [http://slproweb.com/products/Win32OpenSSL.html](http://slproweb.com/products/Win32OpenSSL.html)
-
-2. Access the **tools\\update\_tools\\update\_pkg\_tools** directory, download the upgrade package making tool, and save it to a local directory, for example, **D:\\ota\_tools**.
-3. Run **Generate\_public\_private\_key.bat** in the **ota\_tools\\key** directory to generate **Metis\_PUBLIC.key**, **private.key**, and **public\_arr.txt** that contains public values, as shown in the following figure. Keep the private key properly.
-
- **Figure 1** Generating a Public/Private Key Pair
-
-
- 
-
-4. Use the array written in **public\_arr.txt** as a substitute for **g\_pubKeyBuf** in **base\\update\\ota\_lite\\frameworks\\source\\verify\\hota\_verify.c** of the OTA module.
-
- Example array in **public\_arr.txt**:
-
- ```
- 0x30,0x82,0x1,0xa,0x2,0x82,0x1,0x1,0x0,0xc7,0x8c,0xf3,0x91,0xa1,0x98,0xbf,0xb1,0x8c,
- 0xbe,0x22,0xde,0x32,0xb2,0xfa,0xec,0x2c,0x69,0xf6,0x8f,0x43,0xa7,0xb7,0x6f,0x1e,0x4a,0x97,
- 0x4b,0x27,0x5d,0x56,0x33,0x9a,0x73,0x4e,0x7c,0xf8,0xfd,0x1a,0xf0,0xe4,0x50,0xda,0x2b,0x8,
- 0x74,0xe6,0x28,0xcc,0xc8,0x22,0x1,0xa8,0x14,0x9,0x46,0x46,0x6a,0x10,0xcd,0x39,0xd,0xf3,
- 0x4a,0x7f,0x1,0x63,0x21,0x33,0x74,0xc6,0x4a,0xeb,0x68,0x40,0x55,0x3,0x80,0x1d,0xd9,0xbc,
- 0xd4,0xb0,0x4a,0x84,0xb7,0xac,0x43,0x1d,0x76,0x3a,0x61,0x40,0x23,0x3,0x88,0xcc,0x80,0xe,
- 0x75,0x10,0xe4,0xad,0xac,0xb6,0x4c,0x90,0x8,0x17,0x26,0x21,0xff,0xbe,0x1,0x82,0x16,0x76,
- 0x9a,0x1c,0xee,0x8e,0xd9,0xb0,0xea,0xd5,0x50,0x61,0xcc,0x9c,0x2e,0x78,0x15,0x2d,0x1f,0x8b,
- 0x94,0x77,0x30,0x39,0x70,0xcf,0x16,0x22,0x82,0x99,0x7c,0xe2,0x55,0x37,0xd4,0x76,0x9e,0x4b,
- 0xfe,0x48,0x26,0xc,0xff,0xd9,0x59,0x6f,0x77,0xc6,0x92,0xdd,0xce,0x23,0x68,0x83,0xbd,0xd4,
- 0xeb,0x5,0x1b,0x2a,0x7e,0xda,0x9a,0x59,0x93,0x41,0x7b,0x4d,0xef,0x19,0x89,0x4,0x8d,0x5,
- 0x7d,0xbc,0x3,0x1f,0x77,0xe6,0x3d,0xa5,0x32,0xf5,0x4,0xb7,0x9c,0xe9,0xfa,0x6e,0xc,0x9f,
- 0x4,0x62,0xfe,0x2a,0x5f,0xbf,0xeb,0x9a,0x73,0xa8,0x2a,0x72,0xe3,0xf0,0x57,0x56,0x5c,0x59,
- 0x14,0xdd,0x79,0x11,0x42,0x3a,0x48,0xf7,0xe8,0x80,0xb1,0xaf,0x1c,0x40,0xa2,0xc6,0xec,0xf5,
- 0x67,0xc1,0x88,0xf6,0x26,0x5c,0xd3,0x11,0x5,0x11,0xed,0xb1,0x45,0x2,0x3,0x1,0x0,0x1,
- ```
-
- Example configuration for the public key of the OTA module:
-
- ```
- #define PUBKEY_LENGTH 270
-
- static uint8 g_pubKeyBuf[PUBKEY_LENGTH] = {
- 0x30, 0x82, 0x01, 0x0A, 0x02, 0x82, 0x01, 0x01, 0x00, 0xBF, 0xAA, 0xA5, 0xB3, 0xC2, 0x78, 0x5E,
- 0x63, 0x07, 0x84, 0xCF, 0x37, 0xF0, 0x45, 0xE8, 0xB9, 0x6E, 0xEF, 0x04, 0x88, 0xD3, 0x43, 0x06,
- ```
-
-5. \(Optional\) For Hi3518E V300 and Hi3516D V300 suites, further replace the array written in **g\_pub\_key** with that in **public\_arr.txt**. The **g\_pub\_key** file is provided in **device\\hisilicon\\third\_party\\uboot\\u-boot-2020.01\\product\\hiupdate\\verify\\update\_public\_key.c** of the U-Boot module.
-
- Example configuration for the public key of the U-Boot module:
-
- ```
- static unsigned char g_pub_key[PUBKEY_LEN] = {
- 0x30, 0x82, 0x01, 0x0A, 0x02, 0x82, 0x01, 0x01,
- 0x00, 0xBF, 0xAA, 0xA5, 0xB3, 0xC2, 0x78, 0x5E,
- ```
-
-
-## Generating an Upgrade Package
-
-1. Save the files to be upgraded in the **ota\_tools\\Components** directory.
-
- **Figure 2** Location of original image files
-
-
- 
-
- **Table 1** Files to be upgraded
-
-
-
File
-
-
Description
-
-
-
-
u-boot.bin
-
-
Renamed from the u-boot-hi351XevX00.bin file generated after compilation.
-
-
-
kernel.bin
-
-
Renamed from the liteos.bin or kernel file generated after compilation.
-
-
-
rootfs.img
-
-
Renamed from the rootfs_xxxxx.img file generated after compilation.
-
-
-
config
-
-
Provides development board and kernel information. For details, see the SD card burning description of the corresponding open-source suite.
-
-
-
OTA.tag
-
-
Contains 32 bytes in the package_type:otaA1S2D3F4G5H6J7K8 format. The last 16 bytes are random, varying with the version.
-
-
-
-
-
-2. Open the **packet\_harmony.xml** file in **ota\_tools\\xml** to modify **compAddr** as follows. Other items are reserved.
-
- Example configuration for the component information:
-
- ```
-
-
- .\Components\rootfs_jffs2.img
- .\Components\liteos.bin
- .\Components\userfs_jffs2.img
-
- ```
-
-3. Configure the paths of private and public keys in **packet\_harmony.xml**.
-
- Example configuration for paths of private and public keys:
-
- ```
-
- .\key\private.key
- .\key\Metis_PUBLIC.key
-
- ```
-
-4. Configure the product name and software version in **ota\_tools\\VersionDefine.bat** for anti-rollback.
-
- Example configuration for the product name and software version:
-
- ```
- set FILE_PRODUCT_NAME=Hisi
-
- @rem Set the software version number to a string of no more than 16 characters.
- set SOFTWARE_VER=OHOS_1.1
- ```
-
-5. Run **Make\_Harmony\_PKG.bat** in the **ota\_tools** directory to generate the **Hisi\_OpenHarmony 1.1.bin** upgrade package. The upgrade package is signed using **SHA-256** and **RSA 2048** to ensure its integrity and validity.
-
- **Figure 3** Upgrade package making tool
-
-
- 
-
-
-## Uploading the Upgrade Package
-
-Upload the **Hisi\_OpenHarmony 1.1.bin** upgrade package to the vendor's OTA server.
-
-## Downloading the Upgrade Package
-
-1. Download the **Hisi\_OpenHarmony 1.1.bin** upgrade package from the OTA server.
-2. \(Optional\) Insert an SD card \(capacity greater than 100 MB\) if the device is developed based on Hi3518E V300 or Hi3516D V300.
-
-## Integrating OTA Update Capabilities
-
-- If vendors request OTA capabilities, use the dynamic library **libhota.so** and include the header files **hota\_partition.h** and **hota\_updater.h** in **base\\update\\ota\_lite\\interfaces\\kits**.
-- The **libhota.so** source code is stored in **base\\update\\ota\_lite\\frameworks\\source**.
-- For details about how to use APIs, see [API Application Scenario \(Default\)](#section7685171192916) and OTA APIs in _API Reference_.
-- If the development board needs to be adapted, see the **base\\update\\ota\_lite\\hals\\hal\_hota\_board.h** header file.
-
-## API Application Scenario \(Default\)
-
-The upgrade package is generated by following the instructions provided in [Generating a Public/Private Key Pair](#section94411533155010) and [Generating an Upgrade Package](#section632383718539).
-
-### **How to Develop**
-
-1. Download the upgrade package for the current device, and then call the **HotaInit** function to initialize the OTA module.
-2. Call the **HotaWrite** function to verify, parse, and write data streams into the device.
-3. Call the **HotaRestart** function to restart the system.
-
- If you want to cancel the upgrade, call the **HotaCancel** function.
-
-
-### **Sample Code**
-
-Perform an OTA update using the upgrade package format and verification method provided by OpenHarmony.
-
-```
-int main(int argc, char **argv)
-{
- printf("this is update print!\r\n");
- if (HotaInit(NULL, NULL) < 0) {
- printf("ota update init fail!\r\n");
- return -1;
- }
- int fd = open(OTA_PKG_FILE, O_RDWR, S_IRUSR | S_IWUSR);
- if (fd < 0) {
- printf("file open failed, fd = %d\r\n", fd);
- (void)HotaCancel();
- return -1;
- }
- int offset = 0;
- int fileLen = lseek(fd, 0, SEEK_END);
- int leftLen = fileLen;
- while (leftLen > 0) {
- if (lseek(fd, offset, SEEK_SET) < 0) {
- close(fd);
- printf("lseek fail!\r\n");
- (void)HotaCancel();
- return -1;
- }
- int tmpLen = leftLen >= READ_BUF_LEN ? READ_BUF_LEN : leftLen;
- (void)memset_s(g_readBuf, READ_BUF_LEN, 0, READ_BUF_LEN);
- if (read(fd, g_readBuf, tmpLen) < 0) {
- close(fd);
- printf("read fail!\r\n");
- (void)HotaCancel();
- return -1;
- }
- if (HotaWrite((unsigned char *)g_readBuf, offset, tmpLen) != 0) {
- printf("ota write fail!\r\n");
- close(fd);
- (void)HotaCancel();
- return -1;
- }
- offset += READ_BUF_LEN;
- leftLen -= tmpLen;
- }
- close(fd);
- printf("ota write finish!\r\n");
- printf("device will reboot in 10s...\r\n");
- sleep(10);
- (void)HotaRestart();
- return 0;
-}
-```
-
-## API Application Scenario \(Custom\)
-
-The upgrade package is generated in other ways instead of by referring to the preceding two sections.
-
-### **How to Develop**
-
-1. Download the upgrade package for the current device, and then call the **HotaInit** function to initialize the OTA module.
-2. Call the **HotaSetPackageType** function to set the package type to **NOT\_USE\_DEFAULT\_PKG**.
-3. Call the **HotaWrite** function to write data streams into the device.
-4. Call the **HotaRead** function to read data. Vendors can choose to verify the data.
-5. \(Optional\) Call the **HotaSetBootSettings** function to set the startup tag used for entering the U-Boot mode after restarting the system.
-6. Call the **HotaRestart** function to restart the system.
-
- If you want to cancel the upgrade, call the **HotaCancel** function.
-
-
-### **Sample Code**
-
-Perform an OTA update using the upgrade package format and verification method not provided by OpenHarmony.
-
-```
-int main(int argc, char **argv)
-{
- printf("this is update print!\r\n");
- if (HotaInit(NULL, NULL) < 0) {
- printf("ota update init fail!\r\n");
- (void)HotaCancel();
- return -1;
- }
- (void)HotaSetPackageType(NOT_USE_DEFAULT_PKG);
- int fd = open(OTA_PKG_FILE, O_RDWR, S_IRUSR | S_IWUSR);
- if (fd < 0) {
- printf("file open failed, fd = %d\r\n", fd);
- (void)HotaCancel();
- return -1;
- }
- int offset = 0;
- int fileLen = lseek(fd, 0, SEEK_END);
- int leftLen = fileLen;
- while (leftLen > 0) {
- if (lseek(fd, offset, SEEK_SET) < 0) {
- close(fd);
- printf("lseek fail!\r\n");
- (void)HotaCancel();
- return -1;
- }
- int tmpLen = leftLen >= READ_BUF_LEN ? READ_BUF_LEN : leftLen;
- (void)memset_s(g_readBuf, READ_BUF_LEN, 0, READ_BUF_LEN);
- if (read(fd, g_readBuf, tmpLen) < 0) {
- close(fd);
- printf("read fail!\r\n");
- (void)HotaCancel();
- return -1;
- }
- if (HotaWrite((unsigned char *)g_readBuf, offset, tmpLen) != 0) {
- printf("ota write fail!\r\n");
- close(fd);
- (void)HotaCancel();
- return -1;
- }
- offset += READ_BUF_LEN;
- leftLen -= tmpLen;
- }
- close(fd);
- printf("ota write finish!\r\n");
- leftLen = fileLen;
- while (leftLen > 0) {
- int tmpLen = leftLen >= READ_BUF_LEN ? READ_BUF_LEN : leftLen;
- (void)memset_s(g_readBuf, READ_BUF_LEN, 0, READ_BUF_LEN);
- if (HotaRead(offset, READ_BUF_LEN, (unsigned char *)g_readBuf) != 0) {}
- printf("ota write fail!\r\n");
- (void)HotaCancel();
- return -1;
- }
- /* do your verify and parse */
- offset += READ_BUF_LEN;
- leftLen -= tmpLen;
- }
- /* set your boot settings */
- (void)HotaSetBootSettings();
- printf("device will reboot in 10s...\r\n");
- sleep(10);
- (void)HotaRestart();
- return 0;
-}
-```
-
-## Upgrading the System
-
-Vendor applications call APIs of the OTA module to perform functions such as signature verification of the upgrade package, anti-rollback, burning and data flushing-to-disk. After the upgrade is complete, the system automatically restarts.
-
-For Hi3518E V300 and Hi3516D V300 open-source suites, the value of **LOCAL\_VERSION** needs to be modified for anti-rollback, for example, modifying **ohos default 1.0** to **ohos default 1.1**. The macro **LOCAL\_VERSION** is provided in **device\\hisilicon\\third\_party\\uboot\\u-boot-2020.01\\product\\hiupdate\\ota\_update\\ota\_local\_info.c**.
-
-Example for modification of the local version:
-
-```
-const char *get_local_version(void)
-{
-#if defined(CONFIG_TARGET_HI3516EV200) || \
- defined(CONFIG_TARGET_HI3516DV300) || \
- defined(CONFIG_TARGET_HI3518EV300)
-#define LOCAL_VERSION "ohos default 1.0" /* increase: default release version */
-```
-
diff --git a/en/device-dev/subsystems/overview-4.md b/en/device-dev/subsystems/overview-4.md
deleted file mode 100644
index be32c8ebf46f3db9ab43c7a48fc0556250a04b7b..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/overview-4.md
+++ /dev/null
@@ -1,148 +0,0 @@
-# Overview
-
-- [Basic Concepts](#section72601941194812)
-- [Ability Management Framework](#section14633111813374)
-- [Bundle Management Framework](#section1341146154412)
-- [Working Principles](#section94302021112717)
-- [Limitations and Constraints](#section89534912527)
-
-The application framework is provided by OpenHarmony for you to develop OpenHarmony applications. It consists of two modules: ability management framework \(also called the ability framework\) and bundle management framework.
-
-## Basic Concepts
-
-This section describes some basic concepts for you to better understand the OpenHarmony application framework before you start development.
-
-## Ability Management Framework
-
-The ability management framework manages running status of OpenHarmony applications.
-
-**Figure 1** Architecture of the ability management framework
-
-
-- **Ability** is the minimum unit for the system to schedule applications. It is a component that can implement an independent functionality. An application can contain one or more **Ability** instances. There are two types of templates that you can use to create an **Ability** instance: Page and Service.
- - An **Ability using the Page template** \(Page ability for short\) provides a UI for interacting with users.
-
- - An **Ability using the Service template** does not have a UI and is used for running background tasks.
-
-
-
-- An **AbilitySlice** represents a single screen and its control logic. It is specific to Page abilities. A Page ability may contain one ability slice or multiple ability slices that provide highly relevant capabilities.
-
- **Figure 2** Relationship between a Page ability and its ability slices
- 
-
-- **Lifecycle** is a general term for all states of an ability, including **INITIAL**, **INACTIVE**, **ACTIVE**, and **BACKGROUND**.
-
- **Figure 3** Lifecycle state transition of a Page ability
-
-
- 
-
- - **OnStart\(\)**
-
- This callback is invoked when the system first creates the Page ability. After this callback is executed, the Page ability enters the **INACTIVE** state. This callback is triggered only once in the entire lifecycle of each Page ability. You must override this callback and set the default ability slice to be displayed.
-
- - **OnActive\(\)**
-
- This callback is invoked when the Page ability in the **INACTIVE** state enters the foreground. After this callback is executed, the Page ability enters the **ACTIVE** state, in which it becomes interactive. The Page ability will stay in this state unless it loses focus upon a certain event, for example, when the user touches the Back button or navigates to another Page ability.
-
- When such an event occurs, the Page ability returns to the **INACTIVE** state, and the system invokes the **OnInactive\(\)** callback. The Page ability may move to the **ACTIVE** state again, and the system will then invoke the **OnActive\(\)** callback again. You should implement both **OnActive\(\)** and **OnInactive\(\)** for a Page ability and use **OnActive\(\)** to obtain the resources released in **OnInactive\(\)**.
-
- - **OnInactive\(\)**
-
- This callback is invoked when the Page ability loses focus, and the Page ability then becomes **INACTIVE**. You can implement the behavior to perform after the Page ability loses focus.
-
- - **OnBackground\(\)**
-
- This callback is invoked based on the system resource status when the Page ability becomes invisible to the user. After this callback is executed, the Page ability enters the **BACKGROUND** state. You should release the resources that are no longer needed after the Page ability becomes invisible or perform time-consuming save operations in this callback.
-
- - **OnForeground\(\)**
-
- A Page ability in the **BACKGROUND** state still resides in memory. When the Page ability returns to the foreground \(for example, when the user navigates to this Page ability again\), the system first calls **OnForeground\(\)** to switch the Page ability to the **INACTIVE** state, and then calls **OnActive\(\)** to make it **ACTIVE**. You should use the **OnForeground\(\)** callback to reclaim the resources released in **OnBackground\(\)**. Currently, the **OnForeground\(\)** callback is unavailable to lite devices.
-
- - **OnStop\(\)**
-
- This callback is invoked when the system is destroying a Page ability due to one of the following possible causes:
-
- - The user explicitly closes the Page ability using a system management feature, for example, the task manager.
- - The user behavior, for example, exiting an application, triggers the **TerminateAbility\(\)** function on the Page ability.
- - The system needs to temporarily destroy the Page ability and re-create it due to configuration changes.
- - The system automatically destroys a Page ability in the **BACKGROUND** state due to resource management purposes.
-
-
-- **AbilityKit** is a development kit provided by the ability management framework. You can use this kit to develop applications based on the **Ability** component. There are two types of applications developed based on the **Ability** component: JS Ability developed using the JavaScript language and Native Ability developed using the C/C++ language. The JS application development framework encapsulates JavaScript UI components on the basis of the AbilityKit and is used to help you quickly develop JS Ability-based applications.
-- **AbilityLoader** is used to register and load **Ability** classes. After creating an **Ability** class, you should first call the registration API defined in **AbilityLoader** to register the **Ability** class name with the ability management framework so that this **Ability** can be instantiated when being started.
-
-- **AbilityManager** enables inter-process communication \(IPC\) between the AbilityKit and the Ability Manager Service.
-
-- **EventHandler** is provided by the AbilityKit to enable inter-thread communication between abilities.
-
-- The **Ability Manager Service** is a system service used to coordinate the running relationships and lifecycle states of **Ability** instances. It consists of the following modules:
-
- - The service startup module starts and registers the Ability Manager Service.
- - The service interface management module manages external capabilities provided by the Ability Manager Service.
- - The process management module starts and destroys processes where **Ability** instances are running, and maintains the process information.
- - The ability stack management module maintains the presentation sequence of abilities in the stack.
- - The lifecycle scheduling module changes an ability to a particular state based on the current operation of the system.
- - The connection management module manages connections to Service abilities.
-
-- **AppSpawn** is a system service used to create the process for running an ability. This service has high permissions. It sets permissions for **Ability** instances and pre-loads some common modules to accelerate application startup.
-
-
-## Bundle Management Framework
-
-The bundle management framework is provided by OpenHarmony for you to manage application bundles.
-
-**Figure 4** Architecture of the bundle management framework
-
-
-- **BundleKit** includes external APIs provided by the Bundle Manager Service, including the APIs for application installation and uninstallation, bundle information query, and bundle state change listeners.
-- The **bundle scanning sub-module** parses pre-installed or installed bundles on the local device and extracts information from them for the bundle management module to manage and make the information persistent for storage.
-- The **bundle installation sub-module** installs, uninstalls, and updates a bundle. The **bundle installation service** is an independent process that communicates with the Bundle Manager Service through IPC. It is used to create or delete installation directories and has high permissions.
-
-- The **bundle management sub-module** manages information related to application bundles and stores persistent bundle information.
-
-- The **bundle security management sub-module** verifies signatures, and grants and manages permissions.
-
-
-## Working Principles
-
-The Ability Manager Service and Bundle Manager Service are the core modules of the ability management framework and bundle management framework, respectively. The two system-level services are registered and discovered by using the system service framework SAMgr, and they are used by manage abilities and bundles for other processes. The Ability Manager Service and Bundle Manager Service are provided as open APIs in the AbilityKit and BundleKit.
-
-**Figure 5** Startup of the Ability Manager Service and Bundle Manager Service
-
-
-OpenHarmony applications can be installed and started after the two services are started.
-
-**Figure 6** Application startup process
-
-
-The home screen is the first OpenHarmony application started by the Ability Manager Service. After the home screen is started, the user can touch any installed OpenHarmony application on the home screen to start the particular application. The figure above shows the interaction process of starting an installed application from the home screen.
-
-As shown in the figure, the Ability Manager Service is responsible for displaying or hiding an ability, and the Bundle Manager Service is responsible for storing and querying ability information.
-
-## Limitations and Constraints
-
-- Language version
-
- - C++ 11 or later
-
-
-- The specifications of the application framework vary depending on the System-on-a-Chip \(SoC\) and underlying OS capabilities.
-
- - Cortex-M RAM and ROM
-
- - RAM: greater than 20 KB \(recommended\)
-
- - 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\)
-
- - ROM: greater than 2 MB \(for the JS application development framework and related subsystems, such as UIKit and engine\)
-
-
-
-
diff --git a/en/device-dev/subsystems/overview.md b/en/device-dev/subsystems/overview.md
deleted file mode 100644
index af871180f3042797494129e8a9a80e36e62a1ca7..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/overview.md
+++ /dev/null
@@ -1,116 +0,0 @@
-# Overview
-
-- [Basic Concepts](#section175012297491)
-- [Working Principles](#section193961322175011)
-
-## Basic Concepts
-
-Camera is one of the services provided by the OpenHarmony multimedia subsystem. The camera module provides recording, preview, and photographing features and supports concurrent stream reading by multiple users.
-
-It is considered good practice that you understand the following concepts before starting development:
-
-- Video frame
-
- A video frame is formed by the stream data of a video image. Video data streams are formed by a series of image data arranged at a fixed time interval.
-
-- Frame per second \(FPS\)
-
- FPS is used to represent the frame rate at which images are refreshed during video playback, or the number of frames per second during video playback. A higher frame rate means smoother video playback.
-
-- Resolution
-
- Information about each image frame consists of pixels. The number of pixels in an image is presented by the resolution. For example, 1080p \(1920 x 1080\) indicates that the image width is 1920 pixels and the image height is 1080 pixels.
-
-
-## Working Principles
-
-- Multimedia services
-
- Multimedia services are started by the **Init** process upon system startup, and media hardware resources \(such as memory, display hardware, image sensors, and codecs\) are initialized and allocated. During the initialization, the configuration file is parsed, which determines the upper limit of capabilities and resources of each service. Generally, the upper limit is configured by original equipment manufacturers \(OEMs\) in the configuration file. The following configuration items are available for the camera service during multimedia service initialization:
-
- - Memory pool: Memory blocks in the memory pool are accessed and released continuously by all multimedia services.
- - Image sensor: sensor type, resolution, ISP, and more
- - Image processor: resolution, bit rate, image inversion, and more
- - Image encoder: encoding format, bit rate, resolution, and more
-
-
-- Major classes
-
- You can use the **Camera** class and its asynchronous callback classes to configure and access the camera functionalities. The three callback classes correspond to different asynchronous processing scenarios, as described in [Table 1](#table486418149411).
-
- **Table 1** Class description
-
-
-
Class
-
-
Description
-
-
Examples
-
-
-
-
Camera
-
-
Configures the static camera capability through the configuration class to use basic camera functionalities.
-
-
Photographing, video recording, and previewing
-
-
-
CameraDeviceCallback
-
-
Handles camera hardware state changes.
-
-
Available or unavailable
-
-
-
CameraStateCallback
-
-
Handles camera instance state changes.
-
-
Created or released
-
-
-
FrameStateCallback
-
-
Handles frame status changes.
-
-
Start and end of photographing, and frame rate changes
-
-
-
-
-
-- Stream transfer
-
- A surface is the basic data structure for transferring audio and video data. A camera is generally used as the data producer of a surface and has specific consumers in different scenarios.
-
- Camera preview and recording outputs are video streams, and photographing outputs are image frames. The outputs are transferred through the **Surface** class. A surface can transmit media information streams within and cross processes.
-
- Take video recording as an example. You create a **Recorder** instance, obtain the surface of the **Recorder** instance, and then transfer the surface to the **Camera** instance. In this case, the **Camera** instance works as a producer to inject video streams to the surface, and the **Recorder** instance act as the consumer to obtain video streams from the surface for storage. In this case, you connect the recorder and camera through the surface.
-
- Similarly, you can create a surface, implement consumer logic for it, and transfer it to the **Camera** instance. For example, transmit video streams over the network or save captured frame data as an image file.
-
- The graphics module also obtains stream resources from the camera module through surfaces. For details, see development guidelines on [Graphic](graphics-2.md).
-
-- Camera running process
- 1. Creating a camera
-
- This process creates a **Camera** instance by **CameraManager**, binds the camera device to the server, and asynchronously notifies you of the successful creation. The following figure shows the time sequence between classes.
-
- **Figure 1** Sequence diagram for creating a camera
-
-
- 
-
-
- 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.
-
- **Figure 2** Sequence diagram for recording/previewing
-
-
- 
-
-
-
diff --git a/en/device-dev/subsystems/public_sys-resources/icon-caution.gif b/en/device-dev/subsystems/public_sys-resources/icon-caution.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/public_sys-resources/icon-caution.gif and /dev/null differ
diff --git a/en/device-dev/subsystems/public_sys-resources/icon-danger.gif b/en/device-dev/subsystems/public_sys-resources/icon-danger.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/public_sys-resources/icon-danger.gif and /dev/null differ
diff --git a/en/device-dev/subsystems/public_sys-resources/icon-note.gif b/en/device-dev/subsystems/public_sys-resources/icon-note.gif
deleted file mode 100644
index 6314297e45c1de184204098efd4814d6dc8b1cda..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/public_sys-resources/icon-note.gif and /dev/null differ
diff --git a/en/device-dev/subsystems/public_sys-resources/icon-notice.gif b/en/device-dev/subsystems/public_sys-resources/icon-notice.gif
deleted file mode 100644
index 86024f61b691400bea99e5b1f506d9d9aef36e27..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/public_sys-resources/icon-notice.gif and /dev/null differ
diff --git a/en/device-dev/subsystems/public_sys-resources/icon-tip.gif b/en/device-dev/subsystems/public_sys-resources/icon-tip.gif
deleted file mode 100644
index 93aa72053b510e456b149f36a0972703ea9999b7..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/public_sys-resources/icon-tip.gif and /dev/null differ
diff --git a/en/device-dev/subsystems/public_sys-resources/icon-warning.gif b/en/device-dev/subsystems/public_sys-resources/icon-warning.gif
deleted file mode 100644
index 6e90d7cfc2193e39e10bb58c38d01a23f045d571..0000000000000000000000000000000000000000
Binary files a/en/device-dev/subsystems/public_sys-resources/icon-warning.gif and /dev/null differ
diff --git a/en/device-dev/subsystems/r-d-tools.md b/en/device-dev/subsystems/r-d-tools.md
deleted file mode 100644
index 03f6b950d21aabb40bae141a58f40f1c42793407..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/r-d-tools.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# R&D Tools
-
-- **[bytrace Usage Guidelines](bytrace-usage-guidelines.md)**
-
-- **[hdc\_std Usage Guidelines](hdc_std-usage-guidelines.md)**
-
-- **[hdc\_std FAQs](hdc_std-faqs.md)**
-
-
diff --git a/en/device-dev/subsystems/sdk.md b/en/device-dev/subsystems/sdk.md
deleted file mode 100644
index 5cc0b855635d383e046ae6c117a8d28428406da3..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/sdk.md
+++ /dev/null
@@ -1,162 +0,0 @@
-# SDK
-
-The function of the SDK header file is implemented by mapping SDK API calls to client API calls. [Table 1](#table203963834718) lists the APIs provided by the client.
-
-**Table 1** APIs provided by the client
-
-
-
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
-
-
clientInfo: Indicates engine client information. This parameter must not be null.
-
algorithmInfo: Indicates information about the called algorithm. This parameter must not be null.
-
inputInfo: Indicates input information specified for algorithm plug-in loading. This parameter can be null.
-
outputInfo: Indicates information returned after algorithm plug-in loading, if any. This parameter can be null.
-
cb: Indicates the return result of the asynchronous algorithm. This parameter must not be null for the asynchronous algorithm. For the synchronous algorithm, this parameter must be null.
-
-
-
int AieClientAsyncProcess(const ClientInfo &clientInfo, const AlgorithmInfo &algorithmInfo, const DataInfo &inputInfo)
-
-
Function: Executes an asynchronous algorithm.
-
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
-
-
clientInfo: Indicates engine client information. This parameter must not be null.
-
algorithmInfo: Indicates information about the called algorithm. This parameter must not be null.
-
inputInfo: Indicates input information specified for algorithm operations. This parameter can be null.
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
-
-
clientInfo: Indicates engine client information. This parameter must not be null.
-
algorithmInfo: Indicates information about the called algorithm. This parameter must not be null.
-
inputInfo: Indicates input information specified for algorithm operations. This parameter can be null.
-
outputInfo: Indicates output information in the return result of the synchronous algorithm. This parameter can be null.
-
-
-
int AieClientRelease(const ClientInfo &clientInfo, const AlgorithmInfo &algorithmInfo, const DataInfo &inputInfo)
-
-
Function: Uninstalls an algorithm plug-in.
-
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
-
-
clientInfo: Indicates engine client information. This parameter must not be null.
-
algorithmInfo: Indicates information about the algorithm plug-in to be uninstalled. This parameter must not be null.
-
inputInfo: Indicates input information specified for algorithm plug-in uninstallation. This parameter can be null.
-
-
-
int AieClientDestroy(ClientInfo &clientInfo)
-
-
Function: Disconnects from the server and releases the cache.
-
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
-
-
clientInfo: Indicates information about the engine client to be destroyed. This parameter must not be null.
-
-
-
int AieClientSetOption(const ClientInfo &clientInfo, int optionType, const DataInfo &inputInfo)
-
-
Function: Sets configuration items. You can use this API to pass algorithm's extended information to plug-ins.
-
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
-
-
clientInfo: Indicates engine client information. This parameter must not be null.
-
optionType: Indicates the algorithm for obtaining the configuration item information. An algorithm plug-in can use this parameter as needed. This parameter must not be null.
-
inputInfo: Indicates algorithm parameter information. An algorithm plug-in can use this parameter as needed. This parameter can be null.
-
-
-
int AieClientGetOption(const ClientInfo &clientInfo, int optionType, const DataInfo &inputInfo, DataInfo &outputInfo)
-
-
Function: Obtains configuration item information based on the specified optionType and inputInfo.
-
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
-
-
clientInfo: Indicates engine client information. This parameter must not be null.
-
optionType: Indicates the algorithm for obtaining the configuration item information. This parameter must not be null.
-
inputInfo: Indicates input information specified for obtaining configuration item information of the algorithm. This parameter can be null.
-
outputInfo: Indicates the configuration item information in the return result. This parameter can be null.
-
-
-
-
-
-[Table 2](#table22154317482) describes the data structure of **ConfigInfo**, **ClientInfo**, **AlgorithmInfo**, and **DataInfo**.
-
-**Table 2** Data structure of ConfigInfo, ClientInfo, AlgorithmInfo, and DataInfo
-
-
-
Structure
-
-
Description
-
-
Attributes
-
-
-
-
ConfigInfo
-
-
Algorithm configuration item information
-
-
const char *description: Indicates the body of configuration item information.
-
-
-
ClientInfo
-
-
Client information
-
-
long long clientVersion: Indicates client version number. This parameter is not used currently.
-
int clientId: Indicates the client ID.
-
int sessionId: Indicates the session ID.
-
uid_t serverUid: Indicates the server UID.
-
uid_t clientUid: Indicates the client UID.
-
int extendLen: Indicates the length of the extended information (extendMsg).
-
unsigned char *extendMsg: Indicates the body of the extended information.
-
-
-
AlgorithmInfo
-
-
Algorithm information
-
-
long long clientVersion: Indicates client version number. This parameter is not used currently.
-
bool isAsync: Indicates whether asynchronous execution is used.
-
int algorithmType: Indicates the algorithm type ID allocated by the AI engine framework based on the plug-in loading sequence.
-
long long algorithmVersion: Indicates the algorithm version number.
-
bool isCloud: Indicates whether to migrate data to the cloud. This parameter is not used currently.
-
int operateId: Indicates the execution ID. This parameter is not used currently.
-
int requestId: Indicates the request ID, which identifies each request and corresponds to the execution result.
-
int extendLen: Indicates the length of the extended information (extendMsg).
-
unsigned char *extendMsg: Indicates the body of the extended information.
-
-
-
DataInfo
-
-
Algorithm input parameter configuration information (inputInfo) and output parameter configuration information (outputInfo)
-
-
unsigned char *data: Indicates the data body.
-
int length: Indicates the data length.
-
-
-
-
-
-For details about the development process, see the development example for the KWS SDK.
-
diff --git a/en/device-dev/subsystems/security.md b/en/device-dev/subsystems/security.md
deleted file mode 100644
index e69ec0072cf44c6314e688ce37d3a25bbe8df412..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/security.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Security
-
-- **[Overview](overview-9.md)**
-
-- **[Development Guidelines on Application Signature Verification](development-guidelines-on-application-signature-verification.md)**
-
-- **[Development Guidelines on Application Permission Management](development-guidelines-on-application-permission-management.md)**
-
-- **[Development Guidelines on IPC Authentication](development-guidelines-on-ipc-authentication.md)**
-
-- **[Development Guidelines on Trusted Device Group Management](development-guidelines-on-trusted-device-group-management.md)**
-
-
diff --git a/en/device-dev/subsystems/sensors-overview.md b/en/device-dev/subsystems/sensors-overview.md
deleted file mode 100644
index df576eafc34eefed1cb2740def706a469e72273f..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/sensors-overview.md
+++ /dev/null
@@ -1,99 +0,0 @@
-# Sensors Overview
-
-- [Introduction](#section667413271505)
-- [Available APIs](#section7255104114110)
-
-## Introduction
-
-The pan-sensor service subsystem provides a lightweight sensor service framework. You can call APIs offered by this framework to query the sensor list, enable or disable a sensor, and subscribe to or unsubscribe from sensor data. The following figure shows the architecture of the lightweight sensor framework.
-
-**Figure 1** Sensor service framework
-
-
-
-- Sensor API: provides APIs for performing basic operations on sensors, including querying the sensor list, subscribing to or unsubscribing from sensor data, and executing control commands. This module makes application development simpler.
-- Sensor Framework: manages sensor data subscription, creates and destroys data channels, and implements communication with the Sensor Service module.
-- Sensor Service: interacts with the HDF module to receive, parse, and distribute data, manages sensors on hardware and sensor data reporting, and controls sensor permissions.
-
-## Available APIs
-
-**Table 1** APIs of the sensor framework
-
-
-
Sets the data reporting mode for the specified sensor.
-
Return value: Returns 0 if the sensor data reporting mode is successfully set; returns a non-zero value otherwise.
-
-
sensorTypeId: ID of a sensor type
-
user (not NULL): sensor subscriber that requests sensor data. A subscriber can obtain data from only one sensor.
-
mode: data reporting mode of the sensor
-
-
-
-
-
diff --git a/en/device-dev/subsystems/sensors-usage-guidelines.md b/en/device-dev/subsystems/sensors-usage-guidelines.md
deleted file mode 100644
index f3e692948c004bc721cf862b2ac4a47a01f574f6..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/sensors-usage-guidelines.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# Sensors Usage Guidelines
-
-- [How to Use](#section18816105182315)
-
-The following steps use the sensor whose **sensorTypeId** is **0** as an example. The guidelines for other sensor types are similar.
-
-## How to Use
-
-1. Import the required header files.
-
-```
-#include "sensor_agent.h"
-#include "sensor_agent_type.h"
-```
-
-1. Create a sensor callback.
-
-```
-void SensorDataCallbackImpl(SensorEvent *event)
-{
- if(event == NULL){
- return;
- }
- float *sensorData=(float *)event->data;
-}
-```
-
-> **NOTE:**
->The callback must be of the RecordSensorCallback type.
-
-1. Obtain the list of sensors supported by the device.
-
-```
-SensorInfo *sensorInfo = (SensorInfo *)NULL;
-int32_t count = 0;
-int32_t ret = GetAllSensors(&sensorInfo, &count);
-```
-
-1. Create a sensor user.
-
-```
-SensorUser sensorUser;
-sensorUser.callback = SensorDataCallbackImpl; // Assign the created callback SensorDataCallbackImpl to the member variable callback.
-```
-
-1. Enable the sensor.
-
-```
-int32_t ret = ActivateSensor(0, &sensorUser);
-```
-
-1. Subscribe to sensor data.
-
-```
-int32_t ret = SubscribeSensor(0, &sensorUser);
-```
-
-> **NOTE:**
->Till now, you can obtain the sensor data via the callback.
-
-1. Unsubscribe from the sensor data.
-
-```
-int32_t ret = UnsubscribeSensor(0, &sensorUser);
-```
-
-1. Disable the sensor.
-
-```
-int32_t ret = DeactivateSensor(0, &sensorUser);
-```
-
diff --git a/en/device-dev/subsystems/sensors.md b/en/device-dev/subsystems/sensors.md
deleted file mode 100644
index 1cb5c1ea4ccc7754bf186c31d6d7e1e1fae063ad..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/sensors.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Sensors
-
-- **[Sensors Overview](sensors-overview.md)**
-
-- **[Sensors Usage Guidelines](sensors-usage-guidelines.md)**
-
-- **[Sensors Usage Example](sensors-usage-example.md)**
-
-
diff --git a/en/device-dev/subsystems/setting-up-a-development-environment.md b/en/device-dev/subsystems/setting-up-a-development-environment.md
deleted file mode 100644
index 1fc80b0e712510b8126974d0beffabd558cc66b0..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/setting-up-a-development-environment.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Setting Up a Development Environment
-
-- Development board: Hi3516D V300
-
-- [Download the source code](../get-code/source-code-acquisition.md).
-- [Build the application framework](https://gitee.com/openharmony/docs/blob/master/en/readme/application-framework.md).
-
diff --git a/en/device-dev/subsystems/startup-10.md b/en/device-dev/subsystems/startup-10.md
deleted file mode 100644
index b6ef1916de1c9e9e7cdf903841ded765d0ce841a..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/startup-10.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# Startup
-
-- [Limitations and Constraints](#section2029921310472)
-
-The startup subsystem provides the functions of starting key system processes after the kernel is started and before applications are started, and restoring the system to factory settings. The subsystem consists of the following modules:
-
-- init module
-
- This module corresponds to the init process, which is the first user-space process started after the kernel is initialized. Upon startup, the init process reads and parses the configuration file **init.cfg**. Based on the parsing result, the init module executes the commands listed in Table 2 in [init Module](init-module.md) and starts the key system service processes in sequence with corresponding permissions granted.
-
-- appspawn module
-
- This module spawns application processes upon receiving commands from the application framework, configures permissions for new processes, and calls the entry function of the application framework.
-
-- bootstrap module
-
- This module provides entry identifiers for starting services and features. When the Samgr is started, the entry function identified by boostrap is called and system services are started.
-
-- syspara module
-
- This module provides APIs for obtaining device information, such as the product name, brand name, and manufacturer name, based on the OpenHarmony Product Compatibility Specifications \(PCS\). It also provides APIs for setting and obtaining system parameters.
-
-
-## Limitations and Constraints
-
-The directories of startup subsystem are applicable to different platforms.
-
-**Table 1** Directories and applicable platforms of the startup subsystem
-
-
-
Directory
-
-
Applicable Platform
-
-
-
-
base/startup/appspawn_lite
-
-
Small-system devices (reference memory ≥ 1 MB), for example, Hi3516D V300 and Hi3518E V300
-
-
-
base/startup/bootstrap_lite
-
-
Mini-system devices (reference memory ≥ 128 KB), for example, Hi3861 V100
-
-
-
base/startup/init_lite
-
-
Small-system devices (reference memory ≥ 1 MB), for example, Hi3516D V300 and Hi3518E V300
-
-
-
base/startup/syspara_lite
-
-
Mini-system devices (reference memory ≥ 128 KB), for example, Hi3861 V100
Small-system devices (reference memory ≥ 1 MB), for example, Hi3516D V300 and Hi3518E V300
-
-
-
-
-
-
-
Directory
-
-
Applicable Platform
-
-
-
-
base/startup/startup
-
-
Large-system devices (reference memory ≥ 1 GB)
-
-
-
base/startup/systemrestore
-
-
Large-system devices (reference memory ≥ 1 GB)
-
-
-
-
-
-- init module
- - After being burnt to the development board, the configuration file **init.cfg** changes to read-only. If you want to modify the file, you must repack and burn the rootfs image again.
- - The configuration file **init.cfg** must be in JSON format.
-
-- bootstrap module: The zInit code needs to be configured in the link script.
-- syspara module: The **SetParameter** and **GetParameter** APIs can only be called by applications whose UID is greater than 1000.
-
diff --git a/en/device-dev/subsystems/startup.md b/en/device-dev/subsystems/startup.md
deleted file mode 100644
index 5a2025350a8b09b4a2afd74af17e2dc4894efa53..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/startup.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Startup
-
-- **[Startup](startup-10.md)**
-
-- **[init Module](init-module.md)**
-
-- **[appspawn Module](appspawn-module.md)**
-
-- **[bootstrap Module](bootstrap-module.md)**
-
-- **[syspara Module](syspara-module.md)**
-
-- **[FAQs](faqs.md)**
-
-- **[Reference](reference.md)**
-
-
diff --git a/en/device-dev/subsystems/kws-configuration-file.md b/en/device-dev/subsystems/subsys-aiframework-demo-conf.md
similarity index 100%
rename from en/device-dev/subsystems/kws-configuration-file.md
rename to en/device-dev/subsystems/subsys-aiframework-demo-conf.md
diff --git a/en/device-dev/subsystems/kws-plug-in.md b/en/device-dev/subsystems/subsys-aiframework-demo-plugin.md
similarity index 100%
rename from en/device-dev/subsystems/kws-plug-in.md
rename to en/device-dev/subsystems/subsys-aiframework-demo-plugin.md
diff --git a/en/device-dev/subsystems/subsys-aiframework-demo-sdk.md b/en/device-dev/subsystems/subsys-aiframework-demo-sdk.md
new file mode 100644
index 0000000000000000000000000000000000000000..969d35269f74b0a7efe86fd387d4fe066409d2b2
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-aiframework-demo-sdk.md
@@ -0,0 +1,81 @@
+# KWS SDK
+
+1. Add the API of the KWS SDK to the **//foundation/ai/engine /interfaces/kits** directory. This API can be called by third-party applications. The following code snippet is an example API for the KWS SDK. The reference code is available at the **//foundation/ai/engine /interfaces/kits/asr/keyword\_spotting** directory.
+
+ ```
+ class KWSSdk {
+ public:
+ KWSSdk();
+ virtual ~KWSSdk();
+
+ // Create a KWS SDK instance.
+ int32_t Create();
+
+ // Synchronously execute the KWS task.
+ int32_t SyncExecute(const Array &audioInput);
+
+ // Set the KWS callback.
+ int32_t SetCallback(const std::shared_ptr &callback);
+
+ // Destroy the KWS SDK instance to release the session engaged with the plug-in.
+ int32_t Destroy();
+ };
+ ```
+
+2. Add the API implementation of the SDK to the **//foundation/ai/engine/services/client/algorithm\_sdk** directory and call the APIs provided by the client to use the algorithm plug-in capabilities. The following code snippet is an example implementation of the **create** method in the API of the KWS SDK. For more details, see the reference code at **//foundation/ai/engine/services/client/algorithm\_sdk/asr/keyword\_spotting**.
+
+ ```
+ int32_t KWSSdk::KWSSdkImpl::Create()
+ {
+ if (kwsHandle_ != INVALID_KWS_HANDLE) {
+ HILOGE("[KWSSdkImpl]The SDK has been created");
+ return KWS_RETCODE_FAILURE;
+ }
+ if (InitComponents() != RETCODE_SUCCESS) {
+ HILOGE("[KWSSdkImpl]Fail to init sdk components");
+ return KWS_RETCODE_FAILURE;
+ }
+ // Call the AieClientInit API provided by the client to initialize the engine service and activate IPC call.
+ int32_t retCode = AieClientInit(configInfo_, clientInfo_, algorithmInfo_, nullptr);
+ if (retCode != RETCODE_SUCCESS) {
+ HILOGE("[KWSSdkImpl]AieClientInit failed. Error code[%d]", retCode);
+ return KWS_RETCODE_FAILURE;
+ }
+ if (clientInfo_.clientId == INVALID_CLIENT_ID) {
+ HILOGE("[KWSSdkImpl]Fail to allocate client id");
+ return KWS_RETCODE_FAILURE;
+ }
+ DataInfo inputInfo = {
+ .data = nullptr,
+ .length = 0,
+ };
+ DataInfo outputInfo = {
+ .data = nullptr,
+ .length = 0,
+ };
+ // Call the AieClientPrepare API provided by the client to load the algorithm plug-in.
+ retCode = AieClientPrepare(clientInfo_, algorithmInfo_, inputInfo, outputInfo, nullptr);
+ if (retCode != RETCODE_SUCCESS) {
+ HILOGE("[KWSSdkImpl]AieclientPrepare failed. Error code[%d]", retCode);
+ return KWS_RETCODE_FAILURE;
+ }
+ if (outputInfo.data == nullptr || outputInfo.length <= 0) {
+ HILOGE("[KWSSdkImpl]The data or length of output info is invalid");
+ return KWS_RETCODE_FAILURE;
+ }
+ MallocPointerGuard pointerGuard(outputInfo.data);
+ retCode = PluginHelper::UnSerializeHandle(outputInfo, kwsHandle_);
+ if (retCode != RETCODE_SUCCESS) {
+ HILOGE("[KWSSdkImpl]Get handle from inputInfo failed");
+ return KWS_RETCODE_FAILURE;
+ }
+ return KWS_RETCODE_SUCCESS;
+ }
+ ```
+
+ The preceding code is the specific API implementation. The **create** function in the API of the KWS SDK calls the open **AieClientInit** and **AieClientPrepare** APIs provided by the client to connect to the server and load the algorithm model. For details, see the implementation of the **create** method in following sections.
+
+ > **NOTE:**
+ >The sequence for the SDK to call client APIs: **AieClientInit** -\> **AieClientPrepare** -\> **AieClientSyncProcess** or **AieClientAsyncProcess** -\> **AieClientRelease** -\> **AieClientDestroy**. An exception will be thrown if the call sequence is violated.
+
+
diff --git a/en/device-dev/subsystems/subsys-aiframework-demo.md b/en/device-dev/subsystems/subsys-aiframework-demo.md
new file mode 100644
index 0000000000000000000000000000000000000000..0dd54a375edf3ec101a6999dfd25d3f424c5cca4
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-aiframework-demo.md
@@ -0,0 +1,13 @@
+# Development Examples
+
+For your better understanding, a KWS application is used as an example to walk you through the development process. You can develop the KWS SDK and plug-in based on the AI engine framework on the Hi3516D V300 development board, compile an image for the new version, and burn the image into the version. Then, develop an application with the KWS function. The application can receive external audio and pass the audio to the SDK API. If the audio contains specified keywords, the application will be able to recognize these keywords and print them in the command line.
+
+This example uses a fixed keyword **Hi, xiaowen** for illustration. If the input audio contains **Hi, xiaowen**, the application prints **\[Hi, xiaowen\]**; otherwise, the application prints **\[UNKNOWN\]**.
+
+- **[KWS SDK](subsys-aiframework-demo-sdk.md)**
+
+- **[KWS Plug-in](subsys-aiframework-demo-plugin.md)**
+
+- **[KWS Configuration File](subsys-aiframework-demo-conf.md)**
+
+
diff --git a/en/device-dev/subsystems/configuration-file.md b/en/device-dev/subsystems/subsys-aiframework-devguide-conf.md
similarity index 100%
rename from en/device-dev/subsystems/configuration-file.md
rename to en/device-dev/subsystems/subsys-aiframework-devguide-conf.md
diff --git a/en/device-dev/subsystems/plug-in.md b/en/device-dev/subsystems/subsys-aiframework-devguide-plugin.md
similarity index 100%
rename from en/device-dev/subsystems/plug-in.md
rename to en/device-dev/subsystems/subsys-aiframework-devguide-plugin.md
diff --git a/en/device-dev/subsystems/subsys-aiframework-devguide-sdk.md b/en/device-dev/subsystems/subsys-aiframework-devguide-sdk.md
new file mode 100644
index 0000000000000000000000000000000000000000..f185750d0f6ffa1d1027b717e6b67acc9e1fd666
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-aiframework-devguide-sdk.md
@@ -0,0 +1,162 @@
+# SDK
+
+The function of the SDK header file is implemented by mapping SDK API calls to client API calls. [Table 1](#table203963834718) lists the APIs provided by the client.
+
+**Table 1** APIs provided by the client
+
+
+
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
+
+
clientInfo: Indicates engine client information. This parameter must not be null.
+
algorithmInfo: Indicates information about the called algorithm. This parameter must not be null.
+
inputInfo: Indicates input information specified for algorithm plug-in loading. This parameter can be null.
+
outputInfo: Indicates information returned after algorithm plug-in loading, if any. This parameter can be null.
+
cb: Indicates the return result of the asynchronous algorithm. This parameter must not be null for the asynchronous algorithm. For the synchronous algorithm, this parameter must be null.
+
+
+
int AieClientAsyncProcess(const ClientInfo &clientInfo, const AlgorithmInfo &algorithmInfo, const DataInfo &inputInfo)
+
+
Function: Executes an asynchronous algorithm.
+
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
+
+
clientInfo: Indicates engine client information. This parameter must not be null.
+
algorithmInfo: Indicates information about the called algorithm. This parameter must not be null.
+
inputInfo: Indicates input information specified for algorithm operations. This parameter can be null.
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
+
+
clientInfo: Indicates engine client information. This parameter must not be null.
+
algorithmInfo: Indicates information about the called algorithm. This parameter must not be null.
+
inputInfo: Indicates input information specified for algorithm operations. This parameter can be null.
+
outputInfo: Indicates output information in the return result of the synchronous algorithm. This parameter can be null.
+
+
+
int AieClientRelease(const ClientInfo &clientInfo, const AlgorithmInfo &algorithmInfo, const DataInfo &inputInfo)
+
+
Function: Uninstalls an algorithm plug-in.
+
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
+
+
clientInfo: Indicates engine client information. This parameter must not be null.
+
algorithmInfo: Indicates information about the algorithm plug-in to be uninstalled. This parameter must not be null.
+
inputInfo: Indicates input information specified for algorithm plug-in uninstallation. This parameter can be null.
+
+
+
int AieClientDestroy(ClientInfo &clientInfo)
+
+
Function: Disconnects from the server and releases the cache.
+
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
+
+
clientInfo: Indicates information about the engine client to be destroyed. This parameter must not be null.
+
+
+
int AieClientSetOption(const ClientInfo &clientInfo, int optionType, const DataInfo &inputInfo)
+
+
Function: Sets configuration items. You can use this API to pass algorithm's extended information to plug-ins.
+
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
+
+
clientInfo: Indicates engine client information. This parameter must not be null.
+
optionType: Indicates the algorithm for obtaining the configuration item information. An algorithm plug-in can use this parameter as needed. This parameter must not be null.
+
inputInfo: Indicates algorithm parameter information. An algorithm plug-in can use this parameter as needed. This parameter can be null.
+
+
+
int AieClientGetOption(const ClientInfo &clientInfo, int optionType, const DataInfo &inputInfo, DataInfo &outputInfo)
+
+
Function: Obtains configuration item information based on the specified optionType and inputInfo.
+
Return value: Returns 0 if the operation is successful; returns a non-zero value otherwise.
+
+
clientInfo: Indicates engine client information. This parameter must not be null.
+
optionType: Indicates the algorithm for obtaining the configuration item information. This parameter must not be null.
+
inputInfo: Indicates input information specified for obtaining configuration item information of the algorithm. This parameter can be null.
+
outputInfo: Indicates the configuration item information in the return result. This parameter can be null.
+
+
+
+
+
+[Table 2](#table22154317482) describes the data structure of **ConfigInfo**, **ClientInfo**, **AlgorithmInfo**, and **DataInfo**.
+
+**Table 2** Data structure of ConfigInfo, ClientInfo, AlgorithmInfo, and DataInfo
+
+
+
Structure
+
+
Description
+
+
Attributes
+
+
+
+
ConfigInfo
+
+
Algorithm configuration item information
+
+
const char *description: Indicates the body of configuration item information.
+
+
+
ClientInfo
+
+
Client information
+
+
long long clientVersion: Indicates client version number. This parameter is not used currently.
+
int clientId: Indicates the client ID.
+
int sessionId: Indicates the session ID.
+
uid_t serverUid: Indicates the UID of the server.
+
uid_t clientUid: Indicates the UID of the client.
+
int extendLen: Indicates the length of the extended information (extendMsg).
+
unsigned char *extendMsg: Indicates the body of the extended information.
+
+
+
AlgorithmInfo
+
+
Algorithm information
+
+
long long clientVersion: Indicates client version number. This parameter is not used currently.
+
bool isAsync: Indicates whether asynchronous execution is used.
+
int algorithmType: Indicates the algorithm type ID allocated by the AI engine framework based on the plug-in loading sequence.
+
long long algorithmVersion: Indicates the algorithm version number.
+
bool isCloud: Indicates whether to migrate data to the cloud. This parameter is not used currently.
+
int operateId: Indicates the execution ID. This parameter is not used currently.
+
int requestId: Indicates the request ID, which identifies each request and corresponds to the execution result.
+
int extendLen: Indicates the length of the extended information (extendMsg).
+
unsigned char *extendMsg: Indicates the body of the extended information.
+
+
+
DataInfo
+
+
Algorithm input parameter configuration information (inputInfo) and output parameter configuration information (outputInfo)
+
+
unsigned char *data: Indicates the data body.
+
int length: Indicates the data length.
+
+
+
+
+
+For details about the development process, see the development example for the KWS SDK.
+
diff --git a/en/device-dev/subsystems/subsys-aiframework-devguide.md b/en/device-dev/subsystems/subsys-aiframework-devguide.md
new file mode 100644
index 0000000000000000000000000000000000000000..b3bd0bb4e3ccfccd3d91a6b8c35fec13dd570683
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-aiframework-devguide.md
@@ -0,0 +1,11 @@
+# Development Guidelines
+
+To access the AI engine framework, you need to develop the SDKs and plug-ins shown in [Figure 1](subsys-aiframework-guide.md#fig143186187187). In this way, you can call the APIs provided by the SDKs to call the algorithm capabilities of plug-ins to implement lifecycle management and on-demand deployment of AI capabilities.
+
+- **[SDK](subsys-aiframework-devguide-sdk.md)**
+
+- **[Plug-in](subsys-aiframework-devguide-plugin.md)**
+
+- **[Configuration File](subsys-aiframework-devguide-conf.md)**
+
+
diff --git a/en/device-dev/subsystems/subsys-aiframework-envbuild.md b/en/device-dev/subsystems/subsys-aiframework-envbuild.md
new file mode 100644
index 0000000000000000000000000000000000000000..ebfa0e83dcaf00e8123da6264df60db3ddbfa20e
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-aiframework-envbuild.md
@@ -0,0 +1,5 @@
+# Development Environment
+
+1. Prepare development boards Hi3516D V300 and Hi3518E V300.
+2. [Download the source code](../get-code/sourcecode-acquire.md).
+
diff --git a/en/device-dev/subsystems/subsys-aiframework-guide.md b/en/device-dev/subsystems/subsys-aiframework-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..3e13aeb62273b5b51cd951aa803db6f0d02426ae
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-aiframework-guide.md
@@ -0,0 +1,9 @@
+# AI Engine Framework
+
+The AI subsystem of OpenHarmony provides native distributed AI capabilities. At the heart of the subsystem is a unified AI engine framework, which implements quick integration of AI algorithm plug-ins. The framework consists of the plug-in management, module management, and communication management modules, fulfilling lifecycle management and on-demand deployment of AI algorithms. Plug-in management implements lifecycle management, on-demand deployment, and quick integration of AI algorithm plug-ins. Module management implements task scheduling and client instance management. Communication management implements inter-process communication \(IPC\) between the client and server and data transmission between the AI engine and plug-ins. Under this framework, AI algorithm APIs will be standardized to facilitate distributed calling of AI capabilities. In addition, unified inference APIs will be provided to adapt to different inference framework hierarchies. [Figure 1](#fig143186187187) shows the AI engine framework.
+
+**Figure 1** AI engine framework
+
+
+
+
diff --git a/en/device-dev/subsystems/subsys-aiframework-tech-codemanage.md b/en/device-dev/subsystems/subsys-aiframework-tech-codemanage.md
new file mode 100644
index 0000000000000000000000000000000000000000..71784ff093472cfa6658ba319b3b6d701e955d68
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-aiframework-tech-codemanage.md
@@ -0,0 +1,40 @@
+# Code Management
+
+- [Recommendation: Develop plug-ins and northbound SDKs in the directories specified by the AI engine.](#section17176374131)
+- [Rule: Store all external APIs provided by plug-ins in the interfaces/kits directory of the AI subsystem.](#section2551029111312)
+- [Rule: Make sure that plug-in compilation results are stored in the /usr/lib directory.](#section97021558121310)
+
+Code of the AI engine framework consists of three parts: **client**, **server**, and **common**. The client module provides the server connection management function. The northbound SDK needs to encapsulate and call the public APIs provided by the client in the algorithm's external APIs. The server module provides functions such as plug-in loading and task management. Plug-ins are integrated using the plug-in APIs provided by the server. The common module provides platform-related operation methods, engine protocols, and tool classes for other modules.
+
+[Figure 1](#fig171811112818) shows the code dependency between modules of the AI engine framework.
+
+**Figure 1** Code dependency
+
+
+.jpg)
+
+## Recommendation: Develop plug-ins and northbound SDKs in the directories specified by the AI engine.
+
+In the overall planning of the AI engine framework, northbound SDKs are a part of the client, and plug-ins are called by the server and are considered a part of the server. Therefore, the following directories have been planned for plug-in and northbound SDK development in the AI engine framework:
+
+- SDK code directory: //foundation/ai/engine/services/client/algorithm\_sdk
+
+ e.g. //foundation/ai/engine/services/client/algorithm\_sdk/cv
+
+ e.g. //foundation/ai/engine/services/client/algorithm\_sdk/nlu
+
+- Plug-in code directory: //foundation/ai/engine/services/server/plugin
+
+ e.g. //foundation/ai/engine/services/server/plugin/cv
+
+ e.g. //foundation/ai/engine/services/server/plugin/nlu
+
+
+## Rule: Store all external APIs provided by plug-ins in the **interfaces/kits** directory of the AI subsystem.
+
+The AI subsystem exposes its capabilities through external APIs of northbound SDKs. According to API management requirements of OpenHarmony, store all external APIs of northbound SDKs in the **interfaces/kits** directory of the subsystem. Currently, the external APIs of plug-ins of the AI subsystem are stored in the following directory: **//foundation/ai/engine/interface/kits**. You can add a sub-directory for each newly added plug-in in this directory. For example, if you add a CV plug-in, then store its external APIs in the **//foundation/ai/engine/interfaces/kits/cv** directory.
+
+## Rule: Make sure that plug-in compilation results are stored in the **/usr/lib** directory.
+
+Plug-in loading on the server uses the dlopen mode and can only be performed in the **/usr/lib** directory. Therefore, when compiling the **.so** file of a plug-in, set the output directory as **/usr/lib** in the compilation configuration file.
+
diff --git a/en/device-dev/subsystems/api-development.md b/en/device-dev/subsystems/subsys-aiframework-tech-interface.md
similarity index 100%
rename from en/device-dev/subsystems/api-development.md
rename to en/device-dev/subsystems/subsys-aiframework-tech-interface.md
diff --git a/en/device-dev/subsystems/naming.md b/en/device-dev/subsystems/subsys-aiframework-tech-name.md
similarity index 100%
rename from en/device-dev/subsystems/naming.md
rename to en/device-dev/subsystems/subsys-aiframework-tech-name.md
diff --git a/en/device-dev/subsystems/subsys-aiframework-tech.md b/en/device-dev/subsystems/subsys-aiframework-tech.md
new file mode 100644
index 0000000000000000000000000000000000000000..ed9edda03a6fabc4651e76a13271f159b4510e51
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-aiframework-tech.md
@@ -0,0 +1,15 @@
+# Technical Specifications
+
+**Conventions**
+
+**Rule**: a convention that must be observed
+
+**Recommendation**: a convention that should be considered
+
+- **[Code Management](subsys-aiframework-tech-codemanage.md)**
+
+- **[Naming](subsys-aiframework-tech-name.md)**
+
+- **[API Development](subsys-aiframework-tech-interface.md)**
+
+
diff --git a/en/device-dev/subsystems/subsys-aiframework.md b/en/device-dev/subsystems/subsys-aiframework.md
new file mode 100644
index 0000000000000000000000000000000000000000..bdd0b162508a053ffe7b7b9f62fffa6401d644d1
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-aiframework.md
@@ -0,0 +1,13 @@
+# AI Framework
+
+- **[AI Engine Framework](subsys-aiframework-guide.md)**
+
+- **[Development Environment](subsys-aiframework-envbuild.md)**
+
+- **[Technical Specifications](subsys-aiframework-tech.md)**
+
+- **[Development Guidelines](subsys-aiframework-devguide.md)**
+
+- **[Development Examples](subsys-aiframework-demo.md)**
+
+
diff --git a/en/device-dev/subsystems/subsys-application-framework-builden.md b/en/device-dev/subsystems/subsys-application-framework-builden.md
new file mode 100644
index 0000000000000000000000000000000000000000..c7497eb01035c6d5c8569cfef1ca944cbf444136
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-application-framework-builden.md
@@ -0,0 +1,7 @@
+# Setting Up a Development Environment
+
+- Development board: Hi3516D V300
+
+- [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/development-example.md b/en/device-dev/subsystems/subsys-application-framework-demo.md
similarity index 100%
rename from en/device-dev/subsystems/development-example.md
rename to en/device-dev/subsystems/subsys-application-framework-demo.md
diff --git a/en/device-dev/subsystems/subsys-application-framework-guide.md b/en/device-dev/subsystems/subsys-application-framework-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..a4f37e5be36824b3f229c5f1b178e5a3e8d1197c
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-application-framework-guide.md
@@ -0,0 +1,711 @@
+# Development Guidelines
+
+- [When to Use](#section93012287133)
+- [Available APIs](#section11821047161319)
+- [How to Develop](#section10514141679)
+ - [Creating a Service Ability](#section19921154214315)
+ - [Development Guidelines on Bundle Management](#section1724016743217)
+ - [Packing a HAP File](#section171771212328)
+
+
+## When to Use
+
+- Develop Page abilities for applications that have a UI for human-machine interaction, such as news applications, video players, navigation applications, and payment applications. Most applications we use in our daily lives are such type of applications.
+
+- Develop Service abilities for applications so that they can run particular services in the background, such as music playing, computing, and navigation services.
+
+- Pack both Page and Service abilities into HarmonyOS Ability Packages \(HAPs\). All applications must be packed into HAP files before being published to the application market. Once published, users can then download the applications from the application market.
+
+## Available APIs
+
+**Table 1** APIs of the ability management framework
+
+
+
Function
+
+
Description
+
+
+
+
Want *WantParseUri(const char *uri)
+
+
Converts a specified character string into a Want object.
+
+
+
const char *WantToUri(Want want)
+
+
Converts a specified Want object into a character string.
Sets the UI layout for the host ability of the ability slice.
+
+
+
void OnStart(const Want& want)
+
+
Called when the ability slice is started. This callback is invoked to handle transitions between ability slice lifecycle states.
+
+
+
void OnStop()
+
+
Called when the ability slice is being destroyed. This callback is invoked to handle transitions between ability slice lifecycle states.
+
+
+
void OnActive(const Want& want)
+
+
Called when the ability slice is visible to users. This callback is invoked to handle transitions between ability slice lifecycle states.
+
+
+
void OnInactive()
+
+
Called when the ability slice is invisible to users. This callback is invoked to handle transitions between ability slice lifecycle states.
+
+
+
void OnBackground()
+
+
Called when the ability slice is moved to the background. This callback is invoked to handle transitions between ability slice lifecycle states.
+
+
+
int StartAbility(const Want &want)
+
+
Starts an ability based on the specified Want information.
+
+
+
int StopAbility(const Want &want)
+
+
Stops a Service ability based on the specified Want information.
+
+
+
int TerminateAbility()
+
+
Destroys the ability.
+
+
+
int ConnectAbility(const Want &want, const IAbilityConnection &conn, void *data);
+
+
Connects to a Service ability based on the specified Want information.
+
+
+
int DisconnectAbility(const IAbilityConnection &conn)
+
+
Disconnects from a Service ability.
+
+
+
const char *GetBundleName()
+
+
Obtains the bundle name of the application to which the ability belongs.
+
+
+
const char *GetSrcPath()
+
+
Obtains the source code path of the ability.
+
+
+
const char *GetDataPath()
+
+
Obtains the data path of the ability.
+
+
+
int StartAbility(const Want *want)
+
+
Starts an Ability. This function does not need to be used in applications developed based on Ability.
+
+
+
int ConnectAbility(const Want *want, const IAbilityConnection *conn, void *data);
+
+
Connects to a Service ability based on the specified Want information. This function does not need to be used in applications developed based on Ability.
+
+
+
int DisconnectAbility(const IAbilityConnection *conn);
+
+
Disconnects from a Service ability. This function does not need to be used in applications developed based on Ability.
+
+
+
int StopAbility(const Want *want)
+
+
Stops a Service ability based on the specified Want information. This function does not need to be used in applications developed based on Ability.
+
+
+
void (*OnAbilityConnectDone)(ElementName *elementName, SvcIdentity *serviceSid, int resultCode, void *data)
+
+
Called when a client is connected to a Service ability.
+
+
+
void (*OnAbilityDisconnectDone)(ElementName *elementName, int resultCode, void *data)
+
+
Called after all connections to a Service ability are disconnected.
+
+
+
void PostTask(const Task& task)
+
+
Posts a task to an asynchronous thread.
+
+
+
void PostQuit()
+
+
Quits the event loop of the current thread.
+
+
+
static AbilityEventHandler* GetCurrentHandler()
+
+
Obtains the event handler of the current thread.
+
+
+
void Run()
+
+
Starts running the event loop of the current thread.
+
+
+
#define REGISTER_AA(className)
+
+
Registers the class name of an Ability child class.
+
+
+
#define REGISTER_AS(className)
+
+
Registers the class name of an AbilitySlice child class.
+
+
+
+
+
+## How to Develop
+
+### Creating a Service Ability
+
+1. Create the **MyServiceAbility** child class from **Ability** in **my\_service\_ability.h**.
+
+ ```
+ class MyServiceAbility: public Ability {
+ protected:
+ void OnStart(const Want& want);
+ const SvcIdentity *OnConnect(const Want &want) override;
+ void MsgHandle(uint32_t funcId, IpcIo *request, IpcIo *reply) override;
+ };
+ ```
+
+2. Call the **REGISTER\_AA** macro to register the **ServiceAbility** class with the application framework so that the framework can instantiate the **MyServiceAbility** class you have created.
+
+ ```
+ #include "my_service_ability.h"
+
+ REGISTER_AA(ServiceAbility)
+
+ void MyServiceAbility::OnStart(const Want& want)
+ {
+ printf("ServiceAbility::OnStart\n");
+ Ability::OnStart(want);
+ }
+
+ const SvcIdentity *MyServiceAbility::OnConnect(const Want &want)
+ {
+ printf("ServiceAbility::OnConnect\n");
+ return Ability::OnConnect(want);
+ }
+
+ void MyServiceAbility::MsgHandle(uint32_t funcId, IpcIo *request, IpcIo *reply)
+ {
+ printf("ServiceAbility::MsgHandle, funcId is %u\n", funcId);
+ int result = 0;
+ if (funcId == 0) {
+ result = IpcIoPopInt32(request) + IpcIoPopInt32(request);
+ }
+ // push data
+ IpcIoPushInt32(reply, result);
+ }
+ ```
+
+3. Override the following lifecycle callbacks for Service abilities to implement your own logic for your Service ability. When overriding a lifecycle callback, you must call the corresponding function from the parent class.
+ - OnStart\(\)
+
+ This callback is invoked when a Service ability is being created to perform Service ability initialization operations that take a short time. This callback is invoked only once in the entire lifecycle of a Service ability.
+
+ ```
+ void MyServiceAbility::OnStart(const Want& want)
+ {
+ printf("ServiceAbility::OnStart\n");
+ Ability::OnStart(want);
+ }
+ ```
+
+ - OnConnect\(\)
+
+ This callback is invoked when another ability is connected to the Service ability. This callback returns an **SvcIdentity** object for the other ability to interact with the Service ability.
+
+ ```
+ const SvcIdentity *MyServiceAbility::OnConnect(const Want &want)
+ {
+ printf("ServiceAbility::OnConnect\n");
+ return Ability::OnConnect(want);
+ }
+ ```
+
+ - OnDisconnect\(\)
+
+ This callback is invoked when another ability is disconnected from the Service ability.
+
+ - OnStop\(\)
+
+ 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**.
+
+ ```
+ void ServiceAbility::MsgHandle(uint32_t funcId, IpcIo *request, IpcIo *reply)
+ {
+ printf("ServiceAbility::MsgHandle, funcId is %d\n", funcId);
+ int result = 0;
+ if (funcId == PLUS) {
+ result = IpcIoPopInt32(request) + IpcIoPopInt32(request);
+ }
+ // push data
+ IpcIoPushInt32(reply, result);
+ }
+ ```
+
+5. Register a Service ability.
+
+ Declare your Service ability in the **config.json** file by setting its **type** attribute to **service**.
+
+ ```
+ "abilities": [{
+ "name": "ServiceAbility",
+ "icon": "res/drawable/phone.png",
+ "label": "test app 2",
+ "launchType": "standard",
+ "type": "service",
+ "visible": true
+ }
+ ]
+ ```
+
+6. Start a Service ability.
+ - The **Ability** class provides the **StartAbility\(\)** function to start another ability. You can pass a **Want** object to this function to start a Service ability.
+
+ You can use the **SetWantElement\(\)** function provided in the **AbilityKit** to set information about the target Service ability to start. The **element** parameter of the **SetWantElement\(\)** function indicates the **ElementName** structure that contains the bundle name and target ability name required for starting an ability.
+
+ ```
+ {
+ Want want = { nullptr };
+ ElementName element = { nullptr };
+ SetElementBundleName(&element, "com.company.appname");
+ SetElementAbilityName(&element, "ServiceAbility");
+ SetWantElement(&want, element);
+ StartAbility(want);
+ ClearElement(&element);
+ ClearWant(&want);
+ }
+ ```
+
+ The **StartAbility\(\)** function is executed immediately. If the Service ability is not running while the function is called, the system invokes **OnStart\(\)** first.
+
+ - Stops a Service ability.
+
+ 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.
+
+ ```
+ {
+ // Create an IAbilityConnection object and implement the two callbacks.
+ IAbilityConnection abilityConnection = new IAbilityConnection();
+ abilityConnection->OnAbilityConnectDone = OnAbilityConnectDone;
+ abilityConnection->OnAbilityDisconnectDone = OnAbilityDisconnectDone;
+
+ void OnAbilityConnectDone(ElementName *elementName, SvcIdentity *serviceSid,
+ int resultCode, void *data)
+ {
+ if (resultCode != 0) {
+ return;
+ }
+ // Push data.
+ IpcIo request;
+ char dataBuffer[IPC_IO_DATA_MAX];
+ IpcIoInit(&request, dataBuffer, IPC_IO_DATA_MAX, 0);
+ IpcIoPushInt32(&request, 10);
+ IpcIoPushInt32(&request, 6);
+
+ // Send and receive the reply.
+ IpcIo reply;
+ uintptr_t ptr = 0;
+ if (Transact(nullptr, *serviceSid, 0, &request, &reply,
+ LITEIPC_FLAG_DEFAULT, &ptr) != LITEIPC_OK) {
+ printf("transact error\n");
+ return;
+ }
+ int result = IpcIoPopInt32(&reply);
+ printf("execute add method, result is %d\n", result);
+ if (ptr != 0) {
+ FreeBuffer(nullptr, reinterpret_cast(ptr));
+ }
+ }
+
+ void OnAbilityDisconnectDone(ElementName *elementName,
+ int resultCode, void *data)
+ {
+ printf("elementName is %s, %s\n",
+ elementName->bundleName, elementName->abilityName);
+ }
+ }
+ ```
+
+ - The following sample code snippet shows how to initiate ability connection and disconnection:
+
+ ```
+ {
+ // Connect an ability to a specified Service ability.
+ Want want = { nullptr };
+ ElementName element = { nullptr };
+ SetElementBundleName(&element, "com.company.appname");
+ SetElementAbilityName(&element, "ServiceAbility");
+ SetWantElement(&want, element);
+ ConnectAbility(want, *abilityConnection, this);
+
+ // Disconnect from a Service ability.
+ DisconnectAbility(*abilityConnection);
+ }
+ ```
+
+
+
+### Development Guidelines on Bundle Management
+
+**Installing an Application**
+
+The installation API can only be used by built-in system applications. Applications can be installed in either of the following paths:
+
+- Default installation directory **/storage/app/** in the system
+- Particular directory on the external storage, for example, a microSD card
+
+You can specify the installation path when creating an **InstallParam** instance. To install the application in the **/storage/app/** directory, set the **installLocation** member variable in the **InstallParam** instance to **INSTALL\_LOCATION\_INTERNAL\_ONLY**. To install the application in the **/sdcard/app/** directory of the external storage, set **installLocation** to **INSTALL\_LOCATION\_PREFER\_EXTERNAL**. The application installation process is asynchronous, and a semaphore-like mechanism is required to ensure that the installation callback can be executed.
+
+The procedure for installing an application is as follows \(the system directory is used as an example\):
+
+1. Place the signed HAP file in a specified directory.
+2. Create an **InstallParam** instance and define the semaphore.
+
+ ```
+ InstallParam installParam = {
+ .installLocation = INSTALL_LOCATION_INTERNAL_ONLY, // Install the application in the system directory.
+ .keepData = false
+ };
+ static sem_t g_sem;
+ ```
+
+3. Define the callback function.
+
+ ```
+ static void InstallCallback(const uint8_t resultCode, const void *resultMessage)
+ {
+ std::string strMessage = reinterpret_cast(resultMessage);
+ if (!strMessage.empty()) {
+ printf("install resultMessage is %s, %d\n", strMessage.c_str(),resultCode);
+ }
+ sem_post(&g_sem);
+ }
+ ```
+
+4. Call the **Install** function.
+
+ ```
+ const uint32_t WAIT_TIMEOUT = 30;
+ sem_init(&g_sem, 0, 0);
+ std::string installPath = "/storage/bundle/demo.hap"; // Specify the path where the HAP file is stored.
+ bool result = Install(installPath.c_str(), &installParam, InstallCallback);
+ struct timespec ts = {};
+ clock_gettime(CLOCK_REALTIME, &ts);
+ ts.tv_sec += WAIT_TIMEOUT; // Release the semaphore upon timeout.
+ sem_timedwait(&g_sem, &ts);
+ ```
+
+
+**Uninstalling an Application**
+
+When uninstalling an application, you can specify whether to retain application data using the **keepData** member variable in the created **InstallParam** instance. If **keepData** is set to **true**, the application data will be retained after the application is uninstalled. If the variable is set to **false**, the application data will be removed during application installation.
+
+1. Create an **InstallParam** instance and define the semaphore.
+
+ ```
+ static sem_t g_sem;
+ InstallParam installParam = {
+ .installLocation = 1,
+ .keepData = false // Remove application data.
+ };
+ ```
+
+2. Define the callback function.
+
+ ```
+ static void UninstallCallback(const uint8_t resultCode, const void *resultMessage)
+ {
+ std::string strMessage = reinterpret_cast(resultMessage);
+ if (!strMessage.empty()) {
+ printf("uninstall resultMessage is %s\n", strMessage.c_str());
+ g_resultMessage = strMessage;
+ }
+ g_resultCode = resultCode;
+ sem_post(&g_sem);
+ }
+ ```
+
+3. Call the **Uninstall** function.
+
+ ```
+ sem_init(&g_sem, 0, 0);
+ const uint32_t WAIT_TIMEOUT = 30;
+ std::string BUNDLE_NAME = "com.huawei.demo"; // Bundle name of the application to be uninstalled
+ Uninstall(BUNDLE_NAME.c_str(), &installParam, UninstallCallback);
+ struct timespec ts = {};
+ clock_gettime(CLOCK_REALTIME, &ts);
+ ts.tv_sec += WAIT_TIMEOUT;
+ sem_timedwait(&g_sem, &ts);
+ ```
+
+
+**Querying Bundle Information About an Installed Application**
+
+You can use the **GetBundleInfo** function provided by **BundleManager** to query the bundle information about installed applications in the system.
+
+1. Create and initialize a **BundleInfo** object.
+
+ ```
+ BundleInfo bundleInfo;
+ (void) memset_s(&bundleInfo, sizeof(BundleInfo), 0, sizeof(BundleInfo));
+ ```
+
+2. Call **GetBundleInfo** to obtain bundle information about a specified application. The **bundleName** parameter indicates the pointer to the application bundle name, and the **flags** parameter specifies whether the obtained **BundleInfo** object can contain **AbilityInfo**.
+
+ ```
+ std::string BUNDLE_NAME = "com.huawei.demo";
+ uint8_t ret = GetBundleInfo(BUNDLE_NAME.c_str(), 1, &bundleInfo); // When flags is set to 1, the obtained BundleInfo object contains AbilityInfo.
+ ```
+
+3. After you finish using the obtained **BundleInfo** object, clear the memory space occupied by the object in a timely manner to prevent memory leakage.
+
+ ```
+ ClearBundleInfo(&bundleInfo);
+ ```
+
+
+### Packing a HAP File
+
+The packing tool is generally integrated into the development tool or IDE, and you rarely have the occasion to use it directly. This section is provided for you to have a general knowledge of the packing tool. The JAR file of the packing tool is stored in the **developtools/packing\_tool/jar** directory of the open-source code.
+
+- CLI command parameters for packing a HAP file
+
+ **Table 2** Description of resource files required for packing
+
+
+
Command Parameter
+
+
Resource File
+
+
Description
+
+
Initial Value Allowed
+
+
+
+
--mode
+
+
-
+
+
This parameter is set to hap for packing the resource files into a HAP file.
+
+
No
+
+
+
--json-path
+
+
Configuration file config.json
+
+
-
+
+
No
+
+
+
--resources-path
+
+
Resource file resources
+
+
-
+
+
Yes
+
+
+
--assets-path
+
+
Resource file assets
+
+
-
+
+
Yes
+
+
+
--lib-path
+
+
Dependent library file
+
+
-
+
+
Yes
+
+
+
--shared-libs-path
+
+
Shared library file
+
+
The shared library is used by system applications in special cases.
+
+
Yes
+
+
+
--ability-so-path
+
+
SO file providing main functionality
+
+
-
+
+
Yes
+
+
+
--index-path
+
+
Resource index
+
+
The resource index file is generated by the resource generation tool and integrated by the resource pipeline.
+
+
Yes
+
+
+
--out-path
+
+
-
+
+
This parameter indicates the output path of the generated HAP file. The default value is the current directory.
+
+
Yes
+
+
+
--force
+
+
-
+
+
This parameter specifies whether to overwrite an existing file with the same name. The default value is false.
+
+
Yes
+
+
+
+
+
+- Example HAP File Structure
+ - Development view
+
+ 
+
+ - Compilation view
+
+ 
+
+ - Run the following commands to pack a HAP file using the packing tool.
+
+ 
+
+ ```
+ $ java -jar hmos_app_packing_tool.jar --mode hap --json-path ./config.json --assets-path ./assets/ --ability-so-path ./libentry.so --index-path ./resources.index --out-path out/entry.hap --force true
+ ```
+
+
+
diff --git a/en/device-dev/subsystems/subsys-application-framework-overview.md b/en/device-dev/subsystems/subsys-application-framework-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..a199610651dc5f2867adf61d356371d07e70b91a
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-application-framework-overview.md
@@ -0,0 +1,148 @@
+# Overview
+
+- [Basic Concepts](#section72601941194812)
+- [Ability Management Framework](#section14633111813374)
+- [Bundle Management Framework](#section1341146154412)
+- [Working Principles](#section94302021112717)
+- [Limitations and Constraints](#section89534912527)
+
+The application framework is provided by OpenHarmony for you to develop OpenHarmony applications. It consists of two modules: ability management framework \(also called the ability framework\) and bundle management framework.
+
+## Basic Concepts
+
+This section describes some basic concepts for you to better understand the OpenHarmony application framework before you start development.
+
+## Ability Management Framework
+
+The ability management framework manages running status of OpenHarmony applications.
+
+**Figure 1** Architecture of the ability management framework
+
+
+- **Ability** is the minimum unit for the system to schedule applications. It is a component that can implement an independent functionality. An application can contain one or more **Ability** instances. There are two types of templates that you can use to create an **Ability** instance: Page and Service.
+ - An **Ability using the Page template** \(Page ability for short\) provides a UI for interacting with users.
+
+ - An **Ability using the Service template** does not have a UI and is used for running background tasks.
+
+
+
+- An **AbilitySlice** represents a single screen and its control logic. It is specific to Page abilities. A Page ability may contain one ability slice or multiple ability slices that provide highly relevant capabilities.
+
+ **Figure 2** Relationship between a Page ability and its ability slices
+ 
+
+- **Lifecycle** is a general term for all states of an ability, including **INITIAL**, **INACTIVE**, **ACTIVE**, and **BACKGROUND**.
+
+ **Figure 3** Lifecycle state transition of a Page ability
+
+
+ 
+
+ - **OnStart\(\)**
+
+ This callback is invoked when the system first creates the Page ability. After this callback is executed, the Page ability enters the **INACTIVE** state. This callback is triggered only once in the entire lifecycle of each Page ability. You must override this callback and set the default ability slice to be displayed.
+
+ - **OnActive\(\)**
+
+ This callback is invoked when the Page ability in the **INACTIVE** state enters the foreground. After this callback is executed, the Page ability enters the **ACTIVE** state, in which it becomes interactive. The Page ability will stay in this state unless it loses focus upon a certain event, for example, when the user touches the Back button or navigates to another Page ability.
+
+ When such an event occurs, the Page ability returns to the **INACTIVE** state, and the system invokes the **OnInactive\(\)** callback. The Page ability may move to the **ACTIVE** state again, and the system will then invoke the **OnActive\(\)** callback again. You should implement both **OnActive\(\)** and **OnInactive\(\)** for a Page ability and use **OnActive\(\)** to obtain the resources released in **OnInactive\(\)**.
+
+ - **OnInactive\(\)**
+
+ This callback is invoked when the Page ability loses focus, and the Page ability then becomes **INACTIVE**. You can implement the behavior to perform after the Page ability loses focus.
+
+ - **OnBackground\(\)**
+
+ This callback is invoked based on the system resource status when the Page ability becomes invisible to the user. After this callback is executed, the Page ability enters the **BACKGROUND** state. You should release the resources that are no longer needed after the Page ability becomes invisible or perform time-consuming save operations in this callback.
+
+ - **OnForeground\(\)**
+
+ A Page ability in the **BACKGROUND** state still resides in memory. When the Page ability returns to the foreground \(for example, when the user navigates to this Page ability again\), the system first calls **OnForeground\(\)** to switch the Page ability to the **INACTIVE** state, and then calls **OnActive\(\)** to make it **ACTIVE**. You should use the **OnForeground\(\)** callback to reclaim the resources released in **OnBackground\(\)**. Currently, the **OnForeground\(\)** callback is unavailable to lite devices.
+
+ - **OnStop\(\)**
+
+ This callback is invoked when the system is destroying a Page ability due to one of the following possible causes:
+
+ - The user explicitly closes the Page ability using a system management feature, for example, the task manager.
+ - The user behavior, for example, exiting an application, triggers the **TerminateAbility\(\)** function on the Page ability.
+ - The system needs to temporarily destroy the Page ability and re-create it due to configuration changes.
+ - The system automatically destroys a Page ability in the **BACKGROUND** state due to resource management purposes.
+
+
+- **AbilityKit** is a development kit provided by the ability management framework. You can use this kit to develop applications based on the **Ability** component. There are two types of applications developed based on the **Ability** component: JS Ability developed using the JavaScript language and Native Ability developed using the C/C++ language. The JS application development framework encapsulates JavaScript UI components on the basis of the AbilityKit and is used to help you quickly develop JS Ability-based applications.
+- **AbilityLoader** is used to register and load **Ability** classes. After creating an **Ability** class, you should first call the registration API defined in **AbilityLoader** to register the **Ability** class name with the ability management framework so that this **Ability** can be instantiated when being started.
+
+- **AbilityManager** enables inter-process communication \(IPC\) between the AbilityKit and the Ability Manager Service.
+
+- **EventHandler** is provided by the AbilityKit to enable inter-thread communication between abilities.
+
+- The **Ability Manager Service** is a system service used to coordinate the running relationships and lifecycle states of **Ability** instances. It consists of the following modules:
+
+ - The service startup module starts and registers the Ability Manager Service.
+ - The service interface management module manages external capabilities provided by the Ability Manager Service.
+ - The process management module starts and destroys processes where **Ability** instances are running, and maintains the process information.
+ - The ability stack management module maintains the presentation sequence of abilities in the stack.
+ - The lifecycle scheduling module changes an ability to a particular state based on the current operation of the system.
+ - The connection management module manages connections to Service abilities.
+
+- **AppSpawn** is a system service used to create the process for running an ability. This service has high permissions. It sets permissions for **Ability** instances and pre-loads some common modules to accelerate application startup.
+
+
+## Bundle Management Framework
+
+The bundle management framework is provided by OpenHarmony for you to manage application bundles.
+
+**Figure 4** Architecture of the bundle management framework
+
+
+- **BundleKit** includes external APIs provided by the Bundle Manager Service, including the APIs for application installation and uninstallation, bundle information query, and bundle state change listeners.
+- The **bundle scanning sub-module** parses pre-installed or installed bundles on the local device and extracts information from them for the bundle management module to manage and make the information persistent for storage.
+- The **bundle installation sub-module** installs, uninstalls, and updates a bundle. The **bundle installation service** is an independent process that communicates with the Bundle Manager Service through IPC. It is used to create or delete installation directories and has high permissions.
+
+- The **bundle management sub-module** manages information related to application bundles and stores persistent bundle information.
+
+- The **bundle security management sub-module** verifies signatures, and grants and manages permissions.
+
+
+## Working Principles
+
+The Ability Manager Service and Bundle Manager Service are the core modules of the ability management framework and bundle management framework, respectively. The two system-level services are registered and discovered by using the system service framework SAMgr, and they are used by manage abilities and bundles for other processes. The Ability Manager Service and Bundle Manager Service are provided as open APIs in the AbilityKit and BundleKit.
+
+**Figure 5** Startup of the Ability Manager Service and Bundle Manager Service
+
+
+OpenHarmony applications can be installed and started after the two services are started.
+
+**Figure 6** Application startup process
+
+
+The home screen is the first OpenHarmony application started by the Ability Manager Service. After the home screen is started, the user can touch any installed OpenHarmony application on the home screen to start the particular application. The figure above shows the interaction process of starting an installed application from the home screen.
+
+As shown in the figure, the Ability Manager Service is responsible for displaying or hiding an ability, and the Bundle Manager Service is responsible for storing and querying ability information.
+
+## Limitations and Constraints
+
+- Language version
+
+ - C++ 11 or later
+
+
+- The specifications of the application framework vary depending on the System-on-a-Chip \(SoC\) and underlying OS capabilities.
+
+ - Cortex-M RAM and ROM
+
+ - RAM: greater than 20 KB \(recommended\)
+
+ - 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\)
+
+ - ROM: greater than 2 MB \(for the JS application development framework and related subsystems, such as UIKit and engine\)
+
+
+
+
diff --git a/en/device-dev/subsystems/subsys-application-framework.md b/en/device-dev/subsystems/subsys-application-framework.md
new file mode 100644
index 0000000000000000000000000000000000000000..aeca8dc7dd6695791adc4204f1c76c88acd96568
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-application-framework.md
@@ -0,0 +1,11 @@
+# Application Framework
+
+- **[Overview](subsys-application-framework-overview.md)**
+
+- **[Setting Up a Development Environment](subsys-application-framework-builden.md)**
+
+- **[Development Guidelines](subsys-application-framework-guide.md)**
+
+- **[Development Example](subsys-application-framework-demo.md)**
+
+
diff --git a/en/device-dev/subsystems/appspawn-module.md b/en/device-dev/subsystems/subsys-boot-appspawn.md
similarity index 100%
rename from en/device-dev/subsystems/appspawn-module.md
rename to en/device-dev/subsystems/subsys-boot-appspawn.md
diff --git a/en/device-dev/subsystems/bootstrap-module.md b/en/device-dev/subsystems/subsys-boot-bootstrap.md
similarity index 100%
rename from en/device-dev/subsystems/bootstrap-module.md
rename to en/device-dev/subsystems/subsys-boot-bootstrap.md
diff --git a/en/device-dev/subsystems/subsys-boot-faqs.md b/en/device-dev/subsystems/subsys-boot-faqs.md
new file mode 100644
index 0000000000000000000000000000000000000000..25aa1270b4fb1352445d1e41a4569eb255c95cf1
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-boot-faqs.md
@@ -0,0 +1,56 @@
+# FAQs
+
+- [System startup interrupted due to "parse failed!" error](#section2041345718513)
+- [System automatically restarted again and again](#section57381816168)
+- [Failed to call the SetParameter or GetParameter API with correct parameter values](#section129991227141512)
+
+## System startup interrupted due to "parse failed!" error
+
+**Problem**
+
+During system startup, the error message "\[Init\] InitReadCfg, parse failed! please check file /etc/init.cfg format." is displayed, and the startup is interrupted, as shown in the following figure.
+
+
+
+**Cause**
+
+During the modification of the **init.cfg** file, required commas \(,\) or parentheses are missing or unnecessary ones are added. As a result, the file's JSON format becomes invalid.
+
+**Solution**
+
+Check the **init.cfg** file and ensure that its format meets the JSON specifications.
+
+## System automatically restarted again and again
+
+**Problem**
+
+After the image burning is complete, the system keeps restarting.
+
+**Cause**
+
+Each service started by the init process has the **importance** attribute, as described in Table 3 in [init Module](subsys-boot-init.md).
+
+- If the attribute value is **0**, the init process does not need to restart the development board when the current service process exits.
+- If the attribute value is **1**, the init process needs to restart the development board when the current service process exits.
+
+During the startup of a service whose **importance** is **1**, if the service exits due to a process crash or an error, the init process automatically restarts the development board.
+
+**Solution**
+
+1. View logs to identify the service that encounters a process crash or exits due to an error, rectify the issue, and then burn the image again.
+2. Alternatively, change the value of **importance** to **0** for the service that exits due to a process crash or an error, and then burn the image again. In this way, the development board will not be restarted even if the service exits.
+
+## Failed to call the **SetParameter** or **GetParameter** API with correct parameter values
+
+**Problem**
+
+Calling the **SetParameter** or **GetParameter** API fails even if correct values are passed to all input parameters.
+
+**Cause**
+
+Permission verification has been enabled for the **SetParameter** and **GetParameter** APIs. If the UID of the caller is greater than 1000, that is, the caller does not have the permission to call these APIs, API calls will fail even if the parameters are correct.
+
+**Solution**
+
+No action is required.
+
diff --git a/en/device-dev/subsystems/init-module.md b/en/device-dev/subsystems/subsys-boot-init.md
similarity index 100%
rename from en/device-dev/subsystems/init-module.md
rename to en/device-dev/subsystems/subsys-boot-init.md
diff --git a/en/device-dev/subsystems/subsys-boot-overview.md b/en/device-dev/subsystems/subsys-boot-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..77400377f93c5cbb3df8b79958bb6db53446ae72
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-boot-overview.md
@@ -0,0 +1,66 @@
+# Startup
+
+- [Limitations and Constraints](#section2029921310472)
+
+The startup subsystem provides the functions of starting key system processes after the kernel is started and before applications are started, and restoring the system to factory settings. The subsystem consists of the following modules:
+
+- init module
+
+ This module corresponds to the init process, which is the first user-space process started after the kernel is initialized. Upon startup, the init process reads and parses the configuration file **init.cfg**. Based on the parsing result, the init module executes the commands listed in Table 2 in [init Module](subsys-boot-init.md) and starts the key system service processes in sequence with corresponding permissions granted.
+
+- appspawn module
+
+ This module spawns application processes upon receiving commands from the application framework, configures permissions for new processes, and calls the entry function of the application framework.
+
+- bootstrap module
+
+ This module provides entry identifiers for starting services and features. When the Samgr is started, the entry function identified by boostrap is called and system services are started.
+
+- syspara module
+
+ This module provides APIs for obtaining device information, such as the product name, brand name, and manufacturer name, based on the OpenHarmony Product Compatibility Specifications \(PCS\). It also provides APIs for setting and obtaining system parameters.
+
+
+## Limitations and Constraints
+
+The directories of startup subsystem are applicable to different platforms.
+
+**Table 1** Directories and applicable platforms of the startup subsystem
+
+
+
Directory
+
+
Applicable Platform
+
+
+
+
base/startup/appspawn_lite
+
+
Small-system devices (reference memory ≥ 1 MB), for example, Hi3516D V300 and Hi3518E V300
+
+
+
base/startup/bootstrap_lite
+
+
Mini-system devices (reference memory ≥ 128 KB), for example, Hi3861 V100
+
+
+
base/startup/init_lite
+
+
Small-system devices (reference memory ≥ 1 MB), for example, Hi3516D V300 and Hi3518E V300
+
+
+
base/startup/syspara_lite
+
+
Mini-system devices (reference memory ≥ 128 KB), for example, Hi3861 V100
Small-system devices (reference memory ≥ 1 MB), for example, Hi3516D V300 and Hi3518E V300
+
+
+
+
+
+- init module
+ - After being burnt to the development board, the configuration file **init.cfg** changes to read-only. If you want to modify the file, you must repack and burn the rootfs image again.
+ - The configuration file **init.cfg** must be in JSON format.
+
+- bootstrap module: The zInit code needs to be configured in the link script.
+- syspara module: The **SetParameter** and **GetParameter** APIs can only be called by applications whose UID is greater than 1000.
+
diff --git a/en/device-dev/subsystems/reference.md b/en/device-dev/subsystems/subsys-boot-ref.md
similarity index 100%
rename from en/device-dev/subsystems/reference.md
rename to en/device-dev/subsystems/subsys-boot-ref.md
diff --git a/en/device-dev/subsystems/syspara-module.md b/en/device-dev/subsystems/subsys-boot-syspara.md
similarity index 100%
rename from en/device-dev/subsystems/syspara-module.md
rename to en/device-dev/subsystems/subsys-boot-syspara.md
diff --git a/en/device-dev/subsystems/subsys-boot.md b/en/device-dev/subsystems/subsys-boot.md
new file mode 100644
index 0000000000000000000000000000000000000000..b8f465d360614689758d2a538638e51da9f70007
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-boot.md
@@ -0,0 +1,17 @@
+# Startup
+
+- **[Startup](subsys-boot-overview.md)**
+
+- **[init Module](subsys-boot-init.md)**
+
+- **[appspawn Module](subsys-boot-appspawn.md)**
+
+- **[bootstrap Module](subsys-boot-bootstrap.md)**
+
+- **[syspara Module](subsys-boot-syspara.md)**
+
+- **[FAQs](subsys-boot-faqs.md)**
+
+- **[Reference](subsys-boot-ref.md)**
+
+
diff --git a/en/device-dev/subsystems/subsys-build-mini-lite.md b/en/device-dev/subsystems/subsys-build-mini-lite.md
new file mode 100644
index 0000000000000000000000000000000000000000..5d95a69ed431174a90a4c3c5451b845e349809f2
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-build-mini-lite.md
@@ -0,0 +1,998 @@
+# Building Guidelines for Mini and Small Systems
+
+- [Overview](#section10958256161119)
+ - [Basic Concepts](#section1732301411128)
+ - [Directory Structure](#section1588744014121)
+ - [Build Process](#section15761735134)
+
+- [Configuration Rules](#section2345183962710)
+ - [Module](#section142532518308)
+ - [Chipset](#section121501451143710)
+ - [Product](#section134549283435)
+
+- [Usage Guidelines](#section13754457192211)
+ - [Prerequisites](#section31651120233)
+ - [Using hb](#section1133304172313)
+ - [Adding a Module](#section167110415315)
+ - [Adding a Chipset Solution](#section1474718565412)
+ - [Adding a Product Solution](#section1097623294220)
+
+- [Troubleshooting](#section19909721104319)
+ - [Invalid -- w Option](#section138233464318)
+ - [Library ncurses Not Found](#section151033911442)
+ - [mcopy not Found](#section19811838104418)
+ - [No riscv File or Directory](#section03111118451)
+ - [No Crypto](#section69981127125013)
+ - [Unexpected Operator](#section967617530505)
+
+
+## Overview
+
+The Compilation and Building subsystem is a build framework that supports module-based OpenHarmony development using Generate Ninja \(GN\) and Ninja. You can use this subsystem to:
+
+- Assemble modules for a product and build the product.
+
+- Build chipset source code independently.
+- Build a single module independently.
+
+### Basic Concepts
+
+Learn the following concepts before you start compilation and building:
+
+- Subsystem
+
+ A subsystem is a logical concept. It consists of one or more modules. OpenHarmony is designed with a layered architecture, which consists of the kernel layer, system service layer, framework layer, and application layer from bottom to top. System functions are developed by the level of system, subsystem, and module. In a multi-device deployment scenario, you can customize subsystems and modules as required.
+
+
+- Module
+
+ A module is a reusable, configurable, and tailorable function unit. Each module has an independent directory, and multiple modules can be developed concurrently and built and tested independently.
+
+- **GN**
+
+ Generate Ninja \(GN\) is used to generate Ninja files.
+
+- **Ninja**
+
+ Ninja is a small high-speed build system.
+
+- **hb**
+
+ hb is a command line tool for OpenHarmony to execute build commands.
+
+
+### Directory Structure
+
+```
+build/lite
+├── components # Module description file
+├── figures # Figures in the readme file
+├── hb # hb pip installation package
+├── make_rootfs # Script used to create the file system image
+├── config # Build configuration
+│ ├── component # Module-related template definition
+│ ├── kernel # Kernel-related build configuration
+│ └── subsystem # Subsystem build configuration
+├── platform # ld script
+├── testfwk # Test build framework
+└── toolchain # Build toolchain configuration, which contains the compiler directories, build options, and linking options
+```
+
+### **Build Process**
+
+[Figure 1](#fig9744112715161) shows the build process.
+
+**Figure 1** Build process
+
+
+1. Use **hb set **to set the OpenHarmony source code directory and the product to build.
+2. Use **hb build** to build the product, development board, or module. The procedure is as follows:
+ - Read the **config.gni** file of the development board selected. The file contains the build toolchain, linking commands, and build options.
+ - Run the **gn gen** command to read the product configuration and generate the **out** directory and **ninja** files for the solution.
+ - Run **ninja -C out/board/product** to start the build.
+ - Package the build result, set the file attributes and permissions, and create a file system image.
+
+
+## Configuration Rules
+
+To ensure that the chipset and product solutions are pluggable and decoupled from OpenHarmony, the paths, directory trees, and configuration of modules, chipset solutions, and product solutions must comply with the following rules:
+
+### **Module**
+
+The source code directory for a module is named in the _\{Domain\}/\{Subsystem\}/\{Module\}_ format. The module directory tree is as follows:
+
+> **CAUTION:**
+>Define module attributes, such as the name, source code directory, function description, mandatory or not, build targets, RAM, ROM, build outputs, adapted kernels, configurable features, and dependencies, in the JSON file of the subsystem in the **build/lite/components** directory. When adding a module, add its definition to the JSON file of the corresponding subsystem. The module configured for a product must have been defined in a subsystem. Otherwise, the verification will fail.
+
+```
+component
+├── interfaces
+│ ├── innerkits # APIs exposed internally among modules
+│ └── kits # App APIs provided for app developers
+├── frameworks # Framework implementation
+├── services # Service implementation
+└── BUILD.gn # Build script
+```
+
+The following example shows how to define attributes of the sensor module of the pan-sensor subsystem:
+
+```
+{
+ "components": [
+ {
+ "component": "sensor_lite", # Module name
+ "description": "Sensor services", # Brief description of the module
+ "optional": "true", # Whether the module is mandatory for the system
+ "dirs": [ # Source code directory of the module
+ "base/sensors/sensor_lite"
+ ],
+ "targets": [ # Build entry of the module
+ "//base/sensors/sensor_lite/services:sensor_service"
+ ],
+ "rom": "92KB", # Module ROM
+ "ram": "~200KB", # Module RAM (estimated)
+ "output": [ "libsensor_frameworks.so" ], # Module build outputs
+ "adapted_kernel": [ "liteos_a" ], # Adapted kernel for the module
+ "features": [], # Configurable features of the module
+ "deps": {
+ "components": [ # Other modules on which the module depends
+ "samgr_lite",
+ "ipc_lite"
+
+ ],
+ "third_party": [ # Open-source third-party software on which the module depends
+ "bounds_checking_function"
+ ]
+ }
+ }
+ ]
+}
+```
+
+Observe the following rules when building the **BUILD.gn** module:
+
+- The build target name must be the same as the module name.
+- Define the configurable features in the **BUILD.gn** file of the module. Name the configurable features in the **ohos\_**\{_subsystem_\}**\_**\{_module_\}**\_**\{_feature_\} format. Define the features in module description and configure them in the **config.json** file.
+- Define macros in the **OHOS\_**\{_SUBSYSTEM_\}**\_**\{_MODULE_\}**\_**\{_FEATURE_\} format.
+
+ > **NOTE:**
+ >GN is used as the build script language for modules. For details about how to use GN, see the [GN Quick Start Guide](https://gn.googlesource.com/gn/+/master/docs/quick_start.md). In GN, a module is a build target, which can be a static library, a dynamic library, an executable file, or a group.
+
+
+The following example shows how to build the **foundation/graphic/ui/BUILD.gn** file for a graphics UI module:
+
+```
+ # Declare the configurable features of the module
+ declare_args() {
+ enable_ohos_graphic_ui_animator = false # Animation switch
+ ohos_ohos_graphic_ui_font = "vector" # Configurable font type, which can be vector or bitmap
+ }
+
+ # Basic module functions
+ shared_library("base") {
+ sources = [
+ ......
+ ]
+ include_dirs = [
+ ......
+ ]
+ }
+
+ # Build only when the animator is enabled
+ if(enable_ohos_graphic_ui_animator ) {
+ shared_library("animator") {
+ sources = [
+ ......
+ ]
+ include_dirs = [
+ ......
+ ]
+ deps = [ :base ]
+ }
+ }
+ ......
+ # It is recommended that the target name be the same as the module name, which can be an executable .bin file, shared_library (.so file), static_library (.a file), or a group.
+ executable("ui") {
+ deps = [
+ ":base"
+ ]
+
+ # The animator feature is configured by the product.
+ if(enable_ohos_graphic_ui_animator ) {
+ deps += [
+ "animator"
+ ]
+ }
+ }
+```
+
+### **Chipset**
+
+- The chipset solution is a complete solution based on a development board. The solution includes the drivers, API adaptation, and SDK.
+- The chipset solution is a special module, whose source code directory is named in the _**device**/\{Chipset solution vendor\}/\{Development board\}_ format.
+- The chipset solution module is built by default based on the development board selected by the product.
+
+The chipset solution directory tree is as follows:
+
+```
+device
+└── company # Chipset solution vendor
+ └── board # Name of the development board
+ ├── BUILD.gn # Build script
+ ├── hals # Southbound APIs for OS adaptation
+ ├── linux # Linux kernel version (optional)
+ │ └── config.gni # Build options for the Linux version
+ └── liteos_a # LiteOS kernel version (optional)
+ └── config.gni # Build options for the LiteOS Cortex-A version
+```
+
+> **NOTE:**
+>The **config.gni** file contains build-related configurations of the development board. The parameters in the file are globally visible to the system and can be used to build all OS modules during the build process.
+
+The **config.gni** file contains the following key parameters:
+
+```
+kernel_type: kernel used by the development board, for example, liteos_a, liteos_m, or linux.
+kernel_version: kernel version used by the development board, for example, 4.19.
+board_cpu: CPU of the development board, for example, cortex-a7 or riscv32.
+board_arch: chipset architecture of the development board, for example, armv7-a or rv32imac.
+board_toolchain: name of the customized build toolchain used by the development board, for example, gcc-arm-none-eabi. If this field is not specified, ohos-clang will be used by default.
+board_toolchain_prefix: prefix of the build toolchain, for example, gcc-arm-none-eabi.
+board_toolchain_type: build toolchain type, for example, gcc or clang. Currently, only GCC and clang are supported.
+board_cflags: build options of the .c file configured for the development board.
+board_cxx_flags: build options of the .cpp file configured for the development board.
+board_ld_flags: link options configured for the development board.
+```
+
+### **Product**
+
+The product solution is a complete product based on a development board. It includes the OS adaptation, module assembly configuration, startup configuration, and file system configuration. The source code directory of a product solution is named in the **vendor**/\{_Product solution vendor_\}/\{_Product name_\} format. A product solution is also a special module.
+
+The product solution directory tree is as follows:
+
+```
+vendor
+└── company # Product solution vendor
+ ├── product # Product name
+ │ ├── init_configs
+ │ │ ├── etc # Startup configuration of the init process (only required for the Linux kernel)
+ │ │ └── init.cfg # System service startup configuration
+ │ ├── hals # OS adaptation
+ │ ├── BUILD.gn # Product build script
+ │ └── config.json # Product configuration file
+ │ └── fs.yml # File system packaging configuration
+ └── ......
+```
+
+> **CAUTION:**
+>Create directories and files based on the preceding rules for new products. The Compilation and Building subsystem scans the configured products based on the rules.
+
+The key directories and files are described as follows:
+
+1. **vendor/company/product/init\_configs/etc**
+
+ This folder contains the **rcS**, **S**_xxx_, and **fstab** scripts. The **init** process runs the **rcS**, **fstab**, and **S**_00_-_xxx_ scripts in sequence before starting system services. The **S**_xxx_ script contains content related to the development board and product. It is used to create device nodes and directories, scan device nodes, and change file permissions. These scripts are copied from the **BUILD.gn** file to the **out** directory of the product as required and packaged into the **rootfs** image.
+
+2. **vendor/company/product/init\_configs/init.cfg**
+
+ This file is the configuration file for the **init** process to start services. Currently, the following commands are supported:
+
+ - **start**: starts a service.
+ - **mkdir**: creates a folder.
+ - **chmod**: changes the permission on a specified directory or file.
+ - **chown**: changes the owner group of a specified directory or file.
+ - **mount**: mounts a device.
+
+ The fields in the file are described as follows:
+
+ ```
+ {
+ "jobs" : [{ # Job array. A job corresponds to a command set. Jobs are executed in the following sequence: pre-init > init > post-init.
+ "name" : "pre-init",
+ "cmds" : [
+ "mkdir /storage/data", # Create a directory.
+ "chmod 0755 /storage/data", # Change the permission, which is in 0xxx format, for example, 0755.
+ "mkdir /storage/data/log",
+ "chmod 0755 /storage/data/log",
+ "chown 4 4 /storage/data/log", # Change the owner group. The first number indicates the UID, and the second indicates the GID.
+ ......
+ "mount vfat /dev/mmcblock0 /sdcard rw, umask=000" # The command is in the mount [File system type][source] [target] [flags] [data] format.
+ # Currently, flags can only be nodev, noexec, nosuid, or rdonly.
+ ]
+ }, {
+ "name" : "init",
+ "cmds" : [ # Start services based on the sequence of the cmds array.
+ "start shell", # Note that there is only one space between start and the service name.
+ ......
+ "start service1"
+ ]
+ }, {
+ "name" : "post-init", # Job that is finally executed. Operations performed after the init process is started, for example, mounting a device after the driver initialization.
+ "cmds" : []
+ }
+ ],
+ "services" : [{ # Service array. A service corresponds to a process.
+ "name" : "shell", # Service name
+ "path" : ["/sbin/getty", "-n", "-l", "/bin/sh", "-L", "115200", "ttyS000", "vt100"], # Full path of the executable file. It must start with "path".
+ "uid" : 0, # Process UID, which must be the same as that in the binary file.
+ "gid" : 0, # Process GID, which must be the same as that in the binary file.
+ "once" : 0, # Whether the process is a one-off process. 1: The proces is a one-off process. The init process does not restart it after the process exits. 0: The process is not a one-off process. The init process restarts it if the process exits.
+ "importance" : 0, # Whether the process is a key process. 1: The process is a key process. If it exits, the init process restarts the board. 0: The process is not a key process. If it exits, the init process does not restart the board.
+ "caps" : [4294967295]
+ },
+ ......
+ ]
+ }
+ ```
+
+3. **vendor/company/product/init\_configs/hals**
+
+ This file stores the content related to OS adaptation of the product. For details about APIs for implementing OS adaptation, see the readme file of each module.
+
+4. **vendor/company/product/config.json**
+
+ The **config.json** file is the main entry for the build and contains configurations of the development board, OS modules, and kernel.
+
+ The following example shows the **config.json** file of the IP camera developed based on the hispark\_taurus development board:
+
+ ```
+ {
+ "product_name": "ipcamera", # Product name
+ "ohos_version": "OpenHarmony 1.0", # OS version
+ "device_company": "hisilicon", # Chipset vendor
+ "board": "hispark_taurus", # Name of the development board
+ "kernel_type": "liteos_a", # Kernel type
+ "kernel_version": "3.0.0", # Kernel version
+ "subsystems": [
+ {
+ "subsystem": "aafwk", # Subsystem
+ "components": [
+ { "component": "ability", "features":[ "enable_ohos_appexecfwk_feature_ability = true" ] } # Module and its features
+ ]
+ },
+ {
+ ......
+ }
+ ......
+ More subsystems and modules
+ }
+ }
+ ```
+
+5. **vendor/company/product/fs.yml**
+
+ This file packages the build result to create a configuration file system image, for example, **rootfs.img** \(user-space root file system\) and **userfs.img** \(readable and writable file\). It consists of multiple lists, and each list corresponds to a file system. The fields are described as follows:
+
+ ```
+ fs_dir_name: (Mandatory) declares the name of the file system, for example, rootfs or userfs.
+ fs_dirs: (Optional) configures the mapping between the file directory in the out directory and the system file directory. Each file directory corresponds to a list.
+ source_dir: (Optional) specifies the target file directory in the out directory. If this field is missing, an empty directory will be created in the file system based on target_dir.
+ target_dir: (Mandatory) specifies the corresponding file directory in the file system.
+ ignore_files: (Optional) declares ignored files during the copy operation.
+ dir_mode: (Optional) specifies the file directory permission, which is set to 755 by default.
+ file_mode: (Optional) declares permissions of all files in the directory, which is set to 555 by default.
+ fs_filemode: (Optional) configures files that require special permissions. Each file corresponds to a list.
+ file_dir: (Mandatory) specifies the detailed file path in the file system.
+ file_mode: (Mandatory) declares file permissions.
+ fs_symlink: (Optional) configures the soft link of the file system.
+ fs_make_cmd: (Mandatory) creates the file system script. The script provided by the OS is stored in the build/lite/make_rootfs directory. Linux, LiteOS, ext4, jffs2, and vfat are supported. Chipset vendors can also customize the script as required.
+ fs_attr: (Optional) dynamically adjusts the file system based on configuration items.
+ ```
+
+ The **fs\_symlink** and **fs\_make\_cmd** fields support the following variables:
+
+ - $\{root\_path\}
+
+ Code root directory, which corresponds to **$\{ohos\_root\_path\}** of GN
+
+ - $\{out\_path\}
+
+ **out** directory of the product, which corresponds to **$\{root\_out\_dir\}** of GN
+
+ - $\{fs\_dir\}
+
+ File system directory, which consists of the following variables
+
+ - $\{root\_path\}
+ - $\{fs\_dir\_name\}
+
+
+ > **NOTE:**
+ >**fs.yml** is optional and does not need to be configured for devices without a file system.
+
+6. **vendor/company/product/BUILD.gn**
+
+ This file is the entry for building the source code of the solution vendor and copying the startup configuration file. The **BUILD.gn** file in the corresponding product directory will be built by default if a product is selected. The following example shows how to build the **BUILD.gn** file of a product:
+
+ ```
+ group("product") { # The target name must be the same as the product name (level-3 directory name under the product directory).
+ deps = []
+ # Copy the init configuration.
+ deps += [ "init_configs" ]
+ # Others
+ ......
+ }
+ ```
+
+
+## Usage Guidelines
+
+### Prerequisites
+
+The development environment has GN, Ninja, Python 3.7.4 or later, and hb available. For details about installation methods, see [Environment Setup](../quick-start/quickstart-lite-env-setup.md).
+
+### Using hb
+
+**hb** is a command line tool for OpenHarmony to execute build commands. Common hb commands are described as follows:
+
+**hb set**
+
+```
+hb set -h
+usage: hb set [-h] [-root [ROOT_PATH]] [-p]
+
+optional arguments:
+ -h, --help show this help message and exit
+ -root [ROOT_PATH], --root_path [ROOT_PATH]
+ Set OHOS root path
+ -p, --product Set OHOS board and kernel
+```
+
+- **hb set** \(without argument\): starts the default setting process.
+- **hb set -root** _dir_: sets the root directory of the code.
+- **hb set -p**: sets the product to build.
+
+**hb env**
+
+Displays the current configuration.
+
+```
+hb env
+[OHOS INFO] root path: xxx
+[OHOS INFO] board: hispark_taurus
+[OHOS INFO] kernel: liteos
+[OHOS INFO] product: ipcamera
+[OHOS INFO] product path: xxx/vendor/hisilicon/ipcamera
+[OHOS INFO] device path: xxx/device/hisilicon/hispark_taurus/sdk_linux_4.19
+```
+
+**hb build**
+
+```
+hb build -h
+usage: hb build [-h] [-b BUILD_TYPE] [-c COMPILER] [-t [TEST [TEST ...]]]
+ [--dmverity] [--tee] [-p PRODUCT] [-f] [-n]
+ [-T [TARGET [TARGET ...]]] [-v] [-shs] [--patch]
+ [component [component ...]]
+
+positional arguments:
+ component name of the component
+
+optional arguments:
+ -h, --help show this help message and exit
+ -b BUILD_TYPE, --build_type BUILD_TYPE
+ release or debug version
+ -c COMPILER, --compiler COMPILER
+ specify compiler
+ -t [TEST [TEST ...]], --test [TEST [TEST ...]]
+ compile test suit
+ --dmverity Enable dmverity
+ --tee Enable tee
+ -p PRODUCT, --product PRODUCT
+ build a specified product with
+ {product_name}@{company}, eg: camera@huawei
+ -f, --full full code compilation
+ -n, --ndk compile ndk
+ -T [TARGET [TARGET ...]], --target [TARGET [TARGET ...]]
+ Compile single target
+ -v, --verbose show all command lines while building
+ -shs, --sign_haps_by_server
+ sign haps by server
+ --patch apply product patch before compiling
+
+ --dmverity Enable dmverity
+ -p PRODUCT, --product PRODUCT
+ build a specified product with
+ {product_name}@{company}, eg: ipcamera@hisilcon
+ -f, --full full code compilation
+ -T [TARGET [TARGET ...]], --target [TARGET [TARGET ...]]
+ Compile single target
+```
+
+- **hb build** \(without argument\): builds the code based on the configured code directory, product, and options. The **-f** option deletes all products to be built, which is equivalent to running **hb clean** and **hb build**.
+- **hb build** _\{module\_name\}_: builds a product module separately based on the development board and kernel set for the product, for example, **hb build kv\_store**.
+- **hb build -p ipcamera@hisilicon**: skips the **set** step and builds the product directly.
+- You can run **hb build** in **device/device\_company/board** to select the kernel and start the build based on the current development board and the selected kernel to generate an image that contains the kernel and driver only.
+
+**hb clean**
+
+You can run **hb clean** to clear the build result of the product in the **out** directory and retain the **args.gn** and **build.log** files only. To clear files in a specified directory, add the directory parameter to the command, for example, **hb clean out/xxx/xxx**.
+
+```
+hb clean
+usage: hb clean [-h] [out_path]
+
+positional arguments:
+ out_path clean a specified path.
+
+optional arguments:
+ -h, --help show this help message and exit
+```
+
+### Adding a Module
+
+To add a module, determine the subsystem to which the module belongs and the module name, and then perform the following steps:
+
+1. Add the module build script after the source code development is complete.
+
+ The following example adds the **BUILD.gn** script \(stored in the **applications/sample/hello\_world** directory\) to build the **hello\_world** module \(as an executable file\).
+
+ ```
+ executable("hello_world") {
+ include_dirs = [
+ "include",
+ ]
+ sources = [
+ "src/hello_world.c"
+ ]
+ }
+ ```
+
+ The above script is used to build **hello\_world** that can run on OpenHarmony.
+
+ To build the preceding module separately, select a product via the **hb set** command and run the **-T** command.
+
+ ```
+ hb build -f -T //applications/sample/hello_world
+ ```
+
+ After the module functions are verified on the development board, perform steps [2 to 4](#li11471037297) to configure the module to the product.
+
+2. Add module description.
+
+ The module description is stored in the **build/lite/components** directory. New modules must be added to the JSON file of the corresponding subsystem. The module description must contain the following fields:
+
+ - **module**: name of the module
+ - **description**: brief description of the module
+ - **optional**: whether the module is optional
+ - **dirs**: source code directory of the module
+ - **targets**: module build entry
+
+ For example, to add the **hello\_world** module to the application subsystem, add the **hello\_world** object to the **applications.json** file.
+
+ ```
+ {
+ "components": [
+ {
+ "component": "hello_world",
+ "description": "Hello world.",
+ "optional": "true",
+ "dirs": [
+ "applications/sample/hello_world"
+ ],
+ "targets": [
+ "//applications/sample/hello_world"
+ ]
+ },
+ ...
+ ]
+ }
+ ```
+
+3. Configure the module for the product.
+
+ The **config.json** file is stored in the **vendor/company/product/** directory. The file must contain the product name, OpenHarmony version, device vendor, development board, kernel type, kernel version, and the subsystem and module to configure. The following example adds the **hello\_world** module to the **my\_product.json** configuration file:
+
+ ```
+ {
+ "product_name": "hello_world_test",
+ "ohos_version": "OpenHarmony 1.0",
+ "device_company": "hisilicon",
+ "board": "hispark_taurus",
+ "kernel_type": "liteos_a",
+ "kernel_version": "1.0.0",
+ "subsystems": [
+ {
+ "subsystem": "applications",
+ "components": [
+ { "component": "hello_world", "features":[] }
+ ]
+ },
+ ...
+ ]
+ }
+ ```
+
+4. Build the product.
+
+ 1. Run the **hb set** command in the root code directory and select the product.
+
+ 2. Run the **hb build** command.
+
+
+### Adding a Chipset Solution
+
+The following uses the RTL8720 development board provided by Realtek as an example. To a chipset solution, perform the following steps:
+
+1. Create a directory for the chipset solution.
+
+ To create a directory based on [1-Configuration Rules for Modules, Chipset Solutions, and Product Solutions](#section1625463413327), run the following command in the root code directory:
+
+ ```
+ mkdir -p device/realtek/rtl8720
+ ```
+
+2. Create a directory for kernel adaptation and build the **config.gni** file of the development board.
+
+ For example, to adapt the LiteOS Cortex-M kernel to the RTL8720 development board, configure the **device/realtek/rtl8720/liteos\_a/config.gni** file as follows:
+
+ ```
+ # Kernel type, e.g. "linux", "liteos_a", "liteos_m".
+ kernel_type = "liteos_a"
+
+ # Kernel version.
+ kernel_version = "3.0.0"
+
+ # Board CPU type, e.g. "cortex-a7", "riscv32".
+ board_cpu = "real-m300"
+
+ # Board arch, e.g. "armv7-a", "rv32imac".
+ board_arch = ""
+
+ # Toolchain name used for system compiling.
+ # E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang, riscv32-unknown-elf.
+ # Note: The default toolchain is "ohos-clang". It's not mandatory if you use the default toochain.
+ board_toolchain = "gcc-arm-none-eabi"
+
+ # The toolchain path instatlled, it's not mandatory if you have added toolchian path to your ~/.bashrc.
+ board_toolchain_path =
+ rebase_path("//prebuilts/gcc/linux-x86/arm/gcc-arm-none-eabi/bin",
+ root_build_dir)
+
+ # Compiler prefix.
+ board_toolchain_prefix = "gcc-arm-none-eabi-"
+
+ # Compiler type, "gcc" or "clang".
+ board_toolchain_type = "gcc"
+
+ # Board related common compile flags.
+ board_cflags = []
+ board_cxx_flags = []
+ board_ld_flags = []
+ ```
+
+3. Build the script.
+
+ Create the **BUILD.gn** file in the development board directory. The target name must be the same as that of the development board. The content in the **device/realtek/rtl8720/BUILD.gn** file is configured as follows:
+
+ ```
+ group("rtl8720") { # The target can be shared_library, static_library, or an executable file.
+ # Content
+ ......
+ }
+ ```
+
+4. Build the chipset solution.
+
+ Run the **hb build** command in the development board directory to start the build.
+
+
+### Adding a Product Solution
+
+You can use the Compilation and Building subsystem to customize product solutions by assembling chipset solutions and modules. The procedure is as follows:
+
+1. Create a product directory.
+
+ The following uses the Wi-Fi IoT module on the RTL8720 development board as an example. Run the following command in the root code directory to create a product directory based on [1-Configuration Rules for Modules, Chipset Solutions, and Product Solutions](#section1625463413327):
+
+ ```
+ mkdir -p vendor/my_company/wifiiot
+ ```
+
+2. Assemble the product.
+
+ Create the **config.json** file in the product directory. The **vendor/my\_company/wifiiot/config.json** file is as follows:
+
+ ```
+ {
+ "product_name": "wifiiot", # Product name
+ "ohos_version": "OpenHarmony 1.0", # OS version
+ "device_company": "realtek", # Name of the chipset solution vendor
+ "board": "rtl8720", # Name of the development board
+ "kernel_type": "liteos_m", # Kernel type
+ "kernel_version": "3.0.0", # Kernel version
+ "subsystems": [
+ {
+ "subsystem": "kernel", # Subsystem
+ "components": [
+ { "component": "liteos_m", "features":[] } # Module and its features
+ ]
+ },
+ ...
+ {
+ More subsystems and modules
+ }
+ ]
+ }
+ ```
+
+ Before the build, the Compilation and Building subsystem checks the validity of fields, including **device\_company**, **board**, **kernel\_type**, **kernel\_version**, **subsystem**, and **component**. The **device\_company**, **board**, **kernel\_type**, and **kernel\_version** fields must match the current chipset solution, and **subsystem** and **component** must match the module description in the **build/lite/components** file.
+
+3. Implement adaptation to OS APIs.
+
+ Create the **hals** directory in the product directory and store the source code as well as the build script for OS adaptation in this directory.
+
+4. Configure the system service.
+
+ Create the **init\_configs** directory in the product directory and then the **init.cfg** file in the newly created directory. Configure the system service to be started.
+
+5. \(Optional\) Configure the init process only for the Linux kernel.
+
+ Create the **etc** directory in the **init\_configs** directory, and then the **init.d** folder and the **fstab** file in the newly created directory. Then, create the **rcS** and **S**_xxx_ files in the **init.d** file and edit them based on product requirements.
+
+6. \(Optional\) Configure the file system image only for the development board that supports the file system.
+
+ Create the **fs.yml** file in the product directory and configure it as required. A typical **fs.yml** file is as follows:
+
+ ```
+ -
+ fs_dir_name: rootfs # Image name
+ fs_dirs:
+ -
+ # Copy the files in the out/my_board/my_product/bin directory to the rootfs/bin directory and ignore the .bin files related to testing.
+ source_dir: bin
+ target_dir: bin
+ ignore_files:
+ - Test.bin
+ - TestSuite.bin
+ -
+ # Copy the files in the out/my_board/my_product/libs directory to the rootfs/lib directory, ignore all .a files, and set the file permissions to 644 and folder permissions 755.
+ source_dir: libs
+ target_dir: lib
+ ignore_files:
+ - .a
+ dir_mode: 755
+ file_mode: 644
+ -
+ source_dir: usr/lib
+ target_dir: usr/lib
+ ignore_files:
+ - .a
+ dir_mode: 755
+ file_mode: 644
+ -
+ source_dir: config
+ target_dir: etc
+ -
+ source_dir: system
+ target_dir: system
+ -
+ source_dir: sbin
+ target_dir: sbin
+ -
+ source_dir: usr/bin
+ target_dir: usr/bin
+ -
+ source_dir: usr/sbin
+ target_dir: usr/sbin
+ -
+ # Create an empty proc directory.
+ target_dir: proc
+ -
+ target_dir: mnt
+ -
+ target_dir: opt
+ -
+ target_dir: tmp
+ -
+ target_dir: var
+ -
+ target_dir: sys
+ -
+ source_dir: etc
+ target_dir: etc
+ -
+ source_dir: vendor
+ target_dir: vendor
+ -
+ target_dir: storage
+
+ fs_filemode:
+ -
+ file_dir: lib/ld-uClibc-0.9.33.2.so
+ file_mode: 555
+ -
+ file_dir: lib/ld-2.24.so
+ file_mode: 555
+ -
+ file_dir: etc/init.cfg
+ file_mode: 400
+ fs_symlink:
+ -
+ # Create the soft link ld-musl-arm.so.1 -> libc.so in the rootfs/lib directory.
+ source: libc.so
+ link_name: ${fs_dir}/lib/ld-musl-arm.so.1
+ -
+ source: mksh
+ link_name: ${fs_dir}/bin/sh
+ -
+ source: mksh
+ link_name: ${fs_dir}/bin/shell
+ fs_make_cmd:
+ # Create an ext4 image for the rootfs directory using the script.
+ - ${root_path}/build/lite/make_rootfs/rootfsimg_linux.sh ${fs_dir} ext4
+ -
+ fs_dir_name: userfs
+ fs_dirs:
+ -
+ source_dir: storage/etc
+ target_dir: etc
+ -
+ source_dir: data
+ target_dir: data
+ fs_make_cmd:
+ - ${root_path}/build/lite/make_rootfs/rootfsimg_linux.sh ${fs_dir} ext4
+
+ ```
+
+7. \(Optional\) Configure patches if the product and modules need to be patched.
+
+ Create the **patch.yml** file in the product directory and configure it as required. A typical **patch.yml** file is as follows:
+
+ ```
+ # Directory in which the patch is to be installed
+ foundation/communication/dsoftbus:
+ # Directory in which the patch is stored
+ - foundation/communication/dsoftbus/1.patch
+ - foundation/communication/dsoftbus/2.patch
+ third_party/wpa_supplicant:
+ - third_party/wpa_supplicant/1.patch
+ - third_party/wpa_supplicant/2.patch
+ - third_party/wpa_supplicant/3.patch
+ ...
+ ```
+
+ If you add **--patch** when running the **hb build** command, the patch file can be added to the specified directory before the build.
+
+ ```
+ hb build -f --patch
+ ```
+
+8. Build the script.
+
+ Create the **BUILD.gn** file in the product directory and write the script. The following **BUILD.gn** file uses the Wi-Fi IoT module in [1](#li1970321162111) as an example:
+
+ ```
+ group("wifiiot") { # The target name must be the same as the product name.
+ deps = []
+ # Copy the init configuration.
+ deps += [ "init_configs" ]
+ # Build the hals directory.
+ deps += [ "hals" ]
+ # Others
+ ......
+ }
+ ```
+
+9. Build the product.
+
+ Run the **hb set** command in the code root directory, select the new product as prompted, and run the **hb build** command.
+
+
+## Troubleshooting
+
+### Invalid -- w Option
+
+- **Symptom**
+
+ The build fails, and "usr/sbin/ninja: invalid option -- w" is displayed.
+
+- **Cause**
+
+ The Ninja version in the build environment is outdated and does not support the **--w** option.
+
+- **Solution**
+
+ Uninstall Ninja and GN and follow the instructions provided in [IDE](../get-code/gettools-ide.md) to install Ninja and GN of the required version.
+
+
+### Library ncurses Not Found
+
+- **Symptom**
+
+ The build fails, and "/usr/bin/ld: cannot find -lncurses" is displayed.
+
+- **Cause**
+
+ The ncurses library is not installed.
+
+- **Solution**
+
+ ```
+ sudo apt-get install lib32ncurses5-dev
+ ```
+
+
+### mcopy not Found
+
+- **Symptom**
+
+ The build fails, and "line 77: mcopy: command not found" is displayed.
+
+- **Cause**
+
+ mcopy is not installed.
+
+- **Solution**
+
+ ```
+ sudo apt-get install dosfstools mtools
+ ```
+
+
+### No riscv File or Directory
+
+- **Symptom**
+
+ The build fails, and the following information is displayed:
+
+ riscv32-unknown-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory.
+
+- **Cause**
+
+ Permission is required to access files in the **riscv** compiler directory.
+
+- **Solution**
+
+ Run the following command to query the directory where **gcc\_riscv32** is located:
+
+ ```
+ which riscv32-unknown-elf-gcc
+ ```
+
+ Run the **chmod** command to change the directory permission to **755**.
+
+
+### No Crypto
+
+- **Symptom**
+
+ The build fails, and "No module named 'Crypto'" is displayed.
+
+- **Cause**
+
+ Crypto is not installed in Python 3.
+
+- **Solution**
+ 1. Run the following command to query the Python version:
+
+ ```
+ python3 --version
+ ```
+
+ 2. Ensure that Python 3.7 or later is installed, and then run the following command to install pycryptodome:
+
+ ```
+ sudo pip3 install pycryptodome
+ ```
+
+
+
+### Unexpected Operator
+
+- **Symptom**
+
+ The build fails, and "xx.sh \[: xx unexpected operator" is displayed.
+
+- **Cause**
+
+ The build environment is shell, not bash.
+
+- **Solution**
+
+ ```
+ sudo rm -rf /bin/sh
+ sudo ln -s /bin/bash /bin/sh
+ ```
+
+
diff --git a/en/device-dev/subsystems/subsys-build-standard-large.md b/en/device-dev/subsystems/subsys-build-standard-large.md
new file mode 100644
index 0000000000000000000000000000000000000000..e1a47c1b1329e7efcf2947b9018ae202e3dd50f1
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-build-standard-large.md
@@ -0,0 +1,237 @@
+# Building Guidelines for Standard Systems
+
+- [Overview](#section17466112012244)
+ - [Basic Concepts](#section445513507246)
+ - [Working Principles](#section12541217142510)
+ - [Limitations and Constraints](#section886933762513)
+
+- [Compilation and Building Guidelines](#section16901215262)
+ - [Directory Structure](#section109065332264)
+ - [Build Command](#section123265539266)
+ - [How to Develop](#section591084422719)
+
+
+## Overview
+
+The compilation and building subsystem provides a framework based on Generate Ninja \(GN\) and Ninja. This subsystem allows you to:
+
+- Build products based on different chipset platforms, for example, Hi3516D V300.
+
+- Package capabilities required by a product by assembling modules based on the product configuration.
+
+### Basic Concepts
+
+It is considered best practice to learn the following basic concepts before you start building:
+
+- **Platform**
+
+ A platform is a combination of development boards and kernels.
+
+ Supported subsystems and modules vary according to the platform.
+
+- **Subsystems**
+
+ OpenHarmony is designed with a layered architecture, which from bottom to top consists of the kernel layer, system service layer, framework layer, and application layer. System functions are expanded by levels, from system to subsystem, and further to module. In a multi-device deployment scenario, unnecessary subsystems and modules can be excluded from the system as required. A subsystem is a logical concept and is a flexible combination of functions.
+
+- **Module**
+
+ A module is a reusable software binary unit that contains source code, configuration files, resource files, and build scripts. A module can be built independently, integrated in binary mode, and then tested independently.
+
+- **GN**
+
+ GN is short for Generate Ninja, which is used to generate Ninja files.
+
+- **Ninja**
+
+ Ninja is a small high-speed build system.
+
+
+### Working Principles
+
+The process to build OpenHarmony is as follows:
+
+- Parsing commands: Parse the name of the product to build and load related configurations.
+- Running GN: Configure toolchains and global options based on the parsed product name and compilation type.
+- Running Ninja: Start building and generate a product distribution.
+
+### Limitations and Constraints
+
+- You must download the source code using method 3 described in [Source Code Acquisition](../get-code/sourcecode-acquire.md).
+- The build environment must be Ubuntu 18.04 or later.
+- You must install the software package required for build.
+
+ The installation command is as follows:
+
+ ```
+ sudo apt-get install binutils git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip m4
+ ```
+
+
+## Compilation and Building Guidelines
+
+### Directory Structure
+
+```
+/build # Primary directory
+├── config # Build configuration items
+├── core
+│ └── gn # Build entry BUILD.gn configuration
+├── loader # Loader of module configuration, which also generates a template for the module
+├── ohos # Configuration of the process for building and packaging OpenHarmony
+│ ├── kits # Build and packaging templates and processing flow for kits
+│ ├── ndk # NDK template and processing flow
+│ ├── notice # Notice template and processing flow
+│ ├── packages # Distribution packaging template and processing flow
+│ ├── sa_profile # SA template and processing flow
+│ ├── sdk # SDK template and processing flow, which contains the module configuration in the SDK
+│ └── testfwk # Processing flow related to the test
+├── scripts # Build-related Python script
+├── templates # C/C++ build templates
+└── toolchain # Toolchain configuration
+```
+
+### Build Command
+
+- Run the following command in the root directory of the source code to build the full distribution:
+
+ ```
+ ./build.sh --product-name {product_name}
+ ```
+
+ **product\_name** indicates the product supported by the current distribution, for example, Hi3516D V300.
+
+ The image generated after build is stored in the **out/ohos-arm-release/packages/phone/images/** directory.
+
+- The build command supports the following options:
+
+ ```
+ --product-name # (Mandatory) Name of the product to build, for example, Hi3516D V300
+ --build-target # (Optional) One or more build targets
+ --gn-args # (Optional) One or more gn parameters
+ --ccache # (Optional) Use of Ccache for build. This option takes effect only when Ccache is installed on the local PC.
+ ```
+
+
+### How to Develop
+
+1. Add a module.
+
+ The following steps use a custom module as an example to describe how to build the module, including build a library, an executable file, and a configuration file.
+
+ The example module **partA** consists of **feature1**, **feature2**, and **feature3**. The target is a dynamic library for **feature1**, an executable file for **feature2**, and an etc configuration file for **feature3**.
+
+ Add **partA** to a subsystem, for example, **subsystem\_examples** \(defined in the **test/examples/** directory\).
+
+ The complete directory structure of **partA** is as follows:
+
+ ```
+ test/examples/partA
+ ├── feature1
+ │ ├── BUILD.gn
+ │ ├── include
+ │ │ └── helloworld1.h
+ │ └── src
+ │ └── helloworld1.cpp
+ ├── feature2
+ │ ├── BUILD.gn
+ │ ├── include
+ │ │ └── helloworld2.h
+ │ └── src
+ │ └── helloworld2.cpp
+ └── feature3
+ ├── BUILD.gn
+ └── src
+ └── config.conf
+ ```
+
+ Example 1: GN script \(**test/examples/partA/feature1/BUILD.gn**\) for building a dynamic library
+
+ ```
+ config("helloworld_lib_config") {
+ include_dirs = [ "include" ]
+ }
+
+ ohos_shared_library("helloworld_lib") {
+ sources = [
+ "include/helloworld1.h",
+ "src/helloworld1.cpp",
+ ]
+ public_configs = [ ":helloworld_lib_config" ]
+ part_name = "partA"
+ }
+ ```
+
+ Example 2: GN script \(**test/examples/partA/feature2/BUILD.gn**\) for building an executable file
+
+ ```
+ ohos_executable("helloworld_bin") {
+ sources = [
+ "src/helloworld2.cpp"
+ ]
+ include_dirs = [ "include" ]
+ deps = [ # Dependent submodule
+ "../feature1:helloworld_lib"
+ ]
+ external_deps = [ "partB:module1" ] # (Optional) If there is a cross-module dependency, the format is "module name: submodule name"
+ install_enable = true # By default, the executable file is not installed. You need to set this parameter to true for installation.
+ part_name = "partA"
+ }
+ ```
+
+ Example 3: GN script \(**test/examples/partA/feature3/BUILD.gn**\) for building the etc configuration file \(submodule\).
+
+ ```
+ ohos_prebuilt_etc("feature3_etc") {
+ source = "src/config.conf"
+ relative_install_dir = "init" # (Optional) Directory for installing the submodule, which is relative to the default installation directory (/system/etc)
+ part_name = "partA"
+ }
+ ```
+
+ Example 4: Adding the module configuration file **test/examples/ohos.build** to the **ohos.build** file of this subsystem. Each subsystem has an **ohos.build** file in its root directory. Example:
+
+ ```
+ "partA": {
+ "module_list": [
+ "//test/examples/partA/feature1:helloworld_lib",
+ "//test/examples/partA/feature2:helloworld_bin",
+ "//test/examples/partA/feature3:feature3_etc",
+ ],
+ "inner_kits": [
+
+ ],
+ "system_kits": [
+
+ ],
+ "test_list": [
+
+ ]
+ }
+ ```
+
+ The declaration of a module contains the following parts:
+
+ - **module\_list**: submodule list of the module
+ - **inner\_kits**: APIs for other modules that depend on this module through **external\_deps**
+ - **system\_kits**: APIs for developers
+ - **test\_list**: test cases for the submodules of the module
+
+2. Add the module to the product configuration file.
+
+ Add the module to the product configuration file **productdefine/common/products/\{product-name\}.json**.
+
+ Add "subsystem\_examples:partA" to the product configuration file. **partA** will be built and packaged into the distribution.
+
+3. Build the module.
+
+ For example, run the following command to build Hi3516D V300:
+
+ ```
+ ./build.sh --product-name Hi3516DV300 --ccache
+ ```
+
+4. Obtain the build result.
+
+ Files generated during the build process 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.
+
+
diff --git a/en/device-dev/subsystems/subsys-build.md b/en/device-dev/subsystems/subsys-build.md
new file mode 100644
index 0000000000000000000000000000000000000000..8af635290fe343c07c8da6e6d902a1218ed5207f
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-build.md
@@ -0,0 +1,7 @@
+# Compilation and Building
+
+- **[Building Guidelines for Mini and Small Systems](subsys-build-mini-lite.md)**
+
+- **[Building Guidelines for Standard Systems](subsys-build-standard-large.md)**
+
+
diff --git a/en/device-dev/subsystems/sensors-usage-example.md b/en/device-dev/subsystems/subsys-densor-demo.md
similarity index 100%
rename from en/device-dev/subsystems/sensors-usage-example.md
rename to en/device-dev/subsystems/subsys-densor-demo.md
diff --git a/en/device-dev/subsystems/subsys-densor-guide.md b/en/device-dev/subsystems/subsys-densor-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..74a27dfd84c880908bb950bb9ddacef86230ddb2
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-densor-guide.md
@@ -0,0 +1,72 @@
+# Sensors Usage Guidelines
+
+- [How to Use](#section18816105182315)
+
+The following steps use the sensor whose **sensorTypeId** is **0** as an example. The guidelines for other sensor types are similar.
+
+## How to Use
+
+1. Import the required header files.
+
+```
+#include "sensor_agent.h"
+#include "sensor_agent_type.h"
+```
+
+1. Create a sensor callback.
+
+```
+void SensorDataCallbackImpl(SensorEvent *event)
+{
+ if(event == NULL){
+ return;
+ }
+ float *sensorData=(float *)event->data;
+}
+```
+
+> **NOTE:**
+>The callback must be of the RecordSensorCallback type.
+
+1. Obtain the list of sensors supported by the device.
+
+```
+SensorInfo *sensorInfo = (SensorInfo *)NULL;
+int32_t count = 0;
+int32_t ret = GetAllSensors(&sensorInfo, &count);
+```
+
+1. Create a sensor user.
+
+```
+SensorUser sensorUser;
+sensorUser.callback = SensorDataCallbackImpl; // Assign the created callback SensorDataCallbackImpl to the member variable callback.
+```
+
+1. Enable the sensor.
+
+```
+int32_t ret = ActivateSensor(0, &sensorUser);
+```
+
+1. Subscribe to sensor data.
+
+```
+int32_t ret = SubscribeSensor(0, &sensorUser);
+```
+
+> **NOTE:**
+>Till now, you can obtain the sensor data via the callback.
+
+1. Unsubscribe from the sensor data.
+
+```
+int32_t ret = UnsubscribeSensor(0, &sensorUser);
+```
+
+1. Disable the sensor.
+
+```
+int32_t ret = DeactivateSensor(0, &sensorUser);
+```
+
diff --git a/en/device-dev/subsystems/subsys-densor-overview.md b/en/device-dev/subsystems/subsys-densor-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..89b943330352cb8c3e65927a25fb847f5a69e2fd
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-densor-overview.md
@@ -0,0 +1,99 @@
+# Sensors Overview
+
+- [Introduction](#section667413271505)
+- [Available APIs](#section7255104114110)
+
+## Introduction
+
+The pan-sensor service subsystem provides a lightweight sensor service framework. You can call APIs offered by this framework to query the sensor list, enable or disable a sensor, and subscribe to or unsubscribe from sensor data. The following figure shows the architecture of the lightweight sensor framework.
+
+**Figure 1** Sensor service framework
+
+
+
+- Sensor API: provides APIs for performing basic operations on sensors, including querying the sensor list, subscribing to or unsubscribing from sensor data, and executing control commands. This module makes application development simpler.
+- Sensor Framework: manages sensor data subscription, creates and destroys data channels, and implements communication with the Sensor Service module.
+- Sensor Service: interacts with the HDF module to receive, parse, and distribute data, manages sensors on hardware and sensor data reporting, and controls sensor permissions.
+
+## Available APIs
+
+**Table 1** APIs of the sensor framework
+
+
+
Sets the data reporting mode for the specified sensor.
+
Return value: Returns 0 if the sensor data reporting mode is successfully set; returns a non-zero value otherwise.
+
+
sensorTypeId: ID of a sensor type
+
user (not NULL): sensor subscriber that requests sensor data. A subscriber can obtain data from only one sensor.
+
mode: data reporting mode of the sensor
+
+
+
+
+
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/development-guidelines-on-hilog_lite.md b/en/device-dev/subsystems/subsys-dfx-hilog-lite.md
similarity index 100%
rename from en/device-dev/subsystems/development-guidelines-on-hilog_lite.md
rename to en/device-dev/subsystems/subsys-dfx-hilog-lite.md
diff --git a/en/device-dev/subsystems/development-guidelines-on-hilog.md b/en/device-dev/subsystems/subsys-dfx-hilog-rich.md
similarity index 100%
rename from en/device-dev/subsystems/development-guidelines-on-hilog.md
rename to en/device-dev/subsystems/subsys-dfx-hilog-rich.md
diff --git a/en/device-dev/subsystems/development-guidelines-on-hisysevent.md b/en/device-dev/subsystems/subsys-dfx-hisysevent.md
similarity index 100%
rename from en/device-dev/subsystems/development-guidelines-on-hisysevent.md
rename to en/device-dev/subsystems/subsys-dfx-hisysevent.md
diff --git a/en/device-dev/subsystems/subsys-dfx-hisyseventread.md b/en/device-dev/subsystems/subsys-dfx-hisyseventread.md
new file mode 100644
index 0000000000000000000000000000000000000000..bd59a05b8727eb3b84857d700c04bdf98cb46bbe
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-dfx-hisyseventread.md
@@ -0,0 +1,103 @@
+# 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-dfx-overview.md b/en/device-dev/subsystems/subsys-dfx-overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..b7bfac023a5bf84628ceb40723a9ed2e62dbb892
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-dfx-overview.md
@@ -0,0 +1,34 @@
+# DFX
+
+- [Basic Concepts](#section5635178134811)
+
+[Design for X](https://en.wikipedia.org/wiki/Design_for_X) \(DFX\) refers to the software design that aims to improve the quality attributes in OpenHarmony. It mainly consists of two parts: design for reliability \(DFR\) and design for testability \(DFT\).
+
+The DFX subsystem provides the following functions:
+
+- HiLog: Implements the logging function. It is applicable to Mini-System Devices \(reference memory ≥ 128 KB\) and Small-System Devices \(reference memory ≥ 1 MB\) as well as Standard-System Devices \(reference memory ≥ 128 MB\).
+
+- HiSysEvent: Implements system event logging. It is applicable to Standard-System Devices \(reference memory ≥ 128 MB\).
+
+## Basic Concepts
+
+**Logging**
+
+Logging means to record the log information generated during system running so you can understand the running process and status of the system or applications.
+
+**Distributed call chain tracing**
+
+In a distributed system, the initiation of a service may involve multiple software modules, with control commands and data transmitted over intra-process, inter-process, and inter-device communication interfaces. To help you understand such complex communication processes and locate service faults efficiently, the DFX subsystem provides a distributed call chain tracing framework.
+
+**Thread suspension detection**
+
+If a thread is trapped in an infinite loop or the kernel state \(for example, Uninterruptable Sleep, Traced, Zombie, or synchronous wait\) when it is running, the thread cannot respond to normal service requests and cannot detect and recover from faults by itself. To detect and locate this type of faults, the DFX subsystem provides a simple watchdog mechanism by inserting detection probes to the process nodes that are prone to suspension. This ensures that suspension faults can be detected and logs can be collected.
+
+**Event logging**
+
+Event logging means to collect and log events reported during system running. The log information will help you better analyze the product usage.
+
+**System event**
+
+A system event is an indication of the system status at a given time point during system running. You can use these events to analyze the status change of the system.
+
diff --git a/en/device-dev/subsystems/subsys-dfx.md b/en/device-dev/subsystems/subsys-dfx.md
new file mode 100644
index 0000000000000000000000000000000000000000..88a1a79938cf22e2d9c343ebedb42897934a1b64
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-dfx.md
@@ -0,0 +1,11 @@
+# DFX
+
+- **[DFX](subsys-dfx-overview.md)**
+
+- **[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)**
+
+
diff --git a/en/device-dev/subsystems/subsys-graphics-animation-guide.md b/en/device-dev/subsystems/subsys-graphics-animation-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..4bb1a33190f3c76e78c9d4b4d83c25690b943937
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-graphics-animation-guide.md
@@ -0,0 +1,190 @@
+# Development Guidelines on Animators
+
+- [When to Use](#section726685714018)
+- [Available APIs](#section85794718418)
+- [How to Develop](#section14101161317435)
+
+## When to Use
+
+A UI animator is implemented by calling the callback function you set for each tick using the task processing mechanism. The following classes are provided for you to implement an animator:
+
+- **AnimatorManager**: Manages Animator instances. This is a singleton class, which is registered with the system task callback when the **Init** function is executed. The system task mechanism ensures that each tick invokes the callback function of **AnimatorManager**.
+- **Animator**: Represents animator-related attributes, including the start and end time of an animator. It also provides animator-specific functions, for example, to start and stop an animator, to set the animator state, and to obtain the animator.
+- **AnimatorCallback**: Implements the content of each tick. You need to implement your own logic in this callback class so that the desired operation is executed upon the corresponding callback is invoked.
+
+## Available APIs
+
+**Table 1** Available functions for an animator
+
+
+
Module
+
+
Function
+
+
Description
+
+
+
+
Animator
+
+
void Start ()
+
+
Starts an animator.
+
+
+
Animator
+
+
void Stop ()
+
+
Stops the animator.
+
+
+
Animator
+
+
void Pause ()
+
+
Pauses the animator.
+
+
+
Animator
+
+
void Resume ()
+
+
Resumes the animator.
+
+
+
Animator
+
+
uint8_t GetState () const
+
+
Obtains the current state of the animator.
+
+
+
Animator
+
+
void SetState (uint8_t state)
+
+
Sets the current state for the animator.
+
+
+
Animator
+
+
uint32_t GetTime () const
+
+
Obtains the total duration of the animator.
+
+
+
Animator
+
+
void SetTime (uint32_t time)
+
+
Sets the total duration for the animator.
+
+
+
Animator
+
+
uint32_t GetRunTime () const
+
+
Obtains the running time of the animator.
+
+
+
Animator
+
+
void SetRunTime (uint32_t runTime)
+
+
Sets the running time for the animator.
+
+
+
Animator
+
+
bool IsRepeat () const
+
+
Checks whether the animator is repeated.
+
+
+
AnimatorCallback
+
+
virtual void Callback (UIView *view)=0
+
+
Represents the animator callback. You can implement your own logic in this callback.
+
+
+
AnimatorCallback
+
+
virtual void OnStop(UIView& view) {}
+
+
Called after the animator stops. You can implement your own logic in this callback.
+
+
+
AnimatorManager
+
+
static AnimatorManager* GetInstance()
+
+
Obtains an AnimatorManager instance.
+
+
+
AnimatorManager
+
+
void Add (Animator *animator)
+
+
Adds an animator.
+
+
+
AnimatorManager
+
+
void Remove(const Animator* animator);
+
+
Removes the animator.
+
+
+
+
+
+## How to Develop
+
+1. Implement the callback in **AnimatorCallback**.
+
+ ```
+ class AnimatorCallbackDemo : public OHOS::AnimatorCallback {
+ public:
+ AnimatorCallbackDemo(int16_t startPos, int16_t endPos, uint16_t time)
+ : start_(startPos), end_(endPos), time_(time), curTime_(0) {}
+
+ virtual void Callback(OHOS::UIView* view)
+ {
+ curTime_++;
+ int16_t pos = EasingEquation::CubicEaseIn(start_, end_, curTime_, time_);
+ view->Invalidate();
+ view->SetPosition(pos, view->GetY());
+ view->Invalidate();
+ }
+ protected:
+ int16_t start_;
+ int16_t end_;
+ uint16_t time_;
+ uint16_t curTime_;
+ };
+ ```
+
+2. Register **AnimatorCallback** to the animator.
+
+ ```
+ UIImageView* image = new UIImageView();
+ image->SetSrc("..\\config\\images\\A021_001.bin");
+ image->SetPosition(0, 50);
+ AnimatorCallbackDemo* callback = new AnimatorCallbackDemo(0, 338, 60);
+ Animator* animator = new Animator(callback, image, 0, true);
+ ```
+
+3. Add the animator to **AnimatorManager**.
+
+ ```
+ AnimatorManager::GetInstance()->Add(animator);
+ ```
+
+4. Click the buttons in the lower part of the following figure to verify that the animation effects are as expected.
+
+ **Figure 1** Animator effect
+ 
+
+
diff --git a/en/device-dev/subsystems/subsys-graphics-bundle-guide1.md b/en/device-dev/subsystems/subsys-graphics-bundle-guide1.md
new file mode 100644
index 0000000000000000000000000000000000000000..cc2f751868597158a0473bf52324e0ed708bef89
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-graphics-bundle-guide1.md
@@ -0,0 +1,244 @@
+# Development Guidelines on Container Components
+
+- [UIViewGroup](#section145471898812)
+- [When to Use](#section0916112362216)
+- [Available APIs](#section12641756192212)
+- [How to Develop](#section5412161692311)
+- [UIScrollView](#section174961523161315)
+- [When to Use](#section8937101902413)
+- [Available APIs](#section14789133142420)
+- [How to Develop](#section1769754422417)
+
+Container components are capable of containing UI components and inherit from **UIViewGroup**. Components that are commonly used and need to contain child components are placed in the container class inheritance structure. For example, you need to call the **Add** function to add information such as time statistics and icons to **UIAnalogClock**.
+
+**Figure 1** Structure of common container components
+
+
+The **RootView**, **UIAbstractScroll**, and **UIPicker** components inherit from **UIViewGroup**, and the **UIList**, **UIScrollView**, and **UISwipeView** components inherit from **UIAbstractScroll**.
+
+## UIViewGroup
+
+## When to Use
+
+**UIViewGroup** is a base class for container components. For example, you can call the functions in this class to add, remove, and insert container components. Also, you can call the **Add** function to add child components for a container component. You need to set the position information for child components in a common container component. The position information is the coordinates relative to those of their parent component. The following figure shows the tree structure of components.
+
+**Figure 2** Component tree structure
+
+
+As shown in the figure, the container component **ViewGroup1** and the component **View1** are added to **RootView**, the component **View2** and the container component **ViewGroup2** are added to **ViewGroup1**, and then the component **View3** \(as a sibling of **View1**\) is also added to **ViewGroup1**.
+
+- Rendering: During rendering of a container component, you need to call the **OnDraw** function on all its child components to update them.
+- Coordinates: As the position information of child components is the coordinates relative to those of their parent components, the system calculates and displays the absolute coordinates of child components during rendering.
+- Tree structure traversing: The **UIViewGroup** class provides the functions below to traverse, search for, and manage the component tree.
+
+## Available APIs
+
+**Table 1** Available functions in ViewGroup
+
+
+
+
+## How to Develop
+
+1. Create **ULLabelButton** instances and set their coordinates.
+
+ ```
+ UILabelButton* btn1 = new UILabelButton();
+ btn1->SetPosition(0, 0, 100, 50);
+ btn1->SetText("btn1");
+
+ UILabelButton* btn2 = new UILabelButton();
+ btn2->SetPosition(50, 50, 100, 50);
+ btn2->SetText("btn2");
+
+ UILabelButton* btn3 = new UILabelButton();
+ btn3->SetPosition(100, 100, 100, 50);
+ btn3->SetText("btn3");
+ ```
+
+2. Create a **UIViewGroup** instance and set its coordinates.
+
+ ```
+ UIViewGroup* group = new UIViewGroup();
+ group->SetPosition(0, 0, 300, 300);
+ ```
+
+3. Add the **ULLabelButton** instances to **UIViewGroup**.
+
+ ```
+ group->Add(btn1);
+ group->Add(btn2);
+ group->Add(btn3);
+ ```
+
+4. The following figure shows the effect of adding view instances to a **ViewGroup**.
+
+ **Figure 3** Effect of adding view instances to a ViewGroup
+ 
+
+
+## UIScrollView
+
+## When to Use
+
+**UIScrollView** provides scrolling container components, which enable child components to scroll upwards, downwards, leftwards, and rightwards upon a touch event. This class also supports horizontal and vertical cursor display.
+
+## Available APIs
+
+**Table 2** Available functions in ScrollView
+
+
+
+
+## How to Develop
+
+Add two buttons as child components and display horizontal and vertical cursors.
+
+```
+scrollView* scroll = new UIScrollView();
+scroll->SetStyle(STYLE_BACKGROUND_COLOR, Color::Red().full);
+scroll->SetPosition(0,0, 200, 200);
+scroll->SetXScrollBarVisible(true);
+scroll->SetYScrollBarVisible(true);
+UILabelButton* button1 = new UILabelButton();
+button1->SetText("button1");
+button1->SetPosition(0, 0, 300, 300);
+UILabelButton* button2 = new UILabelButton();
+button2->SetText("button2");
+button2->SetPosition(0, 300, 300, 300);
+scroll->Add(button1);
+scroll->Add(button2);
+```
+
+**Figure 4** Scrolling effect in both horizontal and vertical directions
+
+
diff --git a/en/device-dev/subsystems/subsys-graphics-bundle-guide2.md b/en/device-dev/subsystems/subsys-graphics-bundle-guide2.md
new file mode 100644
index 0000000000000000000000000000000000000000..95e8e154a98157305fcded6bec0d44526399740d
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-graphics-bundle-guide2.md
@@ -0,0 +1,216 @@
+# Development Guidelines on Layout Container Components
+
+- [UISwipeView](#section13631719181717)
+- [When to Use](#section11299120102617)
+- [Available APIs](#section767434119261)
+- [Development Procedure \(Non-Cyclic Horizontal Swiping\)](#section111911175287)
+- [Development Procedure \(Cyclic Horizontal Swiping\)](#section1976914915282)
+- [GridLayout](#section46819199173)
+- [When to Use](#section831618247294)
+- [Available APIs](#section597214622912)
+- [How to Develop](#section1418253410306)
+
+Layout container components consist of basic view classes. You can set the view positions to achieve nested and overlapped layouts, set the layout type and margin to standardize the child components in the layout, and call certain functions to implement layout views based on parent and sibling components.
+
+## UISwipeView
+
+## When to Use
+
+**UISwipeView** inherits from **UIViewGroup**. In addition to the **Add**, **Remove**, and **Insert** functions, **UISwipeView** provides the functions to swipe contents by page and center the current page after swiping. This component can be horizontally or vertically centered. Child components added via the **Add** function are automatically horizontally or vertically centered, adaptive to the **UISwipeView** direction, in the sequence they were added.
+
+## Available APIs
+
+**Table 1** Available functions in SwipeView
+
+
+
+
+## Development Procedure \(Non-Cyclic Horizontal Swiping\)
+
+1. Create a horizontal swiping **UISwipeView**.
+
+ ```
+ UISwipeView* swipe = new UISwipeView(UISwipeView::HORIZONTAL);
+ ```
+
+2. Add child components to **UISwipeView**.
+
+ ```
+ UILabelButton* button1 = new UILabelButton();
+ button1->SetPosition(0, 0, g_ButtonW, g_ButtonH);
+ button1->SetText("button1");
+ swipe->Add(button1);
+ UILabelButton* button2 = new UILabelButton();
+ button2->SetPosition(0, 0, g_ButtonW, g_ButtonH);
+ button2->SetText("button2");
+ swipe->Add(button2);
+ UILabelButton* button3 = new UILabelButton();
+ button3->SetPosition(0, 0, g_ButtonW, g_ButtonH);
+ button3->SetText("button3");
+ swipe->Add(button3);
+ ```
+
+3. Verify that the components are swiping horizontally but not cyclically.
+
+ **Figure 1** Horizontal swiping effect of **UISwipeView**
+
+
+ 
+
+
+## Development Procedure \(Cyclic Horizontal Swiping\)
+
+1. Create a horizontal swiping **UISwipeView** and add its child components.
+
+ ```
+ UISwipeView* swipe = new UISwipeView(UISwipeView::HORIZONTAL);
+ UILabelButton* button1 = new UILabelButton();
+ button1->SetPosition(0, 0, g_ButtonW, g_ButtonH);
+ button1->SetText("button1");
+ swipe->Add(button1);
+ UILabelButton* button2 = new UILabelButton();
+ button2->SetPosition(0, 0, g_ButtonW, g_ButtonH);
+ button2->SetText("button2");
+ swipe->Add(button2);
+ UILabelButton* button3 = new UILabelButton();
+ button3->SetPosition(0, 0, g_ButtonW, g_ButtonH);
+ button3->SetText("button3");
+ swipe->Add(button3);
+ ```
+
+2. Enable cyclic swiping for the **UISwipeView**.
+
+ ```
+ swipe->SetLoopState(true);
+ ```
+
+3. Verify that the components are swiping horizontally and cyclically.
+
+ **Figure 2** Cyclic horizontal swiping effect of **UISwipeView**
+
+
+ 
+
+
+## GridLayout
+
+## When to Use
+
+**GridLayout** provides the basic layout capability to set the number of grid rows and columns. Child components added via the **Add** function are automatically arranged after the **LayoutChildren\(\)** function is called.
+
+## Available APIs
+
+**Table 2** Available functions in GridLayout
+
+
+
Function
+
+
Description
+
+
+
+
void SetRows(const uint16_t& rows)
+
+
Sets the number of grid rows.
+
+
+
void SetCols(const uint16_t& cols)
+
+
Sets the number of grid columns.
+
+
+
void LayoutChildren(bool needInvalidate = false)
+
+
Lays out child components.
+
+
+
+
+
+## How to Develop
+
+1. Create a **GridLayout** instance and set its position and size.
+
+ ```
+ GridLayout* layout_ = new GridLayout();
+ layout_->SetPosition(0, g_y, HROIZONTAL_RESOLUTION, 200);
+ layout_->SetLayoutDirection(LAYOUT_HOR);
+ layout_->SetRows(2);
+ layout_->SetCols(2);
+ ```
+
+2. Create **UILabelButton** instances.
+
+ ```
+ UILabelButton* bt1 = new UILabelButton();
+ bt1->SetPosition(0,0,100,50);
+ bt1->SetText("bt1");
+ UILabelButton* bt2 = new UILabelButton();
+ bt2->SetPosition(0, 0, 100, 50);
+ bt2->SetText("bt2");
+ UILabelButton* bt3 = new UILabelButton();
+ bt3->SetPosition(0, 0, 100, 50);
+ bt3->SetText("bt3");
+ UILabelButton* bt4 = new UILabelButton();
+ bt4->SetPosition(0, 0, 100, 50);
+ bt4->SetText("bt4");
+ ```
+
+3. Add child components and call the **LayoutChildren\(\)** function.
+
+ ```
+ layout_->Add(bt1);
+ layout_->Add(bt2);
+ layout_->Add(bt3);
+ layout_->Add(bt4);
+ layout_->LayoutChildren();
+ ```
+
+4. Verify the layout of buttons, as shown in the following figure.
+
+ **Figure 3** Setting a 2x2 grid and adding four buttons in a layout
+ 
+
+
diff --git a/en/device-dev/subsystems/subsys-graphics-bundle-guide3.md b/en/device-dev/subsystems/subsys-graphics-bundle-guide3.md
new file mode 100644
index 0000000000000000000000000000000000000000..fc7c79ec29f35df2218ea4d5d74ef3da7c5a6783
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-graphics-bundle-guide3.md
@@ -0,0 +1,555 @@
+# Development Guidelines on Common Components
+
+- [UIButton](#section145353310214)
+- [When to Use](#section1169616141577)
+- [Available APIs](#section341211538315)
+- [How to Develop](#section22501726193214)
+- [UIImageView](#section19523161611259)
+- [When to Use](#section1274484210400)
+- [Available APIs](#section74981992411)
+- [How to Develop \(Adaptive Mode\)](#section144341333134114)
+- [How to Develop \(Tile Mode\)](#section97178160421)
+- [UILabel](#section16588132012911)
+- [When to Use](#section6870195634218)
+- [Available APIs](#section2012714510433)
+- [How to Develop \(Default Mode\)](#section83221538114410)
+- [How to Develop \(Background Color and Opacity\)](#section933360204510)
+- [How to Develop \(Letter Spacing\)](#section19447826124518)
+- [How to Develop \(Size-Adaptive Mode\)](#section101711842154617)
+- [How to Develop \(Ellipsis Mode\)](#section1249519410471)
+- [How to Develop \(Scrolling Mode\)](#section15643122618478)
+
+Common components inherit from the base class **UIView**. Child components cannot be added to common components, such as buttons, images, and labels.
+
+**Figure 1** Tree structure of common components
+
+
+**UIView** is a base class of the following components: **UIAbstractProgress**, **UIArcLabel**, **UIButton**, **UICanvas**, **UILabel**, and **UIImageView**. **UIBoxProgress** and **UICircleProgress** inherit from **UIAbstractProgress**. **UILabelButton** and **UIRepeatButton** inherit from **UIButton**. **UIImageAnimatorView** and **UITextureMapper** inherit from **UIImageView**.
+
+## UIButton
+
+## When to Use
+
+**UIButton** supports the click event and allows you to set styles in different states.
+
+## Available APIs
+
+**Table 1** Available functions in UIButton
+
+
+
Sets the style for the button in a specified state.
+
+
+
void Disable ()
+
+
Disables the button.
+
+
+
void Enable ()
+
+
Enables the button.
+
+
+
+
+
+## How to Develop
+
+1. Implement the click event.
+
+ ```
+ class TestBtnOnClickListener : public OHOS::UIView::OnClickListener {
+ bool OnClick(UIView& view, const ClickEvent& event) override
+ {
+ int16_t width = view.GetWidth() + 10;
+ int16_t height = view.GetHeight() + 10;
+ view.Resize(width, height);
+ view.Invalidate();
+ return true;
+ }
+ };
+ ```
+
+2. Create a **UIButton** instance.
+
+ ```
+ UIButton* button = new UIButton();
+ button->SetPosition(50, 50);
+ button->SetWidth(100);
+ button->SetHeight(50);
+ ```
+
+3. Register the click event callback for **UIButton**.
+
+ ```
+ button->SetOnClickListener(new TestBtnOnClickListener());
+ ```
+
+4. Verify that the button is clicked and its size increases gradually, as shown in the following figure.
+
+ **Figure 2** Effect of clicking a **UIButton**
+ 
+
+
+## UIImageView
+
+## When to Use
+
+**UIImageView** supports the functions to display images, set opacity, rotate images, and zoom in or out images. The following image formats are supported: RGB565, RGB888, RGBA8888, PNG, and JPG.
+
+## Available APIs
+
+**Table 2** Available functions in UIImageView
+
+
+
Function
+
+
Description
+
+
+
+
void SetSrc (const char *src)
+
+
Sets the image path with binary data.
+
+
+
void SetSrc (const ImageInfo *src)
+
+
Sets the pointer to image information.
+
+
+
void SetAutoEnable (bool enable)
+
+
Sets whether the component size adapts to the image size.
+
+
+
const void* GetSrcType () const
+
+
Obtains the image type.
+
+
+
bool GetAutoEnable () const
+
+
Checks whether the component size adapts to the image size.
+
+## How to Develop \(Adaptive Mode\)
+
+1. Create a **UIImageView** instance.
+
+ ```
+ UIImageView* imageView = new UIImageView();
+ imageView->SetPosition(0, 30);
+ ```
+
+2. Set the image path with binary data.
+
+ ```
+ imageView->SetSrc("..\\config\\images\\A021_001.bin");
+ ```
+
+3. Verify that the **UIImageView** component is adaptive to the image.
+
+ **Figure 3** Image auto-adaption effect
+ 
+
+
+## How to Develop \(Tile Mode\)
+
+1. Create a **UIImageView** instance.
+
+ ```
+ UIImageView* imageView = new UIImageView();
+ imageView->SetPosition(0, 30);
+ ```
+
+2. Set the image path.
+
+ ```
+ imageView->SetSrc("..\\config\\images\\A021_001.bin");
+ ```
+
+3. Disable the image auto-adaptation effect and resize the image to display the image in tile mode.
+
+ ```
+ imageView->SetAutoEnable(false);
+ imageView->Resize(454, 150);
+ ```
+
+4. Verify that the tile mode has been enabled for the **UIImageView**.
+
+ **Figure 4** Image tile effect
+ 
+
+
+## UILabel
+
+## When to Use
+
+**UILabel** displays text in an area. You can set the background color, text display style, and long text display effect for a label.
+
+## Available APIs
+
+**Table 3** Available functions in UILabel
+
+
+
Sets the enumerated value of the text rotation angle.
+
+
+
LabelRotateDegree GetTextRotation() const
+
+
Obtains the enumerated value of the text rotation angle.
+
+
+
uint16_t GetTextRotateDegree() const
+
+
Obtains the number of text rotation degrees.
+
+
+
+
+
+## How to Develop \(Default Mode\)
+
+1. Create a **lUILabel** instance and set its size and position.
+
+ ```
+ UILabel* label = new UILabel();
+ label->SetPosition(x, y);
+ label->Resize(width, height);
+ ```
+
+2. Set the font.
+
+ ```
+ label->SetFont("SourceHanSansSC-Regular.otf", 30);
+ ```
+
+3. Set the text.
+
+ ```
+ label->SetText("label");
+ ```
+
+4. Verify the label size and display effect, as shown in the following figure.
+
+ 
+
+
+## How to Develop \(Background Color and Opacity\)
+
+1. Create a **lUILabel** instance and set its size and position.
+
+ ```
+ UILabel* label = new UILabel();
+ label->SetPosition(x, y);
+ label->Resize(width, height);
+ ```
+
+2. Set the font.
+
+ ```
+ label->SetFont("SourceHanSansSC-Regular.otf", 30);
+ ```
+
+3. Set the background color and opacity.
+
+ ```
+ label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
+ label->SetStyle(STYLE_BACKGROUND_OPA, 127);
+ label->SetText("Label");
+ ```
+
+4. Verify that the background color of the label is **Gray**, as shown in the following figure.
+
+ 
+
+
+## How to Develop \(Letter Spacing\)
+
+1. Create a **lUILabel** instance and set its size and position.
+
+ ```
+ UILabel* label = new UILabel();
+ label->SetPosition(x, y);
+ label->Resize(width, height);
+ ```
+
+2. Set the font.
+
+ ```
+ label->SetFont("SourceHanSansSC-Regular.otf", 30);
+ ```
+
+3. Set the font color and letter spacing.
+
+ ```
+ label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
+ label->SetStyle(STYLE_LETTER_SPACE, 5);
+ label->SetText("Label");
+ ```
+
+4. Verify that the letter spacing is **5** pixels on the label, as shown in the following figure.
+
+ 
+
+
+## How to Develop \(Size-Adaptive Mode\)
+
+Regarding too long text, the size of a label can be automatically adjusted based on the text, or the text can be truncated or displayed with the scrolling effect.
+
+1. Create a **lUILabel** instance and set its size and position.
+
+ ```
+ UILabel* label = new UILabel();
+ label->SetPosition(x, y);
+ label->Resize(width, height);
+ ```
+
+2. Set the font.
+
+ ```
+ label->SetFont("SourceHanSansSC-Regular.otf", 30);
+ ```
+
+3. Set the font color to **Gray** and enable the label size to adapt to the text.
+
+ ```
+ label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
+ label->SetLineBreakMode(UILabel::LINE_BREAK_ADAPT);
+ label->SetText("123\n567890");
+ ```
+
+4. Verify that the label size adapts to the text, as shown in the following figure.
+
+ 
+
+
+## How to Develop \(Ellipsis Mode\)
+
+In ellipsis mode, an ellipsis \(...\) is displayed at the end of the label if the text cannot be completely displayed.
+
+1. Create a **lUILabel** instance and set its size and position.
+
+ ```
+ UILabel* label = new UILabel();
+ label->SetPosition(x, y);
+ label->Resize(width, height);
+ ```
+
+2. Set the font.
+
+ ```
+ label->SetFont("SourceHanSansSC-Regular.otf", 30);
+ ```
+
+3. Set the text display mode to **LINE\_BREAK\_ELLIPSIS**.
+
+ ```
+ label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
+ label->SetLineBreakMode(UILabel::LINE_BREAK_ELLIPSIS);
+ label->SetText("123567890");
+ ```
+
+4. Verify that the ellipsis mode has taken effect on the label, as shown in the following figure.
+
+ 
+
+
+## How to Develop \(Scrolling Mode\)
+
+In scrolling mode, long text is kept scrolling on a screen to bring the entire text into view.
+
+1. Create a **lUILabel** instance and set its size and position.
+
+ ```
+ UILabel* label = new UILabel();
+ label->SetPosition(x, y);
+ label->Resize(width, height);
+ ```
+
+2. Set the font.
+
+ ```
+ label->SetFont("SourceHanSansSC-Regular.otf", 30);
+ ```
+
+3. Set the text display mode to **UI\_LABEL\_LONG\_ROLL**.
+
+ ```
+ label->SetStyle(STYLE_BACKGROUND_COLOR, Color::Gray().full);
+ label->SetStyle(STYLE_BACKGROUND_OPA, 127);
+ label->SetLineBreakMode(UILabel::LINE_BREAK_MARQUEE);
+ label->SetText("123567890");
+ ```
+
+4. Verify that the text is scrolling on the label, as shown in the following figure.
+
+ .gif)
+
+
diff --git a/en/device-dev/subsystems/graphics-2.md b/en/device-dev/subsystems/subsys-graphics-overview.md
similarity index 100%
rename from en/device-dev/subsystems/graphics-2.md
rename to en/device-dev/subsystems/subsys-graphics-overview.md
diff --git a/en/device-dev/subsystems/subsys-graphics.md b/en/device-dev/subsystems/subsys-graphics.md
new file mode 100644
index 0000000000000000000000000000000000000000..bf96041837411ebf1c96ea894d70fdae2846b2ca
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-graphics.md
@@ -0,0 +1,13 @@
+# Graphics
+
+- **[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 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
new file mode 100644
index 0000000000000000000000000000000000000000..363f36457acbce8ac0ea1a8046c08920bde4807c
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-multimedia-camera-overview.md
@@ -0,0 +1,116 @@
+# Overview
+
+- [Basic Concepts](#section175012297491)
+- [Working Principles](#section193961322175011)
+
+## Basic Concepts
+
+Camera is one of the services provided by the OpenHarmony multimedia subsystem. The camera module provides recording, preview, and photographing features and supports concurrent stream reading by multiple users.
+
+It is considered good practice that you understand the following concepts before starting development:
+
+- Video frame
+
+ A video frame is formed by the stream data of a video image. Video data streams are formed by a series of image data arranged at a fixed time interval.
+
+- Frame per second \(FPS\)
+
+ FPS is used to represent the frame rate at which images are refreshed during video playback, or the number of frames per second during video playback. A higher frame rate means smoother video playback.
+
+- Resolution
+
+ Information about each image frame consists of pixels. The number of pixels in an image is presented by the resolution. For example, 1080p \(1920 x 1080\) indicates that the image width is 1920 pixels and the image height is 1080 pixels.
+
+
+## Working Principles
+
+- Multimedia services
+
+ Multimedia services are started by the **Init** process upon system startup, and media hardware resources \(such as memory, display hardware, image sensors, and codecs\) are initialized and allocated. During the initialization, the configuration file is parsed, which determines the upper limit of capabilities and resources of each service. Generally, the upper limit is configured by original equipment manufacturers \(OEMs\) in the configuration file. The following configuration items are available for the camera service during multimedia service initialization:
+
+ - Memory pool: Memory blocks in the memory pool are accessed and released continuously by all multimedia services.
+ - Image sensor: sensor type, resolution, ISP, and more
+ - Image processor: resolution, bit rate, image inversion, and more
+ - Image encoder: encoding format, bit rate, resolution, and more
+
+
+- Major classes
+
+ You can use the **Camera** class and its asynchronous callback classes to configure and access the camera functionalities. The three callback classes correspond to different asynchronous processing scenarios, as described in [Table 1](#table486418149411).
+
+ **Table 1** Class description
+
+
+
Class
+
+
Description
+
+
Examples
+
+
+
+
Camera
+
+
Configures the static camera capability through the configuration class to use basic camera functionalities.
+
+
Photographing, video recording, and previewing
+
+
+
CameraDeviceCallback
+
+
Handles camera hardware state changes.
+
+
Available or unavailable
+
+
+
CameraStateCallback
+
+
Handles camera instance state changes.
+
+
Created or released
+
+
+
FrameStateCallback
+
+
Handles frame status changes.
+
+
Start and end of photographing, and frame rate changes
+
+
+
+
+
+- Stream transfer
+
+ A surface is the basic data structure for transferring audio and video data. A camera is generally used as the data producer of a surface and has specific consumers in different scenarios.
+
+ Camera preview and recording outputs are video streams, and photographing outputs are image frames. The outputs are transferred through the **Surface** class. A surface can transmit media information streams within and cross processes.
+
+ Take video recording as an example. You create a **Recorder** instance, obtain the surface of the **Recorder** instance, and then transfer the surface to the **Camera** instance. In this case, the **Camera** instance works as a producer to inject video streams to the surface, and the **Recorder** instance act as the consumer to obtain video streams from the surface for storage. In this case, you connect the recorder and camera through the surface.
+
+ Similarly, you can create a surface, implement consumer logic for it, and transfer it to the **Camera** instance. For example, transmit video streams over the network or save captured frame data as an image file.
+
+ The graphics module also obtains stream resources from the camera module through surfaces. For details, see development guidelines on [Graphic](subsys-graphics-overview.md).
+
+- Camera running process
+ 1. Creating a camera
+
+ This process creates a **Camera** instance by **CameraManager**, binds the camera device to the server, and asynchronously notifies you of the successful creation. The following figure shows the time sequence between classes.
+
+ **Figure 1** Sequence diagram for creating a camera
+
+
+ 
+
+
+ 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.
+
+ **Figure 2** Sequence diagram for recording/previewing
+
+
+ 
+
+
+
diff --git a/en/device-dev/subsystems/subsys-multimedia-camera-photo-guide.md b/en/device-dev/subsystems/subsys-multimedia-camera-photo-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..d35bed7457c70bc19d6c66cdbca1267b7da37aec
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-multimedia-camera-photo-guide.md
@@ -0,0 +1,396 @@
+# Development Guidelines on Photographing
+
+- [When to Use](#section1963312376119)
+- [Available APIs](#section56549532016)
+- [Limitations and Constraints](#section1165911177314)
+- [How to Develop](#section138543918214)
+
+## When to Use
+
+Use the camera module APIs to capture frames \(photographing\).
+
+## Available APIs
+
+**Table 1** APIs for photographing
+
+
+
int32_t SetParameter(int32_t sourceId, const Format &format)
+
+
Sets an extended parameter for recording.
+
+
+
+
+
+## Limitations and Constraints
+
+None
+
+## How to Develop
+
+1. Create a **Recorder** instance.
+
+ ```
+ Recorder *recorder = new Recorder();
+ ```
+
+2. Sets parameters for the **Recorder** instance, including the media source information, encoding format, sampling rate, bit rate, and video width and height.
+
+ ```
+ int32_t sampleRate = 48000;
+ int32_t channelCount = 1;
+ AudioCodecFormat audioFormat = AAC_LC;
+ AudioSourceType inputSource = AUDIO_MIC;
+ int32_t audioEncodingBitRate = sampleRate;
+ VideoSourceType source = VIDEO_SOURCE_SURFACE_ES;
+ int32_t frameRate = 30;
+ double fps = 30;
+ int32_t rate = 4096;
+ int32_t sourceId = 0;
+ int32_t audioSourceId = 0;
+ int32_t width = 1920;
+ int32_t height = 1080;
+ VideoCodecFormat encoder = H264;
+ recorder->SetVideoSource(source, sourceId); // Set the video source and obtain the source ID.
+ recorder->SetVideoEncoder(sourceId, encoder); // Set the video encoding format.
+ recorder->SetVideoSize(sourceId, width, height); // Set the video width and height.
+ recorder->SetVideoFrameRate(sourceId, frameRate); // Set the video frame rate.
+ recorder->SetVideoEncodingBitRate(sourceId, rate); // Set the video encoding bit rate.
+ recorder->SetCaptureRate(sourceId, fps); // Set the capture rate for video frames.
+ recorder->SetAudioSource(inputSource, audioSourceId); // Set the audio source and obtain the source ID.
+ recorder->SetAudioEncoder(audioSourceId, audioFormat); // Set the audio encoding format.
+ recorder->SetAudioSampleRate(audioSourceId, sampleRate); // Set the audio sampling rate.
+ recorder->SetAudioChannels(audioSourceId, channelCount); // Set the number of audio channels.
+ recorder->SetAudioEncodingBitRate(audioSourceId, audioEncodingBitRate); // Set the audio encoding bit rate.
+ ```
+
+3. Prepare the **Recorder** instance for recording.
+
+ ```
+ recorder->Prepare(); // Prepare for recording.
+ ```
+
+4. Start recording. The **Recorder** instance starts recording based on the audio and video sources.
+
+ ```
+ recorder->Start(); // Start recording.
+ ```
+
+5. Stop recording and release resources.
+
+ ```
+ recorder->Stop(); // Stop recording.
+ recorder->Release(); // Release recording resources.
+ ```
+
+
diff --git a/en/device-dev/subsystems/subsys-multimedia-video.md b/en/device-dev/subsystems/subsys-multimedia-video.md
new file mode 100644
index 0000000000000000000000000000000000000000..9d075f20b5a9a5ec0570bc6610b7bab093f230fe
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-multimedia-video.md
@@ -0,0 +1,9 @@
+# Audio/Video
+
+- **[Overview](subsys-multimedia-video-overview.md)**
+
+- **[Development Guidelines on Media Playback](subsys-multimedia-video-play-guide.md)**
+
+- **[Development Guidelines on Media Recording](subsys-multimedia-video-record-guide.md)**
+
+
diff --git a/en/device-dev/subsystems/subsys-multimedia.md b/en/device-dev/subsystems/subsys-multimedia.md
new file mode 100644
index 0000000000000000000000000000000000000000..c4b8f72b08f658c27e999c81452c400e0403018b
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-multimedia.md
@@ -0,0 +1,7 @@
+# Multimedia
+
+- **[Camera](subsys-multimedia-camera.md)**
+
+- **[Audio/Video](subsys-multimedia-video.md)**
+
+
diff --git a/en/device-dev/subsystems/subsys-ota-guide.md b/en/device-dev/subsystems/subsys-ota-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..a249a319bae47c068ae9051865429d0e7f74bc27
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-ota-guide.md
@@ -0,0 +1,358 @@
+# OTA Upgrade
+
+- [Limitations and Constraints](#section691733275418)
+- [Generating a Public/Private Key Pair](#section94411533155010)
+- [Generating an Upgrade Package](#section632383718539)
+- [Uploading the Upgrade Package](#section5772112473213)
+- [Downloading the Upgrade Package](#section251732474917)
+- [Integrating OTA Update Capabilities](#section298217330534)
+- [API Application Scenario \(Default\)](#section7685171192916)
+ - [How to Develop](#section0745926153017)
+ - [Sample Code](#section1337111363306)
+
+- [API Application Scenario \(Custom\)](#section1686395317306)
+ - [How to Develop](#section524515314317)
+ - [Sample Code](#section525974743120)
+
+- [Upgrading the System](#section151997114334)
+
+Over the Air \(OTA\) is a technology that makes it easier for you to remotely update devices, such as IP cameras. A device can be upgraded with a full or differential package. A full package contains all content of a new system, and a differential package contains the differences between the old and new systems. Currently, only the full-package upgrade is supported.
+
+## Limitations and Constraints
+
+- The open-source suites for devices developed based on Hi3861, Hi3518E V300 and Hi3516D V300 are supported.
+- Devices developed based on Hi3518E V300 and Hi3516D V300 must support the SD card in the Virtual Festival of Aerobatic Teams \(VFAT\) format.
+
+## Generating a Public/Private Key Pair
+
+1. Download the OpenSSL tool from the following website and install it on a Windows PC, and configure environment variables.
+
+ [http://slproweb.com/products/Win32OpenSSL.html](http://slproweb.com/products/Win32OpenSSL.html)
+
+2. Access the **tools\\update\_tools\\update\_pkg\_tools** directory, download the upgrade package making tool, and save it to a local directory, for example, **D:\\ota\_tools**.
+3. Run **Generate\_public\_private\_key.bat** in the **ota\_tools\\key** directory to generate **Metis\_PUBLIC.key**, **private.key**, and **public\_arr.txt** that contains public values, as shown in the following figure. Keep the private key properly.
+
+ **Figure 1** Generating a Public/Private Key Pair
+
+
+ 
+
+4. Use the array written in **public\_arr.txt** as a substitute for **g\_pubKeyBuf** in **base\\update\\ota\_lite\\frameworks\\source\\verify\\hota\_verify.c** of the OTA module.
+
+ Example array in **public\_arr.txt**:
+
+ ```
+ 0x30,0x82,0x1,0xa,0x2,0x82,0x1,0x1,0x0,0xc7,0x8c,0xf3,0x91,0xa1,0x98,0xbf,0xb1,0x8c,
+ 0xbe,0x22,0xde,0x32,0xb2,0xfa,0xec,0x2c,0x69,0xf6,0x8f,0x43,0xa7,0xb7,0x6f,0x1e,0x4a,0x97,
+ 0x4b,0x27,0x5d,0x56,0x33,0x9a,0x73,0x4e,0x7c,0xf8,0xfd,0x1a,0xf0,0xe4,0x50,0xda,0x2b,0x8,
+ 0x74,0xe6,0x28,0xcc,0xc8,0x22,0x1,0xa8,0x14,0x9,0x46,0x46,0x6a,0x10,0xcd,0x39,0xd,0xf3,
+ 0x4a,0x7f,0x1,0x63,0x21,0x33,0x74,0xc6,0x4a,0xeb,0x68,0x40,0x55,0x3,0x80,0x1d,0xd9,0xbc,
+ 0xd4,0xb0,0x4a,0x84,0xb7,0xac,0x43,0x1d,0x76,0x3a,0x61,0x40,0x23,0x3,0x88,0xcc,0x80,0xe,
+ 0x75,0x10,0xe4,0xad,0xac,0xb6,0x4c,0x90,0x8,0x17,0x26,0x21,0xff,0xbe,0x1,0x82,0x16,0x76,
+ 0x9a,0x1c,0xee,0x8e,0xd9,0xb0,0xea,0xd5,0x50,0x61,0xcc,0x9c,0x2e,0x78,0x15,0x2d,0x1f,0x8b,
+ 0x94,0x77,0x30,0x39,0x70,0xcf,0x16,0x22,0x82,0x99,0x7c,0xe2,0x55,0x37,0xd4,0x76,0x9e,0x4b,
+ 0xfe,0x48,0x26,0xc,0xff,0xd9,0x59,0x6f,0x77,0xc6,0x92,0xdd,0xce,0x23,0x68,0x83,0xbd,0xd4,
+ 0xeb,0x5,0x1b,0x2a,0x7e,0xda,0x9a,0x59,0x93,0x41,0x7b,0x4d,0xef,0x19,0x89,0x4,0x8d,0x5,
+ 0x7d,0xbc,0x3,0x1f,0x77,0xe6,0x3d,0xa5,0x32,0xf5,0x4,0xb7,0x9c,0xe9,0xfa,0x6e,0xc,0x9f,
+ 0x4,0x62,0xfe,0x2a,0x5f,0xbf,0xeb,0x9a,0x73,0xa8,0x2a,0x72,0xe3,0xf0,0x57,0x56,0x5c,0x59,
+ 0x14,0xdd,0x79,0x11,0x42,0x3a,0x48,0xf7,0xe8,0x80,0xb1,0xaf,0x1c,0x40,0xa2,0xc6,0xec,0xf5,
+ 0x67,0xc1,0x88,0xf6,0x26,0x5c,0xd3,0x11,0x5,0x11,0xed,0xb1,0x45,0x2,0x3,0x1,0x0,0x1,
+ ```
+
+ Example configuration for the public key of the OTA module:
+
+ ```
+ #define PUBKEY_LENGTH 270
+
+ static uint8 g_pubKeyBuf[PUBKEY_LENGTH] = {
+ 0x30, 0x82, 0x01, 0x0A, 0x02, 0x82, 0x01, 0x01, 0x00, 0xBF, 0xAA, 0xA5, 0xB3, 0xC2, 0x78, 0x5E,
+ 0x63, 0x07, 0x84, 0xCF, 0x37, 0xF0, 0x45, 0xE8, 0xB9, 0x6E, 0xEF, 0x04, 0x88, 0xD3, 0x43, 0x06,
+ ```
+
+5. \(Optional\) For Hi3518E V300 and Hi3516D V300 suites, further replace the array written in **g\_pub\_key** with that in **public\_arr.txt**. The **g\_pub\_key** file is provided in **device\\hisilicon\\third\_party\\uboot\\u-boot-2020.01\\product\\hiupdate\\verify\\update\_public\_key.c** of the U-Boot module.
+
+ Example configuration for the public key of the U-Boot module:
+
+ ```
+ static unsigned char g_pub_key[PUBKEY_LEN] = {
+ 0x30, 0x82, 0x01, 0x0A, 0x02, 0x82, 0x01, 0x01,
+ 0x00, 0xBF, 0xAA, 0xA5, 0xB3, 0xC2, 0x78, 0x5E,
+ ```
+
+
+## Generating an Upgrade Package
+
+1. Save the files to be upgraded in the **ota\_tools\\Components** directory.
+
+ **Figure 2** Location of original image files
+
+
+ 
+
+ **Table 1** Files to be upgraded
+
+
+
File
+
+
Description
+
+
+
+
u-boot.bin
+
+
Renamed from the u-boot-hi351XevX00.bin file generated after compilation.
+
+
+
kernel.bin
+
+
Renamed from the liteos.bin or kernel file generated after compilation.
+
+
+
rootfs.img
+
+
Renamed from the rootfs_xxxxx.img file generated after compilation.
+
+
+
config
+
+
Provides development board and kernel information. For details, see the SD card burning description of the corresponding open-source suite.
+
+
+
OTA.tag
+
+
Contains 32 bytes in the package_type:otaA1S2D3F4G5H6J7K8 format. The last 16 bytes are random, varying with the version.
+
+
+
+
+
+2. Open the **packet\_harmony.xml** file in **ota\_tools\\xml** to modify **compAddr** as follows. Other items are reserved.
+
+ Example configuration for the component information:
+
+ ```
+
+
+ .\Components\rootfs_jffs2.img
+ .\Components\liteos.bin
+ .\Components\userfs_jffs2.img
+
+ ```
+
+3. Configure the paths of private and public keys in **packet\_harmony.xml**.
+
+ Example configuration for paths of private and public keys:
+
+ ```
+
+ .\key\private.key
+ .\key\Metis_PUBLIC.key
+
+ ```
+
+4. Configure the product name and software version in **ota\_tools\\VersionDefine.bat** for anti-rollback.
+
+ Example configuration for the product name and software version:
+
+ ```
+ set FILE_PRODUCT_NAME=Hisi
+
+ @rem Set the software version number to a string of no more than 16 characters.
+ set SOFTWARE_VER=OpenHarmony 1.1
+ ```
+
+5. Run **Make\_Harmony\_PKG.bat** in the **ota\_tools** directory to generate the **Hisi\_OpenHarmony 1.1.bin** upgrade package. The upgrade package is signed using **SHA-256** and **RSA 2048** to ensure its integrity and validity.
+
+ **Figure 3** Upgrade package making tool
+
+
+ 
+
+
+## Uploading the Upgrade Package
+
+Upload the **Hisi\_OpenHarmony 1.1.bin** upgrade package to the vendor's OTA server.
+
+## Downloading the Upgrade Package
+
+1. Download the **Hisi\_OpenHarmony 1.1.bin** upgrade package from the OTA server.
+2. \(Optional\) Insert an SD card \(capacity greater than 100 MB\) if the device is developed based on Hi3518E V300 or Hi3516D V300.
+
+## Integrating OTA Update Capabilities
+
+- If vendors request OTA capabilities, use the dynamic library **libhota.so** and include the header files **hota\_partition.h** and **hota\_updater.h** in **base\\update\\ota\_lite\\interfaces\\kits**.
+- The **libhota.so** source code is stored in **base\\update\\ota\_lite\\frameworks\\source**.
+- For details about how to use APIs, see [API Application Scenario \(Default\)](#section7685171192916) and OTA APIs in _API Reference_.
+- If the development board needs to be adapted, see the **base\\update\\ota\_lite\\hals\\hal\_hota\_board.h** header file.
+
+## API Application Scenario \(Default\)
+
+The upgrade package is generated by following the instructions provided in [Generating a Public/Private Key Pair](#section94411533155010) and [Generating an Upgrade Package](#section632383718539).
+
+### **How to Develop**
+
+1. Download the upgrade package for the current device, and then call the **HotaInit** function to initialize the OTA module.
+2. Call the **HotaWrite** function to verify, parse, and write data streams into the device.
+3. Call the **HotaRestart** function to restart the system.
+
+ If you want to cancel the upgrade, call the **HotaCancel** function.
+
+
+### **Sample Code**
+
+Perform an OTA update using the upgrade package format and verification method provided by OpenHarmony.
+
+```
+int main(int argc, char **argv)
+{
+ printf("this is update print!\r\n");
+ if (HotaInit(NULL, NULL) < 0) {
+ printf("ota update init fail!\r\n");
+ return -1;
+ }
+ int fd = open(OTA_PKG_FILE, O_RDWR, S_IRUSR | S_IWUSR);
+ if (fd < 0) {
+ printf("file open failed, fd = %d\r\n", fd);
+ (void)HotaCancel();
+ return -1;
+ }
+ int offset = 0;
+ int fileLen = lseek(fd, 0, SEEK_END);
+ int leftLen = fileLen;
+ while (leftLen > 0) {
+ if (lseek(fd, offset, SEEK_SET) < 0) {
+ close(fd);
+ printf("lseek fail!\r\n");
+ (void)HotaCancel();
+ return -1;
+ }
+ int tmpLen = leftLen >= READ_BUF_LEN ? READ_BUF_LEN : leftLen;
+ (void)memset_s(g_readBuf, READ_BUF_LEN, 0, READ_BUF_LEN);
+ if (read(fd, g_readBuf, tmpLen) < 0) {
+ close(fd);
+ printf("read fail!\r\n");
+ (void)HotaCancel();
+ return -1;
+ }
+ if (HotaWrite((unsigned char *)g_readBuf, offset, tmpLen) != 0) {
+ printf("ota write fail!\r\n");
+ close(fd);
+ (void)HotaCancel();
+ return -1;
+ }
+ offset += READ_BUF_LEN;
+ leftLen -= tmpLen;
+ }
+ close(fd);
+ printf("ota write finish!\r\n");
+ printf("device will reboot in 10s...\r\n");
+ sleep(10);
+ (void)HotaRestart();
+ return 0;
+}
+```
+
+## API Application Scenario \(Custom\)
+
+The upgrade package is generated in other ways instead of by referring to the preceding two sections.
+
+### **How to Develop**
+
+1. Download the upgrade package for the current device, and then call the **HotaInit** function to initialize the OTA module.
+2. Call the **HotaSetPackageType** function to set the package type to **NOT\_USE\_DEFAULT\_PKG**.
+3. Call the **HotaWrite** function to write data streams into the device.
+4. Call the **HotaRead** function to read data. Vendors can choose to verify the data.
+5. \(Optional\) Call the **HotaSetBootSettings** function to set the startup tag used for entering the U-Boot mode after restarting the system.
+6. Call the **HotaRestart** function to restart the system.
+
+ If you want to cancel the upgrade, call the **HotaCancel** function.
+
+
+### **Sample Code**
+
+Perform an OTA update using the upgrade package format and verification method not provided by OpenHarmony.
+
+```
+int main(int argc, char **argv)
+{
+ printf("this is update print!\r\n");
+ if (HotaInit(NULL, NULL) < 0) {
+ printf("ota update init fail!\r\n");
+ (void)HotaCancel();
+ return -1;
+ }
+ (void)HotaSetPackageType(NOT_USE_DEFAULT_PKG);
+ int fd = open(OTA_PKG_FILE, O_RDWR, S_IRUSR | S_IWUSR);
+ if (fd < 0) {
+ printf("file open failed, fd = %d\r\n", fd);
+ (void)HotaCancel();
+ return -1;
+ }
+ int offset = 0;
+ int fileLen = lseek(fd, 0, SEEK_END);
+ int leftLen = fileLen;
+ while (leftLen > 0) {
+ if (lseek(fd, offset, SEEK_SET) < 0) {
+ close(fd);
+ printf("lseek fail!\r\n");
+ (void)HotaCancel();
+ return -1;
+ }
+ int tmpLen = leftLen >= READ_BUF_LEN ? READ_BUF_LEN : leftLen;
+ (void)memset_s(g_readBuf, READ_BUF_LEN, 0, READ_BUF_LEN);
+ if (read(fd, g_readBuf, tmpLen) < 0) {
+ close(fd);
+ printf("read fail!\r\n");
+ (void)HotaCancel();
+ return -1;
+ }
+ if (HotaWrite((unsigned char *)g_readBuf, offset, tmpLen) != 0) {
+ printf("ota write fail!\r\n");
+ close(fd);
+ (void)HotaCancel();
+ return -1;
+ }
+ offset += READ_BUF_LEN;
+ leftLen -= tmpLen;
+ }
+ close(fd);
+ printf("ota write finish!\r\n");
+ leftLen = fileLen;
+ while (leftLen > 0) {
+ int tmpLen = leftLen >= READ_BUF_LEN ? READ_BUF_LEN : leftLen;
+ (void)memset_s(g_readBuf, READ_BUF_LEN, 0, READ_BUF_LEN);
+ if (HotaRead(offset, READ_BUF_LEN, (unsigned char *)g_readBuf) != 0) {}
+ printf("ota write fail!\r\n");
+ (void)HotaCancel();
+ return -1;
+ }
+ /* do your verify and parse */
+ offset += READ_BUF_LEN;
+ leftLen -= tmpLen;
+ }
+ /* set your boot settings */
+ (void)HotaSetBootSettings();
+ printf("device will reboot in 10s...\r\n");
+ sleep(10);
+ (void)HotaRestart();
+ return 0;
+}
+```
+
+## Upgrading the System
+
+Vendor applications call APIs of the OTA module to perform functions such as signature verification of the upgrade package, anti-rollback, burning and data flushing-to-disk. After the upgrade is complete, the system automatically restarts.
+
+For Hi3518E V300 and Hi3516D V300 open-source suites, the value of **LOCAL\_VERSION** needs to be modified for anti-rollback, for example, modifying **ohos default 1.0** to **ohos default 1.1**. The macro **LOCAL\_VERSION** is provided in **device\\hisilicon\\third\_party\\uboot\\u-boot-2020.01\\product\\hiupdate\\ota\_update\\ota\_local\_info.c**.
+
+Example for modification of the local version:
+
+```
+const char *get_local_version(void)
+{
+#if defined(CONFIG_TARGET_HI3516EV200) || \
+ defined(CONFIG_TARGET_HI3516DV300) || \
+ defined(CONFIG_TARGET_HI3518EV300)
+#define LOCAL_VERSION "ohos default 1.0" /* increase: default release version */
+```
+
diff --git a/en/device-dev/subsystems/distributed-remote-startup.md b/en/device-dev/subsystems/subsys-remote-start.md
similarity index 100%
rename from en/device-dev/subsystems/distributed-remote-startup.md
rename to en/device-dev/subsystems/subsys-remote-start.md
diff --git a/en/device-dev/subsystems/development-guidelines-on-ipc-authentication.md b/en/device-dev/subsystems/subsys-security-communicationverify.md
similarity index 100%
rename from en/device-dev/subsystems/development-guidelines-on-ipc-authentication.md
rename to en/device-dev/subsystems/subsys-security-communicationverify.md
diff --git a/en/device-dev/subsystems/overview-9.md b/en/device-dev/subsystems/subsys-security-overview.md
similarity index 100%
rename from en/device-dev/subsystems/overview-9.md
rename to en/device-dev/subsystems/subsys-security-overview.md
diff --git a/en/device-dev/subsystems/subsys-security-rightmanagement.md b/en/device-dev/subsystems/subsys-security-rightmanagement.md
new file mode 100644
index 0000000000000000000000000000000000000000..747ecce03eb0dfdeeda525206f398330dbd6f6c4
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-security-rightmanagement.md
@@ -0,0 +1,228 @@
+# Development Guidelines on Application Permission Management
+
+- [How Application Permission Management Works](#section193961322175011)
+- [When to Use](#section18502174174019)
+- [Available APIs](#section1633115419401)
+- [How to Develop](#section022611498210)
+
+## How Application Permission Management Works
+
+OpenHarmony allows users to install third-party applications and controls calls made by third-party applications to sensitive permissions. When developing an application, you need to declare the sensitive permissions that the application may require in the **profile.json** file. The permissions include static and dynamic ones. Static permissions need to be registered during application installation, and dynamic permissions can be obtained only upon user authorization. Authorization modes include system settings, manual authorization by applications, and others. In addition, application signature control is used to ensure that the application installation package has been confirmed by the device vendor.
+
+**Table 1** OpenHarmony permissions
+
+
+
OpenHarmony Permission
+
+
Grant Mode
+
+
Description
+
+
+
+
ohos.permission.LISTEN_BUNDLE_CHANGE
+
+
system_grant (static permission)
+
+
Allows an application to listen for application changes.
+
+
+
ohos.permission.GET_BUNDLE_INFO
+
+
system_grant (static permission)
+
+
Allows an application to obtain information about other applications.
+
+
+
ohos.permission.INSTALL_BUNDLE
+
+
system_grant (static permission)
+
+
Allows an application to install other applications.
+
+
+
ohos.permission.CAMERA
+
+
user_grant (dynamic permission)
+
+
Allows an application to use the camera to take photos and record videos at any time.
+
+
+
ohos.permission.MODIFY_AUDIO_SETTINGS
+
+
system_grant (static permission)
+
+
Allows an application to modify global audio settings, such as the volume and speaker for output.
+
+
+
ohos.permission.READ_MEDIA
+
+
user_grant (dynamic permission)
+
+
Allows an application to read users' favorite videos.
+
+
+
ohos.permission.MICROPHONE
+
+
user_grant (dynamic permission)
+
+
Allows an application to use the microphone for audio recording at any time.
+
+
+
ohos.permission.WRITE_MEDIA
+
+
user_grant (dynamic permission)
+
+
Allows an application to write users' favorite music.
+
+
+
ohos.permission.DISTRIBUTED_DATASYNC
+
+
user_grant (dynamic permission)
+
+
Allows an application to manage distributed data transmission.
+
+
+
ohos.permission.DISTRIBUTED_VIRTUALDEVICE
+
+
user_grant (dynamic permission)
+
+
Allows an application to use distributed virtualization features.
+
+
+
+
+
+> **NOTE:**
+>Static permission: a permission granted by the system during application installation. The sensitivity level of this type of permission is **system\_grant**.
+>Dynamic permission: a permission granted by users during application running. The sensitivity level of this type of permission is **user\_grant**.
+
+## When to Use
+
+Application permissions are used to control access to system resources and features. In scenarios where an application wants to access features or data related to users' privacy, such as accessing hardware features of personal devices like cameras and microphones, and reading and writing media files, OpenHarmony uses the application permission management component to protect such features and data.
+
+When developing a system application that requires a sensitive permission, you can call the corresponding API of the application permission management component to check whether the required permission is granted. If the permission is not granted, the application cannot use it.
+
+## Available APIs
+
+The following table lists the APIs available for application permission management. These APIs are only intended for system applications and services.
+
+**Table 2** APIs available for application permission management
+
+
+
Function
+
+
Description
+
+
+
+
int CheckPermission(int uid, const char *permissionName)
+
+
Checks whether the application with a specified UID has the permission to access system service APIs.
+
+
+
int CheckSelfPermission(const char *permissionName)
+
+
Checks whether the caller has the permission to access system service APIs.
+
+
+
int QueryPermission(const char *identifier, PermissionSaved **permissions, int *permNum)
+
+
Queries all permissions requested by the application and checks whether the requested permissions have been granted.
+
+
+
int GrantPermission(const char *identifier, const char *permName)
+
+
Grants a specified permission to the application.
+
+
+
int RevokePermission(const char *identifier, const char *permName)
+
+
Revokes a specified permission from the application.
+
+
+
int GrantRuntimePermission(int uid, const char *permissionName)
+
+
Grants a specified runtime permission to the application.
+
+
+
int RevokeRuntimePermission(int uid, const char *permissionName)
+
+
Revokes a specified runtime permission from the application.
+
+
+
+
+
+## How to Develop
+
+This section uses the BMS as an example to describe the application permission development. Before starting development, you need to declare the required sensitive permissions in the **config.json** file. During application installation, the BMS calls APIs of the application permission management component to check whether the required permissions have been granted. If yes, the installation proceeds; if not, the installation fails.
+
+1. Declare the required permission \(**ohos.permission.INSTALL\_BUNDLE**\) in the **config.json** file.
+
+ ```
+ {
+ ...
+ "module": {
+ "package": "com.huawei.kitframework",
+ "deviceType": [
+ "phone", "tv","tablet", "pc","car","smartWatch","sportsWatch","smartCamera", "smartVision"
+ ],
+ "reqPermissions": [{
+ // Declare the ohos.permission.INSTALL_BUNDLE permission required for installing the application.
+ "name": "ohos.permission.INSTALL_BUNDLE",
+ "reason": "install bundle",
+ "usedScene": {
+ "ability": [
+ "KitFramework"
+ ],
+ "when": "always"
+ }
+ },
+ {
+ "name": "ohos.permission.LISTEN_BUNDLE_CHANGE",
+ "reason": "install bundle",
+ "usedScene": {
+ "ability": [
+ "KitFramework"
+ ],
+ "when": "always"
+ }
+ },
+ {
+ "name": "ohos.permission.GET_BUNDLE_INFO",
+ "reason": "install bundle",
+ "usedScene": {
+ "ability": [
+ "KitFramework"
+ ],
+ "when": "always"
+ }
+ }
+ ],
+ ...
+ }
+ ```
+
+2. The BMS calls the corresponding API of the application permission management component \(for example, the **CheckPermission** function with **ohos.permission.INSTALL\_BUNDLE** as an input parameter\) to check whether the BMS has the permission to install the application. If yes, the installation proceeds; if not, the installation fails.
+
+ ```
+ constexpr static char PERMISSION_INSTALL_BUNDLE[] = "ohos.permission.INSTALL_BUNDLE";
+
+ bool Install(const char *hapPath, const InstallParam *installParam, InstallerCallback installerCallback)
+ {
+ if ((hapPath == nullptr) || (installerCallback == nullptr) || (installParam == nullptr)) {
+ HILOG_ERROR(HILOG_MODULE_APP, "BundleManager install failed due to nullptr parameters");
+ return false;
+ }
+ // Check whether the ohos.permission.INSTALL_BUNDLE permission has been granted.
+ if (CheckPermission(0, static_cast(PERMISSION_INSTALL_BUNDLE)) != GRANTED) {
+ HILOG_ERROR(HILOG_MODULE_APP, "BundleManager install failed due to permission denied");
+ return false; // Application installation fails.
+ }
+ // Application installation process
+ ...
+ }
+ ```
+
+
diff --git a/en/device-dev/subsystems/subsys-security-sigverify.md b/en/device-dev/subsystems/subsys-security-sigverify.md
new file mode 100644
index 0000000000000000000000000000000000000000..8436c859d8d7708e4fd34d08f786dc53a359db4f
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-security-sigverify.md
@@ -0,0 +1,272 @@
+# Development Guidelines on Application Signature Verification
+
+- [When to Use](#section18502174174019)
+- [Signature Verification Process](#section554632717226)
+- [Available APIs](#section1633115419401)
+- [Development Procedure \(Scenario 1\)](#section4207112818418)
+ - [Signature Verification](#section11470123816297)
+ - [OpenHarmony Self-signed Application Generation](#section167151429133312)
+ - [Development Examples](#section174318361353)
+
+- [Development Procedure \(Scenario 2\)](#section81272563427)
+ - [Signature Verification](#section07028210442)
+ - [Development Examples](#section1930711345445)
+
+- [Debugging and Verification](#section427316292411)
+
+## When to Use
+
+You can call the APIs provided by the signature verification component to check integrity of a debugging, released, or OpenHarmony self-signed application. You can also call APIs of the signature verification component to obtain some information in the profile, for example, **appid**. In addition, you can call APIs to check whether the UDID of a debugging application matches that of the device to ensure that the application is installed on the right device.
+
+## Signature Verification Process
+
+An unsigned HAP is in **.zip** format and consists of a file block, central directory, and end of central directory \(EOCD\).
+
+After the HAP is signed, a signature block is added between the file block and the central directory. The signature block consists of a file signature block, profile signature block, and signature header. The following figure shows the structure of a signed HAP.
+
+**Figure 1** Structure of a signed HAP
+
+
+
+
+The signature verification process consists of three steps: HAP signature verification, signature verification for the profile signature block, and profile content verification.
+
+**HAP signature verification**
+
+Use the preset root certificate of the device and the certificate chain to prove that the leaf certificate is trusted. Then use the digest obtained by decrypting the public key of the leaf certificate to prove that the HAP is not tampered with.
+
+The process is as follows:
+
+1. Use the preset root certificate of the device to verify the certificate chain in the file signature block and prove that the leaf certificate is trusted.
+2. Use the public key in the leaf certificate to verify the file signature block and prove that this block is not tampered with.
+3. Calculate and merge the digests of the file block, central directory, and EOCD. Merge the calculation result with the digest of the profile signature block in the signature block. Then compare the merge result with the digest of the file signature block. If they are the same, the HAP signature verification is successful.
+
+**Signature verification for the profile signature block**
+
+First of all, check who issued the signature of the profile signature block. If the signature was issued by the application market, the signature is trusted and does not need to be verified. Otherwise, the signature needs to be verified. Next, verify the certificate chain and then use the leaf certificate to verify the signature of the profile signature block to prove that it is not tampered with.
+
+**Profile content verification**
+
+Obtain the profile and check the validity of its content. If the HAP is a debugging application, check whether the UDID of the current device is contained in the UDID list in the profile. If yes, the verification is successful. Then compare the certificate in the profile with the leaf certificate used for HAP verification \(this is not required for a released or OpenHarmony self-signed application\). If they are the same, the entire signature verification process is complete.
+
+## Available APIs
+
+The following table lists the innerkits APIs provided by the signature verification component. These APIs are available only for system applications.
+
+**Table 1** APIs provided by the signature verification component
+
+
+
Function
+
+
Description
+
+
+
+
int APPVERI_AppVerify(const char *filePath, VerifyResult *verifyRst)
+
+
Verifies a signature by specifying the file path and returns the data obtained from the profile to the caller through verifyRst. This is the main entry function.
+
+
+
int APPVERI_SetDebugMode(bool mode)
+
+
Sets the debugging mode. If mode is set to true, certificate chain verification based on the debugging root key is enabled; if mode is set to false, it is disabled.
+
Note: Currently, no certificate based on the existing debugging root key is available. You can replace the debugging root key and perform related verification as required.
+
+## Development Procedure \(Scenario 1\)
+
+### Signature Verification
+
+To verify applications released in the application market, debugging applications signed with debugging certificates of the application market, and OpenHarmony self-signed applications, perform the following steps:
+
+1. Construct the VerifyResult structure.
+
+ ```
+ VerifyResult verifyResult = {0};
+ ```
+
+2. Call the APPVERI\_AppVerify function by specifying the file path and VerifyResult to verify the application signature.
+
+ ```
+ int32_t ret = APPVERI_AppVerify(hapFilepath.c_str(), &verifyResult);
+ ```
+
+3. Check the returned result. If the verification is successful, obtain and process the data in VerifyResult.
+
+ ```
+ signatureInfo.appId = verifyResult.profile.appid;
+ signatureInfo.provisionBundleName = verifyResult.profile.bundleInfo.bundleName;
+ ```
+
+4. Call the APPVERI\_FreeVerifyRst function to release memory in VerifyResult.
+
+ ```
+ APPVERI_FreeVerifyRst(&verifyResult);
+ ```
+
+
+### OpenHarmony Self-signed Application Generation
+
+The procedure is as follows:
+
+1. Prepare required materials.
+
+ Prepare the signature tool, system application HAP, system application profile \(\*.p7b\), signing certificate \(\*.cer\), and signing public/private key pair \(\*.jks\).
+
+2. Place all the materials in the same directory and start the shell.
+3. Run the following command in the shell to sign the application:
+
+ ```
+ 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
+ ```
+
+ Key fields:
+
+ **-jar**: signature tool, which is **[hapsigntool](https://repo.huaweicloud.com/harmonyos/develop_tools/hapsigntoolv2.jar)**
+
+ **-mode**: local signature flag, which is fixed at **localjks**
+
+ **-privatekey**: alias of the public/private key pair, which is **OpenHarmony Software Signature**
+
+ **-inputFile**: application to be signed, which is generated through compilation
+
+ **-outputFile**: signed application
+
+ **-signAlg**: signing algorithm, which is fixed at **SHA256withECDSA**
+
+ **-keystore**: public/private key pair, which is [OpenHarmony.jks](https://gitee.com/openharmony/security_appverify/blob/master/interfaces/innerkits/appverify_lite/OpenHarmonyCer/OpenHarmony.jks) in the **OpenHarmonyCer** directory of the **security\_services\_app\_verify** repository. The default password is **123456**. You can use a tool \(such as keytool\) to change the password.
+
+ **-keystorepasswd**: password of the public/private key pair, which is **123456** by default
+
+ **-keyaliaspasswd**: password of the public/private key pair alias, which is **123456** by default
+
+ **-profile**: application profile, which is stored in the code directory
+
+ **-certpath**: signing certificate, which is [OpenHarmony.cer](https://gitee.com/openharmony/security_appverify/blob/master/interfaces/innerkits/appverify_lite/OpenHarmonyCer/OpenHarmony.cer) in the **OpenHarmonyCer** directory of the **security\_services\_app\_verify** repository.
+
+ **-profileSigned**: whether the signature block contains the profile. The value is fixed at **1**, indicating that the signature block contains the profile.
+
+
+### Development Examples
+
+The following example describes how the application management framework component verifies the signature of an application during its installation.
+
+```
+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);
+ // Construct the VerifyResult structure.
+ VerifyResult verifyResult = {0};
+ // Verify the signature by specifying the file path.
+ int32_t ret = APPVERI_AppVerify(hapFilepath.c_str(), &verifyResult);
+ uint8_t errorCode = SwitchErrorCode(ret);
+ if (errorCode != ERR_OK) {
+ return errorCode;
+ }
+ // Obtain appid from the VerifyResult structure.
+ signatureInfo.appId = verifyResult.profile.appid;
+ // Obtain the application name written in the profile from the VerifyResult structure.
+ 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]);
+ }
+ // Release memory in VerifyResult.
+ APPVERI_FreeVerifyRst(&verifyResult);
+ return ERR_OK;
+}
+```
+
+## Development Procedure \(Scenario 2\)
+
+### Signature Verification
+
+To verify applications signed with certificates that are based on debugging root keys, perform the following steps:
+
+1. Call the APPVERI\_SetDebugMode\(true\) function to enable the debugging mode.
+
+ ```
+ 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. Construct the **VerifyResult** structure, verify the application signature, and release memory in **VerifyResult**.
+3. Call the APPVERI\_SetDebugMode\(false\) function to disable the debugging mode.
+
+ ```
+ ManagerService::SetDebugMode(false);
+ ```
+
+
+### Development Examples
+
+The following is the example code \(supplemented based on the example code for scenario 1\):
+
+```
+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)
+{
+ // Enable debugging mode.
+ ManagerService::SetDebugMode(true);
+ bool mode = ManagerService::GetInstance().IsDebugMode();
+ HILOG_INFO(HILOG_MODULE_APP, "current mode is %d!", mode);
+ // Construct the VerifyResult structure.
+ VerifyResult verifyResult = {0};
+ // Verify the signature by specifying the file path.
+ int32_t ret = APPVERI_AppVerify(hapFilepath.c_str(), &verifyResult);
+ uint8_t errorCode = SwitchErrorCode(ret);
+ if (errorCode != ERR_OK) {
+ return errorCode;
+ }
+ // Obtain appid from the VerifyResult structure.
+ signatureInfo.appId = verifyResult.profile.appid;
+ // Obtain the application name written in the profile from the VerifyResult structure.
+ 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]);
+ }
+ // Release memory in VerifyResult.
+ APPVERI_FreeVerifyRst(&verifyResult);
+ // Disable debugging mode.
+ ManagerService::SetDebugMode(false);
+ return ERR_OK;
+}
+```
+
+## Debugging and Verification
+
+1. Choose an application that can be properly installed on OpenHarmony.
+2. Develop the application based on the development guidelines.
+3. Use a self-developed program to verify the signature of the developed application. If the verification is successful and **appid** can be obtained, the development is successful.
+
diff --git a/en/device-dev/subsystems/subsys-security.md b/en/device-dev/subsystems/subsys-security.md
new file mode 100644
index 0000000000000000000000000000000000000000..b4ac9422314e3dcc450be62ed8ad0a2b1328bff5
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-security.md
@@ -0,0 +1,11 @@
+# Security
+
+- **[Overview](subsys-security-overview.md)**
+
+- **[Development Guidelines on Application Signature Verification](subsys-security-sigverify.md)**
+
+- **[Development Guidelines on Application Permission Management](subsys-security-rightmanagement.md)**
+
+- **[Development Guidelines on IPC Authentication](subsys-security-communicationverify.md)**
+
+
diff --git a/en/device-dev/subsystems/subsys-testguide-test.md b/en/device-dev/subsystems/subsys-testguide-test.md
new file mode 100644
index 0000000000000000000000000000000000000000..215b683bd1ccb771b45c32a5256989b67af595ae
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-testguide-test.md
@@ -0,0 +1,987 @@
+# Testing
+
+- [Overview](#section12403172115920)
+ - [Basic Concepts](#section53632272090)
+ - [Working Principles](#section2394431106)
+
+- [Limitations and Constraints](#section2029921310472)
+- [Setting Up a Test Environment](#section175012297491)
+ - [Environment Requirements](#section935055691014)
+ - [Installing the Environment](#section6511193210111)
+ - [Verifying the Test Environment](#section1899144517117)
+
+- [Development Guidelines](#section16741101301210)
+ - [When to Use](#section93782214124)
+ - [Available APIs](#section54131732101218)
+ - [How to Develop](#section53541946111218)
+
+- [Development Example](#section7477121918136)
+- [How to Use the Test Platform](#section76401945124810)
+- [Directory Structure](#section1875515364133)
+
+## Overview
+
+### Basic Concepts
+
+The testing subsystem provides a one-click Python-based self-test platform for developers. It supports cross-platform tests and extension to third-party testing frameworks. The subsystem consists of modules for compiling, managing, scheduling and distributing, and executing test cases, collecting test results, generating test reports, creating test case templates, managing test environments, and many others.
+
+Before development using the testing subsystem, you need to understand the following concepts:
+
+- Test case compilation
+
+ This operation compiles the source code of test cases into binary files that can be executed on the tested device.
+
+- Test case scheduling & distributing
+
+ This operation distributes test cases to different tested devices through the network port or serial port, and allocates a specific executor for each test case.
+
+- Test case executor
+
+ A test case executor defines the execution logic of each test case, such as its pre-processing, execution, and result recording.
+
+- Test case template
+
+ A test case template defines respective unified formats for test cases and for GN files.
+
+- Test platform kits
+
+ The test platform provides common methods to be used during the running of the test tool, for example, providing the test case directory to mount the file system to a tested device, distributing test cases to the tested device, or obtaining test results from the tested device.
+
+- Test report generation
+
+ This operation defines a template for generating self-test reports and web test reports.
+
+- Test environment management
+
+ The tested devices can be managed through the USB port or serial port, including discovering a device and querying the device status.
+
+
+### Working Principles
+
+- The following figure shows the architecture of the test platform.
+
+**Figure 1** Platform architecture
+
+
+- The following figure shows the running sequence diagram of the test platform.
+
+**Figure 2** Running sequence of the test platform
+
+
+- Working principle of the test platform
+
+The test platform is started using a shell script. It executes a series of testing commands entered on the command line interface \(CLI\) and prints the command output.
+
+## Limitations and Constraints
+
+- The self-test platform supports only code-level test case development and verification, such as unit testing and module testing.
+- Currently, the testing framework supports only white-box testing.
+- Only one test platform can be started on a testing device.
+
+## Setting Up a Test Environment
+
+### Environment Requirements
+
+**Table 1** Environment requirements
+
+
+
Item
+
+
Testing Device
+
+
Tested Device
+
+
+
+
Hardware
+
+
Memory: 8 GB or above
Hard disk space: 100 GB or above
Hardware architecture: x86 or ARM64
+
+
Hi3516D V300 development board
Hi3518E V300 development board
+
+
+
Software
+
+
OS: Windows 10 (64-bit) or Ubuntu 18.04
System component (Linux): libreadline-dev
+
Python: 3.7.5 or later
Python plug-ins: pySerial 3.3 or later, Paramiko 2.7.1 or later, Setuptools 40.8.0 or later, and RSA 4.0 or later
NFS server: haneWIN NFS Server 1.2.50 or later, or NFSv4 or later
+
+
OS: OpenHarmony 1.0 or later
Kernel: LiteOS Cortex-A or Linux kernel
+
+
+
+
+
+### Installing the Environment
+
+1. \(Optional\) If the test environment runs Linux, run the following command to install system component Readline:
+
+ ```
+ sudo apt-get install libreadline-dev
+ ```
+
+ If the installation is successful, the following prompts are displayed:
+
+ ```
+ Reading package lists... Done
+ Building dependency tree
+ Reading state information... Done
+ libreadline-dev is already the newest version (7.0-3).
+ 0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
+ ```
+
+2. Install Python extension plug-ins Setuptools. Install RSA, Paramiko, and pySerial if the device supports the serial port only.
+
+ 1. Run the following command to install Setuptools:
+
+ ```
+ pip install setuptools
+ ```
+
+ If the installation is successful, the following prompts are displayed:
+
+ ```
+ Requirement already satisfied: setuptools in d:\programs\python37\lib\site-packages (41.2.0)
+ ```
+
+ 2. Run the following command to install RSA:
+
+ ```
+ pip install rsa
+ ```
+
+ If the installation is successful, the following prompts are displayed:
+
+ ```
+ Installing collected packages: pyasn1, rsa
+ Successfully installed pyasn1-0.4.8 rsa-4.7
+ ```
+
+ 3. Run the following command to install Paramiko:
+
+ ```
+ pip install paramiko
+ ```
+
+ If the installation is successful, the following prompts are displayed:
+
+ ```
+ Installing collected packages: pycparser, cffi, pynacl, bcrypt, cryptography, paramiko
+ Successfully installed bcrypt-3.2.0 cffi-1.14.4 cryptography-3.3.1 paramiko-2.7.2 pycparser-2.20 pynacl-1.4.0
+ ```
+
+ 4. \(Optional\) Run the following command to install pySerial. This step is mandatory for tested devices that support serial ports only.
+
+ ```
+ pip install pyserial
+ ```
+
+ If the installation is successful, the following prompts are displayed:
+
+ ```
+ Requirement already satisfied: pyserial in d:\programs\python37\lib\site-packages\pyserial-3.4-py3.7.egg (3.4)
+ ```
+
+3. \(Optional\) Install the NFS server. This step is mandatory for tested devices that support serial ports only.
+
+ **Windows OS**
+
+ Download and install **haneWIN NFS Server 1.2.50** at https://www.hanewin.net/nfs-e.htm.
+
+ **Linux OS**
+
+ ```
+ sudo apt install nfs-kernel-server
+ ```
+
+ After the environment is installed, you can conduct coding and debugging for a test platform in an integrated development environment \(IDE\) \(DevEco Studio is recommended\).
+
+
+### Verifying the Test Environment
+
+**Table 2** Environment verification
+
+
+
Item
+
+
Operation
+
+
Requirement
+
+
+
+
Check that a compliant Python version has been installed.
+
+
Run the python --version command.
+
+
The Python version must be 3.7.5 or later.
+
+
+
Check that Python extension plug-ins have been installed.
+
+
Access the test/xdevice directory and run run.bat or run.sh.
+
+
The >>> prompt is displayed.
+
+
+
Check that the NFS server has been started (for tested devices that support serial ports only).
+
+
Log in to the development board through the serial port and run the mount command to mount the NFS server.
+
+
The file directory can be mounted properly.
+
+
+
+
+
+## Development Guidelines
+
+### When to Use
+
+You can call the APIs to conduct white box tests of service code.
+
+### Available APIs
+
+The testing framework integrates the open-source unit testing framework and expands the macros of the test cases. For details about the framework, see the official open-source documentation.
+
+**Table 3** Expanded macros of the framework
+
+
+
Macro
+
+
Description
+
+
+
+
HWTEST
+
+
The execution of test cases does not rely on setup and teardown execution. Based on the TEST macro, this macro has added the TestSize.Level1 parameter to specify the test case level, for example, HWTEST(CalculatorAddTest, TestPoint_001, TestSize.Level1).
+
+
+
HWTEST_F
+
+
The execution of test cases (without parameters) depends on setup and teardown execution. Based on the TEST_F macro, this macro has added the TestSize.Level1 parameter to specify the test case level, for example, HWTEST_F(CalculatorAddTest, TestPoint_001, TestSize.Level1).
+
+
+
HWTEST_P
+
+
The execution of test cases (with parameters) depends on setup and teardown execution. Based on the TEST_P macro, this macro has added the TestSize.Level1 parameter to specify the test case level, for example, HWTEST_P(CalculatorAddTest, TestPoint_001, TestSize.Level1).
+
+
+
+
+
+### How to Develop
+
+1. Define a test suite file based on the test case directory, for example, **test/developertest/examples/lite/cxx\_demo/test/unittest/common/calc\_subtraction\_test.cpp**. The class in this test suite should be inherited from the **testing::Test** class and named in the format of "_Tested feature_\_**Test**".
+
+ ```
+ /*
+ * Copyright (c) 2020 OpenHarmony.
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+ #include
+
+ using namespace std;
+ using namespace testing::ext;
+
+ class CalcSubtractionTest : public testing::Test {
+ public:
+ static void SetUpTestCase(void);
+ static void TearDownTestCase(void);
+ void SetUp();
+ void TearDown();
+ };
+ ```
+
+ > **NOTE:**
+ >You must write test cases by observing the following specifications:
+ >- Naming
+ > The source file name of a test case must be consistent with the test suite content. Each test suite has multiple test cases and a test source file that is globally unique and named in \[Feature\]\_\[Function\]\_\[Subfunction 1\]\_\[Subfunction 1.1\] format \(subfunctions can be further divided\).
+ > The file name can contain only lower-case letters and underscores \(\_\) and must end with **test**, for example, **developertest/examples/lite/cxx\_demo**.
+ >- Coding
+ > The test cases must comply with the coding specifications for feature code. In addition, case descriptions are required for further clarification. For details, see [Test case template](#li2069415903917).
+ >- Compilation and configuration
+ > The test cases must be compiled using GN, and the configurations must comply with the compilation guide of this open-source project. For details, see [Compilation and Building Subsystem - Lightweight and Small-Scale Systems](subsys-build-mini-lite.md).
+ >- Test case template
+ > For details, see the example test case **developertest/examples/lite/cxx\_demo/test/unittest/common/calc\_subtraction\_test.cpp**.
+
+2. Implement the preprocessing \(via the **SetUp** function\) and postprocessing \(via the **TearDown** function\) operations required by the execution of the test suite.
+
+ ```
+ void CalcSubtractionTest::SetUpTestCase(void)
+ {
+ // step 1: input testsuite setup step
+ }
+
+ void CalcSubtractionTest::TearDownTestCase(void)
+ {
+ // step 2: input testsuite teardown step
+ }
+
+ void CalcSubtractionTest::SetUp(void)
+ {
+ // step 3: input testcase setup step
+ }
+
+ void CalcSubtractionTest::TearDown(void)
+ {
+ // step 4: input testcase teardown step
+ }
+ ```
+
+3. Compile a test case based on the feature to be tested. The following code uses **HWTEST\_F** as an example:
+
+ ```
+ /**
+ * @tc.name: integer_sub_001
+ * @tc.desc: Test Calculator
+ * @tc.type: FUNC
+ * @tc.require: AR00000000 SR00000000
+ */
+ HWTEST_F(CalcSubtractionTest, integer_sub_001, TestSize.Level1)
+ {
+ EXPECT_EQ(0, Subtraction(1, 0));
+ }
+ ```
+
+ > **NOTE:**
+ >- **@tc.name**: test case name, which briefly describes the test purpose
+ >- **@tc.desc**: detailed description of the test case, including the test purpose, test procedure, and expected result
+ >- **@tc.type**: test type, which can be **FUNC**, **PERF**, **SECU**, or **RELI**.
+ >- **@tc.require**: requirement ID or issue ID, which is used to associate the modification with the test case
+
+
+
SN
+
+
Test Type
+
+
Code
+
+
Description
+
+
+
+
1
+
+
Functionality test
+
+
FUNC
+
+
Verifies that each functionality of the software complies with the function design and specifications.
+
+
+
2
+
+
Performance test
+
+
PERF
+
+
Verifies that the software meets the performance requirements. Performance tests include load tests, capacitance tests, and pressure tests.
+
+
+
3
+
+
Security test
+
+
SECU
+
+
Verifies that the software complies with security requirements and related laws and regulations within the software lifecycle.
+
+
+
4
+
+
Reliability test
+
+
RELI
+
+
Verifies the probability that the software does not cause system failures within a specified period of time and under given conditions. Software stability is also involved in the test.
+
+
+
+
+
+4. Compile the GN file of the test case, including defining the compilation target, adding compilation dependencies, and setting the source file.
+
+ Example file path: **test/developertest/examples/lite/cxx\_demo/test/unittest/common/BUILD.gn**
+
+ ```
+ import("//build/lite/config/test.gni")
+
+ unittest("CalcSubTest") {
+ output_extension = "bin"
+ sources = [
+ "calc_subtraction_test.cpp"
+ ]
+ include_dirs = []
+ deps = []
+ }
+ ```
+
+5. Add the compilation target to the subsystem compilation configuration to ensure that the test case is compiled with the version distribution. The following is an example:
+ 1. For devices that support connection to the Harmony device connector \(hdc\), the example compilation configuration directory is **test/developertest/examples/ohos.build**.
+
+ ```
+ {
+ "subsystem": "subsystem_examples",
+ "parts": {
+ "subsystem_examples": {
+ "module_list": [
+ "//test/developertest/examples/detector:detector",
+ ...
+ ],
+ "test_list": [
+ "//test/developertest/examples/detector/test:unittest",
+ ...
+ ]
+ },
+ ...
+ }
+ ```
+
+ 2. For devices that support serial ports only, the example compilation configuration directory is **test/developertest/examples/lite/BUILD.gn**.
+
+ ```
+ import("//build/lite/config/test.gni")
+
+ subsystem_test("test") {
+ test_components = []
+ if(ohos_kernel_type == "liteos_riscv") {
+ features += [
+ ]
+ }else if(ohos_kernel_type == "liteos_a") {
+ test_components += [
+ "//test/developertest/examples/lite/cxx_demo/test/unittest/common:CalcSubTest"
+ ]
+ }
+ }
+ ```
+
+
+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.
+ 3. Create a folder named after the module in the device type directory, for example, **testmodule**.
+ 4. Create the **ohos\_test.xml** file in the folder named after the module. The file content is in the following format:
+
+ ```
+
+
+
+
+
+
+
+
+ ```
+
+ 5. Define **resource\_config\_file** in the compilation configuration file of the test case to specify the resource file **ohos\_test.xml**.
+
+ > **NOTE:**
+ >The resource file is used to push the **test.txt** file in the **resource** directory to the **/data/test/resource** directory of the device to test. To do so, run the **hdc push** command.
+
+
+7. Execute the test case after it is compiled \(the preceding steps are complete\).
+
+ > **NOTE:**
+ >- For devices that support connection to the hdc, test cases can be compiled separately.
+ >- For devices that support serial ports only, to compile the test case, run the commands in the root directory for compiling the debug code.
+ > For details about how to execute a test case, see [How to Use the Test Platform](#section76401945124810).
+
+
+## Development Example
+
+The code repository of the testing subsystem provides complete demo cases, which are available in the **test/developertest/examples/** directory. The following is an example of compiling a test case for a subtraction function:
+
+- The tested code is as follows:
+
+ ```
+ static int Subtraction(int a, int b)
+ {
+ return a - b;
+ }
+ ```
+
+- The test case code is as follows:
+
+ ```
+ /**
+ * @tc.name: integer_sub_002
+ * @tc.desc: Verify the Subtraction function.
+ * @tc.type: FUNC
+ * @tc.require: AR00000000 SR00000000
+ */
+ HWTEST_F(CalcSubtractionTest, integer_sub_002, TestSize.Level1)
+ {
+ EXPECT_EQ(1, Subtraction(2, 1));
+ }
+ ```
+
+
+## How to Use the Test Platform
+
+1. \(Optional\) Install the XDevice component. XDevice can be used as a Python extension package.
+
+ Go to the installation directory **test/xdevice** and run the following command:
+
+ ```
+ python setup.py install
+ ```
+
+ If the installation is successful, the following prompts are displayed:
+
+ ```
+ ...
+ Installed d:\programs\python37\lib\site-packages\xdevice-0.0.0-py3.7.egg
+ Processing dependencies for xdevice==0.0.0
+ Searching for pyserial==3.4
+ Best match: pyserial 3.4
+ Processing pyserial-3.4-py3.7.egg
+ pyserial 3.4 is already the active version in easy-install.pth
+ Installing miniterm.py script to D:\Programs\Python37\Scripts
+
+ Using d:\programs\python37\lib\site-packages\pyserial-3.4-py3.7.egg
+ Finished processing dependencies for xdevice==0.0.0
+ ```
+
+2. Modify the **developertest/config/user\_config.xml** file to configure the Developertest component.
+ 1. Modify basic configuration parameters.
+
+ \[build\] \# Set build parameters of the test case.
+
+ ```
+
+ false
+ false
+ true
+ ... ...
+
+ ```
+
+ > **NOTE:**
+ >**example**: whether to build the test case example. The default value is **false**.
+ >**version**: whether to build the test version. The default value is **false**.
+ >**testcase**: whether to build the test case. The default value is **true**.
+
+ 2. For devices that support connection to the hdc, modify the configuration file as follows:
+
+ Between the **device** tags with the **"usb-hdc"** attribute, modify the IP address of the device and the port number matching the HDC connection. For example:
+
+ ```
+
+ 192.168.1.1
+ 9111
+
+
+ ```
+
+ 3. For devices that support serial ports only, modify the configuration file as follows:
+
+ \[board\_info\] \# Configure development board information.
+
+ ```
+
+ hispark
+ taurus
+ ipcamera
+ hb build
+
+ ```
+
+ > **NOTE:**
+ >**board\_series**: development board series. The default value is **hispark**.
+ >**board\_type**: development board type. The default value is **taurus**.
+ >**board\_product**: target product. The default value is **ipcamera**.
+ >**build\_command**: command used for building the test version and test case. The default value is **hb build**.
+
+ Between the **device** tags with the **"ipcamera"** attribute, modify the serial port information, including the COM port and baud rate. For example:
+
+ ```
+
+
+ COM1
+ cmd
+ 115200
+ 8
+ 1
+ 1
+
+
+ ```
+
+
+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.
+
+ 1. Specify the output path of the test case, that is, the compilation output directory between the **test\_cases** tags. Example:
+
+ ```
+
+ /home/opencode/out/release/tests
+
+ ```
+
+ 2. For devices that support serial ports only, specify the NFS directory on the PC \(**host\_dir**\) and the corresponding directory on the board \(**board\_dir**\) between the **NFS** tags. For example:
+
+ ```
+
+ D:\nfs
+ user
+
+ ```
+
+
+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.
+ - IP addresses of the development host and development board are in the same network segment and can ping each other.
+ - An empty directory has been created on the development host for mounting test cases through NFS, and the NFS service has been started properly.
+
+5. Start the test platform and execute the test case.
+ - Start the test framework, go to the **test/developertest** directory, and execute the startup script.
+ 1. Run the following command to start the test framework in Windows:
+
+ ```
+ start.bat
+ ```
+
+ 2. Run the following command to start the test framework in Linux:
+
+ ```
+ ./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
+ show typelist Query the supported test type
+ 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]
+ [-tc TESTCASE] [-tl TESTLEVEL]
+
+ Optional arguments:
+ -h, --help Show this help message and exit.
+ -p PRODUCTFORM, --productform PRODUCTFORM Specified product form
+ -t [TESTTYPE [TESTTYPE ...]], --testtype [TESTTYPE [TESTTYPE ...]]
+ Specify test type(UT,MST,ST,PERF,ALL)
+ -ss SUBSYSTEM, --subsystem SUBSYSTEM Specify test subsystem
+ -tm TESTMODULE, --testmodule TESTMODULE Specified test module
+ -ts TESTSUIT, --testsuite TESTSUIT Specify test suite
+ -tc TESTCASE, --testcase TESTCASE Specify test case
+ -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:
+
+ ```
+ reports/xxxx-xx-xx-xx-xx-xx
+ ```
+
+ - The test case formatting result is stored in the following directory:
+
+ ```
+ result/
+ ```
+
+ - The test logs are stored in the following directory:
+
+ ```
+ log/plan_log_xxxx-xx-xx-xx-xx-xx.log
+ ```
+
+ - The report summary file is as follows:
+
+ ```
+ summary_report.html
+ ```
+
+ - The report details file is as follows:
+
+ ```
+ details_report.html
+ ```
+
+
+ - The log directory of the test platform is as follows:
+
+ ```
+ reports/platform_log_xxxx-xx-xx-xx-xx-xx.log
+ ```
+
+
+
+## Directory Structure
+
+The source code of XDevice is stored in the **test/xdevice** directory. The following table describes the **xdevice** directory structure.
+
+**Table 4** XDevice structure
+
+
+
Directory
+
+
Description
+
+
+
+
xdevice
+
+
Basic components of the test platform
+
+
+
xdevice/src/xdevice
+
+
Source code for the basic test framework
+
+
+
xdevice/config
+
+
Configuration file of the basic test framework
+
+
+
xdevice/src/xdevice/__main__.py
+
+
Internal entrance to the basic test framework
+
+
+
xdevice/src/xdevice/__init__.py
+
+
Package and plug-in dependencies
+
+
+
xdevice/src/xdevice/variables.py
+
+
Global variables
+
+
+
xdevice/src/xdevice/_core/command
+
+
Commands input by test cases
+
+
+
xdevice/src/xdevice/_core/config
+
+
Configuration management of the basic test framework
+
+
+
xdevice/src/xdevice/_core/environment
+
+
Environment management of the basic test framework, including device management
+
+
+
xdevice/src/xdevice/_core/executor
+
+
Scheduling and distribution of test cases
+
+
+
xdevice/src/xdevice/_core/driver
+
+
Test executor for the basic test framework
+
+
+
xdevice/src/xdevice/_core/resource
+
+
Resource files and test report templates for the basic test framework
+
+
+
xdevice/src/xdevice/_core/testkit
+
+
Common operations for the basic test framework, including NFS mounting
+
+
+
xdevice/src/xdevice/_core/logger.py
+
+
Log management of the basic test framework
+
+
+
xdevice/src/xdevice/_core/plugin.py
+
+
Plug-in management of the basic test framework
+
+
+
xdevice/src/xdevice/_core/interface.py
+
+
Interfaces for plug-ins of the basic test framework
+
+
+
xdevice/setup.py
+
+
Installation script of the basic test framework
+
+
+
xdevice/run.bat
+
+
Startup script of the basic test framework (Windows)
+
+
+
xdevice/run.sh
+
+
Startup script of the basic test framework (Linux)
+
+
+
+
+
+The source code of Developertest is stored in the **test/developertest** directory. The following table describes the **developertest** directory structure.
+
+**Table 5** Developertest structure
+
+
+
Directory
+
+
Description
+
+
+
+
developertest
+
+
Development test framework
+
+
+
developertest/src
+
+
Test framework source code
+
+
+
developertest/src/core
+
+
Test executor
+
+
+
developertest/src/core/build
+
+
Test case compilation
+
+
+
developertest/src/core/command
+
+
Processing of command lines entered by users
+
+
+
developertest/src/core/config
+
+
Test framework configuration management
+
+
+
developertest/src/core/driver
+
+
Test framework driver executor
+
+
+
developertest/src/core/resource
+
+
Test framework configuration file
+
+
+
developertest/src/core/testcase
+
+
Test case management
+
+
+
developertest/src/core/common.py
+
+
Common operations on the test framework
+
+
+
developertest/src/core/constants.py
+
+
Global constants of the test framework
+
+
+
developertest/src/core/exception.py
+
+
Test framework exceptions
+
+
+
developertest/src/core/utils.py
+
+
Test framework tools and methods
+
+
+
developertest/src/main
+
+
Test framework platform
+
+
+
developertest/src/main/__main__.py
+
+
Internal entrance of the test framework
+
+
+
developertest/examples
+
+
Test framework demo cases
+
+
+
developertest/third_party
+
+
Third-party components
+
+
+
developertest/BUILD.gn
+
+
Compilation configuration of the subsystem
+
+
+
developertest/start.bat
+
+
Developer test entry (Windows)
+
+
+
developertest/start.sh
+
+
Developer test entry (Linux)
+
+
+
+
+
diff --git a/en/device-dev/subsystems/subsys-toolchain-bytrace-guide.md b/en/device-dev/subsystems/subsys-toolchain-bytrace-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..e6ddd00929d2f6b6bd378701f31ea1b756de3a9e
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-toolchain-bytrace-guide.md
@@ -0,0 +1,115 @@
+# bytrace Usage Guidelines
+
+- [Overview](#section11388623181619)
+- [How to Develop](#section1595564317164)
+- [Usage Example](#section667273201818)
+
+## Overview
+
+bytrace is a tool for you to trace processes and analyze performance. It encapsulates and extends the kernel ftrace and supports event tracking in the user space. With bytrace, you can open a user-space or kernel-space label you want to view \(run the **bytrace -l** command to query all the supported labels\) and run the **--trace\_begin** and **-o filename** \(or **--output filename**\) commands to capture traces and dump them to a specified file.
+
+## How to Develop
+
+bytrace supports the following commands:
+
+**Table 1** Commands
+
+
+
Option
+
+
Description
+
+
+
+
-h, --help
+
+
Views the help text for bytrace.
+
+
+
-b n, --buffer_size n
+
+
Sets the size of the buffer (KB) for storing and reading traces. The default buffer size is 2048 KB.
+
+
+
-t n, --time n
+
+
Sets the bytrace uptime in seconds, which depends on the time required for analysis.
+
+
+
--trace_clock clock
+
+
Sets the type of the clock for adding a timestamp to a trace, which can be boot (default), global, mono, uptime, or perf.
+
+
+
--trace_begin
+
+
Starts capturing traces.
+
+
+
--trace_dump
+
+
Dumps traces to a specified position (console where you run this command by default).
+
+
+
--trace_finish
+
+
Stops capturing traces and dumps traces to a specified position (console where you run this command by default).
+
+
+
-l, --list_categories
+
+
Lists the bytrace categories supported by the device.
+
+
+
--overwrite
+
+
Sets the action to take when the buffer is full. If this option is used, the latest traces are discarded; if this option is not used, the earliest traces are discarded (default).
+
+
+
-o filename, --output filename
+
+
Outputs traces to a specified file.
+
+
+
-z
+
+
Compresses a captured trace.
+
+
+
+
+
+## Usage Example
+
+The following are some examples of bytrace commands:
+
+- Run the following command to query supported labels:
+
+```
+bytrace -l
+```
+
+Alternatively, you can run the following command:
+
+```
+bytrace --list_categories
+```
+
+- Run the following command to capture traces whose label is ability, with the buffer size set to 4096 KB and bytrace uptime set to 10s:
+
+```
+bytrace -b 4096 -t 10 --overwrite ability > /data/mytrace.ftrace
+```
+
+- Run the following command to set the clock type for traces to **mono**:
+
+```
+bytrace --trace_clock mono -b 4096 -t 10 --overwrite ability > /data/mytrace.ftrace
+```
+
+- Run the following command to compress the captured trace:
+
+```
+bytrace -z -b 4096 -t 10 --overwrite ability > /data/mytrace.ftrace
+```
+
diff --git a/en/device-dev/subsystems/subsys-toolchain.md b/en/device-dev/subsystems/subsys-toolchain.md
new file mode 100644
index 0000000000000000000000000000000000000000..29f4d588550d44b6260b133f5df92fb29be79db2
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-toolchain.md
@@ -0,0 +1,6 @@
+# R&D Tools
+
+- [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-utils.md b/en/device-dev/subsystems/subsys-utils.md
new file mode 100644
index 0000000000000000000000000000000000000000..53ee39995f7021e3f563ee7cc6ceb08a2353f247
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-utils.md
@@ -0,0 +1,9 @@
+# Utils
+
+- **[Utils Overview](oem_subsys_utils_des.md)**
+
+- **[Utils Development Guidelines](oem_subsys_utils_guide.md)**
+
+- **[Utils FAQ](oem_subsys_utils_faq.md)**
+
+
diff --git a/en/device-dev/subsystems/subsys-xts-guide.md b/en/device-dev/subsystems/subsys-xts-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..8c39f59591f073526f2b2f269e93e5a724fa48cc
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-xts-guide.md
@@ -0,0 +1,716 @@
+# XTS
+
+- [Introduction](#section465982318513)
+- [System Types](#section125090457443)
+- [Directory Structure](#section161941989596)
+- [Constraints](#section119744591305)
+- [Usage Guidelines](#section137768191623)
+- [Test Case Development Guidelines](#section3695134065513)
+ - [C-based Test Case Development and Compilation \(for the Mini System\)](#section198193336544)
+ - [C-based Test Case Execution \(for the Mini System\)](#section13820233175418)
+ - [C++-based Test Case Development and Compilation \(for Standard and Small Systems\)](#section3822123311540)
+ - [C++-based Test Case Execution \(for Standard and Small Systems\)](#section128222336544)
+ - [JavaScript-based Test Case Development \(for the Standard System\)](#section159801435165220)
+ - [JavaScript-based Test Case Packaging \(for the Standard System\)](#section445519106559)
+ - [\#EN-US\_TOPIC\_0000001126156429/section191521423950](#section191521423950)
+
+- [Full Compilation Guide \(for the Standard System\)](#section1519992743415)
+- [Full Test Case Execution Guide \(for Small and Standard Systems\)](#section118149111426)
+
+## Introduction
+
+The X test suite \(XTS\) subsystem contains a set of OpenHarmony certification test suites, including the currently supported application compatibility test suite \(ACTS\) and the device compatibility test suite \(DCTS\) that will be supported in the future.
+
+This subsystem contains the ACTS and **tools** software package.
+
+- The **acts** directory stores the source code and configuration files of ACTS test cases. The ACTS helps device vendors detect the software incompatibility as early as possible and ensures that the software is compatible to OpenHarmony during the entire development process.
+- The **tools** software package stores the test case development framework related to **acts**.
+
+## System Types
+
+OpenHarmony supports the following system types:
+
+- Mini system
+
+ A mini system runs on the devices whose memory is greater than or equal to 128 KiB and that are equipped with MCU processors such as ARM Cortex-M and 32-bit RISC-V. This system provides multiple lightweight network protocols and graphics frameworks, and a wide range of read/write components for the IoT bus. Typical products include connection modules, sensors, and wearables for smart home.
+
+- Small system
+
+ A small system runs on the devices whose memory is greater than or equal to 1 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides higher security capabilities, standard graphics frameworks, and video encoding and decoding capabilities. Typical products include smart home IP cameras, electronic cat eyes, and routers, and event data recorders \(EDRs\) for smart travel.
+
+- Standard system
+
+ A standard system runs on the devices whose memory is greater than or equal to 128 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides a complete application framework supporting the enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. This system applies to high-end refrigerator displays.
+
+
+## Directory Structure
+
+```
+/test/xts
+├── acts # Test code
+│ └── subsystem # Source code of subsystem test cases for the standard system
+│ └── subsystem_lite # Source code of subsystems test cases for mini and small systems
+│ └── BUILD.gn # Build configuration of test cases for the standard system
+│ └── build_lite
+│ └── BUILD.gn # Build configuration of test cases for mini and small systems
+└── tools # Test tool code
+```
+
+## Constraints
+
+Test cases for the mini system must be developed based on C, and those for the small system must be developed based on C++.
+
+## Usage Guidelines
+
+**Table 1** Test case levels
+
+
+
Level
+
+
Definition
+
+
Scope
+
+
+
+
Level0
+
+
Smoke
+
+
Verifies basic functionalities of key features and basic DFX attributes with the most common input. The pass result indicates that the features are runnable.
+
+
+
Level1
+
+
Basic
+
+
Verifies basic functionalities of key features and basic DFX attributes with common input. The pass result indicates that the features are testable.
+
+
+
Level2
+
+
Major
+
+
Verifies basic functionalities of key features and basic DFX attributes with common input and errors. The pass result indicates that the features are functional and ready for beta testing.
+
+
+
Level3
+
+
Regular
+
+
Verifies functionalities of all key features, and all DFX attributes with common and uncommon input combinations or normal and abnormal preset conditions.
+
+
+
Level4
+
+
Rare
+
+
Verifies functionalities of key features under extremely abnormal presets and uncommon input combinations.
+
+
+
+
+
+**Table 2** Test case granularities
+
+
+
Test Scale
+
+
Test Objects
+
+
Test Environment
+
+
+
+
LargeTest
+
+
Service functionalities, all-scenario features, and mechanical power environment (MPE) and scenario-level DFX
+
+
Devices close to real devices
+
+
+
MediumTest
+
+
Modules, subsystem functionalities after module integration, and DFX
+
+
Single device that is actually used. You can perform message simulation, but do not mock functions.
+
+
+
SmallTest
+
+
Modules, classes, and functions
+
+
Local PC. Use a large number of mocks to replace dependencies with other modules.
+
+
+
+
+
+**Table 3** Test types
+
+
+
Type
+
+
Definition
+
+
+
+
Function
+
+
Tests the correctness of both service and platform functionalities provided by the tested object for end users or developers.
+
+
+
Performance
+
+
Tests the processing capability of the tested object under specific preset conditions and load models. The processing capability is measured by the service volume that can be processed in a unit time, for example, call per second, frame per second, or event processing volume per second.
+
+
+
Power
+
+
Tests the power consumption of the tested object in a certain period of time under specific preset conditions and load models.
+
+
+
Reliability
+
+
Tests the service performance of the tested object under common and uncommon input conditions, or specified service volume pressure and long-term continuous running pressure. The test covers stability, pressure handling, fault injection, and Monkey test times.
+
+
+
Security
+
+
Tests the capability of defending against security threats, including but not limited to unauthorized access, use, disclosure, damage, modification, and destruction, to ensure information confidentiality, integrity, and availability.
Tests the privacy protection capability to ensure that the collection, use, retention, disclosure, and disposal of users' private data comply with laws and regulations.
Tests the compliance with various security specifications, such as security design, security requirements, and security certification of the Ministry of Industry and Information Technology (MIIT).
+
+
+
Global
+
+
Tests the internationalized data and localization capabilities of the tested object, including multi-language display, various input/output habits, time formats, and regional features, such as currency, time, and culture taboos.
+
+
+
Compatibility
+
+
Tests backward compatibility of an application with its own data, the forward and backward compatibility with the system, and the compatibility with different user data, such as audio file content of the player and smart SMS messages.
Tests system backward compatibility with its own data and the compatibility of common applications in the ecosystem.
Tests software compatibility with related hardware.
+
+
+
User
+
+
Tests user experience of the object in real user scenarios. All conclusions and comments should come from the users, which are all subjective evaluation in this case.
+
+
+
Standard
+
+
Tests the compliance with industry and company-specific standards, protocols, and specifications. The standards here do not include any security standards that should be classified into the security test.
+
+
+
Safety
+
+
Tests the safety property of the tested object to avoid possible hazards to personal safety, health, and the object itself.
+
+
+
Resilience
+
+
Tests the resilience property of the tested object to ensure that it can withstand and maintain the defined running status (including downgrading) when being attacked, and recover from and adapt defense to the attacks to approach mission assurance.
+
+
+
+
+
+## Test Case Development Guidelines
+
+You should select the appropriate programming language and your target test framework to develop test cases.
+
+**Table 4** Test frameworks and test case languages for different systems
+
+
+
System
+
+
Test Framework
+
+
Language
+
+
+
+
Mini
+
+
HCTest
+
+
C
+
+
+
Small
+
+
HCPPTest
+
+
C++
+
+
+
Standard
+
+
HJSUnit and HCPPTest
+
+
JavaScript and C++
+
+
+
+
+
+### C-based Test Case Development and Compilation \(for the Mini System\)
+
+**Developing test cases for the mini system**
+
+The HCTest framework is used to support test cases developed with the C language. HCTest is enhanced and adapted based on the open-source test framework Unity.
+
+1. Access the **test/xts/acts** repository where the test cases will be stored.
+
+ ```
+ ├── acts
+ │ └──subsystem_lite
+ │ │ └── module_hal
+ │ │ │ └── BUILD.gn
+ │ │ │ └── src
+ │ └──build_lite
+ │ │ └── BUILD.gn
+ ```
+
+2. Write the test case in the **src** directory.
+
+ 1. Import the test framework header file.
+
+ ```
+ #include "hctest.h"
+ ```
+
+ 2. Use the **LITE\_TEST\_SUIT** macro to define names of the subsystem, module, and test suite.
+
+ ```
+ /**
+ * @brief Registers a test suite named IntTestSuite.
+ * @param test Subsystem name
+ * @param example Module name
+ * @param IntTestSuite Test suite name
+ */
+ LITE_TEST_SUIT(test, example, IntTestSuite);
+ ```
+
+ 3. Define Setup and TearDown.
+
+ Format: Test suite name+Setup, Test suite name+TearDown.
+
+ The Setup and TearDown functions must exist, but function bodies can be empty.
+
+ 4. Use the **LITE\_TEST\_CASE** macro to write the test case.
+
+ Three parameters are involved: test suite name, test case name, and test case properties \(including type, granularity, and level\).
+
+ ```
+ LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1)
+ {
+ // Do something
+ };
+ ```
+
+ 5. Use the **RUN\_TEST\_SUITE** macro to register the test suite.
+
+ ```
+ RUN_TEST_SUITE(IntTestSuite);
+ ```
+
+3. Create the configuration file \(**BUILD.gn**\) of the test module.
+
+ Create a **BUILD.gn** \(example\) build file in each test module directory. Specify the name of the built static library and its dependent header file and library in the build file. The format is as follows:
+
+ ```
+ import("//test/xts/tools/lite/build/suite_lite.gni")
+ hctest_suite("ActsDemoTest") {
+ suite_name = "acts"
+ sources = [
+ "src/test_demo.c",
+ ]
+ include_dirs = [ ]
+ cflags = [ "-Wno-error" ]
+ }
+ ```
+
+4. Add build options to the **BUILD.gn** file in the **acts** directory.
+
+ You need to add the test module to the **test/xts/acts/build\_lite/BUILD.gn** script in the **acts** directory.
+
+ ```
+ lite_component("acts") {
+ ...
+ if(board_name == "liteos_m") {
+ features += [
+ ...
+ "//xts/acts/subsystem_lite/module_hal:ActsDemoTest"
+ ]
+ }
+ }
+ ```
+
+5. Run build commands.
+
+ Test suites are built along with version build. The ACTS is built together with the debug version.
+
+ > **NOTE:**
+ >The ACTS build middleware is a static library, which will be linked to the image.
+
+
+### C-based Test Case Execution \(for the Mini System\)
+
+**Executing test cases for the mini system**
+
+Burn the image into the development board.
+
+**Executing the test**
+
+1. Use a serial port tool to log in to the development board and save information about the serial port.
+2. Restart the device and view serial port logs.
+
+**Analyzing the test result**
+
+View the serial port logs, whose format is as follows:
+
+The log for each test suite starts with **Start to run test suite:** and ends with **xx Tests xx Failures xx Ignored**.
+
+### C++-based Test Case Development and Compilation \(for Standard and Small Systems\)
+
+**Developing test cases for small-system devices** \(For examples of the standard system, go to the **global/i18n\_standard directory**.\)
+
+The HCPPTest framework is enhanced and adapted based on the open-source framework Googletest.
+
+1. Access the **test/xts/acts** repository where the test cases will be stored.
+
+ ```
+ ├── acts
+ │ └──subsystem_lite
+ │ │ └── module_posix
+ │ │ │ └── BUILD.gn
+ │ │ │ └── src
+ │ └──build_lite
+ │ │ └── BUILD.gn
+ ```
+
+2. Write the test case in the **src** directory.
+
+ 1. Import the test framework header file.
+
+ The following statement includes **gtest.h**.
+
+ ```
+ #include "gtest/gtest.h"
+ ```
+
+ 2. Define Setup and TearDown.
+
+ ```
+ using namespace std;
+ using namespace testing::ext;
+ class TestSuite: public testing::Test {
+ protected:
+ // Preset action of the test suite, which is executed before the first test case
+ static void SetUpTestCase(void){
+ }
+ // Test suite cleanup action, which is executed after the last test case
+ static void TearDownTestCase(void){
+ }
+ // Preset action of the test case
+ virtual void SetUp()
+ {
+ }
+ // Cleanup action of the test case
+ virtual void TearDown()
+ {
+ }
+ };
+ ```
+
+ 3. Use the **HWTEST** or **HWTEST\_F** macro to write the test case.
+
+ **HWTEST**: definition of common test cases, including the test suite name, test case name, and case annotation.
+
+ **HWTEST\_F**: definition of SetUp and TearDown test cases, including the test suite name, test case name, and case annotation.
+
+ Three parameters are involved: test suite name, test case name, and test case properties \(including type, granularity, and level\).
+
+ ```
+ HWTEST_F(TestSuite, TestCase_0001, Function | MediumTest | Level1) {
+ // Do something
+ }
+ ```
+
+3. Create a configuration file \(**BUILD.gn**\) of the test module.
+
+ Create a **BUILD.gn** build file in each test module directory. Specify the name of the built static library and its dependent header file and library in the build file. Each test module is independently built into a **.bin** executable file, which can be directly pushed to the development board for testing.
+
+ Example:
+
+ ```
+ import("//test/xts/tools/lite/build/suite_lite.gni")
+ hcpptest_suite("ActsDemoTest") {
+ suite_name = "acts"
+ sources = [
+ "src/TestDemo.cpp"
+ ]
+
+ include_dirs = [
+ "src",
+ ...
+ ]
+ deps = [
+ ...
+ ]
+ cflags = [ "-Wno-error" ]
+ }
+
+ ```
+
+4. Add build options to the **BUILD.gn** file in the **acts** directory.
+
+ Add the test module to the **test/xts/acts/build\_lite/BUILD.gn** script in the **acts** directory.
+
+ ```
+ lite_component("acts") {
+ ...
+ else if(board_name == "liteos_a") {
+ features += [
+ ...
+ "//xts/acts/subsystem_lite/module_posix:ActsDemoTest"
+ ]
+ }
+ }
+ ```
+
+5. Run build commands.
+
+ Test suites are built along with the version build. The ACTS is built together with the debug version.
+
+ > **NOTE:**
+ >The ACTS for the small system is independently built to an executable file \(.bin\) and archived in the **suites\\acts** directory of the build result.
+
+
+### C++-based Test Case Execution \(for Standard and Small Systems\)
+
+**Executing test cases for the small system**
+
+Currently, test cases are shared by the NFS and mounted to the development board for execution.
+
+**Setting up the environment**
+
+1. Use a network cable or wireless network to connect the development board to your PC.
+2. Configure the IP address, subnet mask, and gateway for the development board. Ensure that the development board and the PC are in the same network segment.
+3. Install and register the NFS server on the PC and start the NFS service.
+4. Run the **mount** command for the development board to ensure that the development board can access NFS shared files on the PC.
+
+ Format: **mount** _NFS server IP address_**:/**_NFS shared directory_ **/**_development board directory_ **nfs**
+
+ Example:
+
+ ```
+ mount 192.168.1.10:/nfs /nfs nfs
+ ```
+
+
+**Executing test cases**
+
+Execute **ActsDemoTest.bin** to trigger test case execution, and analyze serial port logs generated after the execution is complete.
+
+### JavaScript-based Test Case Development \(for the Standard System\)
+
+The HJSUnit framework is used to support automated test of OpenHarmony apps that are developed using the JavaScript language based on the JS application framework.
+
+**Basic syntax of test cases**
+
+The test cases are developed with the JavaScript language and must meet the programming specifications of the language.
+
+**Table 5**
+
+
+
Syntax
+
+
Description
+
+
Mandatory
+
+
+
+
beforeAll
+
+
Presets a test-suite-level action executed only once before all test cases are executed. You can pass the action function as the only parameter.
+
+
No
+
+
+
afterAll
+
+
Presets a test-suite-level clear action executed only once after all test cases are executed. You can pass the clear function as the only parameter.
+
+
No
+
+
+
beforeEach
+
+
Presets a test-case-level action executed before each test case is executed. The number of execution times is the same as the number of test cases defined by it. You can pass the action function as the only parameter.
+
+
No
+
+
+
afterEach
+
+
Presets a test-case-level clear action executed after each test case is executed. The number of execution times is the same as the number of test cases defined by it. You can pass the clear function as the only parameter.
+
+
No
+
+
+
describe
+
+
Defines a test suite. You can pass two parameters: test suite name and test suite function. The describe statement supports nesting. You can use beforeall, beforeEach, afterEach, and afterAll in each describe statement.
+
+
Yes
+
+
+
it
+
+
Defines a test case. You can pass three parameters: test case name, filter parameter, and test case function.
+
Usage of the filter parameter:
+
The value of the filter parameter is a 32-bit integer. Setting different bits to 1 means different configurations:
+
bit 0: whether the filter parameter takes effect. 1 means that the test case is used for the function test and other settings of the parameter do not take effect.
Bits 0-10: test case categories
Bits 16-18: test case scales
Bits 24-28: test levels
+
Test case categories: Bits 0-10 indicate FUNCTION (function test), PERFORMANCE (performance test), POWER (power consumption test), RELIABILITY (reliability test), SECURITY (security compliance test), GLOBAL (integrity test), COMPATIBILITY (compatibility test), USER (user test), STANDARD (standard test), SAFETY (security feature test), and RESILIENCE (resilience test), respectively.
+
Test case scales: Bits 16-18 indicate SMALL (small-scale test), MEDIUM (medium-scale test), and LARGE (large-scale test), respectively.
+
+Use the standard syntax of Jasmine to write test cases. The ES6 specification is supported.
+
+1. Store the test cases in the **entry/src/main/js/test** directory, whose structure is as follows:
+
+ ```
+ ├── BUILD.gn
+ │ └──entry
+ │ │ └──src
+ │ │ │ └──main
+ │ │ │ │ └──js
+ │ │ │ │ │ └──default
+ │ │ │ │ │ │ └──pages
+ │ │ │ │ │ │ │ └──index
+ │ │ │ │ │ │ │ │ └──index.js # Entry file
+ │ │ │ │ │ └──test # Test code
+ │ │ │ └── resources # HAP resources
+ │ │ │ └── config.json # HAP configuration file
+ ```
+
+2. Start the JS test framework and load test cases. The following is an example for **index.js**.
+
+ ```
+ // Start the JS test framework and load test cases.
+ import {Core, ExpectExtend} from 'deccjsunit/index'
+
+ export default {
+ data: {
+ title: ""
+ },
+ onInit() {
+ this.title = this.$t('strings.world');
+ },
+ onShow() {
+ console.info('onShow finish')
+ const core = Core.getInstance()
+ const expectExtend = new ExpectExtend({
+ 'id': 'extend'
+ })
+ core.addService('expect', expectExtend)
+ core.init()
+ const configService = core.getDefaultService('config')
+ configService.setConfig(this)
+ require('../../../test/List.test')
+ core.execute()
+ },
+ onReady() {
+ },
+ }
+ ```
+
+3. Write a unit test case by referring to the following example:
+
+ ```
+ // Use HJSUnit to perform the unit test.
+ describe('appInfoTest', function () {
+ it('app_info_test_001', 0, function () {
+ var info = app.getInfo()
+ expect(info.versionName).assertEqual('1.0')
+ expect(info.versionCode).assertEqual('3')
+ })
+ })
+ ```
+
+
+### JavaScript-based Test Case Packaging \(for the Standard System\)
+
+For details about how to build a HAP, see the JS application development guide of the standard system [Building and Creating HAPs](https://developer.harmonyos.com/en/docs/documentation/doc-guides/build_overview-0000001055075201).
+
+## Full Compilation Guide \(for the Standard System\)
+
+1. Perform full building.
+
+ Command:
+
+ ```
+ ./build.sh suite=acts system_size=standard
+ ```
+
+ Test case output directory: **out/release/suites/acts/testcases**
+
+ Test framework and case output directory: **out/release/suites/acts** \(The test suite execution framework is compiled during case compilation.\)
+
+
+## Full Test Case Execution Guide \(for Small and Standard Systems\)
+
+**Setting up a test environment**
+
+Install Python 3.7 or a later version on a Windows environment and ensure that the Windows environment is properly connected to the test device.
+
+**Test execution directory** \(corresponding to the **out/release/suites/acts** directory generated during compilation\)
+
+```
+├── testcase # Directory for storing test suite files
+│ └──xxx.hap # HAP file executed by the test suite
+│ └──xxx.json # Execution configuration file of the test suite
+├── tools # Test framework tool directory
+├── run.bat # File for starting the test suite on the Windows platform
+├── report # Directory for storing the test reports
+```
+
+**Executing test cases**
+
+1. On the Windows environment, locate the directory in which the test cases are stored \(**out/release/suites/acts**, copied from the Linux server\), go to the directory in the Windows command window, and run **acts\\run.bat**.
+
+1. Enter the command for executing the test case.
+
+ - Execute all test cases.
+
+ ```
+ run acts
+ ```
+
+ 
+
+
+ - Execute the test cases of a module \(view specific module information in **\\acts\\testcases\\**\).
+
+ ```
+ run –l ActsSamgrTest
+ ```
+
+ 
+
+
+ Wait until the test case is complete.
+
+
+1. View test reports.
+
+ Go to **acts\\reports\\**, obtain the current execution record, and open **summary\_report.html** to view the test report.
+
+
diff --git a/en/device-dev/subsystems/subsys.md b/en/device-dev/subsystems/subsys.md
new file mode 100644
index 0000000000000000000000000000000000000000..64d3b35c40b789ee4394fb3fc107517eb597018d
--- /dev/null
+++ b/en/device-dev/subsystems/subsys.md
@@ -0,0 +1,33 @@
+# Subsystem Development Guidelines
+
+- **[Compilation and Building](subsys-build.md)**
+
+- **[Distributed Remote Startup](subsys-remote-start.md)**
+
+- **[Graphics](subsys-graphics.md)**
+
+- **[Multimedia](subsys-multimedia.md)**
+
+- **[Utils](subsys-utils.md)**
+
+- **[AI Framework](subsys-aiframework.md)**
+
+- **[Sensors](subsys-densor.md)**
+
+- **[Application Framework](subsys-application-framework.md)**
+
+- **[OTA Upgrade](subsys-ota-guide.md)**
+
+- **[Security](subsys-security.md)**
+
+- **[Startup](subsys-boot.md)**
+
+- **[Testing](subsys-testguide-test.md)**
+
+- **[DFX](subsys-dfx.md)**
+
+- **[HiSysEvent订阅指导](subsys-dfx-hisyseventread.md)**
+
+- **[XTS](subsys-xts-guide.md)**
+
+
diff --git a/en/device-dev/subsystems/technical-specifications.md b/en/device-dev/subsystems/technical-specifications.md
deleted file mode 100644
index 6a53ac57a84e50addac49a9b002d3a3db7678e20..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/technical-specifications.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Technical Specifications
-
-**Conventions**
-
-**Rule**: a convention that must be observed
-
-**Recommendation**: a convention that should be considered
-
-- **[Code Management](code-management.md)**
-
-- **[Naming](naming.md)**
-
-- **[API Development](api-development.md)**
-
-
diff --git a/en/device-dev/subsystems/testing.md b/en/device-dev/subsystems/testing.md
deleted file mode 100644
index 6b84a0b1cd8b9ca8a1f149396299679e24d07edc..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/testing.md
+++ /dev/null
@@ -1,987 +0,0 @@
-# Testing
-
-- [Overview](#section12403172115920)
- - [Basic Concepts](#section53632272090)
- - [Working Principles](#section2394431106)
-
-- [Limitations and Constraints](#section2029921310472)
-- [Setting Up a Test Environment](#section175012297491)
- - [Environment Requirements](#section935055691014)
- - [Installing the Environment](#section6511193210111)
- - [Verifying the Test Environment](#section1899144517117)
-
-- [Development Guidelines](#section16741101301210)
- - [When to Use](#section93782214124)
- - [Available APIs](#section54131732101218)
- - [How to Develop](#section53541946111218)
-
-- [Development Example](#section7477121918136)
-- [How to Use the Test Platform](#section76401945124810)
-- [Directory Structure](#section1875515364133)
-
-## Overview
-
-### Basic Concepts
-
-The testing subsystem provides a one-click Python-based self-test platform for developers. It supports cross-platform tests and extension to third-party testing frameworks. The subsystem consists of modules for compiling, managing, scheduling and distributing, and executing test cases, collecting test results, generating test reports, creating test case templates, managing test environments, and many others.
-
-Before development using the testing subsystem, you need to understand the following concepts:
-
-- Test case compilation
-
- This operation compiles the source code of test cases into binary files that can be executed on the tested device.
-
-- Test case scheduling & distributing
-
- This operation distributes test cases to different tested devices through the network port or serial port, and allocates a specific executor for each test case.
-
-- Test case executor
-
- A test case executor defines the execution logic of each test case, such as its pre-processing, execution, and result recording.
-
-- Test case template
-
- A test case template defines respective unified formats for test cases and for GN files.
-
-- Test platform kits
-
- The test platform provides common methods to be used during the running of the test tool, for example, providing the test case directory to mount the file system to a tested device, distributing test cases to the tested device, or obtaining test results from the tested device.
-
-- Test report generation
-
- This operation defines a template for generating self-test reports and web test reports.
-
-- Test environment management
-
- The tested devices can be managed through the USB port or serial port, including discovering a device and querying the device status.
-
-
-### Working Principles
-
-- The following figure shows the architecture of the test platform.
-
-**Figure 1** Platform architecture
-
-
-- The following figure shows the running sequence diagram of the test platform.
-
-**Figure 2** Running sequence of the test platform
-
-
-- Working principle of the test platform
-
-The test platform is started using a shell script. It executes a series of testing commands entered on the command line interface \(CLI\) and prints the command output.
-
-## Limitations and Constraints
-
-- The self-test platform supports only code-level test case development and verification, such as unit testing and module testing.
-- Currently, the testing framework supports only white-box testing.
-- Only one test platform can be started on a testing device.
-
-## Setting Up a Test Environment
-
-### Environment Requirements
-
-**Table 1** Environment requirements
-
-
-
Item
-
-
Testing Device
-
-
Tested Device
-
-
-
-
Hardware
-
-
Memory: 8 GB or above
Hard disk space: 100 GB or above
Hardware architecture: x86 or ARM64
-
-
Hi3516D V300 development board
Hi3518E V300 development board
-
-
-
Software
-
-
OS: Windows 10 (64-bit) or Ubuntu 18.04
System component (Linux): libreadline-dev
-
Python: 3.7.5 or later
Python plug-ins: pySerial 3.3 or later, Paramiko 2.7.1 or later, Setuptools 40.8.0 or later, and RSA 4.0 or later
NFS server: haneWIN NFS Server 1.2.50 or later, or NFSv4 or later
-
-
OS: OpenHarmony 1.0 or later
Kernel: LiteOS Cortex-A or Linux kernel
-
-
-
-
-
-### Installing the Environment
-
-1. \(Optional\) If the test environment runs Linux, run the following command to install system component Readline:
-
- ```
- sudo apt-get install libreadline-dev
- ```
-
- If the installation is successful, the following prompts are displayed:
-
- ```
- Reading package lists... Done
- Building dependency tree
- Reading state information... Done
- libreadline-dev is already the newest version (7.0-3).
- 0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
- ```
-
-2. Install Python extension plug-ins Setuptools. Install RSA, Paramiko, and pySerial if the device supports the serial port only.
-
- 1. Run the following command to install Setuptools:
-
- ```
- pip install setuptools
- ```
-
- If the installation is successful, the following prompts are displayed:
-
- ```
- Requirement already satisfied: setuptools in d:\programs\python37\lib\site-packages (41.2.0)
- ```
-
- 2. Run the following command to install RSA:
-
- ```
- pip install rsa
- ```
-
- If the installation is successful, the following prompts are displayed:
-
- ```
- Installing collected packages: pyasn1, rsa
- Successfully installed pyasn1-0.4.8 rsa-4.7
- ```
-
- 3. Run the following command to install Paramiko:
-
- ```
- pip install paramiko
- ```
-
- If the installation is successful, the following prompts are displayed:
-
- ```
- Installing collected packages: pycparser, cffi, pynacl, bcrypt, cryptography, paramiko
- Successfully installed bcrypt-3.2.0 cffi-1.14.4 cryptography-3.3.1 paramiko-2.7.2 pycparser-2.20 pynacl-1.4.0
- ```
-
- 4. \(Optional\) Run the following command to install pySerial. This step is mandatory for tested devices that support serial ports only.
-
- ```
- pip install pyserial
- ```
-
- If the installation is successful, the following prompts are displayed:
-
- ```
- Requirement already satisfied: pyserial in d:\programs\python37\lib\site-packages\pyserial-3.4-py3.7.egg (3.4)
- ```
-
-3. \(Optional\) Install the NFS server. This step is mandatory for tested devices that support serial ports only.
-
- **Windows OS**
-
- Download and install **haneWIN NFS Server 1.2.50** at https://www.hanewin.net/nfs-e.htm.
-
- **Linux OS**
-
- ```
- sudo apt install nfs-kernel-server
- ```
-
- After the environment is installed, you can conduct coding and debugging for a test platform in an integrated development environment \(IDE\) \(DevEco Studio is recommended\).
-
-
-### Verifying the Test Environment
-
-**Table 2** Environment verification
-
-
-
Item
-
-
Operation
-
-
Requirement
-
-
-
-
Check that a compliant Python version has been installed.
-
-
Run the python --version command.
-
-
The Python version must be 3.7.5 or later.
-
-
-
Check that Python extension plug-ins have been installed.
-
-
Access the test/xdevice directory and run run.bat or run.sh.
-
-
The >>> prompt is displayed.
-
-
-
Check that the NFS server has been started (for tested devices that support serial ports only).
-
-
Log in to the development board through the serial port and run the mount command to mount the NFS server.
-
-
The file directory can be mounted properly.
-
-
-
-
-
-## Development Guidelines
-
-### When to Use
-
-You can call the APIs to conduct white box tests of service code.
-
-### Available APIs
-
-The testing framework integrates the open-source unit testing framework and expands the macros of the test cases. For details about the framework, see the official open-source documentation.
-
-**Table 3** Expanded macros of the framework
-
-
-
Macro
-
-
Description
-
-
-
-
HWTEST
-
-
The execution of test cases does not rely on setup and teardown execution. Based on the TEST macro, this macro has added the TestSize.Level1 parameter to specify the test case level, for example, HWTEST(CalculatorAddTest, TestPoint_001, TestSize.Level1).
-
-
-
HWTEST_F
-
-
The execution of test cases (without parameters) depends on setup and teardown execution. Based on the TEST_F macro, this macro has added the TestSize.Level1 parameter to specify the test case level, for example, HWTEST_F(CalculatorAddTest, TestPoint_001, TestSize.Level1).
-
-
-
HWTEST_P
-
-
The execution of test cases (with parameters) depends on setup and teardown execution. Based on the TEST_P macro, this macro has added the TestSize.Level1 parameter to specify the test case level, for example, HWTEST_P(CalculatorAddTest, TestPoint_001, TestSize.Level1).
-
-
-
-
-
-### How to Develop
-
-1. Define a test suite file based on the test case directory, for example, **test/developertest/examples/lite/cxx\_demo/test/unittest/common/calc\_subtraction\_test.cpp**. The class in this test suite should be inherited from the **testing::Test** class and named in the format of "_Tested feature_\_**Test**".
-
- ```
- /*
- * Copyright (c) 2020 OpenHarmony.
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
- #include
-
- using namespace std;
- using namespace testing::ext;
-
- class CalcSubtractionTest : public testing::Test {
- public:
- static void SetUpTestCase(void);
- static void TearDownTestCase(void);
- void SetUp();
- void TearDown();
- };
- ```
-
- > **NOTE:**
- >You must write test cases by observing the following specifications:
- >- Naming
- > The source file name of a test case must be consistent with the test suite content. Each test suite has multiple test cases and a test source file that is globally unique and named in \[Feature\]\_\[Function\]\_\[Subfunction 1\]\_\[Subfunction 1.1\] format \(subfunctions can be further divided\).
- > The file name can contain only lower-case letters and underscores \(\_\) and must end with **test**, for example, **developertest/examples/lite/cxx\_demo**.
- >- Coding
- > The test cases must comply with the coding specifications for feature code. In addition, case descriptions are required for further clarification. For details, see [Test case template](#li2069415903917).
- >- Compilation and configuration
- > The test cases must be compiled using GN, and the configurations must comply with the compilation guide of this open-source project. For details, see [Compilation and Building Guidelines](https://device.harmonyos.com/en/docs/develop/subsystems/oem_subsys_build_des-0000001060646620).
- >- Test case template
- > For details, see the example test case **developertest/examples/lite/cxx\_demo/test/unittest/common/calc\_subtraction\_test.cpp**.
-
-2. Implement the preprocessing \(via the **SetUp** function\) and postprocessing \(via the **TearDown** function\) operations required by the execution of the test suite.
-
- ```
- void CalcSubtractionTest::SetUpTestCase(void)
- {
- // step 1: input testsuite setup step
- }
-
- void CalcSubtractionTest::TearDownTestCase(void)
- {
- // step 2: input testsuite teardown step
- }
-
- void CalcSubtractionTest::SetUp(void)
- {
- // step 3: input testcase setup step
- }
-
- void CalcSubtractionTest::TearDown(void)
- {
- // step 4: input testcase teardown step
- }
- ```
-
-3. Compile a test case based on the feature to be tested. The following code uses **HWTEST\_F** as an example:
-
- ```
- /**
- * @tc.name: integer_sub_001
- * @tc.desc: Test Calculator
- * @tc.type: FUNC
- * @tc.require: AR00000000 SR00000000
- */
- HWTEST_F(CalcSubtractionTest, integer_sub_001, TestSize.Level1)
- {
- EXPECT_EQ(0, Subtraction(1, 0));
- }
- ```
-
- > **NOTE:**
- >- **@tc.name**: test case name, which briefly describes the test purpose
- >- **@tc.desc**: detailed description of the test case, including the test purpose, test procedure, and expected result
- >- **@tc.type**: test type, which can be **FUNC**, **PERF**, **SECU**, or **RELI**.
- >- **@tc.require**: requirement ID or issue ID, which is used to associate the modification with the test case
-
-
-
SN
-
-
Test Type
-
-
Code
-
-
Description
-
-
-
-
1
-
-
Functionality test
-
-
FUNC
-
-
Verifies that each functionality of the software complies with the function design and specifications.
-
-
-
2
-
-
Performance test
-
-
PERF
-
-
Verifies that the software meets the performance requirements. Performance tests include load tests, capacitance tests, and pressure tests.
-
-
-
3
-
-
Security test
-
-
SECU
-
-
Verifies that the software complies with security requirements and related laws and regulations within the software lifecycle.
-
-
-
4
-
-
Reliability test
-
-
RELI
-
-
Verifies the probability that the software does not cause system failures within a specified period of time and under given conditions. Software stability is also involved in the test.
-
-
-
-
-
-4. Compile the GN file of the test case, including defining the compilation target, adding compilation dependencies, and setting the source file.
-
- Example file path: **test/developertest/examples/lite/cxx\_demo/test/unittest/common/BUILD.gn**
-
- ```
- import("//build/lite/config/test.gni")
-
- unittest("CalcSubTest") {
- output_extension = "bin"
- sources = [
- "calc_subtraction_test.cpp"
- ]
- include_dirs = []
- deps = []
- }
- ```
-
-5. Add the compilation target to the subsystem compilation configuration to ensure that the test case is compiled with the version distribution. The following is an example:
- 1. For devices that support connection to the Harmony device connector \(hdc\), the example compilation configuration directory is **test/developertest/examples/ohos.build**.
-
- ```
- {
- "subsystem": "subsystem_examples",
- "parts": {
- "subsystem_examples": {
- "module_list": [
- "//test/developertest/examples/detector:detector",
- ...
- ],
- "test_list": [
- "//test/developertest/examples/detector/test:unittest",
- ...
- ]
- },
- ...
- }
- ```
-
- 2. For devices that support serial ports only, the example compilation configuration directory is **test/developertest/examples/lite/BUILD.gn**.
-
- ```
- import("//build/lite/config/test.gni")
-
- subsystem_test("test") {
- test_components = []
- if(ohos_kernel_type == "liteos_riscv") {
- features += [
- ]
- }else if(ohos_kernel_type == "liteos_a") {
- test_components += [
- "//test/developertest/examples/lite/cxx_demo/test/unittest/common:CalcSubTest"
- ]
- }
- }
- ```
-
-
-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.
- 3. Create a folder named after the module in the device type directory, for example, **testmodule**.
- 4. Create the **ohos\_test.xml** file in the folder named after the module. The file content is in the following format:
-
- ```
-
-
-
-
-
-
-
-
- ```
-
- 5. Define **resource\_config\_file** in the compilation configuration file of the test case to specify the resource file **ohos\_test.xml**.
-
- > **NOTE:**
- >The resource file is used to push the **test.txt** file in the **resource** directory to the **/data/test/resource** directory of the device to test. To do so, run the **hdc push** command.
-
-
-7. Execute the test case after it is compiled \(the preceding steps are complete\).
-
- > **NOTE:**
- >- For devices that support connection to the hdc, test cases can be compiled separately.
- >- For devices that support serial ports only, to compile the test case, run the commands in the root directory for compiling the debug code.
- > For details about how to execute a test case, see [How to Use the Test Platform](#section76401945124810).
-
-
-## Development Example
-
-The code repository of the testing subsystem provides complete demo cases, which are available in the **test/developertest/examples/** directory. The following is an example of compiling a test case for a subtraction function:
-
-- The tested code is as follows:
-
- ```
- static int Subtraction(int a, int b)
- {
- return a - b;
- }
- ```
-
-- The test case code is as follows:
-
- ```
- /**
- * @tc.name: integer_sub_002
- * @tc.desc: Verify the Subtraction function.
- * @tc.type: FUNC
- * @tc.require: AR00000000 SR00000000
- */
- HWTEST_F(CalcSubtractionTest, integer_sub_002, TestSize.Level1)
- {
- EXPECT_EQ(1, Subtraction(2, 1));
- }
- ```
-
-
-## How to Use the Test Platform
-
-1. \(Optional\) Install the XDevice component. XDevice can be used as a Python extension package.
-
- Go to the installation directory **test/xdevice** and run the following command:
-
- ```
- python setup.py install
- ```
-
- If the installation is successful, the following prompts are displayed:
-
- ```
- ...
- Installed d:\programs\python37\lib\site-packages\xdevice-0.0.0-py3.7.egg
- Processing dependencies for xdevice==0.0.0
- Searching for pyserial==3.4
- Best match: pyserial 3.4
- Processing pyserial-3.4-py3.7.egg
- pyserial 3.4 is already the active version in easy-install.pth
- Installing miniterm.py script to D:\Programs\Python37\Scripts
-
- Using d:\programs\python37\lib\site-packages\pyserial-3.4-py3.7.egg
- Finished processing dependencies for xdevice==0.0.0
- ```
-
-2. Modify the **developertest/config/user\_config.xml** file to configure the Developertest component.
- 1. Modify basic configuration parameters.
-
- \[build\] \# Set build parameters of the test case.
-
- ```
-
- false
- false
- true
- ... ...
-
- ```
-
- > **NOTE:**
- >**example**: whether to build the test case example. The default value is **false**.
- >**version**: whether to build the test version. The default value is **false**.
- >**testcase**: whether to build the test case. The default value is **true**.
-
- 2. For devices that support connection to the hdc, modify the configuration file as follows:
-
- Between the **device** tags with the **"usb-hdc"** attribute, modify the IP address of the device and the port number matching the HDC connection. For example:
-
- ```
-
- 192.168.1.1
- 9111
-
-
- ```
-
- 3. For devices that support serial ports only, modify the configuration file as follows:
-
- \[board\_info\] \# Configure development board information.
-
- ```
-
- hispark
- taurus
- ipcamera
- hb build
-
- ```
-
- > **NOTE:**
- >**board\_series**: development board series. The default value is **hispark**.
- >**board\_type**: development board type. The default value is **taurus**.
- >**board\_product**: target product. The default value is **ipcamera**.
- >**build\_command**: command used for building the test version and test case. The default value is **hb build**.
-
- Between the **device** tags with the **"ipcamera"** attribute, modify the serial port information, including the COM port and baud rate. For example:
-
- ```
-
-
- COM1
- cmd
- 115200
- 8
- 1
- 1
-
-
- ```
-
-
-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.
-
- 1. Specify the output path of the test case, that is, the compilation output directory between the **test\_cases** tags. Example:
-
- ```
-
- /home/opencode/out/release/tests
-
- ```
-
- 2. For devices that support serial ports only, specify the NFS directory on the PC \(**host\_dir**\) and the corresponding directory on the board \(**board\_dir**\) between the **NFS** tags. For example:
-
- ```
-
- D:\nfs
- user
-
- ```
-
-
-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.
- - IP addresses of the development host and development board are in the same network segment and can ping each other.
- - An empty directory has been created on the development host for mounting test cases through NFS, and the NFS service has been started properly.
-
-5. Start the test platform and execute the test case.
- - Start the test framework, go to the **test/developertest** directory, and execute the startup script.
- 1. Run the following command to start the test framework in Windows:
-
- ```
- start.bat
- ```
-
- 2. Run the following command to start the test framework in Linux:
-
- ```
- ./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
- show typelist Query the supported test type
- 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]
- [-tc TESTCASE] [-tl TESTLEVEL]
-
- Optional arguments:
- -h, --help Show this help message and exit.
- -p PRODUCTFORM, --productform PRODUCTFORM Specified product form
- -t [TESTTYPE [TESTTYPE ...]], --testtype [TESTTYPE [TESTTYPE ...]]
- Specify test type(UT,MST,ST,PERF,ALL)
- -ss SUBSYSTEM, --subsystem SUBSYSTEM Specify test subsystem
- -tm TESTMODULE, --testmodule TESTMODULE Specified test module
- -ts TESTSUIT, --testsuite TESTSUIT Specify test suite
- -tc TESTCASE, --testcase TESTCASE Specify test case
- -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:
-
- ```
- reports/xxxx-xx-xx-xx-xx-xx
- ```
-
- - The test case formatting result is stored in the following directory:
-
- ```
- result/
- ```
-
- - The test logs are stored in the following directory:
-
- ```
- log/plan_log_xxxx-xx-xx-xx-xx-xx.log
- ```
-
- - The report summary file is as follows:
-
- ```
- summary_report.html
- ```
-
- - The report details file is as follows:
-
- ```
- details_report.html
- ```
-
-
- - The log directory of the test platform is as follows:
-
- ```
- reports/platform_log_xxxx-xx-xx-xx-xx-xx.log
- ```
-
-
-
-## Directory Structure
-
-The source code of XDevice is stored in the **test/xdevice** directory. The following table describes the **xdevice** directory structure.
-
-**Table 4** XDevice structure
-
-
-
Directory
-
-
Description
-
-
-
-
xdevice
-
-
Basic components of the test platform
-
-
-
xdevice/src/xdevice
-
-
Source code for the basic test framework
-
-
-
xdevice/config
-
-
Configuration file of the basic test framework
-
-
-
xdevice/src/xdevice/__main__.py
-
-
Internal entrance to the basic test framework
-
-
-
xdevice/src/xdevice/__init__.py
-
-
Package and plug-in dependencies
-
-
-
xdevice/src/xdevice/variables.py
-
-
Global variables
-
-
-
xdevice/src/xdevice/_core/command
-
-
Commands input by test cases
-
-
-
xdevice/src/xdevice/_core/config
-
-
Configuration management of the basic test framework
-
-
-
xdevice/src/xdevice/_core/environment
-
-
Environment management of the basic test framework, including device management
-
-
-
xdevice/src/xdevice/_core/executor
-
-
Scheduling and distribution of test cases
-
-
-
xdevice/src/xdevice/_core/driver
-
-
Test executor for the basic test framework
-
-
-
xdevice/src/xdevice/_core/resource
-
-
Resource files and test report templates for the basic test framework
-
-
-
xdevice/src/xdevice/_core/testkit
-
-
Common operations for the basic test framework, including NFS mounting
-
-
-
xdevice/src/xdevice/_core/logger.py
-
-
Log management of the basic test framework
-
-
-
xdevice/src/xdevice/_core/plugin.py
-
-
Plug-in management of the basic test framework
-
-
-
xdevice/src/xdevice/_core/interface.py
-
-
Interfaces for plug-ins of the basic test framework
-
-
-
xdevice/setup.py
-
-
Installation script of the basic test framework
-
-
-
xdevice/run.bat
-
-
Startup script of the basic test framework (Windows)
-
-
-
xdevice/run.sh
-
-
Startup script of the basic test framework (Linux)
-
-
-
-
-
-The source code of Developertest is stored in the **test/developertest** directory. The following table describes the **developertest** directory structure.
-
-**Table 5** Developertest structure
-
-
-
Directory
-
-
Description
-
-
-
-
developertest
-
-
Development test framework
-
-
-
developertest/src
-
-
Test framework source code
-
-
-
developertest/src/core
-
-
Test executor
-
-
-
developertest/src/core/build
-
-
Test case compilation
-
-
-
developertest/src/core/command
-
-
Processing of command lines entered by users
-
-
-
developertest/src/core/config
-
-
Test framework configuration management
-
-
-
developertest/src/core/driver
-
-
Test framework driver executor
-
-
-
developertest/src/core/resource
-
-
Test framework configuration file
-
-
-
developertest/src/core/testcase
-
-
Test case management
-
-
-
developertest/src/core/common.py
-
-
Common operations on the test framework
-
-
-
developertest/src/core/constants.py
-
-
Global constants of the test framework
-
-
-
developertest/src/core/exception.py
-
-
Test framework exceptions
-
-
-
developertest/src/core/utils.py
-
-
Test framework tools and methods
-
-
-
developertest/src/main
-
-
Test framework platform
-
-
-
developertest/src/main/__main__.py
-
-
Internal entrance of the test framework
-
-
-
developertest/examples
-
-
Test framework demo cases
-
-
-
developertest/third_party
-
-
Third-party components
-
-
-
developertest/BUILD.gn
-
-
Compilation configuration of the subsystem
-
-
-
developertest/start.bat
-
-
Developer test entry (Windows)
-
-
-
developertest/start.sh
-
-
Developer test entry (Linux)
-
-
-
-
-
diff --git a/en/device-dev/subsystems/utils-development-guidelines.md b/en/device-dev/subsystems/utils-development-guidelines.md
deleted file mode 100644
index 3c93cc03c0e754686770e4862286f66fed3dbf31..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/utils-development-guidelines.md
+++ /dev/null
@@ -1,293 +0,0 @@
-# Utils Development Guidelines
-
-- [Available APIs](#section1633115419401)
-- [How to Develop](#section17450172710292)
- - [Developing a Native Application for the KV Store That Uses the LiteOS Cortex-A Kernel \(Hi3516 or Hi3518\)](#section258354119295)
- - [Dumping System Attributes on the Platform That Uses the LiteOS Cortex-M Kernel](#section9179161863014)
- - [Dumping System Attributes on the Platform That Uses the LiteOS Cortex-A Kernel](#section3179121853017)
-
-
-## Available APIs
-
-**Table 1** APIs for file operations
-
-
-
Function
-
-
Description
-
-
-
-
int UtilsFileOpen(const char* path, int oflag, int mode)
-
-
Opens or creates a file.
-
-
-
int UtilsFileClose(int fd)
-
-
Closes a file with a specified file descriptor.
-
-
-
int UtilsFileRead(int fd, char *buf, unsigned int len)
-
-
Reads a specified length of data from a file with the specified file descriptor and writes the data into the buffer.
-
-
-
int UtilsFileWrite(int fd, const char *buf, unsigned int len)
-
-
Writes a specified length of data into a file with the specified file descriptor.
-
-
-
int UtilsFileDelete(const char *path)
-
-
Deletes a specified file.
-
-
-
int UtilsFileStat(const char *path, unsigned int *fileSize)
-
-
Obtains the file size.
-
-
-
int UtilsFileSeek(int fd, int offset, unsigned int whence)
-
-
Adjusts the read and write position offset in a file.
-
-
-
int UtilsFileCopy(const char* src, const char* dest)
-
-
Copies the source file to a target file.
-
-
-
int UtilsFileMove(const char* src, const char* dest)
-
-
Moves the source file into a target file.
-
-
-
-
-
-Sample code for file operations:
-
-```
-// Open a file and write data.
-char fileName[] = "testfile";
-static const char def[] = "utils_file_operation implement.";
-int fd = UtilsFileOpen(fileName, O_RDWR_FS | O_CREAT_FS | O_TRUNC_FS, 0);
-printf("file handle = %d\n", fd);
-int ret = UtilsFileWrite(fd, def, strlen(def));
-printf("write ret = %d\n", ret);
-
-// Adjust the position offset in the file.
-ret = UtilsFileSeek(fd, 5, SEEK_SET_FS);
-printf("lseek ret = %d\n", ret);
-
-// Read data and close the file.
-char buf[64] = {0};
-int readLen = UtilsFileRead(fd, buf, 64);
-ret = UtilsFileClose(fd);
-printf("read len = %d : buf = %s\n", readLen, buf);
-
-// Obtain the file size.
-int fileLen = 0;
-ret = UtilsFileStat(fileName, &fileLen);
-printf("file size = %d\n", fileLen);
-
-// Delete the file.
-ret = UtilsFileDelete(fileName);
-printf("delete ret = %d\n", ret);
-```
-
-**Table 2** APIs for KV store operations
-
-
-
Function
-
-
Description
-
-
-
-
int UtilsGetValue(const char* key, char* value, unsigned int len)
-
-
Obtains the value matching a specified key from the file system or cache.
-
-
-
int UtilsSetValue(const char* key, const char* value)
-
-
Adds or updates the value matching a specified key in the file system or cache.
-
-
-
int UtilsDeleteValue(const char* key)
-
-
Deletes the value matching a specified key from the file system or cache.
-
-
-
-
-
-Sample code for the KV store:
-
-```
-// Set the value matching the specified key.
-char key[] = "rw.sys.version_100";
-char value[] = "Hello kv operation implement!";
-int ret = UtilsSetValue(key, value);
-printf("UtilsSetValue set ret = %d\n", ret);
-
-// Obtain the value matching the specified key.
-char temp[128] = {0};
-ret = UtilsGetValue(key, temp, 128);
-printf("UtilsGetValue get ret = %d, temp = %s\n", ret, temp);
-
-// Delete the value matching the specified key.
-ret = UtilsDeleteValue(key);
-printf("UtilsDeleteValue delete ret = %d\n", ret);
-```
-
-## How to Develop
-
-### Developing a Native Application for the KV Store That Uses the LiteOS Cortex-A Kernel \(Hi3516 or Hi3518\)
-
-1. Develop the native application for the KV store using **AbilityKit** APIs.
- - Write the user program by calling the APIs provided by the KV store and compile the **libLauncher.so** file.
-
- ```
- // Set the value matching the specified key.
- char key[] = "rw.sys.version_100";
- char value[] = "Hello kv operation implement!";
- int ret = UtilsSetValue(key, value);
- printf("UtilsSetValue set ret = %d\n", ret);
-
- // Obtain the value matching the specified key.
- char temp[128] = {0};
- ret = UtilsGetValue(key, temp, 128);
- printf("UtilsGetValue get ret = %d, temp = %s\n", ret, temp);
-
- // Delete the value matching the specified key.
- ret = UtilsDeleteValue(key);
- printf("UtilsDeleteValue delete ret = %d\n", ret);
- ```
-
- - Edit the **config.json** file as follows:
-
- ```
- {
- "app": {
- "bundleName": "com.huawei.launcher",
- "vendor": "huawei",
- "version": {
- "code": 1,
- "name": "1.0"
- }
- },
- "deviceConfig": {
- "default": {
- "reqSdk": {
- "compatible": "zsdk 1.0.0",
- "target": "zsdk 1.0.1"
- },
- "keepAlive": false
- },
- "smartCamera": {
- "reqSdk": {
- "compatible": "zsdk 1.0.0",
- "target": "zsdk 1.0.1"
- },
- "keepAlive": false
- }
- },
- "module": {
- "package": "com.huawei.launcher",
- "name": ".MyHarmonyAbilityPackage",
- "deviceType": [
- "phone", "tv","tablet", "pc","car","smartWatch","sportsWatch","smartCamera"
- ],
- "distro": {
- "deliveryWithInstall": true,
- "moduleName": "Launcher",
- "moduleType": "entry"
- },
- "abilities": [{
- "name": "MainAbility",
- "icon": "res/drawable/phone.png",
- "label": "test app 1",
- "launchType": "standard",
- "type": "page"
- },
- {
- "name": "SecondAbility",
- "icon": "res/drawable/phone.png",
- "label": "test app 2",
- "launchType": "standard",
- "type": "page"
- },
- {
- "name": "ServiceAbility",
- "icon": "res/drawable/phone.png",
- "label": "test app 2",
- "launchType": "standard",
- "type": "service"
- }
- ]
- }
- }
- ```
-
-
- - Generate a HAP file.
-
- - Add resource files in the **res/drawable** directory based on the following directory structure.
-
- 
-
- - 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.
-
- ```
- ./nfs/dev_tools/bin/bm install -p /nfs/Launcher.hap
- ```
-
-3. Send the command for running the native KV store application to the board through the serial port.
-
- ```
- ./nfs/dev_tools/bin/aa start -p com.huawei.launcher -n ServiceAbility
- ```
-
-
-### Dumping System Attributes on the Platform That Uses the LiteOS Cortex-M Kernel
-
-1. Connect the development board and send the **AT+SYSPARA** command to the board through the serial port.
-
- ```
- AT+SYSPARA
- ```
-
- **Figure 1** Output of the system attribute dumping command for the LiteOS Cortex-M kernel
- 
-
-
-### Dumping System Attributes on the Platform That Uses the LiteOS Cortex-A Kernel
-
-1. Connect the development board and run the **os\_dump --help** command in the **bin** directory to view the **os\_dump** help information.
-
- ```
- ./bin/os_dump --help
- ```
-
-2. Run the **os\_dump -l** command in the **bin** directory to view system modules that support attribute dumping.
-
- ```
- ./bin/os_dump -l
- ```
-
-3. Run the **os\_dump syspara** command in the **bin** directory to dump the current system attributes.
-
- ```
- ./bin/os_dump syspara
- ```
-
- **Figure 2** Output of the system attribute dumping command for the LiteOS Cortex-A kernel
- 
-
-
diff --git a/en/device-dev/subsystems/utils.md b/en/device-dev/subsystems/utils.md
deleted file mode 100644
index 3b50567c41f81e03d3d937266cd6cb635f15ca4e..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/utils.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Utils
-
-- **[Utils Overview](utils-overview.md)**
-
-- **[Utils Development Guidelines](utils-development-guidelines.md)**
-
-- **[Utils FAQ](utils-faq.md)**
-
-
diff --git a/en/device-dev/subsystems/xts.md b/en/device-dev/subsystems/xts.md
deleted file mode 100644
index 24396f880e05a6ed78dfcb41c8a78660ad469317..0000000000000000000000000000000000000000
--- a/en/device-dev/subsystems/xts.md
+++ /dev/null
@@ -1,648 +0,0 @@
-# XTS
-
-- [Introduction](#section465982318513)
-- [System Types](#section125090457443)
-- [Directory Structure](#section161941989596)
-- [Constraints](#section119744591305)
-- [Usage Guidelines](#section137768191623)
-- [Test Case Development Guidelines](#section3695134065513)
- - [C-based Test Case Development and Compilation \(for the Mini System\)](#section198193336544)
- - [C-based Test Case Execution \(for the Mini System\)](#section13820233175418)
- - [C++-based Test Case Development and Compilation \(for Standard and Small Systems\)](#section3822123311540)
- - [C++-based Test Case Execution \(for Standard and Small Systems\)](#section128222336544)
- - [JavaScript-based Test Case Development \(for the Standard System\)](#section159801435165220)
- - [JavaScript-based Test Case Packaging \(for the Standard System\)](#section445519106559)
-
-
-## Introduction
-
-The X test suite \(XTS\) subsystem contains a set of OpenHarmony certification test suites, including the currently supported application compatibility test suite \(ACTS\) and the device compatibility test suite \(DCTS\) that will be supported in the future.
-
-This subsystem contains the ACTS and **tools** software package.
-
-- The **acts** directory stores the source code and configuration files of ACTS test cases. The ACTS helps device vendors detect the software incompatibility as early as possible and ensures that the software is compatible to OpenHarmony during the entire development process.
-- The **tools** software package stores the test case development framework related to **acts**.
-
-## System Types
-
-OpenHarmony supports the following system types:
-
-- Mini system
-
- A mini system runs on the devices whose memory is greater than or equal to 128 KiB and that are equipped with MCU processors such as ARM Cortex-M and 32-bit RISC-V. This system provides multiple lightweight network protocols and graphics frameworks, and a wide range of read/write components for the IoT bus. Typical products include connection modules, sensors, and wearables for smart home.
-
-- Small system
-
- A small system runs on the devices whose memory is greater than or equal to 1 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides higher security capabilities, standard graphics frameworks, and video encoding and decoding capabilities. Typical products include smart home IP cameras, electronic cat eyes, and routers, and event data recorders \(EDRs\) for smart travel.
-
-- Standard system
-
- A standard system runs on the devices whose memory is greater than or equal to 128 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides a complete application framework supporting the enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. This system applies to high-end refrigerator displays.
-
-
-## Directory Structure
-
-```
-/test/xts
-├── acts # Test code
-│ └── subsystem # Source code of subsystem test cases for the standard system
-│ └── subsystem_lite # Source code of subsystems test cases for mini and small systems
-│ └── BUILD.gn # Build configuration of test cases for the standard system
-│ └── build_lite
-│ └── BUILD.gn # Build configuration of test cases for mini and small systems
-└── tools # Test tool code
-```
-
-## Constraints
-
-Test cases for the mini system must be developed based on C, and those for the small system must be developed based on C++.
-
-## Usage Guidelines
-
-**Table 1** Test case levels
-
-
-
Level
-
-
Definition
-
-
Scope
-
-
-
-
Level0
-
-
Smoke
-
-
Verifies basic functionalities of key features and basic DFX attributes with the most common input. The pass result indicates that the features are runnable.
-
-
-
Level1
-
-
Basic
-
-
Verifies basic functionalities of key features and basic DFX attributes with common input. The pass result indicates that the features are testable.
-
-
-
Level2
-
-
Major
-
-
Verifies basic functionalities of key features and basic DFX attributes with common input and errors. The pass result indicates that the features are functional and ready for beta testing.
-
-
-
Level3
-
-
Regular
-
-
Verifies functionalities of all key features, and all DFX attributes with common and uncommon input combinations or normal and abnormal preset conditions.
-
-
-
Level4
-
-
Rare
-
-
Verifies functionalities of key features under extremely abnormal presets and uncommon input combinations.
-
-
-
-
-
-**Table 2** Test case granularities
-
-
-
Test Scale
-
-
Test Objects
-
-
Test Environment
-
-
-
-
LargeTest
-
-
Service functionalities, all-scenario features, and mechanical power environment (MPE) and scenario-level DFX
-
-
Devices close to real devices
-
-
-
MediumTest
-
-
Modules, subsystem functionalities after module integration, and DFX
-
-
Single device that is actually used. You can perform message simulation, but do not mock functions.
-
-
-
SmallTest
-
-
Modules, classes, and functions
-
-
Local PC. Use a large number of mocks to replace dependencies with other modules.
-
-
-
-
-
-**Table 3** Test types
-
-
-
Type
-
-
Definition
-
-
-
-
Function
-
-
Tests the correctness of both service and platform functionalities provided by the tested object for end users or developers.
-
-
-
Performance
-
-
Tests the processing capability of the tested object under specific preset conditions and load models. The processing capability is measured by the service volume that can be processed in a unit time, for example, call per second, frame per second, or event processing volume per second.
-
-
-
Power
-
-
Tests the power consumption of the tested object in a certain period of time under specific preset conditions and load models.
-
-
-
Reliability
-
-
Tests the service performance of the tested object under common and uncommon input conditions, or specified service volume pressure and long-term continuous running pressure. The test covers stability, pressure handling, fault injection, and Monkey test times.
-
-
-
Security
-
-
Tests the capability of defending against security threats, including but not limited to unauthorized access, use, disclosure, damage, modification, and destruction, to ensure information confidentiality, integrity, and availability.
Tests the privacy protection capability to ensure that the collection, use, retention, disclosure, and disposal of users' private data comply with laws and regulations.
Tests the compliance with various security specifications, such as security design, security requirements, and security certification of the Ministry of Industry and Information Technology (MIIT).
-
-
-
Global
-
-
Tests the internationalized data and localization capabilities of the tested object, including multi-language display, various input/output habits, time formats, and regional features, such as currency, time, and culture taboos.
-
-
-
Compatibility
-
-
Tests backward compatibility of an application with its own data, the forward and backward compatibility with the system, and the compatibility with different user data, such as audio file content of the player and smart SMS messages.
Tests system backward compatibility with its own data and the compatibility of common applications in the ecosystem.
Tests software compatibility with related hardware.
-
-
-
User
-
-
Tests user experience of the object in real user scenarios. All conclusions and comments should come from the users, which are all subjective evaluation in this case.
-
-
-
Standard
-
-
Tests the compliance with industry and company-specific standards, protocols, and specifications. The standards here do not include any security standards that should be classified into the security test.
-
-
-
Safety
-
-
Tests the safety property of the tested object to avoid possible hazards to personal safety, health, and the object itself.
-
-
-
Resilience
-
-
Tests the resilience property of the tested object to ensure that it can withstand and maintain the defined running status (including downgrading) when being attacked, and recover from and adapt defense to the attacks to approach mission assurance.
-
-
-
-
-
-## Test Case Development Guidelines
-
-You should select the appropriate programming language and your target test framework to develop test cases.
-
-**Table 4** Test frameworks and test case languages for different systems
-
-
-
System
-
-
Test Framework
-
-
Language
-
-
-
-
Mini
-
-
HCTest
-
-
C
-
-
-
Small
-
-
HCPPTest
-
-
C++
-
-
-
Standard
-
-
HJSUnit and HCPPTest
-
-
JavaScript and C++
-
-
-
-
-
-### C-based Test Case Development and Compilation \(for the Mini System\)
-
-**Developing test cases for the mini system**
-
-The HCTest framework is used to support test cases developed with the C language. HCTest is enhanced and adapted based on the open-source test framework Unity.
-
-1. Access the **test/xts/acts** repository where the test cases will be stored.
-
- ```
- ├── acts
- │ └──subsystem_lite
- │ │ └── module_hal
- │ │ │ └── BUILD.gn
- │ │ │ └── src
- │ └──build_lite
- │ │ └── BUILD.gn
- ```
-
-2. Write the test case in the **src** directory.
-
- 1 Import the test framework header file.
-
- ```
- #include "hctest.h"
- ```
-
- 2. Use the **LITE\_TEST\_SUIT** macro to define names of the subsystem, module, and test suite.
-
- ```
- /**
- * @brief Registers a test suite named IntTestSuite.
- * @param test Subsystem name
- * @param example Module name
- * @param IntTestSuite Test suite name
- */
- LITE_TEST_SUIT(test, example, IntTestSuite);
- ```
-
- 3. Define Setup and TearDown.
-
- Format: Test suite name+Setup, Test suite name+TearDown.
-
- The Setup and TearDown functions must exist, but function bodies can be empty.
-
- 4. Use the **LITE\_TEST\_CASE** macro to write the test case.
-
- Three parameters are involved: test suite name, test case name, and test case properties \(including type, granularity, and level\).
-
- ```
- LITE_TEST_CASE(IntTestSuite, TestCase001, Function | MediumTest | Level1)
- {
- // Do something
- };
- ```
-
- 5. Use the **RUN\_TEST\_SUITE** macro to register the test suite.
-
- ```
- RUN_TEST_SUITE(IntTestSuite);
- ```
-
-3. Create the configuration file \(**BUILD.gn**\) of the test module.
-
- Create a **BUILD.gn** \(example\) build file in each test module directory. Specify the name of the built static library and its dependent header file and library in the build file. The format is as follows:
-
- ```
- import("//test/xts/tools/lite/build/suite_lite.gni")
- hctest_suite("ActsDemoTest") {
- suite_name = "acts"
- sources = [
- "src/test_demo.c",
- ]
- include_dirs = [ ]
- cflags = [ "-Wno-error" ]
- }
- ```
-
-4. Add build options to the **BUILD.gn** file in the **acts** directory.
-
- You need to add the test module to the **test/xts/acts/build\_lite/BUILD.gn** script in the **acts** directory.
-
- ```
- lite_component("acts") {
- ...
- if(board_name == "liteos_m") {
- features += [
- ...
- "//xts/acts/subsystem_lite/module_hal:ActsDemoTest"
- ]
- }
- }
- ```
-
-5. Run build commands.
-
- Test suites are built along with version build. The ACTS is built together with the debug version.
-
- > **NOTE:**
- >The ACTS build middleware is a static library, which will be linked to the image.
-
-
-### C-based Test Case Execution \(for the Mini System\)
-
-**Executing test cases for the mini system**
-
-Burn the image into the development board.
-
-**Executing the test**
-
-1. Use a serial port tool to log in to the development board and save information about the serial port.
-2. Restart the device and view serial port logs.
-
-**Analyzing the test result**
-
-View the serial port logs, whose format is as follows:
-
-The log for each test suite starts with **Start to run test suite:** and ends with **xx Tests xx Failures xx Ignored**.
-
-### C++-based Test Case Development and Compilation \(for Standard and Small Systems\)
-
-**Developing test cases for small-system devices** \(For examples of the standard system, go to the **global/i18n\_standard directory**.\)
-
-The HCPPTest framework is enhanced and adapted based on the open-source framework Googletest.
-
-1. Access the **test/xts/acts** repository where the test cases will be stored.
-
- ```
- ├── acts
- │ └──subsystem_lite
- │ │ └── module_posix
- │ │ │ └── BUILD.gn
- │ │ │ └── src
- │ └──build_lite
- │ │ └── BUILD.gn
- ```
-
-2. Write the test case in the **src** directory.
-
- 1. Import the test framework header file.
-
- The following statement includes **gtest.h**.
-
- ```
- #include "gtest/gtest.h"
- ```
-
- 2. Define Setup and TearDown.
-
- ```
- using namespace std;
- using namespace testing::ext;
- class TestSuite: public testing::Test {
- protected:
- // Preset action of the test suite, which is executed before the first test case
- static void SetUpTestCase(void){
- }
- // Test suite cleanup action, which is executed after the last test case
- static void TearDownTestCase(void){
- }
- // Preset action of the test case
- virtual void SetUp()
- {
- }
- // Cleanup action of the test case
- virtual void TearDown()
- {
- }
- };
- ```
-
- 3. Use the **HWTEST** or **HWTEST\_F** macro to write the test case.
-
- **HWTEST**: definition of common test cases, including the test suite name, test case name, and case annotation.
-
- **HWTEST\_F**: definition of SetUp and TearDown test cases, including the test suite name, test case name, and case annotation.
-
- Three parameters are involved: test suite name, test case name, and test case properties \(including type, granularity, and level\).
-
- ```
- HWTEST_F(TestSuite, TestCase_0001, Function | MediumTest | Level1) {
- // Do something
- }
- ```
-
-3. Create a configuration file \(**BUILD.gn**\) of the test module.
-
- Create a **BUILD.gn** build file in each test module directory. Specify the name of the built static library and its dependent header file and library in the build file. Each test module is independently built into a **.bin** executable file, which can be directly pushed to the development board for testing.
-
- Example:
-
- ```
- import("//test/xts/tools/lite/build/suite_lite.gni")
- hcpptest_suite("ActsDemoTest") {
- suite_name = "acts"
- sources = [
- "src/TestDemo.cpp"
- ]
-
- include_dirs = [
- "src",
- ...
- ]
- deps = [
- ...
- ]
- cflags = [ "-Wno-error" ]
- }
- ```
-
-4. Add build options to the **BUILD.gn** file in the **acts** directory.
-
- Add the test module to the **test/xts/acts/build\_lite/BUILD.gn** script in the **acts** directory.
-
- ```
- lite_component("acts") {
- ...
- else if(board_name == "liteos_a") {
- features += [
- ...
- "//xts/acts/subsystem_lite/module_posix:ActsDemoTest"
- ]
- }
- }
- ```
-
-5. Run build commands.
-
- Test suites are built along with the version build. The ACTS is built together with the debug version.
-
- > **NOTE:**
- >The ACTS for the small system is independently built to an executable file \(.bin\) and archived in the **suites\\acts** directory of the build result.
-
-
-### C++-based Test Case Execution \(for Standard and Small Systems\)
-
-**Executing test cases for the small system**
-
-Currently, test cases are shared by the NFS and mounted to the development board for execution.
-
-**Setting up the environment**
-
-1. Use a network cable or wireless network to connect the development board to your PC.
-2. Configure the IP address, subnet mask, and gateway for the development board. Ensure that the development board and the PC are in the same network segment.
-3. Install and register the NFS server on the PC and start the NFS service.
-4. Run the **mount** command for the development board to ensure that the development board can access NFS shared files on the PC.
-
- Format: **mount** _NFS server IP address_**:/**_NFS shared directory_ **/**_development board directory_ **nfs**
-
- Example:
-
- ```
- mount 192.168.1.10:/nfs /nfs nfs
- ```
-
-
-**Executing test cases**
-
-Execute **ActsDemoTest.bin** to trigger test case execution, and analyze serial port logs generated after the execution is complete.
-
-### JavaScript-based Test Case Development \(for the Standard System\)
-
-The HJSUnit framework is used to support automated test of OpenHarmony apps that are developed using the JavaScript language based on the JS application framework.
-
-**Basic syntax of test cases**
-
-The test cases are developed with the JavaScript language and must meet the programming specifications of the language.
-
-**Table 5**
-
-
-
Syntax
-
-
Description
-
-
Mandatory
-
-
-
-
beforeAll
-
-
Presets a test-suite-level action executed only once before all test cases are executed. You can pass the action function as the only parameter.
-
-
No
-
-
-
afterAll
-
-
Presets a test-suite-level clear action executed only once after all test cases are executed. You can pass the clear function as the only parameter.
-
-
No
-
-
-
beforeEach
-
-
Presets a test-case-level action executed before each test case is executed. The number of execution times is the same as the number of test cases defined by it. You can pass the action function as the only parameter.
-
-
No
-
-
-
afterEach
-
-
Presets a test-case-level clear action executed after each test case is executed. The number of execution times is the same as the number of test cases defined by it. You can pass the clear function as the only parameter.
-
-
No
-
-
-
describe
-
-
Defines a test suite. You can pass two parameters: test suite name and test suite function. The describe statement supports nesting. You can use beforeall, beforeEach, afterEach, and afterAll in each describe statement.
-
-
Yes
-
-
-
it
-
-
Defines a test case. You can pass three parameters: test case name, filter parameter, and test case function.
-
Usage of the filter parameter:
-
The value of the filter parameter is a 32-bit integer. Setting different bits to 1 means different configurations:
-
bit 0: whether the filter parameter takes effect. 1 means that the test case is used for the function test and other settings of the parameter do not take effect.
Bits 0-10: test case categories
Bits 16-18: test case scales
Bits 24-28: test levels
-
Test case categories: Bits 0-10 indicate FUNCTION (function test), PERFORMANCE (performance test), POWER (power consumption test), RELIABILITY (reliability test), SECURITY (security compliance test), GLOBAL (integrity test), COMPATIBILITY (compatibility test), USER (user test), STANDARD (standard test), SAFETY (security feature test), and RESILIENCE (resilience test), respectively.
-
Test case scales: Bits 16-18 indicate SMALL (small-scale test), MEDIUM (medium-scale test), and LARGE (large-scale test), respectively.
-
-Use the standard syntax of Jasmine to write test cases. The ES6 specification is supported.
-
-1. Store the test cases in the **entry/src/main/js/test** directory, whose structure is as follows:
-
- ```
- ├── BUILD.gn
- │ └──entry
- │ │ └──src
- │ │ │ └──main
- │ │ │ │ └──js
- │ │ │ │ │ └──default
- │ │ │ │ │ │ └──pages
- │ │ │ │ │ │ │ └──index
- │ │ │ │ │ │ │ │ └──index.js # Entry file
- │ │ │ │ │ └──test # Test code
- │ │ │ └── resources # HAP resources
- │ │ │ └── config.json # HAP configuration file
- ```
-
-2. Start the JS test framework and load test cases. The following is an example for **index.js**.
-
- ```
- // Start the JS test framework and load test cases.
- import {Core, ExpectExtend} from 'deccjsunit/index'
-
- export default {
- data: {
- title: ""
- },
- onInit() {
- this.title = this.$t('strings.world');
- },
- onShow() {
- console.info('onShow finish')
- const core = Core.getInstance()
- const expectExtend = new ExpectExtend({
- 'id': 'extend'
- })
- core.addService('expect', expectExtend)
- core.init()
- const configService = core.getDefaultService('config')
- configService.setConfig(this)
- require('../../../test/List.test')
- core.execute()
- },
- onReady() {
- },
- }
- ```
-
-3. Write a unit test case by referring to the following example:
-
- ```
- // Use HJSUnit to perform the unit test.
- describe('appInfoTest', function () {
- it('app_info_test_001', 0, function () {
- var info = app.getInfo()
- expect(info.versionName).assertEqual('1.0')
- expect(info.versionCode).assertEqual('3')
- })
- })
- ```
-
-
-### JavaScript-based Test Case Packaging \(for the Standard System\)
-
-For details about how to build a HAP, see the JS application development guide of the standard system [Building and Creating HAPs](https://developer.harmonyos.com/en/docs/documentation/doc-guides/build_overview-0000001055075201).
-
diff --git a/en/readme.md b/en/readme.md
index 6f5507767fb638dc4a82b16d8c40da15bc4bf0af..c7f787adcd62cb78af7cf616132539ecb702266f 100644
--- a/en/readme.md
+++ b/en/readme.md
@@ -1,77 +1,82 @@
# WELCOME TO OPENHARMONY
+
This project stores OpenHarmony documentation, including the quick start guide, development guides, and API reference. We appreciate your contribution to the OpenHarmony documentation.
-## Motivation
-Traditional OSs are limited to a specific type of device, while OpenHarmony provides distributed features that are compatible with a wide range of different devices. The first version supports devices with 128 KB to 128 MB of memory. Join us as we keep updating OpenHarmony versions.
-For device developers, OpenHarmony utilizes a component-based design to tailor its features to better suit specific devices, based on each device's capabilities and service characteristics. OpenHarmony can run on devices with limited resources and wearables with hundreds of KB of memory, as well as more powerful devices, such as smart home cameras and dashcams with hundreds of MB of memory.
-
-[中文版本](../zh-cn/readme.md)
-
-## Device Development - Documentation Directory Structure
-- [Overview](device-dev/quick-start/overview.md)
-- [Getting Started](device-dev/quick-start/Readme-EN.md)
-- [Source Code Acquisition/Tool Acquisition](device-dev/get-code/Readme-EN.md)
-- [Kernel Usage Guidelines](device-dev/kernel/Readme-EN.md)
-- [Driver Usage Guidelines](device-dev/driver/Readme-EN.md)
-- [Subsystem Development Guidelines](device-dev/subsystems/Readme-EN.md)
- - [Compilation and Building](device-dev/subsystems/compilation-and-building.md)
- - [Distributed Remote Startup](device-dev/subsystems/distributed-remote-startup.md)
- - [Graphics](device-dev/subsystems/graphics.md)
- - [Multimedia](device-dev/subsystems/multimedia.md)
- - [Utils](device-dev/subsystems/utils.md)
- - [AI Framework](device-dev/subsystems/ai-framework.md)
- - [Sensors](device-dev/subsystems/sensors.md)
- - [Application Framework](device-dev/subsystems/application-framework.md)
- - [OTA Upgrade](device-dev/subsystems/ota-upgrade.md)
- - [Security](device-dev/subsystems/security.md)
- - [Startup](device-dev/subsystems/startup.md)
- - [Testing](device-dev/subsystems/testing.md)
- - [DFX](device-dev/subsystems/dfx.md)
- - [R&D Tools](device-dev/subsystems/r-d-tools.md)
- - [X Test Suite](device-dev/subsystems/xts.md)
-- [Bundle Development Guidelines](device-dev/bundles/Readme-EN.md)
-- [Third-Party Library Porting Guide](device-dev/porting/Readme-EN.md)
-- [Device Development Guidelines](device-dev/guide/Readme-EN.md)
- - [WLAN-connected Products](device-dev/guide/wlan-connected-products.md)
- - [Cameras Without a Screen](device-dev/guide/cameras-without-a-screen.md)
- - [Cameras with a Screen](device-dev/guide/cameras-with-a-screen.md)
- - [Visual Application Development](device-dev/guide/visual-application-development.md)
- - [Development Example for Clock Apps](device-dev/guide/development-example-for-clock-apps.md)
- - [Development Example for Platform Drivers](device-dev/guide/development-example-for-platform-drivers.md)
- - [Development Example for Peripheral Drivers](device-dev/guide/development-example-for-peripheral-drivers.md)
-- [Privacy and Security](device-dev/security/Readme-EN.md)
-- [Glossary](device-dev/glossary/glossary.md)
-
-# Application Development - Documentation Directory Structure
-
-- [Getting Started](application-dev/quick-start/getting-started.md)
-- [UI](application-dev/ui/Readme-EN.md)
-- [Media](application-dev/media/Readme-EN.md)
-- [Connectivity](application-dev/connectivity/Readme-EN.md)
-- [JS Reference](application-dev/js-reference/Readme-EN.md)
-
-## Start Contributing
-
-OpenHarmony is an open-source community and encourages everyone in the community to submit patches directly to the project. You can contribute either to the code or documentation.
-- [Contributing to the Code](contribute/contributing-code.md)
-- [Contributing to the Documentation](contribute/documentation-contribution.md)
-
-For more details on how to contribute, see [Contributing Documents](contribute).
-## Get Source Code and Tools
-To download the source code and tools required for the project, click the following links:
-- [Source Code Acquisition](device-dev/get-code/source-code-acquisition.md)
-- [Tool Acquisition](device-dev/get-code/tool-acquisition.md)
-
-## Where to Turn for Help
-You can subscribe to the mailing list to get constant updates on new features, released road maps, and community activities. For how to subscribe to the mailing list or get any other support, see [Communication in Community](https://gitee.com/openharmony/docs/tree/master/contribute/communication-in-community.md).
-
-## Code of Conduct
-OpenHarmony is committed to providing a welcoming and inspiring community for all. In order to maintain a collaborative environment, we recommend you read and follow the community [Code of Conduct](https://gitee.com/openharmony/docs/blob/master/contribute/code-of-conduct.md).
-
-## Contributors & Acknowledgements
-A great open-source project wouldn't be possible without the hard work of many contributors. We'd like to invite anyone from around the world to participate in this exciting journey, and we're grateful for your time, passion, and efforts!
-
-## Release
-In order to provide new features and bug fixes, the community constantly updates code and provides new releases.
-
-See [OpenHarmony Release Notes](release-notes/OpenHarmony-Release-Notes.md).
\ No newline at end of file
+## Contents
+
+- [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)
+ - **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)
+ - **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-camera.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)
+
+ - **bundles**:
+ - [Development Specifications](device-dev/bundles/bundles-standard-rules.md)
+ - [Development Guidelines](device-dev/bundles/bundles-guide.md)
+ - [HPM User Guide](device-dev/bundles/bundles-demo.md)
+
+- Standard System Development Guidelines \(Reference Memory ≥ 128 MB\)
+ - Device development
+ - **overview**: [device development overview](device-dev/overview.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)
+ - **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)
+ - [Platform drivers](device-dev/guide/device-drive-demo.md)
+ - [Peripheral drivers](device-dev/guide/device-outerdrive-demo.md)
+
+ - **porting**:
+
+ [Third-Party Library Porting Guide](device-dev/porting/transplant-thirdparty.md)
+
+ - **bundles**:
+ - [Development Specifications](device-dev/bundles/bundles-standard-rules.md)
+ - [Development Guidelines](device-dev/bundles/bundles-guide.md)
+ - [HPM User Guide](device-dev/bundles/bundles-demo.md)
+
+
+- App development
+ - **Overview**: [app development overview](application-dev/application-dev-guide.md)
+ - **quick-start**: [quick start guide](application-dev/quick-start/Readme-EN.md)
+ - **ui**: [UI](application-dev/ui/Readme-EN.md)
+ - **media**: [media](application-dev/media/Readme-EN.md)
+ - **connectivity**: [networks and connectivity](application-dev/connectivity/Readme-EN.md)
+ - **js-reference**: [JS reference](application-dev/js-reference/Readme-EN.md)
+- **glossary**: [glossary](device-dev/glossary/glossary.md)
+
+## Version Change History
+
+For details, see [Release Notes](release-notes/OpenHarmony-Release-Notes.md).
+
+## Third-Party Open-Source Software and License Notice
+
+None.
+
+## How to Contribute
+
+A great open-source project wouldn't be possible without the hard work of many contributors. We'd like to invite anyone from around the world to [participate](contribute/contribution.md) in this exciting journey, and we're grateful for your time, passion, and efforts!
+
+You can evaluate available documents, make simple modifications, provide feedback on document quality, and contribute your original content. For details, see [Documentation Contribution](contribute/documentation-contribution.md).
+
+Excellent contributors will be awarded and the contributions will be publicized in the developer community.
+