System backup starting method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application relate to a system backup starting method and device, electronic equipment and storage medium. The method comprises: in response to triggering operating system starting, loading system boot data to enter a system boot starting state; obtaining a kernel mark from a storage area corresponding to a preset kernel loading address; determining whether the current operating system starting meets a starting failure condition based on the kernel mark; if not, loading first system kernel data from a first kernel storage partition, the first kernel data comprising first basic file system data; if the starting failure condition is met, loading second system kernel data from a second kernel storage partition, the first kernel data comprising first basic file system data; and starting the operating system based on the loaded system kernel data. The embodiments of the present application realize backup of only the system kernel, and the system kernel contains the basic file system, thereby saving the memory space occupied by system backup.

Description

Technical Field

[0001] This application relates to the field of embedded device technology, and in particular to a system backup boot method, apparatus, electronic device and storage medium. Background Technology

[0002] Currently, embedded devices are widely used in various industries, and the functions they support are becoming increasingly diverse, leading to a higher frequency of embedded software upgrades and iterations. However, embedded devices face many uncontrollable factors during software upgrades, such as power outages or unstable power supplies causing frequent power cycles, which can easily lead to upgrade failures and render the devices unusable.

[0003] To enhance the stability of equipment upgrades and prevent upgrade failures from rendering the equipment unusable, the current solution primarily involves introducing a dual-system approach (where the two systems serve as backups for each other).

[0004] Current dual-system solutions typically use two equivalent partitions, A and B, in the flash memory. Both partitions back up kernel data, application data, u-boot, and other data equally, requiring a sufficiently large flash memory capacity. However, with the increasing number of business functions in embedded devices and the growing size of upgrade packages, the flash memory of embedded devices will face resource bottlenecks, making this method of fully backing up the system partitions increasingly difficult to implement. Summary of the Invention

[0005] In view of this, in order to solve some or all of the above-mentioned technical problems, embodiments of this application provide a system backup boot method, apparatus, electronic device and storage medium.

[0006] In a first aspect, embodiments of this application provide a system backup boot method, the method comprising: in response to triggering operating system boot, loading system boot data to enter a system boot state; obtaining a kernel flag from a storage area corresponding to a preset kernel load address; determining, based on the kernel flag, whether the current operating system boot meets boot failure conditions; if the boot failure conditions are not met, loading first system kernel data from a first kernel storage partition among two preset kernel storage partitions, wherein the first kernel data includes first basic file system data; if the boot failure conditions are met, loading second system kernel data from a second kernel storage partition among the two kernel storage partitions, wherein the second kernel data includes second basic file system data; and booting the operating system based on the loaded system kernel data.

[0007] In one possible implementation, the method further includes: in response to triggering the operating system to start, starting a system startup timer; loading first system kernel data from the first kernel storage partition of two preset kernel storage partitions, including: in response to the startup time recorded by the startup timer timeout, re-triggering the operating system to start and incrementing the startup timeout count by one; in response to the successful startup of the operating system, setting the timeout count to zero.

[0008] In one possible implementation, determining whether the current operating system startup meets the startup failure conditions based on kernel flags includes: determining whether the kernel flags are consistent with the kernel flags included in the first system kernel data; if they are inconsistent, determining that the current operating system startup does not meet the startup failure conditions; if they are consistent, determining whether the startup timeout count has reached a preset number; if the preset number has been reached, determining that the current operating system startup meets the startup failure conditions and setting the startup timeout count to zero; if the preset number has not been reached, determining that the current operating system startup does not meet the startup failure conditions.

[0009] In one possible implementation, loading first system kernel data from a first kernel storage partition among two preset kernel storage partitions includes: obtaining a kernel index; determining, based on the kernel index, the kernel storage partition corresponding to the kernel index from the two kernel storage partitions as the first kernel storage partition, and loading the first system kernel data from the first kernel storage partition; loading second system kernel data from a second kernel storage partition among the two kernel storage partitions includes: adjusting the kernel index from an initial value to a target value; determining, based on the target value, the kernel storage partition corresponding to the target value from the two kernel storage partitions as the second kernel storage partition, and loading the second system kernel data from the second kernel storage partition.

[0010] In one possible implementation, loading system boot data to enter the system boot startup state includes: loading system boot data from a preset system boot data partition to enter the system boot startup state.

[0011] In one possible implementation, after the operating system is started based on the loaded system kernel data, the method further includes: obtaining business data from a preset business data partition and loading the business data to run the business program.

[0012] In one possible implementation, after the operating system is started based on the loaded system kernel data, the method further includes: receiving upgrade package data in response to triggering a system upgrade operation; parsing the upgrade package data to extract the kernel data to be upgraded; determining, from two kernel storage partitions, an initial kernel storage partition for storing the system kernel data before the upgrade, and a backup kernel storage partition for storing the kernel data to be upgraded; storing the kernel data to be upgraded in the backup kernel storage partition, and setting the backup kernel storage partition as the partition used when the operating system starts.

[0013] In one possible implementation, determining an initial kernel storage partition for storing system kernel data before the upgrade and a backup kernel storage partition for storing kernel data to be upgraded from two kernel storage partitions includes: obtaining a kernel index, and determining the initial kernel storage partition for storing system kernel data before the upgrade and the backup kernel storage partition for storing kernel data to be upgraded from the two kernel storage partitions based on the kernel index; setting the backup kernel storage partition as the partition used when the operating system starts includes: adjusting the value of the kernel index from corresponding to the initial kernel storage partition to corresponding to the backup kernel storage partition.

