From 24eddc9a8f3bec9fb71c26b270193474ac48f4ea Mon Sep 17 00:00:00 2001 From: Annie_wang Date: Sat, 16 Apr 2022 10:01:18 +0800 Subject: [PATCH] update docs Signed-off-by: Annie_wang --- en/device-dev/Readme-EN.md | 2 +- en/device-dev/device-dev-guide.md | 7 ++----- .../driver/driver-peripherals-touch-des.md | 4 ++-- .../driver/driver-platform-adc-develop.md | 2 +- .../driver/driver-platform-dac-develop.md | 2 +- .../driver/driver-platform-i2c-develop.md | 2 +- .../driver/driver-platform-i3c-develop.md | 2 +- .../driver/driver-platform-mipicsi-develop.md | 2 +- .../driver/driver-platform-mipidsi-develop.md | 2 +- .../driver/driver-platform-mmc-develop.md | 2 +- .../driver/driver-platform-pwm-develop.md | 2 +- .../driver/driver-platform-rtc-develop.md | 2 +- .../driver/driver-platform-sdio-develop.md | 2 +- .../driver/driver-platform-uart-develop.md | 8 +------- .../driver/driver-platform-watchdog-develop.md | 2 +- .../subsys-security-devicesecuritylevel.md | 15 ++++++++------- 16 files changed, 25 insertions(+), 33 deletions(-) diff --git a/en/device-dev/Readme-EN.md b/en/device-dev/Readme-EN.md index eb6e2ceafd..3f84a69d54 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 2fd16e2ec4..8a891ecc8c 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 15c1892db7..ecaf1c771e 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 36dca8941b..fd48b7f8b7 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 11585ba116..902035e732 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 4ce103b1f9..c5dddbd42f 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 e21de4f0cc..e5b08e2067 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 f5691e402b..4c84061f5c 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 326076cc91..ceb69f730c 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 3c9c9cd6d0..7becfa6f23 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 4207b04e5d..269e990a87 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 42d1d4126c..20639f951a 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 330d863572..0f7e41238f 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 b9592d57cc..bc6d827363 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 1c3d0b5d65..367b2531c4 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 203873ca01..e123f16859 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 { -- GitLab