diff --git a/zh-cn/device-dev/subsystems/subsys-boot-overview.md b/zh-cn/device-dev/subsystems/subsys-boot-overview.md index b01a66bd714d51a20eef8bf11c1f9b844db5b3f7..ab904f73a95bc8f7682fa500aeaa09c65bdc1eea 100644 --- a/zh-cn/device-dev/subsystems/subsys-boot-overview.md +++ b/zh-cn/device-dev/subsystems/subsys-boot-overview.md @@ -215,7 +215,7 @@ return fstab; } ``` - 以上代码分别展示了获取fstab信息的两种方式，首先调用LoadFstabFromCommandLine()，从cmdline中获取fstab信息，如果获取失败，则输出log，表示继续尝试从fstab.required文件中获取fstab信息。 + 以上代码分别展示了获取fstab信息的两种方式，首先调用`LoadFstabFromCommandLine()`，从cmdline中获取fstab信息，如果获取失败，则输出log，表示继续尝试从`fstab.required`文件中获取fstab信息。 对于system分区来说，其读到devices中的关键信息如下所示： ``` @@ -244,7 +244,7 @@ int ret = GetProcCmdlineValue("default_boot_device", buffer, bootDevice, CMDLINE_VALUE_LEN_MAX); INIT_CHECK_ONLY_ELOG(ret == 0, "Failed get default_boot_device value from cmdline"); ``` - 这里取得的default_boot_device的值应该是soc/10100000.himci.eMMC，也就对应了system分区设备所在目录，这一值存放在了bootDevice这个全局变量当中，将在后续创建system分区设备软链接前进行匹配。 + 这里取得的`default_boot_device`的值应该是`soc/10100000.himci.eMMC`，也就对应了system分区设备所在目录，这一值存放在了bootDevice这个全局变量当中，将在后续创建system分区设备软链接前进行匹配。 4. 处理required设备uevent事件 ``` @@ -264,11 +264,11 @@ break; } ``` - 存在devices中的设备信息，就是在此处与内核上报的uevent事件进行匹配的。对于system分区设备的uevent消息，其uevent->partitionName值应该为system，与devices中存在的/dev/block/platform/fe310000.sdhci/by-name/system字段匹配成功，则开始处理system分区设备的uevent消息。 + 存在devices中的设备信息，就是在此处与内核上报的uevent事件进行匹配的。对于system分区设备的uevent消息，其`uevent->partitionName`值应该为`system`，与devices中存在的`/dev/block/platform/fe310000.sdhci/by-name/system`字段匹配成功，则开始处理system分区设备的uevent消息。 5. 创建required设备节点和对应软链接 - 首先应该格式化对应软链接的路径，这一部分就用到了bootargs中default_boot_device的值，与上报的required设备节点路径进行匹配，以创建平台无关的可读性更高的指向该设备节点的软链接，关键部分代码如下： + 首先应该格式化对应软链接的路径，这一部分就用到了`bootargs`中`default_boot_device`的值，与上报的required设备节点路径进行匹配，以创建平台无关的可读性更高的指向该设备节点的软链接，关键部分代码如下： ``` if (STRINGEQUAL(bus, "/sys/bus/platform")) { INIT_LOGV("Find a platform device: %s", parent); @@ -285,10 +285,10 @@ ``` 首先解释一下这段代码中出现的关键变量。 - bus: 这是一个保存了路径信息的字符串，路径是当前处理的设备所连接的总线路径。 - parent: 同样是一个保存了路径信息的字符串，路径是从uevent->syspath取出的当前处理的设备路径。 - links：事先申请好的指向保存软链接路径内存的指针 - bootDevice: 存放bootargs中default_boot_device值的字符串 + - bus: 这是一个保存了路径信息的字符串，路径是当前处理的设备所连接的总线路径。 + - parent: 同样是一个保存了路径信息的字符串，路径是从`uevent->syspath`取出的当前处理的设备路径。 + - links：事先申请好的指向保存软链接路径内存的指针。 + - bootDevice: 存放`bootargs`中`default_boot_device`值的字符串。 根据代码可知，只有处理到所连接总线类型为platform时的设备才会创建对应软链接，这一软链接所在的目录是： ``` /dev/block/platform/soc/10100000.himci.eMMC/by-name @@ -299,7 +299,7 @@ ``` /sys/devices/platform/soc/10100000.himci.eMMC/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p5 ``` - 因此在处理内核上报的该设备uevent消息时，会与bootDevice中的路径soc/10100000.himci.eMMC相匹配，因此而创建相应的软链接，这一软连接的路径是： + 因此在处理内核上报的该设备uevent消息时，会与bootDevice中的路径`soc/10100000.himci.eMMC`相匹配，因此而创建相应的软链接，这一软连接的路径是： ``` /dev/block/by-name/system ``` @@ -339,16 +339,16 @@ - init执行system和vendor中的启动脚本，挂载vendor中更多的分区 -挂载完必要的分区后，init扫描各个脚本文件。vendor中与芯片或开发板相关的初始化脚本入口如/vendor/etc/init.{ohos.boot.hardware}.cfg。vendor中扩展的挂载分区文件是/vendor/etc/fstab.{ohos.boot.hardware}。hardware的来源是bootloader传递给内核的bootargs。 +挂载完必要的分区后，init扫描各个脚本文件。vendor中与芯片或开发板相关的初始化脚本入口如`/vendor/etc/init.{ohos.boot.hardware}.cfg`。vendor中扩展的挂载分区文件是`/vendor/etc/fstab.{ohos.boot.hardware}`。hardware的来源是bootloader传递给内核的bootargs。 ### 无ramdisk的启动加载流程 -有些开发板没有采用ramdisk启动引导，直接通过内核挂载system.img。此场景需要修改productdefine中的产品配置文件，通过"enable_ramdisk"开关关闭ramdisk生成，init也不会从ramdisk里二次启动到system。 +有些开发板没有采用ramdisk启动引导，直接通过内核挂载`system.img`。此场景需要修改productdefine中的产品配置文件，通过"enable_ramdisk"开关关闭ramdisk生成，init也不会从ramdisk里二次启动到system。 -此场景的主要启动过程与上述流程类似，只是有ramdisk时，init会把system.img挂载到/usr目录，然后chroot到/usr下；而没有ramdisk时，没有chroot过程，但是都会读取init.cfg文件从而执行脚本。 +此场景的主要启动过程与上述流程类似，只是有ramdisk时，init会把`system.img`挂载到`/usr`目录，然后chroot到`/usr`下；而没有ramdisk时，没有chroot过程，但是都会读取`init.cfg`文件从而执行脚本。 -对于无ramdisk的启动加载，即system as root. 在bootloader阶段将根文件系统所在的块设备通过bootargs传给内核，如root=/dev/mmcblk0p5，rootfstype=ext4。内核在初始化根文件系统时，解析bootargs中root，完成根文件系统的挂载。 +对于无ramdisk的启动加载，即system as root. 在bootloader阶段将根文件系统所在的块设备通过bootargs传给内核，如`root=/dev/mmcblk0p5，rootfstype=ext4`。内核在初始化根文件系统时，解析bootargs中root，完成根文件系统的挂载。 ### A/B分区启动 @@ -369,7 +369,7 @@ OpenHarmony现支持A/B双分区启动（主备系统分区），即在设备的 return GetSlotInfoFromCmdLine("bootslots"); } ``` - 在系统正常启动后，用户可以在控制台通过系统参数ohos.boot.bootslots来获取bootslots的值，以查看当前系统是否支持A/B分区启动。获取该系统参数的具体命令如下： + 在系统正常启动后，用户可以在控制台通过系统参数`ohos.boot.bootslots`来获取`bootslots`的值，以查看当前系统是否支持A/B分区启动。获取该系统参数的具体命令如下： ``` param get ohos.boot.bootslots ``` @@ -378,7 +378,7 @@ OpenHarmony现支持A/B双分区启动（主备系统分区），即在设备的 currentslot是指当前启动的系统分区，比如A分区或B分区。currentslot的值使用数字表示，比如数字1表示当前启动A分区，数字2表示当前启动B分区。 - init在启动的第一阶段通过bootslots判断系统是否支持A/B分区，若不支持，将不再获取currentslot值，直接启动默认系统分区；若支持，将会继续获取currentslot值，根据该值判断当前启动的系统分区为A分区或B分区。init获取currentslot的主要接口如下： + init在启动的第一阶段通过bootslots判断系统是否支持A/B分区，若不支持，将不再获取`currentslot`值，直接启动默认系统分区；若支持，将会继续获取`currentslot`值，根据该值判断当前启动的系统分区为A分区或B分区。init获取`currentslot`的主要接口如下： ``` int GetCurrentSlot(void) { @@ -399,7 +399,7 @@ OpenHarmony现支持A/B双分区启动（主备系统分区），即在设备的 - A/B分区启动流程 - 1. 获取当前启动的A/B分区信息，即currentslot信息。 + 1. 获取当前启动的A/B分区信息，即`currentslot`信息。 2. 以原始fstab为基础构造新的分区挂载配置，为支持A/B启动的分区（目前支持的分区有system分区和chipset分区）添加对应的"_a"或"_b"后缀。 3. 按照构造后的分区挂载配置挂载带有相应后缀的分区并切换到启动的第二阶段，启动第二阶段将在具体的A分区或B分区中进行，涉及A/B分区启动部分至此结束。 @@ -431,49 +431,50 @@ OpenHarmony现支持A/B双分区启动（主备系统分区），即在设备的 使用原始镜像构造A/B分区镜像，测试A/B分区启动功能 - 复制system、vendor镜像并添加_b后缀。 - - 在分区表（parameter.txt）中添加system_b、vendor_b分区。 + - 在分区表（`parameter.txt`）中添加system_b、vendor_b分区。 2. 烧写A/B分区镜像 - - 在rk3568烧写工具中导入配置，选择带有system_b和vendor_b分区的parameter.txt。 + - 在rk3568烧写工具中导入配置，选择带有system_b和vendor_b分区的`parameter.txt`。 - 按照新的分区表配置选择镜像（注意新增的system_b和vendor_b镜像），选择完成后烧写。 3. 启动完成后 - 1. 执行cat /proc/cmdline，能够找到bootslot=2，说明当前系统支持A/B分区启动。 + 1. 执行`cat /proc/cmdline`，能够找到`bootslot=2`，说明当前系统支持A/B分区启动。 ![cmdline](figures/ABStartup_2.png) - 2. 执行param get ohos.boot.bootslot，得到的结果是2，说明bootslot信息被成功写到了parameter中。 + 2. 执行`param get ohos.boot.bootslot`，得到的结果是2，说明bootslot信息被成功写到了parameter中。 - 3. 执行ls -l /dev/block/by-name，能够找到system_b、vendor_b，说明新增的B分区设备节点创建成功。 + 3. 执行`ls -l /dev/block/by-name`，能够找到system_b、vendor_b，说明新增的B分区设备节点创建成功。 ![设备信息](figures/ABStartup_3.png) - 4. 执行df -h 查看当前系统挂载分区。 + 4. 执行`df -h`查看当前系统挂载分区。 ![分区信息](figures/ABStartup_4.png) - 可以看到根文件系统（一个 ” / ” 表示）挂载的是mmcblk0p6，从上一张图中可以找到对应mmcblk0p6的是system；也可以看到/vendor中挂载的是mmcblk0p7，从上一张图中可以找到对应mmcblk0p7的是vendor。也就是说，现在挂载的是默认分区（就是原来的没有后缀的system和vendor分区，可以理解为默认分区就是A分区）。 + 可以看到根文件系统（一个“/”表示）挂载的是mmcblk0p6，从上一张图中可以找到对应mmcblk0p6的是system；也可以看到`/vendor`中挂载的是mmcblk0p7，从上一张图中可以找到对应mmcblk0p7的是vendor。也就是说，现在挂载的是默认分区（就是原来的没有后缀的system和vendor分区，可以理解为默认分区就是A分区）。 接下来，我们将尝试B分区启动。 - 1）执行partitionslot setactive 2，将活动分区slot设置为2，也就是B分区的slot。 + 1）执行`partitionslot setactive 2`，将活动分区slot设置为2，也就是B分区的slot。 - ![设置slot](figures/ABStartup_5.png) + ![设置slot](figures/ABStartup_5.png) - 2）执行partitionslot getslot，查看刚刚设置的slot值是否设置成功。 + 2）执行`partitionslot getslot`，查看刚刚设置的slot值是否设置成功。 - ![查看slot](figures/ABStartup_6.png) + ![查看slot](figures/ABStartup_6.png) - current slot: 2表示活动分区slot被成功设置为2 + `current slot: 2`表示活动分区slot被成功设置为2。 - 3）重启设备后，执行df -h，查看当前系统挂载分区 - 发现当前根文件系统挂载的是mmcblk0p11，/vendor挂载的是mmcblk0p12。 + 3）重启设备后，执行`df -h`，查看当前系统挂载分区。 + + 发现当前根文件系统挂载的是mmcblk0p11，/vendor挂载的是mmcblk0p12。 - ![挂载信息](figures/ABStartup_7.png) + ![挂载信息](figures/ABStartup_7.png) - 4）再次执行ls -l /dev/block/by-name。 + 4）再次执行`ls -l /dev/block/by-name`。 - ![新增设备信息](figures/ABStartup_8.png) + ![新增设备信息](figures/ABStartup_8.png) 找到mmcblk0p11对应的是system_b，mmcblk0p12对应的是vendor_b，也就是说，本次启动系统已经成功从B分区挂载启动。