[0014] In one possible implementation, parsing the upgrade package data to extract the kernel data to be upgraded includes: extracting at least one type of data to be verified from the header data of the upgrade package data; obtaining verification benchmark data corresponding to each of the at least one type of data to be verified; verifying the data with the corresponding at least one type of data to be verified and the verification benchmark data to obtain a verification result; if the verification result indicates successful verification, determining the target sub-package data containing the kernel data to be upgraded from at least one set of sub-package data included in the upgrade package data; and extracting the kernel data to be upgraded from the target sub-package data.

[0015] In one possible implementation, after receiving upgrade package data in response to triggering a system upgrade operation, the method further includes: exiting all current business processes and unloading a preset business data partition; parsing the upgrade package data, extracting business data, and storing the business data in the business data partition.

[0016] In one possible implementation, after receiving upgrade package data in response to triggering a system upgrade operation, the method further includes: parsing the upgrade package data to extract system boot data; determining whether the version of the system boot data is higher than the version of the original system boot data in a preset system boot data partition; if it is higher than the version of the original system boot data, storing the system boot data in the system boot data partition.

[0017] Secondly, embodiments of this application provide a system backup boot device, comprising: a first loading module, configured to load system boot data in response to triggering operating system startup to enter a system boot startup state; a first acquisition module, configured to acquire a kernel flag from a storage area corresponding to a preset kernel load address; a first determination module, configured to determine, based on the kernel flag, whether the current operating system startup meets the startup failure conditions; a second loading module, configured to load first system kernel data from a first kernel storage partition among two preset kernel storage partitions if the startup failure conditions are not met, wherein the first kernel data includes first basic file system data; a third loading module, configured to load second system kernel data from a second kernel storage partition among two kernel storage partitions if the startup failure conditions are met, wherein the second kernel data includes second basic file system data; and a startup module, configured to start the operating system based on the loaded system kernel data.

[0018] Thirdly, embodiments of this application provide an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, wherein when the computer program is executed, it implements the method of any embodiment of the system backup startup method of the first aspect of this application.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the method of any embodiment of the system backup startup method of the first aspect described above.

[0020] Fifthly, embodiments of this application provide a computer program including computer-readable code that, when executed on a device, causes a processor in the device to implement the method of any embodiment of the system backup boot method of the first aspect described above.

[0021] The system backup boot method, apparatus, electronic device, and storage medium provided in this application embodiment, by setting two kernel storage partitions in the memory, first enters the system boot state when the operating system starts, and then obtains the kernel flag according to the kernel load address. If the kernel flag determines that the boot failure condition is met, the system kernel data is loaded from the backup kernel storage partition. If the boot failure condition is not met, the system kernel data is loaded from the default kernel storage partition. This achieves backup of only the system kernel, and the system kernel contains the basic file system but does not contain business function data. The backup system only implements basic file operations, that is, the data volume of the backup system is minimized, saving the memory space occupied by the system backup and solving the memory resource bottleneck problem of embedded devices. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0025] Figure 1 A flowchart illustrating a system backup and startup method provided in an embodiment of this application;

[0026] Figure 2 A flowchart illustrating another system backup and startup method provided in this application embodiment;

[0027] Figure 3 A flowchart illustrating another system backup and startup method provided in this application embodiment;

[0028] Figure 4 A flowchart illustrating another system backup and startup method provided in this application embodiment;

[0029] Figure 5 A flowchart illustrating another system backup and startup method provided in this application embodiment;

[0030] Figure 6 A flowchart illustrating another system backup and startup method provided in this application embodiment;

[0031] Figure 7 A flowchart illustrating another system backup and startup method provided in this application embodiment;

[0032] Figure 8 A flowchart illustrating another system backup and startup method provided in this application embodiment;

[0033] Figure 9 A flowchart illustrating another system backup and startup method provided in this application embodiment;

[0034] Figure 10 A schematic diagram of a system backup boot device provided in an embodiment of this application;

[0035] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0036] Various exemplary embodiments of this application will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this application.

[0037] Those skilled in the art will understand that the terms "first" and "second" in the embodiments of this application are only used to distinguish different steps, devices or modules, and do not represent any specific technical meaning, nor do they indicate the logical order between them.

[0038] It should also be understood that in this embodiment, "multiple" can refer to two or more, and "at least one" can refer to one, two or more.

[0039] It should also be understood that any component, data or structure mentioned in the embodiments of this application can generally be understood as one or more unless explicitly defined or given contrary guidance in the context.

[0040] Furthermore, the term "and / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this application generally indicates that the preceding and following related objects have an "or" relationship.

[0041] It should also be understood that the description of the various embodiments in this application emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0042] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the scope of this application and its application or use.

[0043] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0044] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0045] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. To facilitate understanding of the embodiments of this application, the application will be described in detail below with reference to the accompanying drawings and embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0046] To address the technical problem of excessive memory resource consumption during system backup in existing technologies, this application provides a system backup startup method that can minimize the memory resources occupied by system backup.

