corrected link errors

Signed-off-by: Nwusongqing <wusongqing@huawei.com>

en/application-dev/dfx/hitracemeter-guidelines.md

@@ -5,8 +5,8 @@
 HiTraceMeter provides APIs for system performance tracing. You can call the APIs provided by HiTraceMeter module in your own service logic to effectively track service processes and check the system performance.
 
 ## Available APIs
- 
-The performance tracing APIs are provided by the **hiTraceMeter** module. For details, see [API Reference]( ../reference/apis/js-apis-hitracemeter.md).
+
+The performance tracing APIs are provided by the **hiTraceMeter** module. For details, see [API Reference](../reference/apis/js-apis-hitracemeter.md).
 
 **APIs for performance tracing**
 

en/contribute/OpenHarmony-hdf-coding-guide.md

@@ -190,7 +190,7 @@ root {
 
 [Description] The HDF places the same type of devices in the same host. You can develop and deploy the driver functionalities of the host by layer, so that one driver has multiple nodes. The following figure shows the HDF driver model.
 
-![HDFDriverModel.png]( ../device-dev/driver/figures/HDFDriverModel.png)
+![HDFDriverModel.png](../device-dev/driver/figures/HDF-driver-model.png)
 
 Place devices of the same type in the same host. When adding a device, check whether the host of the same type already exists. If such a host already exists, configure the device in the host. Do not configure the same host again. A device belongs to only one driver. Therefore, do not configure the same device in different hosts.
 

en/device-dev/faqs/faqs-burning.md

@@ -71,7 +71,7 @@
 
 1.  Obtain the U-Boot file.
 
-    >![](public_sys-resources/icon-notice.gif) **NOTICE:** 
+    >![](../public_sys-resources/icon-notice.gif) **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**

en/device-dev/faqs/faqs-startup.md

@@ -9,7 +9,7 @@ During system startup, the error message "[Init] InitReadCfg, parse failed! plea
 
   **Figure 1** Error information
 
-  ![en-us_image_0000001200053087](figures/en-us_image_0000001200053087.png)
+  ![en-us_image_0000001200053087](figures/error-information.png)
 
 **Possible Cause**
 
@@ -57,85 +57,3 @@ Permission verification has been enabled for **SetParameter** and **GetParameter
 
 No action is required.
 
-
-## ueventd Service Failed to Obtain a Socket upon Startup
-
-**Symptom**
-
-After the ueventd service is started, the error message "Failed to get uevent socket, try to create" is displayed, and the error information as shown in the following figure is logged.
-
-  **Figure 2** Failure to obtain a socket
-
-  ![ueventd_socket](figures/ueventd_socket.png)
-
-**Possible Cause**
-
-The ueventd service is started on demand. Upon startup, it first needs to check the environment variables for **fd** of the socket created by the init process. The preceding error information will be displayed if the ueventd service fails to obtain environment variables. The possible causes are as follows:
-1. No socket has been configured for the ueventd service in the **.cfg** file. As a result, the init process does not create a socket for the ueventd service, and no socket ID is present in environment variables.
-2. If a socket has been configured for the ueventd service in the **.cfg** file, it is probable that the ueventd service is also configured in another **.cfg** file but no socket is designated for it.
-
-**Solution**
-
-For case 1, configure a socket for the ueventd service in the **.cfg** file. For details, see [Development Guidelines](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/subsys-boot-init.md#development-guidelines).
-
-For case 2, check all **.cfg** files for any duplicate ueventd service and delete it. Retain only one ueventd service with valid configuration.
-
-
-## ueventd Service Exits Because of a Socket Polling Timeout
-
-**Symptom**
-
-After the ueventd service is started for a period of time, the error message "poll ueventd socket timeout, ueventd exit" is displayed and the ueventd service automatically exits.
-
-**Possible Causes**
-
-The ueventd service is started on demand. When a uevent is reported, the init process receives a socket message and starts the ueventd service to process the message. After processing the message, the ueventd service polls the corresponding socket handle for 30s. If a new socket message is reported within this period of time, the ueventd service continues to process the message. After processing the message, the ueventd service polls the socket handle for 30s once again. If no new socket message is reported within this period of time, the ueventd service exits and returns the socket to the init process for polling. In this case, the preceding error message is displayed.
-
-**Solution**
-
-This is a normal phenomenon and no action is required.
-
-
-## Service with the ondemand Attribute Failed to Start Because of a Configuration Parsing Error
-
-**Symptom**
-
-The service configuration in JSON format cannot be correctly parsed, and the error message "Service is invalid which has both critical and ondemand attribute" is displayed. When the service is started, the error message "Cannot find service" is displayed.
-
-**Possible Cause**
-
-The service configuration is not in the JSON format. This can result in a **.cfg** file parsing error, leading to a service parsing failure. For a service configured with the **ondemand** attribute, the **critical** attribute is set to **1**, or the first value in the **critical** attribute array is set to **1**. When the **ondemand** attribute is configured, the service is started on demand by default. The service exits when it is idle. However, when the **critical** attribute is configured, the service is regarded as a critical system service and is not allowed to exit. Therefore, a conflict occurs if both attributes are configured the same service.
-
-**Solution**
-
-Check whether the service needs to be started on demand. If not, do not configure the **ondemand** attribute. If yes, do not configure the **critical** attribute along with the **ondemand** attribute. To limit the number of times that a critical service exits abnormally, set the first value in the **critical** attribute array to **0** and then add a limitation on the exit times. For example, **"critical": [0, 15, 5]** means that, if a service exits for more than 15 times within 5s, the service will not be started and the system will not be restarted.
-
-
-## Parallel Startup Is Not Effective for Services Configured with the ondemand Attribute
-
-**Symptom**
-
-Services configured with the **ondemand** attribute are not started in the parallel startup phase, regardless of whether **start-mode** is set to **boot**, **normal**, or the default value.
-
-**Possible Cause**
-
-Services configured with the **ondemand** attribute are started only when the startup conditions are met. Therefore, parallel startup is not effective for these services.
-
-**Solution**
-
-If you want to add a service to parallel startup, do not configure the **ondemand** attribute for it.
-
-
-## SA Services Cannot Be Started on Demand
-
-**Symptom**
-
-When an SA service is configured with the **ondemand** attribute, the samgr process does not start the SA service after the SA client sends a request.
-
-**Possible Cause**
-
-At the initial implementation of on-demand startup, **SystemAbilityManager::CheckSystemAbility(int32_t systemAbilityId)** is used for all SA services. To distinguish SA services that are started on demand, **LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)** provided by the samgr process is added. If an SA service is not started on demand, it is probable that the original API is used by mistake.
-
-**Solution**
-
-Use **LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)** for any SA service that needs to be started on demand.

