1# Device Boot 2 3## Context Structure 4 5The following figure shows the context structure of the Startup subsystem. 6 7 **Figure 1** Context structure of the Startup subsystem 8 9  10 11When the system is powered on, the kernel loads and starts services and applications as follows: 12 131. The kernel loads the init process, which is specified by cmdline of the kernel when the bootloader starts the kernel. 142. After the init process is started, tmpfs and procfs are mounted and basic dev nodes are created to establish a basic root file system. 153. The init process starts the ueventd process to listen for device hot-swap events in the kernel and creates dev nodes for related devices as well as partitions for the block device. 164. After mounting partitions (system and vendor) of the block device, the init process scans for the init startup script of each system service and starts the respective system ability (SA). 175. Each SA registers with the samgr process, which serves as the service registration center. The samgr process assigns each SA with an ID, which will be used by an application to access the desired SA. 186. The foundation process implements application lifecycle management. It is a special SA service process that provides the user program management framework and basic services. This process manages the lifecycle of applications. 197. For an application, loading of the JS running environment involves a great deal of preparations. To reduce the application startup time, the appspawn process directly spawns an application process once receiving an application startup request from the foundation process. 20 21 22The Startup subsystem consists of the following modules: 23 24- init Module 25 26 This module corresponds to the init process, which is the first user-space 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 in [Job Management](../subsystems/subsys-boot-init-jobs.md#available-apis) and starts the key system service processes in sequence with corresponding permissions granted. 27 28- ueventd module 29 30 This module listens for **netlink** events about hot plug of kernel device drivers and dynamically manages the dev node of the corresponding device based on the event type. 31 32- appspawn Module 33 34 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. 35 36- bootstrap Module 37 38 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. 39 40## Constraints 41 42 The source code directory of the Startup subsystem varies according to the platform. 43 44 **Table 1** Directories and applicable platforms of the Startup subsystem 45 46| Name| Applicable Platform| 47| -------- | -------- | 48| base/startup/appspawne | Small system devices (reference memory ≥ 1 MB) and standard systems, such as Hi3516D V300 , Hi3518E V300, and RK3568| 49| base/startup/bootstrap_lite | Mini-system devices (reference memory ≥ 128 KiB), for example, Hi3861 V100| 50| base/startup/init | Small system devices (reference memory ≥ 1 MB) and standard systems, such as Hi3516D V300 , Hi3518E V300, and RK3568| 51 52- init module 53 - To start a system service, you first need to write a boot script file named `init.cfg`, in which you define the service name, path of executable files, permissions, etc. 54 - The boot script of each system service is installed in the `/system/etc/init` directory. The init process scans this directory for the boot script to execute. 55 56- When porting a new chip platform, you need to add the `/vendor/etc/init/init.{hardware}.cfg` file that contains the platform-level initialization configuration. This file is used to implement platform-level initialization, for example, installing the ko driver and configuring information on the related `/proc` nodes. 57 58 > **NOTE** 59 > 60 > The `init.cfg` file must be in JSON format. 61 62- bootstrap module: The zInit code must be configured in the link script. 63 64## Boot Process for the OpenHarmony Standard System 65 66By default, the OpenHarmony standard system supports the images listed in the following table. 67 68| Image | Mount Point | Description | 69| ------------ | ------- | ---------------------------------------------------- | 70| boot.img | NA | Kernel and ramdisk image, which is the first image loaded by the bootloader. | 71| system.img | /system | System component image, which stores chip-irrelevant platform services. | 72| vendor.img | /vendor | Chip component image, which stores chip-related hardware abstraction services. | 73| updater.img | / | Updater image, which is used for system updating. This image is not loaded during normal startup.| 74| userdata.img | /data | Writable user data image. | 75 76On each development board, you need to partition the memory to store the preceding images. When the SoC starts, the bootloader loads the images as follows: 77 78- Initializes hardware such as the ROM and RAM, and loads the partition table information. 79- Loads the `boot.img` file based on the partition table and parses and loads the `ramdisk.img` file to the memory. 80- Prepares the partition table information and ramdisk address and enters the kernel, so that the kernel loads the the ramdisk image and starts the init process. 81- Waits until the init process prepares the initial file system and mounts `required.fstab` (including `system.img` and `vendor.img`) to the file system. 82- Scans the boot scripts in the `etc/init` directory in `system.img` and `vendor.img` and runs each boot command. 83 84### U-Boot Process 85 86[U-Boot](https://elinux.org/U-Boot) is used as an example to describe the key image loading process. When U-Boot starts the system, it passes the boot information to the system by using bootargs. 87 88- `boot.img` loading and parsing 89 90 - `boot.img` format 91 92 boot.img building and loading varies depending on the platform. The implementation on mainstream OpenHarmony platforms is as follows: 93 94 - Hi3516DV300 95 96 On this platform, the `boot.img` file uses the flattened image tree (FIT) format. It is generated by the Mkimage tool by packing the `ramdisk.img` files, which are packed by using zImage-dtb or cpio during kernel building, based on the information in the `its` file. 97 98 The related files and tool are described as follows: 99 100 1. `its` file 101 102 An image source file that describes the information about the image to be generated. You need to create the file, for example, the `ohos.its` file on the Hi3516 platform. 103 104 2. Mkimage packaging tool 105 106 A tool that parses its files and packs the corresponding images based on the image configuration to generate an itb file, that is, `boot.img`. 107 108 3. ramdisk 109 110 A `ramdisk.img` file packed by using cpio. 111 112 4. zImage-dtb 113 114 An image that contains the compressed kernel image and device description file image. 115 116 - rk3568 117 118 On this platform, the boot.img file is named `boot_linux.img`. The packaged files are different from those on the Hi3516D V300 platform. 119 120 1. Image 121 122 Image file generated after kernel building. 123 124 2. toybrick.dtb 125 126 A file that is similar to the device description file image generated through dts building. 127 128 3. ramdisk.img 129 130 A `ramdisk.img` file packed by using cpio. 131 132 - U-Boot loading 133 134 The ramdisk boot process is supported. In this scenario, you need to modify the product configuration file in `productdefine` and enable ramdisk generation by setting `enable_ramdisk`. The ramdisk processing method varies according to the platform. Take the Hi3516D V300 platform as an example. You need to change the original U-Boot parameter to `root=/dev/ram0 initrd=0x84000000,0x292e00`. 135 136 137- Kernel start 138 139 When U-Boot starts the kernel, it can pass key information to the kernel through bootargs. The information varies according to the platform. The main fields are described in the table below. 140 141 | Name | Example | Description | 142 | ----------- | ------------------------------------------------------------ | ------------------------------------------------------------ | 143 | initrd | 0x84000000,0x292e00 | For details, see the kernel documentation:<br>[ramfs-rootfs-initramfs.rst](https://gitee.com/openharmony/kernel_linux_5.10/blob/master/Documentation/filesystems/ramfs-rootfs-initramfs.rst)<br>[initrd.rst](https://gitee.com/openharmony/kernel_linux_5.10/blob/master/Documentation/admin-guide/initrd.rst) | 144 | init | /init | | 145 | 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. | 146 | hardware | Hi3516D V300, rk3568, etc. | (Mandatory information) Hardware platform.| 147 | root | /dev/ram0 (Hi3516DV00), root=PARTUUID=614e0000-0000 rw (rk3568) | Boot device loaded by the kernel.| 148 | rootfstype | ext4 | Type of the root file system.| 149 | 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 partition device based on this field.| 150 | 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.| 151 152- Mounting of `required` partitions 153 154 A `required` partition is one that is essential for system boot. It must be mounted before level-2 boot. For mandatory images like `system` and `vendor` images, the corresponding block device files must be created before mounting. This is usually done based on the **uevent** messages reported by the kernel. The init process needs to know the main device directory of the storage device. The bootloader process passes the primary device directory of the storage device to the init process through `default_boot_device`. 155 156 Currently, the init process obtains required partition information in two ways. The init process first reads the required partition information through `bootargs` in `/proc/cmdline`. If the attempt fails, the init process reads the `fstab.required` file in the ramdisk image. 157 158 - Logic of block device creation 159 160 - Preparations 161 162 1. The init process reads the `fstab.required` file from cmdline. If the attempt fails, the init process reads the `fstab.required` file to obtain `PARTNAME` of the block devices that must be mounted, for example, `system` or `vendor`. 163 2. Create a socket for receiving **uevent** messages reported by the kernel and read `default_boot_device` from `/proc/cmdline`. 164 3. Traverse the `/sys/devices` directory with the fstab information and socket handle to get the kernel prepared for reporting **uevent** messages. 165 166 - Event triggering 167 168 1. Use **ueventd** to trigger the kernel to report a **uevent** message. 169 2. Check whether partitionName in the **uevent** message matches with device information in the `fstab.required` file. 170 3. If they match, format the device node path and proceed with device node creation. 171 172 - Node creation 173 174 1. Format the path of the soft link to be created for required block device nodes. A soft link helps facilitate access to device nodes in user mode and improve their readability. 175 2. Create device nodes based on the primary and secondary device numbers passed in the **uevent** message, and the device node path and soft link path obtained in the previous steps. Meanwhile, create a soft link for them. 176 177 Up to now, the creation of block device nodes is complete. 178 179 - Mapping with default_boot_device 180 181 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. 182 183 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. 184 185 - Example 186 187 This example assumes the `system` partition as the required partition on the Hi3516D V300 platform to illustrate the boot process. During this process, the init process reads the `fstab.required` file, creates a block device node, and mounts it to the required partition. The following provides the key code snippets and log information as reference for debugging. 188 189 > **NOTE** 190 > 191 > The code snippets below are exhibited in the logical sequence. They are not neighboring to each other in the source code. 192 193 1. Obtain the `required` partition device information. 194 ``` 195 Fstab* LoadRequiredFstab(void) 196 { 197 Fstab *fstab = NULL; 198 fstab = LoadFstabFromCommandLine(); 199 if (fstab == NULL) { 200 INIT_LOGI("Cannot load fstab from command line, try read from fstab.required"); 201 const char *fstabFile = "/etc/fstab.required"; 202 if (access(fstabFile, F_OK) != 0) { 203 fstabFile = "/system/etc/fstab.required"; 204 } 205 INIT_ERROR_CHECK(access(fstabFile, F_OK) == 0, abort(), "Failed get fstab.required"); 206 fstab = ReadFstabFromFile(fstabFile, false); 207 } 208 return fstab; 209 } 210 ``` 211 The preceding code provides two methods for the init process to obtain the fstab information. First, the init process calls `LoadFstabFromCommandLine()` to read the fstab information from cmdline. If the attempt fails, the init process outputs log information and continues to read the `fstab.required` file for the fstab information. 212 213 For the `system` partition, the key information read from devices is as follows: 214 ``` 215 /dev/block/platform/fe310000.sdhci/by-name/system 216 ``` 217 218 2. Create a socket and trigger the kernel to report a **uevent** message. 219 ``` 220 static int StartUeventd(char **requiredDevices, int num) 221 { 222 INIT_ERROR_CHECK(requiredDevices != NULL && num > 0, return -1, "Failed parameters"); 223 int ueventSockFd = UeventdSocketInit(); 224 if (ueventSockFd < 0) { 225 INIT_LOGE("Failed to create uevent socket"); 226 return -1; 227 } 228 RetriggerUevent(ueventSockFd, requiredDevices, num); 229 close(ueventSockFd); 230 return 0; 231 } 232 ``` 233 234 3. Read information from cmdline to obtain `default_boot_device`. 235 ``` 236 char *buffer = ReadFileData("/proc/cmdline"); 237 int ret = GetProcCmdlineValue("default_boot_device", buffer, bootDevice, CMDLINE_VALUE_LEN_MAX); 238 INIT_CHECK_ONLY_ELOG(ret == 0, "Failed get default_boot_device value from cmdline"); 239 ``` 240 In this example, the value of `default_boot_device` is `soc/10100000.himci.eMMC`. The value is stored in the global variable `bootDevice` and will be matched with the path of the `system` partition device when a soft link is created. 241 242 4. Process the **uevent** message of the `required` partition device. 243 ``` 244 if (uevent->partitionName == NULL) { 245 INIT_LOGI("Match with %s for %s", devices[i], uevent->syspath); 246 deviceName = strstr(devices[i], "/dev/block"); 247 INIT_INFO_CHECK(deviceName != NULL, continue, 248 "device %s not match \"/dev/block\".", devices[i]); 249 deviceName += sizeof("/dev/block") - 1; 250 INIT_INFO_CHECK(strstr(uevent->syspath, deviceName) != NULL, continue, 251 "uevent->syspath %s not match deviceName %s", uevent->syspath, deviceName); 252 HandleBlockDeviceEvent(uevent); 253 break; 254 } else if (strstr(devices[i], uevent->partitionName) != NULL) { 255 INIT_LOGI("Handle block device partitionName %s", uevent->partitionName); 256 HandleBlockDeviceEvent(uevent); 257 break; 258 } 259 ``` 260 In this step, the device information in `devices` is matched with the **uevent** message reported by the kernel. The value of `uevent -> partitionName` should be system for the **uevent** message of the system partition device. If the value matches that of the `/dev/block/platform/fe310000.sdhci/by-name/system` field in `devices`, the **uevent** message of the system partition device will be processed. 261 262 5. Create the `required` partition device node and the corresponding soft link. 263 264 The first thing is to format the path of the corresponding soft link. In this step, the value of `default_boot_device` in `bootargs` will be matched with the path of the required device node in the **uevent** message, so as to create a platform-irrelevant soft link that points to the device node. The key code is as follows: 265 ``` 266 if (STRINGEQUAL(bus, "/sys/bus/platform")) { 267 INIT_LOGV("Find a platform device: %s", parent); 268 parent = FindPlatformDeviceName(parent); 269 if (parent != NULL) { 270 BuildDeviceSymbolLinks(links, linkNum, parent, uevent->partitionName, uevent->deviceName); 271 } 272 linkNum++; 273 if ((parent != NULL) && STRINGEQUAL(parent, bootDevice)) { 274 BuildBootDeviceSymbolLink(links, linkNum, uevent->partitionName); 275 linkNum++; 276 } 277 } 278 ``` 279 The key variables in the code are as follows: 280 281 - `bus`: a string that saves the path of the bus connected to the current device. 282 - `parent`: a string that stores the device path obtained from `uevent -> syspath` in the **uevent** message. 283 - `links`: a pointer to the memory that stores the soft link path. 284 - `bootDevice`: a string that stores the value of `default_boot_device` in `bootargs`. 285 According to the code, the corresponding soft link is created for the device only when the type of the connected bus is platform. The path of the soft link is as follows: 286 ``` 287 /dev/block/platform/soc/10100000.himci.eMMC/by-name 288 ``` 289 A platform-irrelevant soft link is created only when the device path matches that in `bootDevice`. 290 291 For the `system` partition device, the path is as follows: 292 ``` 293 /sys/devices/platform/soc/10100000.himci.eMMC/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p5 294 ``` 295 Therefore, when processing the **uevent** message of the device, the init process compares the device path with that in `bootDevice`, that is, `soc/10100000.himci.eMMC`. If they match, a soft link will be created as follows: 296 ``` 297 /dev/block/by-name/system 298 ``` 299 300 After the soft link path is formatted, the init process creates the device node and soft link based on the information in the **uevent** message. Up to now, the creation of a device node for the `system` partition is complete. 301 302 6. Mount the `required` partition. 303 304 After a device node is created, mount it to the corresponding partition. The code is as follows: 305 ``` 306 int MountRequiredPartitions(const Fstab *fstab) 307 { 308 INIT_ERROR_CHECK(fstab != NULL, return -1, "Failed fstab is NULL"); 309 int rc; 310 INIT_LOGI("Mount required partitions"); 311 rc = MountAllWithFstab(fstab, 1); 312 return rc; 313 } 314 ``` 315 Therefore, when "Mount required partitions" is displayed, the `required` partition device is ready for mounting. During the mounting process, the following key information is printed: 316 ``` 317 BEGET_LOGE("Unsupported file system \" %s \"", item->fsType); 318 ``` 319 The current file system type is not supported. 320 ``` 321 BEGET_LOGE("Cannot get stat of \" %s \", err = %d", target, errno); 322 ``` 323 The attempt to obtain the mount point directory has failed. 324 ``` 325 BEGET_LOGE("Failed to create dir \" %s \", err = %d", target, errno); 326 ``` 327 The attempt to create the mount point directory has failed. 328 ``` 329 BEGET_LOGI("Mount %s to %s successful", item->deviceName, item->mountPoint); 330 ``` 331 The device is successfully mounted. The output also contains the name of the mounted device and information about the mount point. 332 333- Mounting of `vendor` partition 334 335After mounting required partitions, the init process scans each script file in the `vendor` partition. The initialization scripts related to the chip or development board is named in the format of `/vendor/etc/init.{ohos.boot.hardware}.cfg`. Wherein, `/vendor/etc/fstab.{ohos.boot.hardware}` represents the extended mount partition file; `hardware` is sourced from `bootargs`, which is passed from the bootloader to the kernel. 336 337### fstable File Description 338 339- File content 340 341 ``` 342 # fstab file. 343 #<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags> 344 /dev/block/platform/fe310000.sdhci/by-name/system /usr ext4 ro,barrier=1 wait,required 345 /dev/block/platform/fe310000.sdhci/by-name/vendor /vendor ext4 ro,barrier=1 wait,required 346 /dev/block/platform/fe310000.sdhci/by-name/sys-prod /sys_prod ext4 ro,barrier=1 wait 347 /dev/block/platform/fe310000.sdhci/by-name/chip-prod /chip_prod ext4 ro,barrier=1 wait 348 /dev/block/platform/fe310000.sdhci/by-name/userdata /data f2fs discard,noatime,nosuid,nodev,fscrypt=2:aes-256-cts:aes-256-xts,usrquota wait,check,fileencryption=software,quota 349 ``` 350 351- Field description 352 353 | Field | Description | 354 | --------------------- | ------------------------------------------------------------ | 355 | src | Address of the partition or path of the device mounted to the file system | 356 | mnt_point | Mount point in the root file system. | 357 | type | File system type. Common file systems are **ext2**, **vfat**, and **NTFS**. | 358 | mnt_flags and options | Mounting parameters. | 359 | fs_mgr_flags | File system manager flags.<br>Available values include **check**, **wait**, **required**, **nofail**, and **hvb**.| 360 361- Description of mnt_flags and options 362 363 ``` 364 auto Attempts automatic mounting at startup or after the mount -a command is entered. 365 noauto Do not attempt automatic mounting upon system startup. The mount -a command is not used to load the file system. 366 exec Allows execution of binary files in this file system. 367 noexec Do not allow execution of binary files in this file system. 368 ro Mounts a file system as read-only. 369 rw Mounts a file system as read/write. 370 user Allows any user to mount the file system. If no definition is displayed, the noexec nosuid nodev parameter is implicitly enabled. 371 users Allows all users in the users group to mount the file system. 372 nouser Allows only the root user to mount the file system. 373 owner Allows only the device owner to mount the file system. 374 sync Synchronizes the data in the memory and disk in real time without buffering the write operations of the device. This protects the file system against damages caused by abnormal device shutdown but reduces the system speed. 375 async Do not synchronize the data in the memory and disk. The system writes the memory data to the disk at a specified interval. 376 dev Parses block special files in the file system. 377 nodev Do not parse block special files in the file system. 378 suid/nosuid Allows a partition to have the suid attribute or not. 379 quota Forcibly limits the disk quota on the file system. 380 usrquota Enables the disk quota mode to limit the disk quota by users. 381 grpquota Enables the disk quota mode to limit the disk quota by groups. 382 nodiratime Do not update the inode access records on the file system. 383 realtime Updates inode access records in real time. 384 defaults Uses the default mounting parameters of the file system. The default parameters of the ext4 file system are rw, suid, dev, exec ,auto, nouser, and async. 385 ``` 386### Boot Loading Without ramdisk 387 388Certain development boards do not use the ramdisk boot mode. For these boards, the boot process is implemented by directly loading the `system.img` file through the kernel. In such case, you need to modify the product configuration file in `productdefine`. Specifically, you need to turn off the `enable_ramdisk` switch to disable ramdisk generation so that the init process does not boot from `ramdisk` to `system`. 389 390The boot loading process in this scenario is similar to that in the preceding section. The only difference is as follows: If ramdisk is used, the init process mounts `system.img` to the `/usr` directory and then switches to the `/usr` directory using chroot. If ramdisk is not used, the init process directly runs the `init.cfg` file. 391 392For the boot loading process without ramdisk, that is, system as root, the block device where the root file system is located is passed to the kernel through `bootargs`, for example, `root=/dev/mmcblk0p5` and `rootfstype=ext4`. During initialization of the root file system, the kernel parses the `root` field in `bootargs` to complete mounting of the root file system. 393 394 395### Partition A/B Booting 396 397Currently, OpenHarmony supports booting from partitions A and B (active and standby system partitions), both of which are configured in the same device storage. During the booting process, the system partition to load is determined based on the slot of the active partition. Partition A/B booting is supported only for the system and chipset partitions. 398 399- bootslots 400 401 Number of the supported boot partitions. If `bootslots` is set to **2**, the system can boot from both system partitions A and B. If `bootslots` is set to **1**, partition A/B booting is not supported and the system can boot only from the default system partition. 402 403 In the initial phase of init process startup, the system reads the `bootslots` value to determine whether partition A/B booting is supported. If yes, the system continues to determine the system partition to mount. If not, the system mounts the system partition based on the default fstab. The API for the init process to obtain the `bootslots` value is as follows: 404 ``` 405 int GetBootSlots(void) 406 { 407 int bootSlots = GetSlotInfoFromParameter("bootslots"); 408 BEGET_CHECK_RETURN_VALUE(bootSlots <= 0, bootSlots); 409 BEGET_LOGI("No valid slot value found from parameter, try to get it from cmdline"); 410 return GetSlotInfoFromCmdLine("bootslots"); 411 } 412 ``` 413 After normal system startup, you can obtain the `bootslots` value from the system parameter `ohos.boot.bootslots` to check whether the current system supports partition A/B booting. The command for obtaining `ohos.boot.bootslots` is as follows: 414 ``` 415 param get ohos.boot.bootslots 416 ``` 417 418- currentslot 419 420 `currentslot` indicates the current system partition, for example, partition A or partition B. The value is a number. For example, **1** indicates partition A, and **2** indicates partition B. 421 422 In the initial phase of startup, the init process determines whether the system supports partition A/B booting based on `bootslots`. If the system does not support partition A/B booting, the init process directly boots from the default system partition instead of obtaining the `currentslot` value. If the system supports partition A/B booting, the init process obtains the `currentslot` value and determines whether partition A or partition B is the current system partition. The API for the init process to obtain the `currentslot` value is as follows: 423 ``` 424 int GetCurrentSlot(void) 425 { 426 // get current slot from parameter 427 int currentSlot = GetSlotInfoFromParameter("currentslot"); 428 BEGET_CHECK_RETURN_VALUE(currentSlot <= 0, currentSlot); 429 BEGET_LOGI("No valid slot value found from parameter, try to get it from cmdline"); 430 431 // get current slot from cmdline 432 currentSlot = GetSlotInfoFromCmdLine("currentslot"); 433 BEGET_CHECK_RETURN_VALUE(currentSlot <= 0, currentSlot); 434 BEGET_LOGI("No valid slot value found from cmdline, try to get it from misc"); 435 436 // get current slot from misc 437 return GetSlotInfoFromMisc(MISC_PARTITION_ACTIVE_SLOT_OFFSET, MISC_PARTITION_ACTIVE_SLOT_SIZE); 438 } 439 ``` 440 441- Partition A/B booting process 442 443 1. Obtain the `currentslot` value to determine whether partition A or partition B is the current system partition. 444 2. Construct new partition mounting configuration based on the original fstab file, and add the suffix `_a` or `_b` to the partitions that support partition A/B booting, that is, `system` and `chipset` partitions. 445 3. Mount the partition added with the corresponding suffix and enter the second phase of startup. This phase occurs in partition A or B and concludes the partition A/B booting process. 446 447 The API for constructing new partition mounting configuration is as follows: 448 ``` 449 static void AdjustPartitionNameByPartitionSlot(FstabItem *item) 450 { 451 BEGET_CHECK_ONLY_RETURN(strstr(item->deviceName, "/system") != NULL || 452 strstr(item->deviceName, "/chipset") != NULL); 453 char buffer[MAX_BUFFER_LEN] = {0}; 454 int slot = GetCurrentSlot(); 455 BEGET_ERROR_CHECK(slot > 0 && slot <= MAX_SLOT, slot = 1, "slot value %d is invalid, set default value", slot); 456 BEGET_INFO_CHECK(slot > 1, return, "default partition doesn't need to add suffix"); 457 BEGET_ERROR_CHECK(sprintf_s(buffer, sizeof(buffer), "%s_%c", item->deviceName, 'a' + slot - 1) > 0, 458 return, "Failed to format partition name suffix, use default partition name"); 459 free(item->deviceName); 460 item->deviceName = strdup(buffer); 461 BEGET_LOGI("partition name with slot suffix: %s", item->deviceName); 462 } 463 ``` 464 465- Development example 466 467 The following uses the rk3568 platform as an example to illustrate how to change from default partition booting to partition A/B booting. 468 469 1. Burn the original image, and view the device information of each partition. 470 471  472 473 Use the original image to construct images of the partitions used for partition A/B booting, and test the partition A/B booting function. 474 - Copy the `system` and `vendor` images, and add the suffix `_b` to them. 475 - Add the `system_b` and `vendor_b` partitions to the partition table in the `parameter.txt` file. 476 477 2. Burn the images of the partitions used for partition A/B booting. 478 479 - Import the partition configuration to the rk3568 burning tool, and select the `parameter.txt` file containing the `system_b` and `vendor_b` partitions. 480 - Select images (including `system_b` and `vendor_b` images) based on the new partition table configuration, and then burn the images. 481 482 3. After the configuration is complete, perform the following: 483 484 1. Run the `cat /proc/cmdline` command. If the command output contains `bootslot=2`, the system supports partition A/B booting. 485 486  487 2. Run the `param get ohos.boot.bootslot` command. If the command output contains 2, the `bootslot` information is successfully written to the `parameter.txt` file. 488 489 3. Run the `ls -l /dev/block/by-name` command. If the command output contains `system_b` and `vendor_b`, device nodes are successfully created in partition B. 490 491  492 493 4. Run the `df -h` command to check the partitions mounted to the system. 494 495  496 497 As shown in the figure, partition `mmcblk0p6` is mounted to the root file system (represented by a slash), and partition `mmcblk0p7` is mounted to `/vendor`. Based on the command output in step 3, `mmcblk0p6` is the system partition, and `mmcblk0p7` is the `/vendor` partition. That is, the mounted partitions are the default partitions, that is, `system` and `vendor` partitions without suffixes. In other words, partition A is the default partition. 498 499 Next, let's try booting from partition B. 500 501 1. Run the `partitionslot setactive 2` command to set the slot of the active partition to **2**, that is, the slot of partition B. 502 503  504 505 2. Run the `partitionslot getslot` command to check the configured slot. 506 507  508 509 If `current slot` is 2, the slot of the active partition is successfully set to **2**. 510 511 3. Upon restarting, run the `df -h` command to check the partitions mounted to the system. 512 513 According to the command output, partition `mmcblk0p11` is mounted to the root file system, and partition `mmcblk0p12` is mounted to `/vendor`. 514 515  516 517 4. Run the `ls -l /dev/block/by-name` command again. 518 519  520 521 mmcblk0p11 corresponds to system_b, and mmcblk0p12 corresponds to vendor_b. That is, the system is successfully booted from partition B. 522