[0047] Figure 1 This is a flowchart illustrating a system backup and boot method provided in an embodiment of this application. This method can be applied to various embedded devices, as well as to one or more electronic devices such as vehicles (e.g., autonomous vehicles), smartphones, laptops, desktop computers, portable computers, and servers. Furthermore, the execution entity of this method can be hardware or software. When the execution entity is hardware, it can be one or more of the aforementioned electronic devices. For example, a single electronic device can execute this method, or multiple electronic devices can cooperate with each other to execute this method. When the execution entity is software, this method can be implemented as multiple software programs or software modules, or as a single software program or software module. No specific limitations are imposed here.

[0048] like Figure 1 As shown, the method specifically includes:

[0049] Step 101: In response to triggering the operating system to start, load system boot data to enter the system boot state.

[0050] In this embodiment, the operating system startup triggering method can include software restart and hardware restart. Software restart refers to the system automatically restarting due to a malfunction, while hardware restart refers to the system restarting after a power outage. During system startup, system boot data (e.g., uboot) is first loaded, entering the system boot state, at which point a series of startup instructions can be executed.

[0051] Optionally, system boot data can be loaded from a preset system boot data partition to enter the system initialization state. This system boot data partition can be located in the same memory (e.g., flash memory) as the two kernel storage partitions described below. Since the need for system boot data updates is infrequent, no backup of the system boot data is performed. The system boot data and system kernel data constitute a minimal system, thereby minimizing the amount of data required for system backup and further conserving memory resources.

[0052] Step 102: Obtain the kernel tag from the storage area corresponding to the preset kernel load address.

[0053] In this embodiment, the kernel load address refers to the starting address of the system data in memory when loading system kernel data from a memory (e.g., flash memory) to main memory (i.e., random access memory, RAM). The kernel marker is typically present in the first few bytes of the system kernel data image file; that is, the kernel marker is loaded first. Typically, the kernel marker can be the first 4 bytes of the system kernel image; these can be called magic words. It should be noted that when a kernel data image reload occurs, the aforementioned kernel load address is the starting address of the reloaded system data.

[0054] As an example, the magic words for legacy image and fit image format image files are 0x27051956 and 0xd00dfeed, respectively. When uboot boots the kernel, it first reads the kernel image data from the flash memory to the kernel load address in RAM, and then starts the kernel using the bootm command.

[0055] Step 103: Based on kernel flags, determine whether the current operating system startup meets the startup failure conditions.

[0056] In this embodiment, since the kernel flag is read from RAM, and RAM is a power-loss volatile memory, meaning that the data stored in RAM is lost when the power is turned off, based on the volatile nature of RAM, it can be determined whether the kernel flag matches a preset value. If they match, it means that the kernel flag has been pre-loaded into RAM, and the system undergoes a soft reboot; if they do not match, it means that the system has undergone a power-off reboot or its first power-on startup, and the kernel flag has not yet been loaded into the memory area corresponding to the kernel load address in RAM.

[0057] Optionally, if the kernel flag matches the preset flag, i.e. a soft reboot occurs, it can be determined that the boot failure condition is met, or the number of soft reboots can be recorded. If a certain number of soft reboots are recorded, it can be determined that the boot failure condition is met.

[0058] If the startup failure conditions are not met, proceed to step 104; if the startup failure conditions are met, proceed to step 105.

[0059] Step 104: Load the first system kernel data from the first kernel storage partition of the two preset kernel storage partitions.

[0060] In this embodiment, the first kernel storage partition is the default partition used to load system kernel data during this boot, i.e., the partition used first during normal boot. The first kernel data includes first basic file system data, which is used to run the basic file system, i.e., the system that performs basic file operations.

[0061] Step 105: Load the second system kernel data from the second kernel storage partition of the two kernel storage partitions.

[0062] In this embodiment, the second kernel storage partition is the backup partition used during this boot process. In case of boot failure, system kernel data can be loaded from the backup partition. The second kernel data includes second basic file system data, which is used to run the basic file system, i.e., the system that performs basic file operations. Typically, the second basic file system data can be the same as the first basic file system data.

[0063] Typically, the two kernel partitions mentioned above are located in flash memory, with common flash memory capacities ranging from 1 to 32 MB (NOR flash) and 16 to 512 MB (NAND flash), resulting in very limited storage resources. Embedded operating systems mainly consist of three parts: uboot (bootloader), kernel, and rootfs (file system), which are generally partitioned separately. The file system primarily includes a basic file system and business function modules, with the business function modules accounting for a larger proportion of the basic file system. To alleviate the flash storage resource bottleneck faced by embedded dual systems, this embodiment separates the business function modules from the file system and constructs a minimal file system based on the basic file system. The first system kernel data and the second system kernel data can each be configured with a basic file system (i.e., a minimal file system). Both the first and second basic file system data are data contained within the basic file system. The basic file system can include basic function modules such as platform dynamic libraries, busybox, startup scripts, and upgrade daemons, but does not contain any other business function modules. Furthermore, the minimal file system can be packaged into the system kernel data image using file system operations such as initramfs, and the two images can be stored in the first and second kernel storage partitions respectively.

[0064] Step 106: Based on the loaded system kernel data, start the operating system.

[0065] In this embodiment, the electronic device can use the loaded system kernel data to start the operating system, and can also complete CPU initialization, peripheral driver registration, mounting of memory file system, loading of business data of various applications, etc.

