未验证 提交 f8c3b60c 编写于 作者: O openharmony_ci 提交者: Gitee

!5255 翻译已完成4761

Merge pull request !5255 from shawn_he/4761-b
...@@ -22,19 +22,19 @@ When the system is powered on, the kernel loads and starts services and applicat ...@@ -22,19 +22,19 @@ When the system is powered on, the kernel loads and starts services and applicat
The Startup subsystem consists of the following modules: The Startup subsystem consists of the following modules:
- init module - init module<br>
This module corresponds to the init process, which is the first user-mode process started after the kernel is initialized. After the init process starts, it reads and parses the **init.cfg** file. Based on the parsing result, the init module executes the commands listed in [Table 2](../subsystems/subsys-boot-init.md) and starts the key system service processes in sequence with corresponding permissions granted. This module corresponds to the init process, which is the first user-mode process started after the kernel is initialized. After the init process starts, it reads and parses the **init.cfg** file. Based on the parsing result, the init module executes the commands listed in [Table 2](../subsystems/subsys-boot-init.md) and starts the key system service processes in sequence with corresponding permissions granted.
- ueventd module - ueventd module<br>
This module listens for **netlink** events about hot swap of kernel device drivers and dynamically manages the **dev** node of the corresponding device based on the event type. This module listens for **netlink** events about hot swap of kernel device drivers and dynamically manages the **dev** node of the corresponding device based on the event type.
- appspawn module - appspawn module<br>
This module spawns application processes upon receiving commands from the foundation, configures permissions for new processes, and calls the entry function of the application framework. This module spawns application processes upon receiving commands from the foundation, configures permissions for new processes, and calls the entry function of the application framework.
- bootstrap module - bootstrap module<br>
This module provides entry identifiers for starting services and features. When SAMGR is started, the entry function identified by bootstrap is called and system services are started. This module provides entry identifiers for starting services and features. When SAMGR is started, the entry function identified by bootstrap is called and system services are started.
- syspara module - syspara module<br>
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 attributes. 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 attributes.
...@@ -93,7 +93,7 @@ On each development board, you need to partition the memory to store the precedi ...@@ -93,7 +93,7 @@ On each development board, you need to partition the memory to store the precedi
**boot.img** building and loading varies depending on the platform. The implementation on mainstream OpenHarmony platforms is as follows: **boot.img** building and loading varies depending on the platform. The implementation on mainstream OpenHarmony platforms is as follows:
- Hi3516DV300 - Hi3516D V300
On this platform, the **boot.img** file uses the flattened image tree (FIT) format. It is generated by the Mkimage tool by packing the **zImage-dtb** and **cpio** images, which are generated after kernel compilation, based on the information in the **.its** file. On this platform, the **boot.img** file uses the flattened image tree (FIT) format. It is generated by the Mkimage tool by packing the **zImage-dtb** and **cpio** images, which are generated after kernel compilation, based on the information in the **.its** file.
...@@ -146,9 +146,10 @@ On each development board, you need to partition the memory to store the precedi ...@@ -146,9 +146,10 @@ On each development board, you need to partition the memory to store the precedi
| init | /init | | | init | /init | |
| blkdevparts | mmcblk0:1M(boot),15M(kernel),200M(system),200M(vendor),<br>2M(misc),20M(updater),-(userdata) | Partition table information. The kernel creates physical partitions based on the information. | | blkdevparts | mmcblk0:1M(boot),15M(kernel),200M(system),200M(vendor),<br>2M(misc),20M(updater),-(userdata) | Partition table information. The kernel creates physical partitions based on the information. |
| hardware | Hi3516D V300, rk3568, etc. | (Mandatory information) Hardware platform.| | hardware | Hi3516D V300, rk3568, etc. | (Mandatory information) Hardware platform.|
| root | /dev/ram0 (Hi3516DV00) , root=PARTUUID=614e0000-0000 rw (rk3568) | Boot device loaded by the kernel.| | root | /dev/ram0 (Hi3516D V00) , root=PARTUUID=614e0000-0000 rw (rk3568) | Boot device loaded by the kernel.|
| rootfstype | ext4 | Type of the root file system.| | rootfstype | ext4 | Type of the root file system.|
| default_boot_device | soc/10100000.himci.eMMC | (Recommended information) Default boot device. In the first phase of the boot process, a soft link will be created for the required device based on this field.| | default_boot_device | soc/10100000.himci.eMMC | (Recommended information) Default boot device. In the first phase of the boot process, a soft link will be created for the required device based on this field.|
| ohos.required_mount.xxx | /dev/block/platform/soc/10100000.himci.eMMC/by-name/xxx@/usr@ext4@ro,barrier=1@wait,required | The fstab information is first read from cmdline. If this fails, the system will try to read the information from the **fstab.required** file.|
- Mounting of required partitions - Mounting of required partitions
...@@ -179,7 +180,7 @@ On each development board, you need to partition the memory to store the precedi ...@@ -179,7 +180,7 @@ On each development board, you need to partition the memory to store the precedi
- Mapping with **default_boot_device** - Mapping with **default_boot_device**
The kernel writes **bootargs** information to **/proc/cmdline**. The information includes **default_boot_device**, which specifies the primary device directory required for system boot. The kernel writes **bootargs** information to **/proc/cmdline**. The information includes **default_boot_device**, which specifies the primary device directory required for system boot. The content prefixed with **ohos.required_mount.** is the partition mounting information required for system boot. It should be the same as that in the **fstab.required** file. In addition, the block device node in the partition mounting information should be a device node pointed by the soft link under **by-name** in the **default_boot_device** directory. For example, if the value of **default_boot_device** is **soc/10100000.himci.eMMC**, then the value of **ohos.required_mount.system** contains **/dev/block/platform/soc/10100000.himci.eMMC/by-name/system**, which is the soft link pointing to the system device node.
During creation of a block device node, the device path will be matched against the value of **default_boot_device**. If the matching is successful, a soft link pointing to the real block device node will be created in **/dev/block/by-name**. In this way, device node access is made irrelevant to the chip platform. During creation of a block device node, the device path will be matched against the value of **default_boot_device**. If the matching is successful, a soft link pointing to the real block device node will be created in **/dev/block/by-name**. In this way, device node access is made irrelevant to the chip platform.
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册