diff --git a/en/device-dev/Readme-EN.md b/en/device-dev/Readme-EN.md index eb6e2ceafd34f71881c393a6d0e2fb93423ebb69..3f84a69d54746b0a839ff546c2dfc6536a13f089 100644 --- a/en/device-dev/Readme-EN.md +++ b/en/device-dev/Readme-EN.md @@ -3,7 +3,7 @@ - [Device Development Overview](device-dev-guide.md) - Learn About OpenHarmony - [OpenHarmony Community](../OpenHarmony-Overview.md) - - [Glossary](glossary/glossary.md) + - [Glossary](glossary.md) - [Release Notes](../release-notes/Readme.md) - Quick Start - [Mini and Small Systems](quick-start/quickstart-lite.md) diff --git a/en/device-dev/device-dev-guide.md b/en/device-dev/device-dev-guide.md index 2fd16e2ec4bdf2e8fc67dffdda452c0117215543..8a891ecc8c8d2db8510d4ae2ffa7cde541e08eeb 100644 --- a/en/device-dev/device-dev-guide.md +++ b/en/device-dev/device-dev-guide.md @@ -27,19 +27,16 @@ In addition, OpenHarmony provides a wide array of system components that can be ## 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) | Topic| Development Scenario| Related Documentation| | -------- | -------- | -------- | | About OpenHarmony| Getting familiar with OpenHarmony| - [About OpenHarmony](https://gitee.com/openharmony)
- [Glossary](../glossary.md) | | Development resources| Preparing for your development| - [Obtaining Source Code](get-code/sourcecode-acquire.md)
- [Obtaining Tools](get-code/gettools-acquire.md) | -| Getting started| Getting started with setup, build, burning, debugging, and running of OpenHarmony| [Mini and Small Systems](quickstart/quickstart-lite.md)| +| Getting started| Getting started with setup, build, burning, debugging, and running of OpenHarmony| [Mini and Small Systems](quick-start/quickstart-ide-lite-overview.md)| | Basic capabilities| Using basic capabilities of OpenHarmony| - [Kernel for Mini System](kernel/kernel-mini-overview.md)
- [Kernel for Small System](kernel/kernel-small-overview.md)
- [HDF](driver/driver-hdf-overview.md)
- [Subsystems](subsystems/subsys-build-mini-lite.md)
- [Security Guidelines](security/security-guidelines-overall.md)
- [Privacy Protection](security/security-privacy-protection.md)| | Advanced development| Developing smart devices based on system capabilities| - [WLAN-connected Products](guide/device-wlan-led-control.md)
- [Cameras Without a Screen](guide/device-iotcamera-control-overview.md)
- [Cameras with a Screen](guide/device-camera-control-overview.md) | -| Porting and adaptation| - Porting and adapting OpenHarmony to an SoC
- Porting and adapting OpenHarmony to a third-party library| - [Mini System SoC Porting](porting/oem_transplant_chip_prepare_knows.md)
- [Small System SoC Porting](porting/porting-smallchip-prepare-needs.md)
- [Third-Party Library Porting for Mini and Small Systems](porting/porting-thirdparty-overview.md) | +| Porting and adaptation| - Porting and adapting OpenHarmony to an SoC
- Porting and adapting OpenHarmony to a third-party library| - [Mini System SoC Porting](porting/porting-minichip.md)
- [Small System SoC Porting](porting/porting-smallchip-prepare-needs.md)
- [Third-Party Library Porting for Mini and Small Systems](porting/porting-thirdparty-overview.md) | | Contributing components| Contributing components to OpenHarmony| - [HPM Part Overview](hpm-part/hpm-part-about.md)
- [HPM Part Development](hpm-part/hpm-part-development.md)
- [HPM Part Reference](hpm-part/hpm-part-reference.md) | | Reference| Referring to development specifications| [FAQs](faqs/faqs-overview.md) | diff --git a/en/device-dev/driver/driver-peripherals-touch-des.md b/en/device-dev/driver/driver-peripherals-touch-des.md index 15c1892db7902caa09c05182bae61ac9cdc35c16..ecaf1c771e1a4dba7fd268710910035ebe6f030f 100644 --- a/en/device-dev/driver/driver-peripherals-touch-des.md +++ b/en/device-dev/driver/driver-peripherals-touch-des.md @@ -88,7 +88,7 @@ Perform the following steps: 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](driver-hdf-development.md#section1969312275533). + 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](driver-hdf-development.md#how-to-development). 2. Complete the board-level configuration and private data configuration of the touchscreen. @@ -96,7 +96,7 @@ Perform the following steps: 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](driver-platform-gpio-des.md#section1635911016188). + Use the platform APIs to perform operations for the reset pins, interrupt pins, and power based on the communications interfaces designed for boards. For details about the GPIO-related operations, see [GPIO](driver-platform-gpio-des.md#overview). ## Development Example diff --git a/en/device-dev/driver/driver-platform-adc-develop.md b/en/device-dev/driver/driver-platform-adc-develop.md index 36dca8941b3f294d34f375496db3b767483ceb49..fd48b7f8b7ae6defb0a09ff48587c6cb7228c8d5 100644 --- a/en/device-dev/driver/driver-platform-adc-develop.md +++ b/en/device-dev/driver/driver-platform-adc-develop.md @@ -89,7 +89,7 @@ The ADC module adaptation involves the following steps: >![](../public_sys-resources/icon-note.gif) **NOTE** - >For details, see [Available APIs](#availableapis). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/driver/driver-platform-dac-develop.md b/en/device-dev/driver/driver-platform-dac-develop.md index 11585ba1168c289a2963112996f36391b97eec5e..902035e732d52abee81c13fa0ce0fa377b3622e2 100644 --- a/en/device-dev/driver/driver-platform-dac-develop.md +++ b/en/device-dev/driver/driver-platform-dac-develop.md @@ -284,7 +284,7 @@ The DAC module adaptation procedure is as follows: ``` ![](../public_sys-resources/icon-note.gif) **NOTE**
- For details about **DacMethod**, see [Available APIs](#section752964871810). + For details about **DacMethod**, see [Available APIs](#available-apis). - **Init** function diff --git a/en/device-dev/driver/driver-platform-i2c-develop.md b/en/device-dev/driver/driver-platform-i2c-develop.md index 4ce103b1f9026e0ed0f44cac21f7e14f148a7d61..c5dddbd42ffdf3234046dfca56689dd44eeb15c5 100644 --- a/en/device-dev/driver/driver-platform-i2c-develop.md +++ b/en/device-dev/driver/driver-platform-i2c-develop.md @@ -70,7 +70,7 @@ The I2C module adaptation involves the following steps: >![](../public_sys-resources/icon-note.gif) **NOTE** - >For details, see [Available APIs](#availableapis). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/driver/driver-platform-i3c-develop.md b/en/device-dev/driver/driver-platform-i3c-develop.md index e21de4f0cc61b257bf87c4171622e44b5dd37e50..e5b08e2067c5c2dd01c39b64dc7d1b4f48364fa1 100644 --- a/en/device-dev/driver/driver-platform-i3c-develop.md +++ b/en/device-dev/driver/driver-platform-i3c-develop.md @@ -52,7 +52,7 @@ The I3C module adaptation involves the following steps: 3. Instantiate the I3C controller object. - Initialize **I3cCntlr**. - - Instantiate **I3cMethod** in **I3cCntlr**. For details, see [Available APIs](#Available_apis). + - Instantiate **I3cMethod** in **I3cCntlr**. For details, see [Available APIs](#available-apis). 4. Register an interrupt handler. Register an interrupt handler for the controller to implement the device hot-join and in-band interrupt (IBI) features. diff --git a/en/device-dev/driver/driver-platform-mipicsi-develop.md b/en/device-dev/driver/driver-platform-mipicsi-develop.md index f5691e402b30a14bf5316490a5fa83a504f2d0e9..4c84061f5cf79be998c1ed5dca454b6376566abc 100644 --- a/en/device-dev/driver/driver-platform-mipicsi-develop.md +++ b/en/device-dev/driver/driver-platform-mipicsi-develop.md @@ -214,7 +214,7 @@ The MIPI CSI module adaptation involves the following steps: - Instantiate **MipiCsiCntlrMethod** in the **MipiCsiCntlr** object. >![](../public_sys-resources/icon-note.gif) **NOTE:** - >For details, see [Available APIs](#section735525713405). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/driver/driver-platform-mipidsi-develop.md b/en/device-dev/driver/driver-platform-mipidsi-develop.md index 326076cc91d79ac4b7072174175901e236bf09f2..ceb69f730c2fe94c62bf1bff90cb05601d8a799b 100644 --- a/en/device-dev/driver/driver-platform-mipidsi-develop.md +++ b/en/device-dev/driver/driver-platform-mipidsi-develop.md @@ -118,7 +118,7 @@ The MIPI DSI module adaptation involves the following steps: >![](../public_sys-resources/icon-note.gif) **NOTE** - >For details, see [Available APIs](#availableapis). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/driver/driver-platform-mmc-develop.md b/en/device-dev/driver/driver-platform-mmc-develop.md index 3c9c9cd6d09c86e92add16e9a6b01237716f6e07..7becfa6f2308da0b8e3143b0edc11c0e7d307bcd 100644 --- a/en/device-dev/driver/driver-platform-mmc-develop.md +++ b/en/device-dev/driver/driver-platform-mmc-develop.md @@ -209,7 +209,7 @@ The MMC module adaptation involves the following steps: >![](../public_sys-resources/icon-note.gif) **NOTE** - >For details, see [Available APIs](#availableapis). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/driver/driver-platform-pwm-develop.md b/en/device-dev/driver/driver-platform-pwm-develop.md index 4207b04e5da8c3951c3b84e2f641650e38d6cdfe..269e990a8784782725bfbb054e5bdd6c8cd968b7 100644 --- a/en/device-dev/driver/driver-platform-pwm-develop.md +++ b/en/device-dev/driver/driver-platform-pwm-develop.md @@ -81,7 +81,7 @@ The PWM module adaptation involves the following steps: >![](../public_sys-resources/icon-note.gif) **NOTE** - >For details, see [Available APIs](#availableapis). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/driver/driver-platform-rtc-develop.md b/en/device-dev/driver/driver-platform-rtc-develop.md index 42d1d4126c11dc4f708816f7d2f1701931ba504f..20639f951acdbb5c97ec050fdc1f4712b579fe35 100644 --- a/en/device-dev/driver/driver-platform-rtc-develop.md +++ b/en/device-dev/driver/driver-platform-rtc-develop.md @@ -196,7 +196,7 @@ The RTC module adaptation involves the following steps: >![](../public_sys-resources/icon-note.gif) **NOTE** - >For details, see [Available APIs](#availableapis). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/driver/driver-platform-sdio-develop.md b/en/device-dev/driver/driver-platform-sdio-develop.md index 330d863572c1f5f2041dfbabb8ac6efe46e8ffd2..0f7e41238f87543d23c4b34146f8829ad0424d22 100644 --- a/en/device-dev/driver/driver-platform-sdio-develop.md +++ b/en/device-dev/driver/driver-platform-sdio-develop.md @@ -292,7 +292,7 @@ The SDIO module adaptation involves the following steps: >![](../public_sys-resources/icon-note.gif) **NOTE** - >For details, see [Available APIs](#availableapis). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/driver/driver-platform-uart-develop.md b/en/device-dev/driver/driver-platform-uart-develop.md index b9592d57cc1de947df9d21ba44c4f362b2f2586e..bc6d8273634db163254459755a4aceb46c3f4993 100644 --- a/en/device-dev/driver/driver-platform-uart-develop.md +++ b/en/device-dev/driver/driver-platform-uart-develop.md @@ -1,11 +1,5 @@ # UART -- [Overview](#section1761881586154520) -- [How to Develop](#section944397404154520) - - [UartHostMethod](#section192316441461) - -- [Development Example](#section774610224154520) - ## Overview In the Hardware Driver Foundation \(HDF\), the Universal Asynchronous Receiver/Transmitter \(UART\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage. @@ -186,7 +180,7 @@ The UART module adaptation involves the following steps: >![](../public_sys-resources/icon-note.gif) **NOTE** - >For details, see [Available APIs](#availableapis). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/driver/driver-platform-watchdog-develop.md b/en/device-dev/driver/driver-platform-watchdog-develop.md index 1c3d0b5d658d7456667c9ec362718eba9989a370..367b2531c4e9edf353aef4c821be9e1f8ae094dc 100644 --- a/en/device-dev/driver/driver-platform-watchdog-develop.md +++ b/en/device-dev/driver/driver-platform-watchdog-develop.md @@ -129,7 +129,7 @@ The Watchdog module adaptation involves the following steps: >![](../public_sys-resources/icon-note.gif) **NOTE** - >For details, see [Available APIs](#availableapis). + >For details, see [Available APIs](#available-apis). 4. Debug the driver. diff --git a/en/device-dev/subsystems/subsys-security-devicesecuritylevel.md b/en/device-dev/subsystems/subsys-security-devicesecuritylevel.md index 203873ca0162c84c1b7d7c90bb378bddc6a7de2c..e123f16859967aca7377d941f8f6075837debbe6 100644 --- a/en/device-dev/subsystems/subsys-security-devicesecuritylevel.md +++ b/en/device-dev/subsystems/subsys-security-devicesecuritylevel.md @@ -42,7 +42,7 @@ The security level of each device in a Super Device provides the decision-making ### Constraints -The default security level of OpenHarmony devices is SL1. Device manufacturers can customize a higher security level based on service requirements. For details, see [Customizing Device Security Levels](#customizingdevicesecuritylevels). +The default security level of OpenHarmony devices is SL1. Device manufacturers can customize a higher security level based on service requirements. For details, see [Customizing Device Security Levels](#customizing-device-security-levels). ## Development Guidelines @@ -187,7 +187,7 @@ To ensure its integrity and non-repudiation, the security level information must The DSLM module provides default implementation of security level information synchronization and verification. It is assumed that the security level of all OpenHarmony devices is SL1, and a loose verification scheme is used. For details, see the [source code](https://gitee.com/openharmony/security_device_security_level/tree/master/oem_property/ohos). -You can change the device security level as required. For details about the OpenHarmony device security levels, see [Basic Concepts](#basicconcepts). You can also use more severe verification schemes, including but are not limited to using device-specific credential, periodically downloading updated credentials from a server and strictly authenticating the issuer and validity period of the credentials, and using Trusted Execution Environment (TEE) or even Secure Element (SE) to sign credential files. +You can change the device security level as required. For details about the OpenHarmony device security levels, see [Basic Concepts](#basic-concepts). You can also use more severe verification schemes, including but are not limited to using device-specific credential, periodically downloading updated credentials from a server and strictly authenticating the issuer and validity period of the credentials, and using Trusted Execution Environment (TEE) or even Secure Element (SE) to sign credential files. ### Generating a Credential File @@ -287,9 +287,9 @@ MGUCMDb9xoiFzTWVkHDU3VWSVQ59gLyw4TchZ0+eQ3vUfQsLt3Hkg0r7a/PmhkNr3X/mTgIxAIywIRE6 > This step must be performed in a secure and reliable environment, for example, a cryptographic machine that meets related security requirements, to ensure that the key used for signature is not disclosed. > The key pairs involved in this step do not need to be generated each time. Secure key pairs can be reused. -##### 4.1 Generate level-3 signature verification information. +##### 4.1 Generate verification information for an end-entity certificate signature. -1. Generate an ECDSA key pair `` and `` for a level-2 signature. +1. Generate an ECDSA key pair `` and `` for an intermediate CA certificate signature. 2. Use `` to sign `` (generated in step 3.2) to obtain ``. 3. Combine `` and `` into a JSON string. The following is an example: @@ -300,11 +300,12 @@ MGUCMDb9xoiFzTWVkHDU3VWSVQ59gLyw4TchZ0+eQ3vUfQsLt3Hkg0r7a/PmhkNr3X/mTgIxAIywIRE6 } ``` -##### 4.2 Generate level-2 signature verification information. +##### 4.2 Generate verification information for an intermediate CA certificate signature. -1. Generate an ECDSA key pair `` and `` for a level-1 signature. +1. Generate an ECDSA key pair `` and `` for a root certificate signature. 2. Use `` to sign `` (generated in step 4.1) to obtain ``. -3. Combine `` and `` into a JSON string. The following is an example: +3. Combine `` and `` into a JSON string. +The following is an example: ``` json {