[0066] The system backup boot method provided in this application sets two kernel storage partitions in the memory. When the operating system starts, it first enters the system boot state, and then obtains the kernel flag according to the kernel load address. If the kernel flag determines that the boot failure condition is met, the system kernel data is loaded from the backup kernel storage partition. If the boot failure condition is not met, the system kernel data is loaded from the default kernel storage partition. This achieves backup of only the system kernel, and the system kernel contains the basic file system but does not contain business function data. The backup system only implements basic file operations, that is, the data volume of the backup system is minimized, saving the memory space occupied by the system backup and solving the memory resource bottleneck problem of embedded devices.

[0067] In some optional implementations of this embodiment, such as Figure 2 As shown, the method also includes:

[0068] Step 107: In response to triggering the operating system to start, start the system startup timer.

[0069] The aforementioned system startup timer is used to time the system startup time. If the startup time expires, the system will automatically restart. Optionally, the system startup timer can be implemented using a watchdog module; that is, if the watchdog module is not initialized with a count value after a certain period of time, the startup time is determined to have expired.

[0070] Step 104 includes:

[0071] Step 1041: In response to the startup timeout recorded by the startup timer, the operating system startup is retried and the startup timeout count is incremented by one.

[0072] Specifically, after the operating system restarts, this method is re-executed from step 101.

[0073] Step 1042: In response to the successful startup of the operating system, the timeout count is set to zero.

[0074] Setting the timeout count to zero will reset the count when a startup failure occurs, thus effectively determining whether the backup system kernel data needs to be used.

[0075] This embodiment monitors the system startup time by setting a system startup timer, which can restart the system in a timely manner if it fails to start. At the same time, combined with the number of startup timeouts, it helps to accurately determine whether the startup failure conditions are met and load the backup system in a timely manner.

[0076] In some optional implementations of this embodiment, such as Figure 3 As shown, step 103 includes:

[0077] Step 1031: Determine whether the kernel tag is consistent with the kernel tag included in the first system kernel data.

[0078] The kernel marker in the first system kernel data refers to the first few bytes of the first system kernel data. For example, the kernel marker could be the first 4 bytes of the kernel data image file.

[0079] If they do not match, proceed to step 1032; if they match, proceed to step 1033.

[0080] Step 1032: Determine that the current operating system startup does not meet the startup failure conditions.

[0081] Specifically, when loading system kernel data, the kernel flag is first loaded into RAM. The kernel flag read in step 102 is read from RAM. RAM has the characteristic of being volatile when power is off. When the kernel flag read is inconsistent with the kernel flag included in the first system kernel data, it indicates that this boot is a hard reboot, that is, a power-off reboot or the first power-on boot. At this time, the reboot is caused by the external operating conditions of the electronic device (such as vibration, unstable power supply, abnormal ambient temperature). Therefore, it is determined that the boot failure conditions are not met.

[0082] Step 1033: Determine whether the startup timeout count has reached the preset number.

[0083] For example, the preset number of attempts is 3. If the preset number of attempts is reached, proceed to step 1034; otherwise, proceed to step 1035.

[0084] Step 1034: Determine that the current operating system startup meets the startup failure conditions, and set the startup timeout count to zero.

[0085] Step 1035: Determine that the current operating system startup does not meet the startup failure conditions.

[0086] If the boot failure conditions are not met, load the first system kernel data from the default first kernel storage partition. If a soft reboot occurs again, continue to execute step 1033.

[0087] This embodiment determines whether the read kernel flag is consistent with the kernel flag included in the system kernel data and records the number of boot timeouts. This enables timely system restart when booting fails. When multiple boot failures occur, it determines that the boot failure conditions are met and promptly uses the backed-up system kernel data to run the operating system. It can also avoid accidental system partition switching under external conditions such as unstable power supply to the device, making the system operation more stable and reliable.

[0088] In some optional implementations of this embodiment, such as Figure 4 As shown, step 104 includes:

[0089] Step 1041: Obtain the kernel index. Based on the kernel index, determine the kernel storage partition corresponding to the kernel index from the two kernel storage partitions as the first kernel storage partition, and load the first system kernel data from the first kernel storage partition.

[0090] As an example, the kernel index can be either 0 or 1, and the two kernel storage partitions mentioned above are denoted as mos0 and mos1. Kernel index 0 corresponds to the mos0 partition, and kernel index 1 corresponds to the mos1 partition. When the kernel index is 0, the mos0 partition is the first kernel storage partition, and when the kernel index is 1, the mos1 partition is the first kernel storage partition.

[0091] Step 105 includes:

[0092] Step 1051: Adjust the kernel index from the initial value to the target value.

[0093] The initial value is the current value of the kernel index, and the target value is the value that the kernel index can be changed to. For example, if the initial value of the kernel index is 0, the target value is 1; if the initial value is 1, the target value is 0.

[0094] Step 1052: Based on the target value, determine the kernel storage partition corresponding to the target value from the two kernel storage partitions as the second kernel storage partition, and load the second system kernel data from the second kernel storage partition.

[0095] For example, when the kernel index changes from 0 to 1, the mos1 partition becomes the second kernel storage partition, and when the kernel index changes from 1 to 0, the mos0 partition becomes the second kernel storage partition.

[0096] This embodiment achieves accurate scheduling of the two kernel storage partitions by setting kernel indexes. When the boot failure conditions are met, the backed-up system kernel data is accurately loaded, thereby improving the stability of system operation.

[0097] In some optional implementations of this embodiment, after step 106, the method further includes:

[0098] Retrieve business data from the preset business data partition and load the business data to run the business program.

[0099] The business data partition is located in the same storage medium as the two kernel storage partitions mentioned above, such as flash memory. The business data partition is separate from the two kernel storage partitions and the boot data partition. It only affects the business functions of various applications and does not affect system operation.

