!4484 4247 处理完成：更新 js-apis-environment.md

Merge pull request !4484 from ester.zhou/TR-4247

en/application-dev/reference/apis/js-apis-environment.md

 # Environment
 
-> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE**
+> **NOTE**
 >
 > - The initial APIs of this module are supported since API version 8. Newly added APIs will be marked with a superscript to indicate their earliest API version.
 > - The APIs of this module are system APIs and cannot be called by third-party applications.
 
+This module provides JS APIs for obtaining the root directories of the storage and public files.
+
 ## Modules to Import
 
 ```js

en/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md

@@ -79,7 +79,7 @@ kernel_version = "3.0.0"                --- Kernel version, which corresponds to
 
 ![hb env](figures/bes2600_hb_env.png)
 
-Before running the `hb build` command, complete the LiteOS-M kernel adaptation. For details, see [Kernel Porting](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md#%E5%86%85%E6%A0%B8%E7%A7%BB%E6%A4%8D).
+Before running the `hb build` command, complete the LiteOS-M kernel adaptation. For details, see [Kernel Porting](https://gitee.com/openharmony/docs/blob/master/en/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md#%E5%86%85%E6%A0%B8%E7%A7%BB%E6%A4%8D).
 
 ## Kernel Porting
 

en/device-dev/porting/porting-smallchip-kernel-a.md

@@ -18,7 +18,7 @@ The LiteOS Cortex-A initialization process consists of seven 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.  Define  **g\_archMmuInitMapping**, the global array of MMU mappings, to specify the memory segment attributes and the virtual-to-physical address mappings. The memory mapping will be established based on this array during kernel startup.
-3.  If there are multiple cores, define  **struct SmpOps**, the handle to the slave core operation function. The  **SmpOps-\>SmpCpuOn**  function needs to implement the feature of waking up a slave core. Then, define the  **SmpRegFunc**  function and call the  **LOS\_SmpOpsSet**  interface to register the handle. The registration process is completed by starting the framework using  **LOS\_MODULE\_INIT\(SmpRegFunc, LOS\_INIT\_LEVEL\_EARLIEST\)**.
+3.  If there are multiple cores, define  **struct SmpOps**, the handle to the secondary core operation function. The  **SmpOps-\>SmpCpuOn**  function needs to implement the feature of waking up a secondary core. Then, define the  **SmpRegFunc**  function and call the  **LOS\_SmpOpsSet**  interface to register the handle. The registration process is completed by starting the framework using  **LOS\_MODULE\_INIT\(SmpRegFunc, LOS\_INIT\_LEVEL\_EARLIEST\)**.
 4.  Create a kernel image based on the linker script  **board.ld**.
 5.  Perform 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.
 6.  Enable the assembly code in  **reset\_vector.S**  to jump 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**. Then, create the  **SystemInit**  task to be implemented in the board code, with  **OsSchedStart\(\)**  enabled for task scheduling.