en/device-dev/guide/device-iotcamera-control-example.md

 # Use Case<a name="EN-US_TOPIC_0000001055686082"></a>
 
--   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**.
+-   For details about the development board, compilation, burning, and image running, see  [Hi3518 Development Board](../quick-start/quickstart-lite-overview.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**.
 

en/device-dev/guide/device-wlan-led-control.md

@@ -97,7 +97,7 @@ Based on the Hi3861 platform, the OpenHarmony WLAN module provides abundant peri
 
 ## Verification<a name="section1949121910344"></a>
 
-For details about the compilation and burning processes, see  [Building Source Code](../quick-start/quickstart-lite-steps-hi3861-connection.md#section191121332125319)  and  [Burning Images](../quick-start/quickstart-lite-steps-hi3861-connection.md#section3288165814218)  in the  _Getting Started with Hi3861_.
+For details about the compilation and burning processes, see  [Building](../quick-start/quickstart-lite-steps-hi3861-building.md)  and  [Burning](../quick-start/quickstart-lite-steps-hi3861-burn.md)  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.
 

en/device-dev/porting/Readme-EN.md

@@ -24,7 +24,7 @@ The download steps for other resources are the same as those in the mainline ver
 
 - [Mini System SoC Porting Guide](porting-minichip.md)
   - Porting Preparations
-    - [Before You Start](porting-chip-prepare-knows.md)
+    - [Before You Start](oem_transplant_chip_prepare_knows.md)
     - [Building Adaptation Process](porting-chip-prepare-process.md)
   - Kernel Porting
     - [Overview](porting-chip-kernel-overview.md)

en/device-dev/porting/porting-chip-prepare.md

 # Porting Preparations<a name="EN-US_TOPIC_0000001199842513"></a>
 
--   **[Before You Start](porting-chip-prepare-knows.md)**  
+-   **[Before You Start](oem_transplant_chip_prepare_knows.md)**  
 
 -   **[Building Adaptation Process](porting-chip-prepare-process.md)**  
 

en/device-dev/porting/porting-minichip-cases.md

 # Mini System SoC Porting Cases
 
 -   **[Mini-System Devices with Screens — Bestechnic SoC Porting Case](porting-bes2600w-on-minisystem-display-demo.md)**
--   **[Combo Solution – ASR Chip Porting Case](porting-asr582x-combo-demo.md)**
+

en/device-dev/quick-start/quickstart-lite-package-directory.md

@@ -9,7 +9,7 @@
         - [Burning](quickstart-lite-steps-hi3861-burn.md)
         - [Networking](quickstart-lite-steps-hi3861-netconfig.md)
         - [Debugging and Verification](quickstart-lite-steps-hi3861-debug.md)
-        - [Running](quickstart-lite-steps-hi3816-running.md)
+        - [Running](quickstart-lite-steps-hi3861-running.md)
     - Hi3516 Development Board
         - [Setting Up the Hi3516 Development Board Environment](quickstart-lite-steps-hi3516-setting.md)
         - [Writing a Hello World Program](quickstart-lite-steps-hi3516-application-framework.md)

en/device-dev/subsystems/subsys-tel-guide.md

-# Development Guidelines<a name="EN-US_TOPIC_0000001167051994"></a>
+# Telephony Development<a name="EN-US_TOPIC_0000001167051994"></a>
 
 ## Initializing a Modem Vendor Library<a name="section211mcpsimp"></a>
 
@@ -121,7 +121,7 @@ The following table describes the API for initializing a modem vendor library.
 
 ### Debugging and Verification<a name="section5351151517132"></a>
 
-1.  Use the  [hdc\_std](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/subsys-toolchain-hdc-guide.md#preparations)  tool to connect to a debugging device. Then, run the following command to send the generated  **libril\_vendor.z.so**  library file to the  **/system/lib/**  directory of the device. For details about how to integrate a library file, see  [Integrating Modem Vendor Libraries](#section590mcpsimp).
+1.  Use the  [hdc\_std](subsys-toolchain-hdc-guide.md#section05992022154916)  tool to connect to a debugging device. Then, run the following command to send the generated  **libril\_vendor.z.so**  library file to the  **/system/lib/**  directory of the device. For details about how to integrate a library file, see  [Integrating Modem Vendor Libraries](#section590mcpsimp).
 
     ```
     hdc_std file send libril_vendor.z.so /system/lib/
@@ -241,7 +241,7 @@ The following table describes the APIs for responding to modem service requests,
 
 ### Debugging and Verification<a name="section10207938171413"></a>
 
-1.  Use the  [hdc\_std](../subsystems/subsys-toolchain-hdc-guide.md)  tool to connect to a debugging device. Then, run the following command to send the generated  **libril\_vendor.z.so**  library file to the  **/system/lib/**  directory of the device.
+1.  Use the  [hdc\_std](subsys-toolchain-hdc-guide.md#section05992022154916)  tool to connect to a debugging device. Then, run the following command to send the generated  **libril\_vendor.z.so**  library file to the  **/system/lib/**  directory of the device.
 
     ```
     hdc_std file send libril_vendor.z.so /system/lib/
@@ -380,7 +380,7 @@ The following table describes the API for reporting modem events.
 
 ### Debugging and Verification<a name="section16999174401516"></a>
 
-1.  Use the  [hdc\_std](subsystems/subsys-toolchain-hdc-guide.md)  tool to connect to a debugging device. Then, run the following command to send the generated  **libril\_vendor.z.so**  library file to the  **/system/lib/**  directory of the device.
+1.  Use the  [hdc\_std](subsys-toolchain-hdc-guide.md#section05992022154916)  tool to connect to a debugging device. Then, run the following command to send the generated  **libril\_vendor.z.so**  library file to the  **/system/lib/**  directory of the device.
 
     ```
     hdc_std file send libril_vendor.z.so /system/lib/

en/device-dev/subsystems/subsys-tel-overview.md

-# Telephony Service<a name="EN-US_TOPIC_0000001164469232"></a>
+# Telephony Overview<a name="EN-US_TOPIC_0000001164469232"></a>
 
 ## Introduction<a name="section184mcpsimp"></a>
 

en/readme/common-event-notification.md

@@ -14,7 +14,7 @@ Each application can subscribe to common events as required. After your applicat
 
 ### Architecture
 
-![]( figures/cesfwk_architecture_diagram.png "CES Architecture")
+![](figures/cesfwk_architecture_diagram.png "CES Architecture")
 
 ## Directory Structure