[0100] This embodiment separates the business data required for application runtime from the system data by setting up a business data partition. During system backup, only the system kernel data is backed up, so that the backed-up system can run basic system functions without needing to back up business data. This saves storage resources and improves the stability of system operation.

[0101] In some optional implementations of this embodiment, such as Figure 5 As shown, after step 106, the method further includes:

[0102] Step 108: In response to triggering a system upgrade operation, receive upgrade package data.

[0103] Specifically, when the system starts up and runs normally, an upgrade daemon process can be executed, which monitors upgrade package data sent by electronic devices such as servers or host computers in real time.

[0104] Step 109: Parse the upgrade package data and extract the kernel data to be upgraded.

[0105] Specifically, the upgrade package data may include the kernel data to be upgraded, as well as other types of data such as the packet header data. The electronic device can parse information such as the number of sub-packets, sub-packet type, sub-packet version, sub-packet offset, and sub-packet length from the packet header data, and determine the sub-packets containing the kernel data to be upgraded.

[0106] Step 110: From the two kernel storage partitions, determine the initial kernel storage partition for storing the system kernel data before the upgrade, and the backup kernel storage partition for storing the kernel data to be upgraded.

[0107] The initial kernel storage partition is the currently used kernel storage partition, and the backup kernel storage partition is another currently unused kernel storage partition.

[0108] Step 111: Store the kernel data to be upgraded into the backup kernel storage partition, and set the backup kernel storage partition as the partition used when the operating system starts.

[0109] After this step is completed, the backup kernel storage partition will become the new initial kernel storage partition the next time the system is started, and the original initial kernel storage partition will become the new backup kernel storage partition.

[0110] Optionally, after storing the kernel data to be upgraded in the backup kernel storage partition, the system can be automatically restarted to complete the system update.

[0111] This embodiment extracts the kernel data to be upgraded from the received upgrade package data during system upgrades and stores the kernel data to be upgraded in the backup kernel storage partition. This enables the setting of dual systems on the device, and the memory space occupied by the dual systems is greatly reduced, providing more storage space for the business data of various applications and improving the stability of device operation.

[0112] In some optional implementations of this embodiment, such as Figure 6 As shown, step 110 includes:

[0113] Step 1101: Obtain the kernel index, and based on the kernel index, determine the initial kernel storage partition for storing the system kernel data before the upgrade, and the backup kernel storage partition for storing the kernel data to be upgraded, from the two kernel storage partitions.

[0114] As an example, when the kernel index is 0, the initial kernel storage partition is mos0 and the backup kernel storage partition is mos1; when the kernel index is 1, the initial kernel storage partition is mos1 and the backup kernel storage partition is mos0.

[0115] Step 111 includes:

[0116] Step 1111: Adjust the value of the kernel index from the initial kernel storage partition to the backup kernel storage partition.

[0117] For example, if the backup kernel storage partition is mos1, the kernel index is updated to the number 1; if the backup kernel storage partition is mos0, the kernel index is updated to the number 0. Upon the next system boot, the new kernel index can be used to determine the partition where the loaded system kernel data resides, thus enabling the operating system to be updated and run.

[0118] This embodiment improves system stability by setting a kernel index, enabling the system to quickly determine the partition containing the updated system kernel data upon the next system startup after an update.

[0119] In some optional implementations of this embodiment, such as Figure 7 As shown, step 109 includes:

[0120] Step 1091: Extract at least one type of data to be verified from the header data of the upgrade package data.

[0121] Among them, at least one of the data to be verified may include at least one of the following: packet header identifier, device identifier, CRC value of the whole packet data, CRC value of the packet header data, etc. Each type of data to be verified may be included in the corresponding field of the packet header data, so that the data to be verified can be extracted according to the field identifier.

[0122] Step 1092: Obtain the verification benchmark data corresponding to at least one type of data to be verified.

[0123] As an example, the verification reference data may include at least one of the following: a preset packet header identifier, the device identifier of the execution subject device of this method (for example, data on the GPIO0, GPIO1, and GPIO2 ports of the device can be read as the device identifier), the CRC value calculated by the CRC algorithm on the entire packet data, and the CRC value calculated on the packet header data, etc.

[0124] Step 1093 involves verifying the data against at least one corresponding data to be verified and a verification benchmark data to obtain the verification result.

[0125] The verification result indicates whether each type of data to be verified is consistent with the verification benchmark data.

[0126] Step 1094: If the verification result indicates that the verification was successful, determine the target sub-package data containing the kernel data to be upgraded from at least one set of sub-package data included in the upgrade package data.

[0127] Typically, a successful verification occurs when the verification result indicates that each type of data to be verified matches its corresponding baseline data. If any data fails verification, a message indicating that the upgrade package verification failed is returned. The sub-package identifier, sub-package version, sub-package offset address, and sub-package length corresponding to at least one set of sub-package data can be included in the packet header data. Based on this information, the target sub-package data containing the kernel data to be upgraded can be determined; that is, the sub-package containing the kernel data to be upgraded is determined based on the kernel sub-package identifier, kernel version, kernel offset, and kernel length included in the packet header data.

[0128] Step 1095: Extract the kernel data to be upgraded from the target sub-package data.

[0129] This embodiment can effectively improve the security of system upgrades by verifying the packet header data, ensuring that the system kernel data backed up to the system kernel storage partition is valid data, and improving the stability of system operation.

