Embedded device starting method and embedded device
By using the switching mechanism of the main and spare Boot files and system files and CRC verification in embedded devices, the problem of increased storage costs in the existing technology is solved, efficient start-up and maintenance of the equipment is achieved, and the startup success rate is improved.
Patent Information
- Application Number
- CN202510383964.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-28
- Publication Date
- 2025-07-18
AI Technical Summary
The software backup solution for embedded devices in the prior art requires increasing the capacity or number of storage devices, resulting in an increase in storage costs and affecting the success rate of the device startup.
The switching mechanism between the main and backup Boot files and the main and backup system files is adopted, and the main and backup files are stored using different storage devices, and the file integrity is ensured through the CRC checksum repair mechanism to avoid simultaneous damage, so as to achieve successful startup without increasing the capacity or number of memory devices.
Without increasing storage costs, the startup success rate of embedded devices is improved, the possibility of software corruption is reduced, and the software maintenance workload is simplified.
Smart Images
Figure CN120336087A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of embedded devices, and particularly relates to a method for starting an embedded device and an embedded device. Background Art
[0002] The startup of an embedded device depends on the Boot file and the operating system file. The Boot file is used to prepare for the subsequent loading of the operating system file. After the operating system file is loaded, various functions of the embedded device can be completed.
[0003] In the related art, the embedded device uses a combination of multiple storage devices for software storage. The Boot file with a small occupied space and high reliability requirements is stored in a storage device with a high cost per unit capacity and a small maximum capacity, such as Flash (flash memory). The system file with a large occupied space and medium reliability requirements is stored in a storage device with a low cost per unit capacity and a large maximum capacity, such as EMMC (Embedded Multi Media Card). Thus, on the premise of meeting the reliability requirements, the storage cost is reduced.
[0004] During the use of the embedded device, the software often needs to be upgraded online. Power failure may occur during the upgrade process, and the storage device often performs write operations. Interference may occur during the write process. These factors may cause damage to the Boot file or the system file, affecting the normal startup of the embedded device.
[0005] Therefore, in the related art, the Boot file and the system file are also backed up. When the primary software is damaged, the backup software is switched to run, thereby improving the startup success rate of the embedded device. However, the currently commonly used software backup solutions either require increasing the capacity of the storage device or increasing the number of the same storage devices, both of which will significantly increase the storage cost of the embedded device. Summary of the Invention
[0006] This application provides a method for starting an embedded device and an embedded device, which can solve the technical problem that software backup in the related art significantly increases the storage cost of the embedded device.
[0007] In a first aspect, an embodiment of this application provides a method for starting an embedded device. The method for starting an embedded device includes:
[0008] Loading a target Boot file, where the default target Boot file after power-on is the primary Boot file. When the primary Boot file is damaged, the target Boot file is switched to the backup Boot file. The primary Boot file is stored in a first storage device, and the backup Boot file is stored in a second storage device;
[0009] Under the control of the target Boot file, the target operating system file is loaded. Among them, the default target operating system file after power-on is the main system file. When the main system file is damaged, the target operating system file is switched to the backup system file. The main system file and the backup system file are stored in the second storage device;
[0010] When the target operating system file is the backup system file, under the control of the backup system file, the network interface is initialized, the main system file is repaired through networking, the target operating system file is switched to the main system file, and the target Boot file is reloaded.
[0011] Further, in one embodiment, the method for starting the embedded device further includes:
[0012] When the target Boot file is the backup Boot file, under the control of the backup Boot file, the main Boot file is repaired based on the backup Boot file.
[0013] Further, in one embodiment, the method for starting the embedded device further includes:
[0014] When the target Boot file is the main Boot file, under the control of the main Boot file, a CRC check is performed on the backup Boot file: if the backup Boot file fails the CRC check, the backup Boot file is repaired based on the main Boot file.
[0015] Further, in one embodiment, the method for starting the embedded device further includes:
[0016] When the target operating system file is the main system file, under the control of the main system file, a CRC check is performed on the backup system file: if the backup system file fails the CRC check, the backup system file is repaired based on the main system file.
[0017] Further, in one embodiment, the backup Boot file, the main system file, and the backup system file are stored in different partitions of the second storage device.
[0018] Further, in one embodiment, the first storage device is Flash, and the second storage device is EMMC.
[0019] In a second aspect, an embodiment of the present application further provides an embedded device, including a CPLD, a CPU, a first storage device, and a second storage device. The first storage device is used to store the main Boot file, and the second storage device is used to store the backup Boot file, the main system file, and the backup system file;
[0020] The startup process of the embedded device includes:
[0021] The CPLD sets the startup source of the CPU to the first storage device, resets the CPU, and starts the first countdown;
[0022] If the CPU successfully loads the main Boot file, the CPU writes a success value to the first register under the control of the main Boot file. Before the CPU loads the main Boot file, the value of the first register is a failure value;
[0023] After the first countdown ends, the CPLD detects the value of the first register: if the value of the first register is a failure value, the CPLD sets the startup source of the CPU to the second storage device and resets the CPU;
[0024] If the CPU successfully loads the main Boot file or the backup Boot file, the CPU detects the value of the second register under the control of the main Boot file or the backup Boot file: if the value of the second register is a success value, the CPU writes a failure value to the second register, triggers the CPLD to start the second countdown, and loads the main system file; if the value of the second register is a failure value, the CPU loads the backup system file. The initial value of the second register is a success value;
[0025] If the CPU successfully loads the main system file, the CPU writes a success value to the second register under the control of the main system file;
[0026] After the second countdown ends, the CPLD detects the value of the second register: if the value of the second register is a failure value, the CPLD returns to the step of setting the startup source of the CPU to the first storage device, resetting the CPU, and starting the first countdown;
[0027] If the CPU successfully loads the backup system file, the CPU completes the network interface initialization under the control of the backup system file, repairs the main system file through the network, writes a success value to the second register, performs a self-reset, and returns to the step of setting the startup source of the CPU to the first storage device, resetting the CPU, and starting the first countdown.
[0028] Furthermore, in one embodiment, the startup process of the embedded device further includes:
[0029] If the CPU successfully loads the backup Boot file, the CPU repairs the main Boot file based on the backup Boot file under the control of the backup Boot file.
[0030] Furthermore, in one embodiment, the startup process of the embedded device further includes:
[0031] If the CPU successfully loads the main Boot file, the CPU performs a CRC check on the backup Boot file under the control of the main Boot file: if the backup Boot file fails the CRC check, the CPU repairs the backup Boot file based on the main Boot file.
[0032] Further, in one embodiment, the startup process of the embedded device further includes:
[0033] If the CPU successfully loads the main system file, the CPU performs a CRC check on the backup system file under the control of the main system file: if the backup system file fails the CRC check, the backup system file is repaired based on the main system file.
[0034] In this application, as long as either the main Boot file or the backup Boot file is normal, it can prepare for the subsequent loading of the operating system file and load the target operating system file. As long as either the main system file or the backup system file is normal, the successful loading of the main system file can be ultimately achieved to complete various functions of the embedded device. The main Boot file and the backup Boot file are similar in size, the function of the backup system file is simpler than that of the main system file, and the occupied space of the backup Boot file and the backup system file is much smaller than that of the main system file. Therefore, there is no need to increase the capacity of the storage device or the number of the same storage devices. Through this application, the startup success rate of the embedded device can be improved without increasing the storage cost. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] Figure 1 It is a schematic flowchart of the startup method of the embedded device in an embodiment of this application;
[0036] Figure 2 It is a hardware system block diagram of the startup method of the embedded device in an embodiment of this application;
[0037] Figure 3 It is a schematic flowchart of the startup method of the embedded device in another embodiment of this application;
[0038] Figure 4 is Figure 3 A schematic flowchart of the process of adding the main Boot file repair step;
[0039] Figure 5 is Figure 3 A schematic flowchart of the process of adding the backup Boot file repair step;
[0040] Figure 6 is Figure 3 A schematic flowchart of the process of adding the backup system file repair step. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0041] To enable those skilled in the art to better understand the solution of this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this application.
[0042] To make the purpose, technical solutions and advantages of this application clearer, the embodiments of this application will be further described in detail below in conjunction with the accompanying drawings.
[0043] In a first aspect, an embodiment of this application provides a method for starting an embedded device.
[0044] Figure 1 The flowchart of the method for starting an embedded device in an embodiment of this application is shown.
[0045] Referring to Figure 1 , in an embodiment, the method for starting an embedded device includes the following steps:
[0046] S1. Load the target Boot file. Among them, the default target Boot file after power-on is the main Boot file. When the main Boot file is damaged, the target Boot file is switched to the backup Boot file. The main Boot file is stored in the first storage device, and the backup Boot file is stored in the second storage device.
[0047] Specifically, when the embedded device enters step S1 for the first time after power-on, the target Boot file is the main Boot file. If the main Boot file is normal, it can directly enter step S2. If it is found that the operation defined by the main Boot file is not completed normally, it is determined that the main Boot file is damaged, and the target Boot file is switched to the backup Boot file, and then enter step S1 again.
[0048] Generally, the main Boot file and the backup Boot file will not be damaged at the same time. In this embodiment, the situation where both are damaged at the same time will not be discussed in detail. When the main Boot file is damaged, it is defaulted that the backup Boot file is normal. The operations defined by the main Boot file and the backup Boot file can both prepare for the subsequent loading of the operating system file. Therefore, after switching to the backup Boot file, it can enter step S2.
[0049] It can be understood that for the situation where the main Boot file and the backup Boot file are both damaged, new detection logic can be added to jump out of the loop.
[0050] S2. Under the control of the target Boot file, load the target operating system file. Among them, the default target operating system file after power-on is the main system file. When the main system file is damaged, the target operating system file is switched to the backup system file. The main system file and the backup system file are stored in the second storage device.
[0051] Specifically, when the embedded device enters step S2 for the first time after power-on, the target operating system file is the main system file. If the main system file is normal, various functions of the embedded device can be completed, and the startup process ends. If it is found that the operations defined by the main system file are not completed normally, it is determined that the main system file is damaged, and the target operating system file is switched to the backup system file, and then enter step S2 through step S1 again.
[0052] The main system file and the backup system file usually will not be damaged at the same time. This embodiment does not expand the discussion on the situation where both are damaged at the same time. When the main system file is damaged, it is assumed that the backup system file is normal, and step S3 can be entered.
[0053] It can be understood that for the situation where the main system file and the backup system file are damaged at the same time, detection logic can be added to jump out of the loop.
[0054] S3. When the target operating system file is the backup system file, under the control of the backup system file, complete the network interface initialization, connect to the network to repair the main system file, switch the target operating system file to the main system file, and reload the target Boot file. After the main system file is repaired and restored to normal, the startup process can end in step S2.
[0055] Specifically, the backup system file is used to enable the embedded device to complete the network interface initialization, connect to the network to repair the main system file, switch the target operating system file to the main system file, and re-enter step S1, without including other operations defined by the main system file.
[0056] Thus, in this embodiment, as long as either the main Boot file or the backup Boot file is normal, it can prepare for loading the operating system file subsequently and load the target operating system file. As long as either the main system file or the backup system file is normal, the successful loading of the main system file can be finally achieved, and various functions of the embedded device can be completed. The main Boot file and the backup Boot file are similar in size, the function of the backup system file is simpler than that of the main system file, and the occupied space of the backup Boot file and the backup system file is much smaller than that of the main system file. Therefore, there is no need to increase the capacity of the storage device or the number of the same storage devices. Through this embodiment, the startup success rate of the embedded device can be improved without increasing the storage cost.
[0057] Exemplarily, the size of the Boot file is generally within 1MB, the size of the backup system file can be controlled within 100MB, and the capacity of the EMMC for storing the main system file is generally 8GB or more. The newly added backup Boot file and backup system file have relatively little impact on the EMMC capacity, and there is no need to additionally increase the EMMC capacity or use multiple EMMC devices.
[0058] Further, in one embodiment, the method for starting the embedded device further includes:
[0059] When the target Boot file is the backup Boot file, under the control of the backup Boot file, the main Boot file is repaired based on the backup Boot file.
[0060] In this embodiment, when the target Boot file is the backup Boot file, it has been confirmed that the main Boot file is damaged. Since most of the content of the backup Boot file coincides with that of the main Boot file, the backup Boot file can copy this coincident content to the main Boot file to attempt to repair the main Boot file. Through this embodiment, the possibility of simultaneous damage to the main Boot file and the backup Boot file can be further reduced without increasing the software maintenance workload.
[0061] Further, the method for starting the embedded device further includes:
[0062] When the target Boot file is the main Boot file, under the control of the main Boot file, a CRC check (Cyclic Redundancy Check) is performed on the backup Boot file: if the backup Boot file fails the CRC check, the backup Boot file is repaired based on the main Boot file.
[0063] In this embodiment, when the target Boot file is the main Boot file, a CRC check is performed on the backup Boot file to detect whether the backup Boot file is damaged. Passing the CRC check indicates that the backup Boot file is normal, and failing the CRC check indicates that the backup Boot file is damaged. Since most of the content of the main Boot file coincides with that of the backup Boot file, the main Boot file can copy this coincident content to the backup Boot file to attempt to repair the backup Boot file. Through this embodiment, the possibility of simultaneous damage to the main Boot file and the backup Boot file can be further reduced without increasing the software maintenance workload.
[0064] Further, in one embodiment, the method for starting the embedded device further includes:
[0065] When the target operating system file is the main system file, under the control of the main system file, perform CRC check on the backup system file: if the backup system file fails the CRC check, repair the backup system file based on the main system file.
[0066] In this embodiment, when the target operating system file is the main system file, perform CRC check on the backup system file to detect whether the backup system file is damaged. Passing the CRC check indicates that the backup system file is normal, and failing the CRC check indicates that the backup system file is damaged. The relevant content about completing network interface initialization in the backup system file also exists in the main system file, and the main system file can copy these overlapping contents to the backup system file to attempt to repair the backup system file. Through this embodiment, the possibility of simultaneous damage to the main system file and the backup system file can be further reduced without increasing the software maintenance workload.
[0067] Further, in one embodiment, the backup Boot file, the main system file, and the backup system file are stored in different partitions of the second storage device.
[0068] In this embodiment, file damage in the storage device usually occurs by region. By storing in partitions, the possibility of simultaneous damage to the backup Boot file, the main system file, and the backup system file can be further reduced.
[0069] Further, in one embodiment, the first storage device is Flash, and the second storage device is EMMC.
[0070] Figure 2 The hardware system block diagram of the embedded device startup method in one embodiment of the present application is shown.
[0071] Refer to Figure 2 , the embedded device includes a CPLD (Complex Programmable Logic Device), a CPU, a Flash, and an EMMC. The CPLD starts working first after the embedded device is powered on. According to the pre-programmed logic configuration, it completes the initialization of some key hardware modules to prepare for the normal operation of the subsequent CPU and other hardware components. Other operations during the startup process of the embedded device are executed by the CPU under the control of the target Boot file and the target operating system file. The CPLD sets the startup source of the CPU and resets the CPU through GPIO (General Purpose Input Output) so that the CPU can find and load the Boot file from the storage device corresponding to the startup source. The CPU can read and write the values of the registers in the CPLD through the control bus to exchange the required information according to the values of the registers.
[0072] Flash is used as the first storage device to store the main Boot file, and EMMC is used as the second storage device to store the backup Boot file, the main system file, and the backup system file. EMMC has four default partitions, namely Boot1 partition, Boot2 partition, RPMB (Replay Protected Memory Block) partition, and user partition. The backup Boot file is stored through the Boot1 partition, and the user partition is further divided into P1 partition and P2 partition. The main system file is stored through the P1 partition, and the backup system file is stored through the P2 partition. The embedded device is interconnected with the master device or the host computer through a PHY (Physical Layer) network interface, so that the embedded device can obtain software packages from the master device or the host computer to repair the main system file.
[0073] In a second aspect, an embodiment of the present application further provides an embedded device.
[0074] In one embodiment, the embedded device includes a CPLD, a CPU, a first storage device, and a second storage device. The first storage device is used to store the main Boot file, and the second storage device is used to store the backup Boot file, the main system file, and the backup system file;
[0075] The startup process of the embedded device includes:
[0076] The CPLD sets the startup source of the CPU to the first storage device, resets the CPU, and starts the first countdown;
[0077] If the CPU successfully loads the main Boot file, the CPU writes a success value to the first register under the control of the main Boot file. Before the CPU loads the main Boot file, the value of the first register is a failure value;
[0078] After the first countdown ends, the CPLD detects the value of the first register: if the value of the first register is a failure value, the CPLD sets the startup source of the CPU to the second storage device and resets the CPU;
[0079] If the CPU successfully loads the main Boot file or the backup Boot file, the CPU detects the value of the second register under the control of the main Boot file or the backup Boot file: if the value of the second register is a success value, the CPU writes a failure value to the second register, triggers the CPLD to start the second countdown, and loads the main system file; if the value of the second register is a failure value, the backup system file is loaded, where the initial value of the second register is a success value;
[0080] If the CPU successfully loads the main system file, the CPU writes a success value to the second register under the control of the main system file;
[0081] After the second countdown ends, the CPLD detects the value of the second register: If the value of the second register is a failure value, return the step where the CPLD sets the startup source of the CPU to the first storage device, resets the CPU, and starts the first countdown;
[0082] If the CPU successfully loads the backup system file, under the control of the backup system file, the CPU completes network interface initialization, repairs the main system file through the network, writes a success value to the second register, performs a self-reset, and returns the step where the CPLD sets the startup source of the CPU to the first storage device, resets the CPU, and starts the first countdown.
[0083] Specifically, the first register is used to inform the CPLD whether the main Boot file is damaged after the CPU loads the main Boot file, so as to determine whether to switch the target Boot file to the backup Boot file. The second register is used to inform the CPU whether the main system file is damaged before the CPU loads the target operating system file, so as to determine whether to use the main system file or the backup system file as the target operating system file. The second register is also used to inform the CPLD whether the main system file is damaged after the CPU loads the main system file, so as to determine whether to switch the target operating system file to the backup system file. A success value of the register represents that the corresponding file is normal, and a failure value represents that the corresponding file is damaged.
[0084] Through this embodiment, after the embedded device is powered on, by default, the CPU sequentially loads the main Boot file and the main system file. When the CPU successfully loads the main Boot file and the main system file, the CPLD does not perform additional interference. When the CPU fails to load the main Boot file or the main system file, the CPLD can reset the CPU and re-boot the CPU to load the backup Boot file or the backup system file.
[0085] Figure 3 The flowchart of the startup method of the embedded device in another embodiment of the present application is shown.
[0086] Refer to Figure 3 , the startup process of the embedded device includes:
[0087] S101. After the embedded device is powered on, the CPLD writes a failure value to the first register, writes a success value to the second register, and enters step S102.
[0088] It should be noted that the most basic requirements for the first register and the second register are: the value of the first register is a failure value before the CPU loads the main Boot file, and the initial value of the second register is a success value.
[0089] Step S101 is an optional implementation, but not the only one. For example, the CPLD can write a failure value to the first register before setting the CPU's startup source to the first storage device, and write a success value to the second register when the CPU first detects the value of the second register.
[0090] S102. The CPLD sets the CPU's startup source to the first storage device, resets the CPU, and starts the first countdown. If the main Boot file is normal, it proceeds to step S103a; if the main Boot file is corrupted, it proceeds to step S103b.
[0091] Exemplarily, starting the first countdown is to set the watchdog for a 20s countdown.
[0092] S103a. The CPU successfully loads the main Boot file. Under the control of the main Boot file, the CPU writes a success value to the first register and proceeds to step S104.
[0093] S103b. The CPU fails to load the main Boot file and does not write a success value to the first register, then proceeds to step S104.
[0094] S104. After the first countdown ends, the CPLD detects the value of the first register. If it proceeds to step S104 from step S103a, the CPLD will detect that the value of the first register is a success value, indicating that the CPU has successfully loaded the main Boot file and confirming that the main Boot file is normal, then proceeds to step S105. If it proceeds to step S104 from step S103b, the CPLD will detect that the value of the first register is a failure value, indicating that the CPU has failed to load the main Boot file and confirming that the main Boot file is corrupted, then proceeds to step S106.
[0095] S105. The CPLD writes a failure value to the first register and proceeds to step S108.
[0096] It should be noted that the purpose of the CPLD writing a failure value to the first register is to ensure that after the main system file is corrupted and returns to step S102 from the subsequent steps, the first register can play the same role. Assuming that the value of the first register is still a success value when re - entering step S102, then even if the main Boot file is corrupted, the CPLD will detect that the value of the first register is a success value in step S104 and cannot know that the CPU has failed to load the main Boot file, resulting in a startup failure.
[0097] Step S105 is an optional implementation, but not the only one. For example, the CPLD can write a failure value to the first register after detecting that the value of the second register is a failure value at the end of the second countdown, that is, Figure 3Add a step where the CPLD writes a failure value to the first register between steps S111 and S102. For another example, after successfully loading the backup system file, the CPU can write a failure value to the first register under the control of the backup Boot file.
[0098] S106. The CPLD sets the startup source of the CPU to the second storage device, resets the CPU, and enters step S107.
[0099] S107. The CPU successfully loads the backup Boot file and enters step S108.
[0100] It should be noted that Figure 3 the relevant branches for the CPU to fail to load the backup Boot file are not shown and can be added as needed.
[0101] S108. Under the control of the main Boot file or the backup Boot file, the CPU detects the value of the second register. If the CPU detects that the value of the second register is a success value, it determines that the main system file is normal and enters step S109. If the CPU detects that the value of the second register is a failure value, it determines that the main system file is damaged and enters step S112.
[0102] Specifically, if entering step S108 from step S105, the CPU executes steps S108, S109, and S112 under the control of the main Boot file. If entering step S108 from step S107, the CPU executes steps S108, S109, and S112 under the control of the backup Boot file.
[0103] It can be understood that before the CPU loads the main system file, it is impossible to determine whether the main system file is normal. First, assume that the main system file is normal and set the initial value of the second register to the success value. That is, if entering step S108 from step S101 for the first time, the CPU will detect that the value of the second register is the success value and enter step S109.
[0104] S109. Under the control of the main Boot file or the backup Boot file, the CPU writes a failure value to the second register, triggers the CPLD to start the second countdown, and loads the main system file. If the main system file is normal, it enters step S110a. If the main system file is damaged, it enters step S110b.
[0105] Exemplarily, starting the second countdown is to set the watchdog for a 300s countdown.
[0106] S110a. The CPU successfully loads the main system file and writes a success value to the second register under the control of the main system file, then enters step S111.
[0107] S110b. The CPU fails to load the main system file and does not write a success value to the second register, then proceed to step S111.
[0108] S111. After the second countdown ends, the CPLD detects the value of the second register. If it enters step S111 from step S110a, the CPLD will detect that the value of the second register is the success value, indicating that the CPU has successfully loaded the main system file, confirming that the main system file is normal, and the device startup is completed, then end the process. If it enters step S111 from step S110b, the CPLD will detect that the value of the second register is the failure value, indicating that the CPU has failed to load the main system file, confirming that the main system file is damaged, and then return to step S102.
[0109] It can be understood that if it returns from step S111 to step S102 and enters step S108 again, the CPU will detect that the value of the second register is the failure value and enter step S112.
[0110] S112. Under the control of the main Boot file or the backup Boot file, the CPU loads the backup system file and enters step S113.
[0111] It should be noted that Figure 3 the relevant branch for the CPU to fail to load the backup system file is not shown in the figure and can be added as needed.
[0112] S113. If the CPU successfully loads the backup system file, under the control of the backup system file, it completes the network interface initialization, repairs the main system file through networking, writes a success value to the second register, performs a self-reset, and returns to step S102.
[0113] It should be noted that the purpose of the CPU performing a self-reset in step S113 is to relinquish control to ensure the smooth progress of step S102. In step S111, when the CPU fails to load the main system file and the control right is not occupied, it can directly return to step S102. When the CPLD detects that the value of the second register is the failure value, it can also reset the CPU first and then return to step S102.
[0114] It can be understood that if it returns from step S113 to step S102 and enters step S108 again, the CPU will detect that the value of the second register is the success value and enter step S109.
[0115] Furthermore, in one embodiment, the startup process of the embedded device further includes:
[0116] If the CPU successfully loads the backup Boot file, then under the control of the backup Boot file, the CPU repairs the main Boot file based on the backup Boot file.
[0117] The analysis of this embodiment refers to the foregoing text.
[0118] Figure 4 shows Figure 3 a schematic flowchart of the steps for repairing the main Boot file added.
[0119] Referring to Figure 4 , between step S107 and step S108, add step S201 for repairing the main Boot file, which is specifically as follows:
[0120] S107. The CPU successfully loads the backup Boot file and enters step S201.
[0121] S201. Under the control of the backup Boot file, the CPU repairs the main Boot file based on the backup Boot file and enters step S108.
[0122] Furthermore, in one embodiment, the startup process of the embedded device further includes:
[0123] If the CPU successfully loads the main Boot file, the CPU performs a CRC check on the backup Boot file under the control of the main Boot file: if the backup Boot file fails the CRC check, the backup Boot file is repaired based on the main Boot file.
[0124] The analysis of this embodiment refers to the foregoing text.
[0125] Figure 5 shows Figure 3 a schematic flowchart of the steps for repairing the backup Boot file added.
[0126] Referring to Figure 5 , between step S103a and step S104, add steps S202, S203a, and S203b for repairing the backup Boot file, which are specifically as follows:
[0127] S103a. The CPU successfully loads the main Boot file. Under the control of the main Boot file, the CPU writes a success value to the first register and enters step S202.
[0128] S202. Under the control of the main Boot file, the CPU performs a CRC check on the backup Boot file. If the backup Boot file is normal, it enters step S203a; if the backup Boot file is damaged, it enters step S203b.
[0129] S203a. The backup Boot file passes the CRC check. The CPU confirms that the backup Boot file is normal and enters step S104.
[0130] S203a. The backup Boot file fails the CRC check. The CPU confirms that the backup Boot file is corrupted. Under the control of the main Boot file, the backup Boot file is repaired based on the main Boot file, and step S104 is entered.
[0131] Further, in one embodiment, the startup process of the embedded device further includes:
[0132] If the CPU successfully loads the main system file, the CPU performs a CRC check on the backup system file under the control of the main system file: If the backup system file fails the CRC check, the backup system file is repaired based on the main system file.
[0133] The analysis of this embodiment refers to the foregoing.
[0134] Figure 6 Shows Figure 3 The flow diagram of adding the step of repairing the backup system file.
[0135] Refer to Figure 5 , between step S110a and step S111, add steps S204, S205a, and S205b for repairing the backup system file, specifically as follows:
[0136] S110a. The CPU successfully loads the main system file. Under the control of the main system file, a success value is written to the second register, and step S204 is entered.
[0137] S204. The CPU performs a CRC check on the backup system file under the control of the main system file. If the backup system file is normal, step S205a is entered. If the backup system file is corrupted, step S205b is entered.
[0138] S205a. The backup system file passes the CRC check. The CPU confirms that the backup system file is normal, and step S111 is entered.
[0139] S205a. The backup system file fails the CRC check. The CPU confirms that the backup system file is corrupted. Under the control of the main system file, the backup system file is repaired based on the main system file, and step S111 is entered.
[0140] It should be noted that the serial numbers of the embodiments of the present application above are only for description and do not represent the advantages or disadvantages of the embodiments.
[0141] In the description of the specification, claims and the above-mentioned drawings of this application, the terms "comprising", "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products or devices. Descriptions such as "first", "second", and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit that "first", "second", and "third" are different types.
[0142] In the description of the embodiments of this application, terms such as "exemplary", "for example" or "for instance" are used to indicate examples, illustrations or explanations. Any embodiment or design solution described as "exemplary", "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary", "for example" or "for instance" is intended to present the relevant concepts in a specific manner.
[0143] In the description of the embodiments of this application, unless otherwise specified, " / " means "or". For example, A / B can mean A or B; "and / or" in the text is merely a description of the association relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "a plurality of" means two or more than two.
[0144] In some processes described in the embodiments of this application, there are multiple operations or steps that appear in a specific order. However, it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of this application or may be executed in parallel. The serial numbers of the operations are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.
[0145] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-described embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium as described above (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions for causing a terminal device to execute the methods described in various embodiments of this application.
[0146] The above are only the preferred embodiments of the present application, and do not limit the patent scope of the present application accordingly. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, shall be similarly included in the patent protection scope of the present application.
Claims
1. An embedded device startup method, characterized in that, The described method for starting an embedded device includes: Loading a target Boot file. Among them, the default target Boot file after power-on is the main Boot file. When the main Boot file is damaged, the target Boot file switches to the backup Boot file. The main Boot file is stored in the first storage device, and the backup Boot file is stored in the second storage device; Under the control of the target Boot file, loading the target operating system file. Among them, the default target operating system file after power-on is the main system file. When the main system file is damaged, the target operating system file switches to the backup system file. The main system file and the backup system file are stored in the second storage device; When the target operating system file is the backup system file, under the control of the backup system file, complete the network interface initialization, connect to the network to repair the main system file, switch the target operating system file to the main system file, and reload the target Boot file.
2. The embedded device startup method according to claim 1, wherein The described method for starting an embedded device further includes: When the target Boot file is the backup Boot file, under the control of the backup Boot file, repair the main Boot file based on the backup Boot file.
3. The embedded device startup method according to claim 1, characterized in that, The described method for starting an embedded device further includes: When the target Boot file is the main Boot file, under the control of the main Boot file, perform a CRC check on the backup Boot file: If the backup Boot file fails the CRC check, repair the backup Boot file based on the main Boot file.
4. The embedded device startup method according to claim 1, characterized in that, The described method for starting an embedded device further includes: When the target operating system file is the main system file, under the control of the main system file, perform a CRC check on the backup system file: If the backup system file fails the CRC check, repair the backup system file based on the main system file.
5. The embedded device startup method according to any one of claims 1 to 4, characterized in that, The backup Boot file, the main system file, and the backup system file are stored in different partitions of the second storage device.
6. The embedded device startup method according to any one of claims 1 to 4, characterized in that, The first storage device is Flash, and the second storage device is EMMC.
7. An embedded device, characterized in that, It includes a CPLD, a CPU, a first storage device, and a second storage device. The first storage device is used to store the main Boot file, and the second storage device is used to store the backup Boot file, the main system file, and the backup system file; The startup process of the embedded device includes: The CPLD sets the startup source of the CPU to the first storage device, resets the CPU, and starts the first countdown; If the CPU successfully loads the main Boot file, the CPU writes a success value to the first register under the control of the main Boot file. Among them, before the CPU loads the main Boot file, the value of the first register is a failure value; After the first countdown ends, the CPLD detects the value of the first register: If the value of the first register is a failure value, set the startup source of the CPU to the second storage device and reset the CPU; If the CPU successfully loads the primary Boot file or the secondary Boot file, the CPU, under the control of the primary Boot file or the secondary Boot file, checks the value of the second register: If the value of the second register is the success value, write the failure value to the second register, trigger the CPLD to start the second countdown, and load the primary system file; If the value of the second register is the failure value, load the secondary system file, where the initial value of the second register is the success value; If the CPU successfully loads the primary system file, the CPU, under the control of the primary system file, writes the success value to the second register; After the second countdown ends, the CPLD checks the value of the second register: If the value of the second register is the failure value, return to the step where the CPLD sets the CPU's boot source to the first storage device, resets the CPU, and starts the first countdown; If the CPU successfully loads the secondary system file, the CPU, under the control of the secondary system file, completes the network interface initialization, repairs the primary system file through networking, writes the success value to the second register, performs a self-reset, and returns to the step where the CPLD sets the CPU's boot source to the first storage device, resets the CPU, and starts the first countdown.
8. The embedded device according to claim 7, wherein The startup process of the embedded device further includes: If the CPU successfully loads the secondary Boot file, the CPU, under the control of the secondary Boot file, repairs the primary Boot file based on the secondary Boot file.
9. The embedded device according to claim 7, wherein The startup process of the embedded device further includes: If the CPU successfully loads the primary Boot file, the CPU, under the control of the primary Boot file, performs a CRC check on the secondary Boot file: If the secondary Boot file fails the CRC check, repair the secondary Boot file based on the primary Boot file.
10. The embedded device according to claim 7, wherein The startup process of the embedded device further includes: If the CPU successfully loads the primary system file, the CPU, under the control of the primary system file, performs a CRC check on the secondary system file: If the secondary system file fails the CRC check, repair the secondary system file based on the primary system file.