[0130] In some optional implementations of this embodiment, such as Figure 8As shown, after step 108, the method further includes:

[0131] Step 112: Exit all current business processes and unload the preset business data partition.

[0132] Specifically, unloading the business data partition here means completely isolating the business data partition in the memory from the system kernel partition, so that the system will no longer call any data in the business data partition during runtime.

[0133] Step 113: Parse the upgrade package data, extract the business data, and store the business data in the business data partition.

[0134] Specifically, the header data of the upgrade package data may include information such as the business data sub-package identifier, business data version, business data offset, and business data length. Based on this information, the sub-package containing business data can be identified from the sub-packages included in the upgrade package data, thereby extracting the business data.

[0135] This embodiment unloads the business data partition before storing business data in it, which can completely stop the running business program and prevent the system from calling any business data. This avoids software errors caused when writing data to the business data partition and thus avoids affecting the system upgrade process.

[0136] In some optional implementations of this embodiment, such as Figure 9 As shown, after step 108, the method further includes:

[0137] Step 114: Parse the upgrade package data and extract the system boot data.

[0138] Specifically, the system boot data (such as uboot data) in the upgrade package data may include information such as the system boot data sub-package identifier, system boot data version, system boot data offset, and system boot data length. Based on this information, the sub-package containing system boot data can be determined from the sub-packages included in the upgrade package data, thereby extracting the system boot data.

[0139] Step 115: Determine whether the version of the system boot data is higher than the version of the original system boot data in the preset system boot data partition.

[0140] The version information of the system boot data can be included in the packet header data, so that the version of the system boot data in the upgrade package data can be determined based on the version information.

[0141] Step 116: If the version is higher than the original system boot data, store the system boot data in the system boot data partition.

[0142] When the version of the system boot data in the upgrade package is higher than the version of the original system boot data, it means that the system boot data in the upgrade package is the latest version. After this step is completed, the system boot data partition will only retain the latest version of the system boot data.

[0143] This embodiment stores the system boot data in the system boot data partition when the version of the system boot data in the upgrade package data is higher than the version of the original system boot data in the system boot data partition. This eliminates the need to back up the system boot data, thereby saving storage space and shortening the system upgrade time.

[0144] Figure 10 This is a schematic diagram of a system backup boot device provided in an embodiment of this application. Specifically, it includes: a first loading module, used to load system boot data in response to triggering an operating system boot, to enter a system boot state; a first acquisition module 1001, used to acquire a kernel marker from a storage area corresponding to a preset kernel load address; a first determination module 1002, used to determine, based on the kernel marker, whether the current operating system boot meets the boot failure conditions; a second loading module 1003, used to load first system kernel data from the first kernel storage partition of two preset kernel storage partitions if the boot failure conditions are not met, wherein the first kernel data includes first basic file system data; a third loading module 1004, used to load second system kernel data from the second kernel storage partition of two kernel storage partitions if the boot failure conditions are met, wherein the second kernel data includes second basic file system data; and a boot module 1005, used to boot the operating system based on the loaded system kernel data.

[0145] In one possible implementation, the device further includes: an activation module for activating a system startup timer in response to triggering the operating system startup; the second loading module includes: a trigger unit for re-triggering the operating system startup in response to a startup timeout recorded by the startup timer, and incrementing the startup timeout count by one; and a reset unit for setting the timeout count to zero in response to successful operating system startup.

[0146] In one possible implementation, the first determining module includes: a first determining unit, configured to determine whether the kernel flag is consistent with the kernel flag included in the first system kernel data; a second determining unit, configured to determine, if inconsistent, that the current operating system startup does not meet the startup failure conditions; a third determining unit, configured to determine, if consistent, whether the startup timeout count has reached a preset number; a fourth determining unit, configured to determine, if the preset number has been reached, that the current operating system startup meets the startup failure conditions and set the startup timeout count to zero; and a fifth determining unit, configured to determine, if the preset number has not been reached, that the current operating system startup does not meet the startup failure conditions.

[0147] In one possible implementation, the second loading module includes: a first acquisition unit, configured to acquire a kernel index, determine the kernel storage partition corresponding to the kernel index from two kernel storage partitions as the first kernel storage partition based on the kernel index, and load the first system kernel data in the first kernel storage partition; the third loading module includes: an adjustment unit, configured to adjust the kernel index from an initial value to a target value; and a loading unit, configured to determine the kernel storage partition corresponding to the target value from two kernel storage partitions as the second kernel storage partition based on the target value, and load the second system kernel data in the second kernel storage partition.

[0148] In one possible implementation, the first loading module is further configured to: load system boot data from a preset system boot data partition to enter the system boot startup state.

[0149] In one possible implementation, the device further includes a second acquisition module, configured to acquire business data from a preset business data partition and load the business data to run a business program.

[0150] In one possible implementation, the apparatus further includes: a receiving module for receiving upgrade package data in response to triggering a system upgrade operation; a first extraction module for parsing the upgrade package data and extracting the kernel data to be upgraded; a second determining module for determining, from two kernel storage partitions, an initial kernel storage partition for storing the system kernel data before the upgrade, and a backup kernel storage partition for storing the kernel data to be upgraded; and a setting module for storing the kernel data to be upgraded in the backup kernel storage partition and setting the backup kernel storage partition as the partition used when the operating system starts.

[0151] In one possible implementation, the second determining module includes: a second obtaining unit, configured to obtain a kernel index, and based on the kernel index, determine an initial kernel storage partition for storing system kernel data before the upgrade, and a backup kernel storage partition for storing kernel data to be upgraded, from two kernel storage partitions; the setting module is further configured to: adjust the value of the kernel index from corresponding to the initial kernel storage partition to corresponding to the backup kernel storage partition.

[0152] In one possible implementation, the first extraction module includes: a first extraction unit, configured to extract at least one type of data to be verified from the header data of the upgrade package data; a third acquisition unit, configured to acquire verification benchmark data corresponding to each of the at least one type of data to be verified; a verification unit, configured to verify the data against the corresponding at least one type of data to be verified and the verification benchmark data to obtain a verification result; a sixth determination unit, configured to determine, if the verification result indicates successful verification, a target sub-package data containing the kernel data to be upgraded from at least one set of sub-package data included in the upgrade package data; and a second extraction unit, configured to extract the kernel data to be upgraded from the target sub-package data.

[0153] In one possible implementation, the device further includes: an unloading unit for exiting all current business processes and unloading a preset business data partition; and a second extraction unit for parsing the upgrade package data, extracting the business data, and storing the business data in the business data partition.

[0154] In one possible implementation, the device further includes: a parsing module for parsing the upgrade package data and extracting system boot data; a third determining module for determining whether the version of the system boot data is higher than the version of the original system boot data in the preset system boot data partition; and a storage unit for storing the system boot data into the system boot data partition if the version is higher than the original system boot data.

[0155] The system backup boot device provided in this embodiment can be as follows: Figure 10 The system backup boot device shown can execute all the steps of the above system backup boot methods, thereby achieving the technical effects of the above system backup boot methods. For details, please refer to the above descriptions. For the sake of brevity, it will not be elaborated here.

[0156] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 11 The illustrated electronic device 1100 includes at least one processor 1101, a memory 1102, at least one network interface 1104, and other user interfaces 1103. The various components in the electronic device 1100 are coupled together via a bus system 1105. It is understood that the bus system 1105 is used to implement communication between these components. In addition to a data bus, the bus system 1105 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 11 The general designated all buses as Bus System 1105.

[0157] The user interface 1103 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0158] It is understood that the memory 1102 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 1102 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0159] In some implementations, memory 1102 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 11021 and application program 11022.

[0160] The operating system 11021 includes various system programs, such as a framework layer, a core library layer, and a driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 11022 includes various applications, such as a media player and a browser, used to implement various application functions. Programs implementing the methods of the embodiments of this application can be included in the application program 11022.

[0161] In this embodiment, by calling the program or instructions stored in memory 1102, specifically the program or instructions stored in application program 11022, processor 1101 executes the method steps provided in each method embodiment, including, for example:

[0162] In response to triggering the operating system startup, system boot data is loaded to enter the system boot state; a kernel flag is obtained from the storage area corresponding to the preset kernel load address; based on the kernel flag, it is determined whether the current operating system startup meets the startup failure conditions; if the startup failure conditions are not met, first system kernel data is loaded from the first kernel storage partition of the two preset kernel storage partitions, wherein the first kernel data includes first basic file system data; if the startup failure conditions are met, second system kernel data is loaded from the second kernel storage partition of the two kernel storage partitions, wherein the second kernel data includes second basic file system data; based on the loaded system kernel data, the operating system is started.

[0163] The methods disclosed in the embodiments of this application can be applied to or implemented by processor 1101. Processor 1101 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 1101 or by instructions in the form of software. The processor 1101 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 1102. Processor 1101 reads the information in memory 1102 and, in conjunction with its hardware, completes the steps of the above method.

[0164] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described above in this application, or combinations thereof.

[0165] For software implementation, the techniques described herein can be implemented by units that perform the functions described above. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or external to the processor.

[0166] The electronic device provided in this embodiment may be as follows: Figure 11 The electronic device shown can execute all the steps of the system backup and boot methods described above, thereby achieving the technical effects of the system backup and boot methods described above. For details, please refer to the relevant descriptions above. For the sake of brevity, it will not be elaborated here.

[0167] This application also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0168] When one or more programs in the storage medium can be executed by one or more processors to implement the system backup boot method described above that is executed on the electronic device side.

[0169] The processor described above is used to execute programs stored in memory to implement the following steps of a system backup boot method executed on the electronic device side:

[0170] In response to triggering the operating system startup, system boot data is loaded to enter the system boot state; a kernel flag is obtained from the storage area corresponding to the preset kernel load address; based on the kernel flag, it is determined whether the current operating system startup meets the startup failure conditions; if the startup failure conditions are not met, first system kernel data is loaded from the first kernel storage partition of the two preset kernel storage partitions, wherein the first kernel data includes first basic file system data; if the startup failure conditions are met, second system kernel data is loaded from the second kernel storage partition of the two kernel storage partitions, wherein the second kernel data includes second basic file system data; based on the loaded system kernel data, the operating system is started.

[0171] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0172] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0173] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0174] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A system backup boot method, characterized in that, The method includes: In response to triggering the operating system to start, load system boot data to enter the system boot state; Retrieve the kernel tag from the memory area corresponding to the preset kernel load address; Based on the kernel flags, determine whether the current operating system startup meets the startup failure conditions; If the boot failure conditions are not met, load the first system kernel data from the first kernel storage partition of the two preset kernel storage partitions, wherein the first system kernel data includes the first basic file system data; If the boot failure conditions are met, load the second system kernel data from the second kernel storage partition of the two kernel storage partitions, wherein the second system kernel data includes the second basic file system data; The operating system is started based on the loaded system kernel data.

2. The method according to claim 1, characterized in that, The method further includes: In response to triggering the operating system to start, start the system startup timer; The step of loading the first system kernel data from the first kernel storage partition of the two preset kernel storage partitions includes: In response to the startup timeout recorded by the startup timer, the operating system startup is retried, and the startup timeout count is incremented by one; In response to the successful startup of the operating system, the timeout count is set to zero.

3. The method according to claim 2, characterized in that, The process of determining whether the current operating system startup meets the startup failure conditions based on the kernel flag includes: Determine whether the kernel tag is consistent with the kernel tag included in the first system kernel data; If they do not match, it is determined that the current operating system startup does not meet the startup failure conditions. If they match, determine whether the number of startup timeouts has reached the preset number; If the preset number of times is reached, it is determined that the current operating system startup meets the startup failure conditions, and the startup timeout count is set to zero; If the preset number of attempts is not reached, the operating system startup is determined to fail to meet the startup failure conditions.

4. The method according to claim 1, characterized in that, The step of loading the first system kernel data from the first kernel storage partition of the two preset kernel storage partitions includes: Obtain the kernel index, and based on the kernel index, determine the kernel storage partition corresponding to the kernel index from the two kernel storage partitions as the first kernel storage partition, and load the first system kernel data in the first kernel storage partition; Loading the second system kernel data from the second kernel storage partition of the two kernel storage partitions includes: Adjust the kernel index from its initial value to its target value; Based on the target value, the kernel storage partition corresponding to the target value is determined from the two kernel storage partitions as the second kernel storage partition, and the second system kernel data in the second kernel storage partition is loaded.

5. The method according to claim 1, characterized in that, The loading of system boot data to enter the system boot startup state includes: Load system boot data from the preset system boot data partition to enter the system boot startup state.

6. The method according to claim 1, characterized in that, After the operating system is started based on the loaded system kernel data, the method further includes: Retrieve business data from a preset business data partition and load the business data to run the business program.

7. The method according to any one of claims 1-6, characterized in that, After the operating system is started based on the loaded system kernel data, the method further includes: In response to a system upgrade operation, receive upgrade package data; The upgrade package data is parsed to extract the kernel data to be upgraded; From the two kernel storage partitions, determine the initial kernel storage partition for storing the system kernel data before the upgrade, and the backup kernel storage partition for storing the kernel data to be upgraded; The kernel data to be upgraded is stored in the backup kernel storage partition, and the backup kernel storage partition is set as the partition used when the operating system starts.

8. The method according to claim 7, characterized in that, The step of determining, from the two kernel storage partitions, an initial kernel storage partition for storing the system kernel data before the upgrade, and a backup kernel storage partition for storing the kernel data to be upgraded, includes: Obtain the kernel index, and based on the kernel index, determine the initial kernel storage partition for storing the system kernel data before the upgrade, and the backup kernel storage partition for storing the kernel data to be upgraded, from the two kernel storage partitions; Setting the backup kernel storage partition as the partition used when the operating system boots includes: The value of the kernel index is adjusted from that corresponding to the initial kernel storage partition to that corresponding to the backup kernel storage partition.

9. The method according to claim 7, characterized in that, The step of parsing the upgrade package data and extracting the kernel data to be upgraded includes: Extract at least one type of data to be verified from the header data of the upgrade package data; Obtain the verification benchmark data corresponding to each of the at least one data to be verified; The at least one data to be verified and its corresponding verification benchmark data are verified to obtain the verification result. If the verification result indicates that the verification is successful, the target sub-package data containing the kernel data to be upgraded is determined from at least one set of sub-package data included in the upgrade package data; Extract the kernel data to be upgraded from the target sub-package data.

10. The method according to claim 7, characterized in that, After receiving upgrade package data in response to triggering a system upgrade operation, the method further includes: Exit all current business processes and unload the preset business data partition; The upgrade package data is parsed to extract business data, and the business data is stored in the business data partition.

11. The method according to claim 7, characterized in that, After receiving upgrade package data in response to triggering a system upgrade operation, the method further includes: The upgrade package data is parsed to extract system boot data; Determine whether the version of the system boot data is higher than the version of the original system boot data in the preset system boot data partition; If the version is higher than the original system boot data, the system boot data is stored in the system boot data partition.

12. A system backup boot device, characterized in that, The device includes: The first loading module is used to load system boot data in response to triggering the operating system to start, so as to enter the system boot state; The first acquisition module is used to acquire kernel markers from the storage area corresponding to the preset kernel load address; The first determining module is used to determine, based on the kernel flag, whether the current operating system startup meets the startup failure conditions; The second loading module is used to load first system kernel data from the first kernel storage partition of the two preset kernel storage partitions if the boot failure conditions are not met. The first system kernel data includes first basic file system data. The third loading module is used to load second system kernel data from the second kernel storage partition of the two kernel storage partitions if the boot failure conditions are met, wherein the second system kernel data includes second basic file system data; The startup module is used to start the operating system based on the loaded system kernel data.

13. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, it implements the system backup startup method according to any one of claims 1-11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the system backup startup method according to any one of claims 1-11.

Images